Ваш ИИ-пилот никогда не станет рабочим решением: 7 признаков провала

Всего 16% ИИ-инициатив доходят до масштабирования на уровне компании — об этом сообщили эксперты IBM. Остальные редко проваливаются громко. Обычно пилот работает на презентации, отвечает на тестовые вопросы — и на этом останавливается, так и не став частью рабочего контура.

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

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

Признак 1. Пилот начинается с технологии, а не с бизнес-задачи

Симптом. Команда обсуждает модель, RAG, агентов, промпты, векторную базу и интерфейс. На вопрос о цели для бизнеса отвечает расплывчато: «проверим потенциал ИИ», «сократим ручной труд».

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

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

Проверочный вопрос. Какая метрика должна измениться после внедрения — и на сколько?

Признак 2. У пилота нет владельца со стороны бизнеса

Симптом. Проектом занимается ИТ-команда или группа энтузиастов. Бизнес-заказчик приходит на демо, дает комментарии, иногда подкидывает примеры — но не берет на себя результат после внедрения.

В чем проблема? Когда решение выходит в прод, оно меняет реальную работу людей: роли, регламенты, маршруты согласования, зоны ответственности. Технической команде это не по полномочиям.

Без владельца со стороны бизнеса пилот зависает между подразделениями. ИТ отвечает за разработку, но не за процесс; бизнесу нужен результат, но не ценой перестройки работы команды. Пользователи пробуют инструмент и возвращаются к старому маршруту — новый порядок никто не закрепил.

Проверочный вопрос. Кто будет отвечать за эффект этого решения через полгода после запуска?

Признак 3. Пилот работает на подготовленных данных, а не в реальной среде

Симптом. Для пилота вручную собрали документы, почистили базу знаний, подготовили аккуратную выгрузку и ограничили набор сценариев. На демо все убедительно. В реальной работе данные лежат в разных системах, устаревают, дублируются, противоречат друг другу или закрыты правами доступа.

В чем проблема? На витрине ИИ выглядит сильнее, чем в бою: уверенно отвечает, выдает складный результат. Дальше начинается рабочий контур, где часть данных в CRM, часть в Service Desk, часть в Jira, Confluence, DWH или почте.

Выясняется, что источники нужно подключать по одному, права доступа описаны неполно, обновление не настроено, а часть информации вообще нельзя отдавать в выбранный контур. Формально модель работает — стабильно решать задачи сотрудников не может.

Проверочный вопрос. Пилот работает на тех же данных, что сотрудники видят каждый день, или на специально причесанной витрине?

Признак 4. Решение не встроено в рабочий процесс

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

В чем проблема? Инструментом, который живет сбоку от процесса, редко продолжают пользоваться. На тестах его открывают из интереса; в ежедневной работе побеждает короткий маршрут — привычная система, понятные действия, минимум переключений.

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

Проверочный вопрос. Какое действие человек перестает делать вручную после внедрения?

Признак 5. Нет критериев качества и границ ответственности

Симптом. Пилот оценивают на словах: «отвечает нормально», «часто помогает», «стало лучше», «надо еще погонять». Ни порогов качества, ни правил проверки, ни сценариев эскалации, ни списка действий, которые ИИ выполняет сам.

В чем проблема? Для запуска в прод субъективных оценок мало — нужны измеримые пороги: точность и полнота ответа, доля автозакрытых задач, доля эскалаций, влияние на SLA, стоимость одной операции.

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

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

Признак 6. Безопасность, архитектуру и комплаенс отложили на потом

Симптом. Сначала делают пилот, а ИБ, юристов, архитекторов и эксплуатацию планируют подключить после того, как гипотеза подтвердится. Данные уже уходят в модель, но хранение, доступы и логирование держатся на общей договоренности.

В чем проблема? Так пилот доходит до убедительного демо и упирается в стену перед запуском: технически работает, но не проходит требования безопасности, регуляторные ограничения или корпоративные правила архитектуры.

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

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

Признак 7. После масштабирования не сходится экономика

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

В чем проблема? Технически удачный пилот может оказаться дорогим в эксплуатации. На старте стоимость легко недооценить: часть работы тянет команда проекта, часть проверяется руками, часть сложностей просто не успевает проявиться.

С ростом нагрузки экономика меняется. Если ИИ ускоряет задачу, но требует дорогой инфраструктуры, смысл масштабирования быстро тает.

Проверочный вопрос. Сколько будет стоить один обработанный кейс после масштабирования — и это дешевле текущего процесса?

Чек-лист вместо заключения: готов ли ваш пилот выйти в рабочий контур

Общий корень почти всех признаков один: пилот проектировали как демо, а не как будущий узел рабочей системы. Сильное демо и рабочее решение — разные инженерные задачи, и вторую нельзя получить, отложив ее на «потом».

Быстрый способ проверить, готов ли пилот к переходу в прод, — короткий чек-лист:

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

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