Почему ИИ-пилот не внедряется и как довести его до результата

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

В открытой базе кейсов ИИ на platforms.su собрано более 1300 описаний внедрений. Среди тех, что дошли до промышленной работы, повторяются несколько сценариев.

Системы управления технологическими режимами

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

Ассистенты для операторов и сотрудников поддержки

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

Антифрод и выявление аномалий

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

Обработка входящих документов и данных

Задача: убрать ручной перенос данных из документов в учётные системы. ИИ распознаёт и извлекает поля, робот заносит их в систему. В промышленных кейсах время реакции на входящую информацию сокращается на порядок. Ключевое условие – готовая интеграция с учётной системой.

Типовые сервисы, которые закупают готовыми

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

У проектов, которые работают в промышленном режиме, есть общие черты. Эффект измеряется в деньгах или в штате, а не в точности модели. Решение встроено в существующую рабочую систему пользователя. Есть владелец со стороны бизнеса и команда, которая сопровождает модель. Архитектура и требования безопасности согласованы до пилота. У застрявших пилотов картина обратная, и причины повторяются.

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

• Запускать пилот без критериев перехода. Если заранее не сказано, какой результат ведёт к масштабированию, пилот длится бесконечно.
• Оценивать пилот по точности модели. Решение о переходе принимается по эффекту на процесс и по стоимости эксплуатации.
• Не бюджетировать вторую фазу. Интеграция, инфраструктура, обучение людей и поддержка часто стоят больше самого пилота.
• Распылять ресурсы на десятки пилотов. Даже в компаниях, где сотрудники массово создают ИИ-агентов в конструкторе, в ежедневной работе остаётся меньшинство сценариев. Отбор – нормальная часть процесса, но его нужно делать сознательно.
• Не готовить пользователей. Обучение и изменение регламентов откладывают на потом, а потом решение никто не использует.
• Забывать о сопровождении. Модели теряют качество при изменении данных и правил. Без мониторинга и переобучения эффект через год снижается.

1. Недели 1–2. Критерии и владелец. До старта фиксируются целевые показатели, порог перехода в эксплуатацию и порог остановки. Назначается владелец со стороны бизнеса, который будет отвечать за решение после пилота.
2. Недели 2–3. Архитектура эксплуатации. С ИТ и безопасностью согласуется, где будет работать решение, с какими системами интегрироваться, какие данные обрабатывать. Пилот сразу строится в целевом контуре или максимально близко к нему.
3. Недели 3–8. Пилот на реальном потоке. Не на отобранной выборке, а на части реального потока, с пользователями в их рабочих системах. Параллельно замеряется эффект на процесс.
4. Недели 6–10. Подготовка к переходу. Изменения регламентов, обучение пользователей, план поддержки, расчёт стоимости эксплуатации при полном объёме.
5. Точка решения. Правление принимает решение по заранее согласованным критериям: масштабировать, доработать или остановить.
6. Опытная эксплуатация. Для критичных процессов – 2–4 месяца с контролем человека, затем промышленный режим с регулярным мониторингом качества.

• Какой результат пилота станет основанием для перехода в эксплуатацию и какой – для остановки?
• Где будет работать решение в промышленном режиме и согласовано ли это с безопасностью?
• С какими системами нужна интеграция и заложена ли она в бюджет второй фазы?
• На каких данных проводится пилот и насколько они похожи на реальный поток?
• Кто будет владельцем решения после пилота и кто отвечает за качество модели?
• Как будет отслеживаться качество модели и как часто её нужно переобучать?
• Сколько будет стоить эксплуатация при полном объёме, включая вычисления и поддержку?

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