Почему 80% AI-пилотов не доходят до прода — и что с этим делать

Есть цифра, которую любят повторять на конференциях: из десяти AI-пилотов в продакшен выходит максимум два. В разных отчётах она колеблется между 70% и 88% «непрошедших», но порядок один и тот же. RAND в своём исследовании 2024 года ставит планку «более 80%». Gartner в обзоре AI Hype Cycle 2025 называет «through 2026, 60% AI projects will be abandoned». MIT Sloan в опросе CIO даёт похожие 70–75%.

Цифра не про то, что AI не работает. Она про то, что большинство компаний делают пилоты так, что они не имеют шанса дойти до прода с самого начала. Разбираем семь главных причин — и что с каждой можно сделать.

Причина 1. Пилот делается без бизнес-вопроса

Самая частая формулировка задачи на старте: «нам нужен PoC, чтобы посмотреть, что AI может». Это не задача — это любопытство.

PoC с такой постановкой даёт ровно один результат: красивую демку на 10 вручную выбранных примерах. CFO эта демка ничего не говорит. Технического директора — тоже. Никто не понимает, что значит «успех» или «провал» этого пилота. В итоге проект тихо умирает после демонстрации, потому что никто не может сказать «давайте идём дальше».

Что делать. Любой пилот должен начинаться с вопроса вида: «Если AI закроет N% типовых обращений в саппорте с качеством не ниже X, мы сэкономим Y и расширим до полноценного внедрения». Здесь N, X и Y — конкретные числа, согласованные с заказчиком до начала работ.

«Если вы не можете сформулировать критерий успеха одним предложением — пилот не нужен» — общая формулировка из методичек McKinsey по AI-программам, перекликается с подходом BCG в их серии материалов про AI ROI.

Причина 2. Данные оказываются мусором

Это становится понятно через 2–3 недели после старта, когда команда впервые садится смотреть, что вообще есть.

Типичные сюрпризы:

• Половина диалогов с клиентами хранится в скриншотах в Telegram.
• CRM ведётся неконсистентно: один менеджер заполняет поля, другой пишет всё в комментарии.
• Документы лежат в виде сканов с пометками от руки — OCR на них даёт 30% точность.
• «База знаний» — это PDF, выгруженный из Confluence три года назад.

Любой ML-инженер скажет: качество модели редко превышает качество данных. Если корпус для обучения и тестирования собран на коленке — итоговое качество тоже будет на коленке. И уже на этом этапе пилот фактически закрыт, просто формально его ещё ведут до конца.

Что делать. До любого PoC проводить аудит данных. Это 1–2 недели работы, в результате которой появляется честный ответ: данные есть и они пригодны / данные есть, но нужно 2 месяца чистки / данных нет, нужно собирать заново. Иногда правильный вывод по итогам аудита — отложить AI-проект на квартал и сначала навести порядок в источниках.

Причина 3. Пилот сделан на бенчмарке, прод — на реальности

Это очень частая история. На контрольной выборке из 1000 примеров модель показывает 92% точности. Все радуются, готовят запуск, выкатывают в прод — и через неделю получают 68%.

Почему так:

• Distribution shift. В реальном продакшене данные распределены не так, как в тестовой выборке. Сезонность, новые продукты, изменения в формулировках клиентов — модель этого не видела.
• Long-tail queries. В выборке нет редких сценариев, которые в проде составляют 10–15% от потока. Модель на них падает катастрофически.
• Drift. За два месяца между пилотом и продом контекст изменился. Появились новые тарифы, новые правила обработки заявок, новый язык клиентов.

Что делать. Тестировать пилот не на отобранной выборке, а на свежем потоке за последние 2–4 недели. Лучше с разбивкой по категориям, чтобы поймать слабые места по отдельным типам запросов. И обязательно ставить мониторинг качества в проде с первого дня — иначе вы не узнаете о drift, пока не получите жалобу от клиента.

Причина 4. Никто не подумал об интеграции

PoC живёт в изолированной песочнице: ноутбук датасайентиста, Jupyter Notebook, фейковая база. Демонстрация проходит блестяще.

Дальше начинается реальность:

• LDAP/AD для аутентификации.
• Интеграция с CRM/ERP/тикетной системой по API.
• Очередь сообщений (Kafka, RabbitMQ) для асинхронной обработки.
• Логирование в SIEM, метрики в Prometheus, алёрты в PagerDuty.
• Бэкапы, репликация, disaster recovery.
• Согласование с ИБ, security review, пентест.
• Документация для оператора.

Каждый из этих пунктов — две-три недели работы. В сумме — 4–6 месяцев инженерного truда, которые не закладывались в бюджет пилота. Проект встаёт, потому что денег на «доделку» нет, а делать «доделку» в формате пилота — невозможно.

Что делать. Считать стоимость PoC в формате «стоимость прототипа + 60% на промышленизацию», а не «стоимость прототипа». Если бюджет пилота 600 тыс. ₽, заранее закладывать 1,0–1,5 млн ₽ на доведение до прода. Иначе вы делаете не пилот, а форму выученной беспомощности.

Причина 5. Качество измеряют не там

«Точность 92% на validation set» — техническая метрика. Бизнес она ничего не говорит. Через эту метрику нельзя ответить на вопрос «стоит ли запускать в прод».

Полезные бизнес-метрики выглядят иначе:

• AHT (Average Handling Time) — среднее время обработки тикета. Снизилось на 30% — значит, AI экономит время операторов.
• Deflection rate — доля обращений, закрытых AI без эскалации. 40% — хороший результат для первой линии саппорта.
• NPS / CSAT — клиенты не должны заметить ухудшения. Если NPS просел на 5 п.п., экономия в AHT ничего не стоит.
• Стоимость одного успешно закрытого обращения в рублях. С учётом инфраструктуры, лицензий, людей.

Технические метрики (precision, recall, F1, BLEU) полезны для отладки модели, но решения о запуске принимаются по бизнесовым.

Что делать. До начала PoC согласовать с заказчиком 2–3 бизнес-метрики и формулу их расчёта. По этим метрикам и принимать решение в финале пилота.

Причина 6. Игнорируют human-in-the-loop

Самый частый сценарий провала в B2C: AI начинает массово отвечать клиентам, через два дня появляется виральный твит «бот сошёл с ума и обещает вернуть деньги за всё», PR-кризис, AI выключают.

Это решается архитектурно:

• Confidence-based routing. Когда модель уверена ≥0,8 — отвечает сама. Когда меньше — передаёт человеку.
• Шорт-листинг ответов вместо генерации. Особенно на ранней стадии: модель не пишет ответ с нуля, а выбирает из 5–10 заготовленных оператором вариантов.
• Approval-workflow. Для критичных решений (компенсация, отмена услуги, изменение договора) — обязательное подтверждение оператором.
• Кnown-bad list. Список фраз и тем, которые модель никогда не обсуждает (политика, конкуренты, чувствительные исключения).

Все эти механизмы стоит закладывать в архитектуру с первого дня PoC, а не после первого инцидента.

Причина 7. Нет ownership с бизнес-стороны

В компании запустили AI-пилот. У него есть PM на стороне подрядчика, есть тимлид со стороны IT клиента, есть data engineer. Нет одного человека на стороне бизнеса, для которого этот пилот — лично его KPI.

Что происходит:

• На демонстрации сидит 15 человек, никто не хочет принимать решение.
• Замечания собираются «в общую кучу», команда не понимает, что важно, а что нет.
• Через месяц после пилота на стороне клиента меняется руководитель, новому неинтересно — проект сворачивается.

Что делать. Перед стартом пилота назначить AI Champion на стороне бизнеса — человека, у которого результат внедрения попадает в личные KPI и который участвует в проекте еженедельно, а не только на финальной презентации. Без этого человека пилот превращается в технологический фестиваль без цели.

«Самый дорогой урок от провалившихся AI-проектов — отсутствие у бизнеса собственника результата. Без него любой пилот превращается в R&D без шансов выйти в прод» — рефрен из серии аналитики Harvard Business Review по AI-стратегии, 2024–2025.

Чек-лист «пилот, который дойдёт до прода»

Перед стартом любого PoC ответьте честно на эти 12 вопросов:

1. У нас есть один бизнес-вопрос, на который пилот должен дать ответ?
2. Критерий успеха сформулирован в цифрах, а не в качественных оценках?
3. Назначен AI Champion на стороне бизнеса с KPI на результат?
4. Проведён аудит данных, и они признаны пригодными?
5. Заложен бюджет «PoC + 60% на промышленизацию»?
6. Согласованы 2–3 бизнес-метрики, по которым будем принимать решение?
7. Прописана архитектура human-in-the-loop для рисковых сценариев?
8. Определены интеграции (CRM, ERP, тикетная, очередь, мониторинг)?
9. Пройден предварительный security review?
10. Есть план выкатки в прод с поэтапным расширением аудитории?
11. Есть план мониторинга модели в проде и реагирования на drift?
12. Есть письменное обязательство заказчика идти в прод, если метрики достигнуты?

Если на половину пунктов ответ «нет» или «потом разберёмся» — это и есть тот самый пилот, который не дойдёт до прода. Лучше потратить лишнюю неделю на формулировки, чем 4 месяца на эффектную презентацию, после которой ничего не запустят.

Если коротко

AI-проекты не проваливаются из-за AI. Они проваливаются из-за того, что:

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

Технология в 2026 году дозрела. Сложности теперь — почти полностью организационные. Хорошая новость: это значит, что их можно лечить процессом, а не очередным апгрейдом модели.

Если у вас уже один пилот лёг, и не хочется повторять — стоит начать со второго пилота с правильной постановкой. Под это мы делаем AI-аудит и экспресс-диагностику: 2–5 дней разбираем процесс, считаем экономику и говорим, какой PoC реально дойдёт до прода — а какой лучше не запускать.