Почему AI-пилот не доходит до прода: 6 разрывов

TL;DR: Большинство AI-пилотов умирают не на демо, а на переходе в продакшн. Причина одна: пилот тестировали в вакууме, на подчищенных данных и без стыка с реальными процессами. Ниже шесть типичных разрывов, на которых гибнут проекты, чек-лист gate-критериев «пилот готов к проду» и пороги, при которых стоп лучше, чем запуск.

Я шесть лет разбираю цифровые проекты в среднем бизнесе, и за последние два года AI-пилоты стали отдельным жанром. Устроен он так: на демо всё блестит, через квартал проекта нет. CEO смотрит на закрытый пилот и заключает, что «AI ещё сырой». Сырым был не AI, сырым был переход между демо и эксплуатацией.

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

Разрыв первый: данные подчистили руками

Самая частая причина смерти. Чтобы пилот заработал к демо, аналитик берёт выгрузку, вычищает дубли, приводит даты к одному формату, дописывает пропущенные ИНН, выкидывает строки с битыми статусами. На вылизанной выборке модель отвечает почти без ошибок. Все аплодируют.

В проде данные приходят сырыми: те же дубли, те же битые статусы, те же три формата даты в одном поле. Доля верных ответов проседает примерно на треть (по разборам, что я вёл, точность падала с уровня демо до состояния, когда пользователи перестают доверять системе за неделю). Откатить нельзя: ручную чистку никто не заложил в стоимость эксплуатации, потому что на пилоте её делал один человек за два вечера.

Проверка простая: спросите, на каких данных крутился пилот. Если ответ «мы подготовили выборку», у вас не пилот, а демо-ролик. Настоящий пилот ест то же, что будет есть прод: грязный поток из системы-источника, без человека-санитара на входе.

Разрыв второй: у прода нет владельца

На пилоте владелец всегда есть. Это энтузиаст, который притащил идею, ночами правил промпты и лично показывал результат совету директоров. Пока он горит, пилот живёт.

Прод требует другого. Кто-то должен отвечать за то, что агент работает в понедельник в 9 утра, что метрика не просела, что после обновления CRM ничего не сломалось. Это рутина, а не подвиг. И вот тут выясняется, что энтузиаст хотел сделать прорыв, а не дежурить по системе. В KPI эта система не стоит ни у кого, она ничья.

Ничьи системы умирают первыми. Не от поломки умирают, а от того, что первую же поломку никто не чинит. Заявка висит, пользователи возвращаются к старому процессу, через месяц про агента забывают. На бумаге проект «в эксплуатации», в реальности им никто не пользуется.

Разрыв третий: нет интеграции с системами-источниками

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

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

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

Разрыв четвёртый: метрика успеха не привязана к P&L

«Сотрудникам стало удобнее» не считается результатом. «Модель отвечает за 3 секунды» не считается тоже. Это технические метрики, под них CFO бюджет не продлевает.

Считается другое: «среднее время от обращения клиента до ответа сократилось с 4 часов до 35 минут, экономия 280 тысяч ₽/мес на ФОТ поддержки». Это метрика, которую видно в P&L. По ней принимают решение о продлении.

Когда метрика техническая, происходит вот что. Пилот закрывается, приходит время защищать бюджет на прод, и владелец не может ответить на вопрос «сколько мы на этом заработали». А для CFO «не могу посчитать» читается как «ноль». Проект закрывают, хотя технически он работал. Метрику привязывают к деньгам до старта, искать её постфактум поздно.

Разрыв пятый: не учли человека на стыке

AI редко работает в полном автомате. Чаще он готовит черновик, а человек проверяет и отправляет. Или агент эскалирует сложный случай оператору. На пилоте этот человек был частью команды, мотивированным и обученным. В проде это рядовой сотрудник, у которого своя работа, и проверка AI-черновиков для него лишняя нагрузка.

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

Человек на стыке между AI и результатом должен иметь понятную роль: что он проверяет, по какому правилу, сколько времени это занимает и зачем ему это в его KPI. Без этого вы автоматизировали не процесс, а его половину, и вторая половина теперь узкое место.

Разрыв шестой: нет плана сопровождения

Модель деградирует. Меняются данные, меняются формулировки клиентов, выходит новая версия CRM с другим API, регулятор обновляет требования по 152-ФЗ. AI-система без сопровождения медленно теряет качество, и никто этого не замечает, пока точность не упадёт до уровня, на котором пользователи бунтуют.

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

Чек-лист gate-критериев: пилот готов к проду

Перед тем как переводить пилот в эксплуатацию, прогоните его по семи воротам. Каждые ворота либо открыты, либо закрыты, без полутонов.

1. Данные. Пилот работал на сыром потоке из системы-источника, без ручной чистки. Если данные готовили руками, ворота закрыты.
2. Владелец прода. Назначен человек, у которого работа системы стоит в KPI. Не энтузиаст-инициатор, а тот, кто дежурит по понедельникам.
3. Интеграция. Подключение к CRM или ERP работает на пилоте, а не запланировано на «второй этап».
4. Метрика в P&L. Зафиксирован эффект в часах и рублях на горизонте 90 дней. Технические метрики не считаются.
5. Человек на стыке. Описана роль проверяющего: что проверяет, по какому правилу, сколько времени, зачем ему это в KPI.
6. План сопровождения. Есть ответ, кто смотрит на метрику, что делает при просадке и какой бюджет на год.
7. Стык. Вы знаете, на каком стыке стоит AI, его тип и цену в рублях в месяц. Если стык не назван, пилот стоит на удобном кейсе, а не на дорогом.

Пороги для решения. Шесть и семь открытых ворот: запускайте прод. Четыре или пять: достройте недостающее (две-три недели работы), сейчас не запускайте. Три и меньше: остановитесь. Перед вами не пилот, готовый к продакшну, а демо, выдавшее результат в тепличных условиях. Перевод в прод сожжёт бюджет и оставит у CEO ложный вывод, что AI не работает.

Анонимный кейс: дистрибьютор, 340 сотрудников

Компания (дистрибуция стройматериалов, выручка около 4 млрд ₽/год) запустила AI-помощника для отдела продаж: бот формировал коммерческие предложения по запросу менеджера. Пилот за два месяца показал экономию двух часов в неделю на менеджера. Совет директоров утвердил масштабирование.

На проде проект встал на трёх разрывах сразу. Первый: на пилоте номенклатуру и цены подгружали вручную выверенной выгрузкой, а в реальности прайс менялся ежедневно и приходил в трёх форматах от разных поставщиков. Второй: интеграции с 1С не было, менеджеры копировали КП руками, и экономия времени обнулилась. Третий: владельцем был руководитель проектного офиса, у которого в KPI продажи не стояли, а у РОПа эта система не стояла нигде.

Прямые потери: 5,2 млн ₽ на пилот и доработки за полгода, эффект в P&L нулевой. Когда мы разобрали проект по картам, выяснилось, что самый дорогой стык был не «менеджер пишет КП», а «согласование цены между продажами и закупками»: заявки зависали там в среднем на 1,7 дня, и это стоило компании около 2,1 млн ₽/мес упущенной маржи на просроченных сделках. AI просто посадили не на тот стык. Пересобрали: перевели агента на согласование цены, привязали к сквозной метрике скорости сделки, назначили владельцем коммерческого директора. Через квартал время согласования упало с 1,7 дня до 4 часов, прибавка к марже около 1,4 млн ₽/мес. Движок остался тот же, поменялось только место, на которое его поставили, и стык под ним был назван и оцифрован заранее.

FAQ

Чем демо отличается от настоящего пилота? Демо показывает, что технология в принципе работает, обычно на подготовленных данных и в изоляции. Пилот проверяет, что решение работает на реальном потоке данных, на конкретном стыке процесса, с замером эффекта в рублях. Если ваш «пилот» крутился на выверенной выборке, это демо.

Сколько обычно стоит провал перехода пилот→прод? По разборам в среднем бизнесе прямые затраты на умерший пилот это 4–8 млн ₽, плюс косвенные (внимание команды, отвлечение CIO) в два-три раза больше. Но дороже денег обходится ложный вывод «AI не работает»: компания на год замораживает направление, на котором конкуренты в это время выигрывают.

Можно ли спасти пилот, который уже встал перед продом? Часто да, если причина в разрыве, а не в самой модели. Сначала надо понять, на каком из шести разрывов он встал. Если AI поставили не на тот стык (частый случай), пилот пересобирают на правильный переход, и тот же движок начинает давать эффект.

Что важнее для успеха: модель или процесс? Процесс. По нашим разборам живучие пилоты отличаются не вендором и не моделью, а тем, что компания заранее знала свои стыки, их цену в рублях и посадила AI на самый дорогой переход под бизнес-метрику с явным владельцем.

С чего начать, если пилота ещё нет? С карты сквозного процесса с цифрами потерь напротив каждой передачи между отделами. Это две-три недели работы, и она переставляет приоритеты: самый удобный для AI кейс почти никогда не совпадает с самым дорогим стыком.

Что дальше

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

• Методика, по которой считается цена каждого стыка в рублях: «Стыки дороже систем».
• Как строится карта сквозного процесса с цифрами потерь: карта бизнес-процессов.
• Быстрая оценка потерь на стыках между отделами: калькулятор.
• Пилот с фиксацией gate-критериев и метрики в P&L до старта: услуга пилота.
• Кто следит за качеством ответов и интеграциями после запуска: поддержка ИИ-проектов.