Ошибка масштабирования AI: почему удачный пилот ломается в продакшене

Ошибка масштабирования AI: почему удачный пилот ломается в продакшене

Самая дорогая фраза в AI-проекте звучит так: «На демо же работало».

Работало. Пока у системы была одна задача, несколько понятных кейсов и сильный человек рядом. Он видел, где модель не поняла контекст, где уверенно соврала, где полезла не туда. Поправлял. Пилот выглядел убедительно.

Потом системе дали доступ менеджерам, CRM, клиентам, коду. Ошибки остались примерно теми же. Просто теперь они поехали по конвейеру.

И кажется, что AI внезапно стал хуже.

Нет. Система вышла из своего окна возможностей.

Кузнечик высоко прыгает не потому, что нашёл секрет вечного двигателя. Он маленький. Увеличь его до размера человека, и прежняя механика перестанет работать: масса растёт иначе, чем сила его ножек.

С AI та же история. У каждой системы есть предел, в котором она полезна. Ошибка начинается, когда успех внутри этого предела принимают за разрешение раскатывать всё на всех.

Пилот не равен продакшену

На малом объёме ручная коррекция терпима.

AI составил договор, юрист посмотрел.
AI разобрал заявку, менеджер поправил. AI написал кусок кода, разработчик провёл ревью. Ошибка не исчезла, но её поймали внутри короткого контура.

Потом поток растёт.
Ручная коррекция превращается в скрытый отдел контроля качества. Люди уже не получают усиление от системы.
Они разгребают ошибки, которые эта система успела размазать по процессу.

Пилот всё равно нужен. Он отвечает на узкий вопрос: может ли модель дать пользу в конкретной задаче, на конкретных данных и рядом с конкретным человеком?

Но он не отвечает на другой вопрос: готов ли процесс к тиражированию?

Перед масштабированием полезно перестать спрашивать «работает ли AI?».

Смотрите на другое:

- какие ошибки он уже делает; - как далеко каждая ошибка успеет уйти до обнаружения; - сколько стоит её исправить; - кто заметит её в реальном потоке; - что произойдёт, если никто не заметит.

Вот там и прячется разница между удачным демо и рабочим продуктом.

На масштабе меняется экономика

Один удачный запрос почти всегда выглядит дёшево. Особенно если считать только токены.

В реальной системе появляются повторные прогоны, лишний контекст, интеграции, очереди, мониторинг, доступы, поддержка, разбор инцидентов и цена плохого решения. Появляются люди, которым надо объяснять, почему система сделала именно это и как откатить её действие.

На малом объёме это шум. На большом объёме это и есть экономика продукта.

Поэтому спор «облачный API или свои сервера» часто начинается слишком рано. Сначала надо измерить нагрузку, повторяемость задач, цену ошибки и долю запросов, которые реально можно стандартизировать.

Иначе вы сравниваете две красивые гипотезы, а не два варианта работающей системы.

Открытые веса не делают инференс бесплатным. Хорошее демо не делает операционный контур дешёвым.

У зрелой команды есть хотя бы простая карта: сколько стоит запрос, сколько стоит его повторить, сколько времени человек тратит на разбор исключения, какие действия необратимы. Без неё разговор об инфраструктуре быстро превращается в выбор любимой железки.

Когда AI начинает управлять, задача меняется

Пока AI помогает сильному специалисту, это инструмент. Человек держит контекст, видит исключение и отвечает за решение.

Когда система сама меняет статус сделки, отправляет письмо, платит подрядчику, влияет на приоритеты команды или пишет код в общий контур, она становится частью системы управления.

Тогда ей нужны права, ограничения, журнал действий, обратимость и понятный владелец ошибки. Иначе «автономность» оказывается красивым названием для отсутствия контроля.

Есть ещё одна ловушка. Человеческую проверку нельзя просто нанять и размножить. На потоке человек привыкает к обычно правильной системе и начинает пропускать её ошибки.

Масштабировать надо не ручной review. Масштабировать надо контур проверки.

Какие действия агент вообще имеет право делать? Что требует подтверждения? Что можно откатить? Где он обязан остановиться и передать задачу человеку? По какому сигналу команда понимает, что система вывалилась за границы своего окна?

Это не бюрократия вокруг AI. Это его скелет.

Что проверить до масштабирования

Перед тем как расширять пилот, соберите короткую карточку решения.

Задача. Что именно делает AI и что он не делает.

Граница самостоятельности. Какие действия разрешены без человека, а какие всегда требуют подтверждения.

Ошибки. Какие случаи встретились на пилоте, какие данные в него не попали и как система распознает новые.

Экономика. Стоимость обычного запроса, повторного прогона, ручной проверки и исправления ошибки.

Откат. Можно ли отменить действие, вернуть запись, остановить цепочку, отключить инструмент без остановки всего процесса.

Владелец. Кто отвечает за качество входных данных, правила работы, наблюдение за ошибками и решение остановить масштабирование.

Смысл этой карточки простой: она превращает «давайте раскатим агент» в проверяемую гипотезу с границами.

AI часто продают как двигатель роста. Но сначала стоит спросить: для какого веса, на какой дистанции и в какой среде этот двигатель рассчитан?

Пилот показал возможность. Продакшен должен доказать управляемость.

В телеграм-канале @gorilla_under_hood разбираю, где AI реально усиливает бизнес, а где красивое демо тихо становится дорогим отделом по разбору собственных ошибок.

11