После диагностики были определены границы сценария, метрики качества, требования к данным, роли ответственности и условия перехода к промышленному запуску.
Карта разбора
Ситуация, риски и решение
AI-пилот хорошо выглядел на демонстрации, но не стал рабочим инструментом после попытки использовать его в реальном процессе.
- расширение пилота без готовых данных и метрик
- ошибочные ответы в критичных сценариях
- отсутствие владельца качества после запуска
- реальный пользовательский сценарий и границы AI
- источники знаний, права доступа и правила отказа
- метрики точности, полезности, риска и эксплуатации
- сузить пилот до проверяемого рабочего сценария
- оставить человека в контуре для критичных ответов
- описать метрики и правила перехода в эксплуатацию
- стало понятно, какие части пилота можно сохранить
- появился критерий: расширять, сужать или остановить AI-сценарий
- снизился риск внедрения AI без ответственности за качество
Почему сценарий обезличен
Разбор описывает типовой AI-пилот без названия компании, внутренних данных, точных показателей и неподтверждаемых обещаний. Цель - показать, почему успешная демонстрация не равна внедрению, и какие проверки нужны до промышленного запуска.
Контекст
Команда подготовила AI-пилот для внутреннего или клиентского процесса. На демонстрации сценарий выглядел убедительно: ассистент отвечал на подготовленные вопросы, быстро находил информацию, помогал сформировать черновики и создавал ощущение готового решения.
После попытки использовать пилот в рабочем контуре появились проблемы. Пользователи задавали вопросы шире демо-сценария, документы оказывались устаревшими, часть ответов требовала проверки, права доступа были не до конца описаны, а ответственность за качество не была закреплена.
Пилот технически существовал, но бизнес не мог безопасно перевести его в промышленную эксплуатацию.
Симптомы
- на демо ответы выглядели убедительно, но реальные вопросы пользователей были сложнее;
- не было списка сценариев, где AI должен отказаться от ответа;
- источники данных и документов обновлялись нерегулярно;
- права доступа не были проверены на всех ролях;
- пользователи не понимали, когда можно доверять ответу;
- ошибки фиксировались в чатах, но не превращались в процесс улучшения;
- не было владельца качества AI-сценария после запуска;
- команда не определила критерии перехода из пилота в эксплуатацию.
Что проверяли
Диагностика была построена вокруг вопроса: может ли пилот стать рабочим инструментом, а не только демонстрацией технологии.
| Зона проверки | Что искали |
|---|---|
| Сценарий | Какую конкретную задачу AI решает и где заканчиваются его границы |
| Пользователи | Кто реально использует инструмент и какие вопросы задаёт |
| Данные и документы | Какие источники актуальны, кто их обновляет и где есть противоречия |
| Права доступа | Что можно показывать разным ролям и где нужен отказ от ответа |
| Метрики качества | Как измеряются точность, полезность, риск и отказ от ответа |
| Эксплуатация | Кто поддерживает сценарий, базу знаний и разбор ошибок |
| Переход в прод | Какие условия должны быть выполнены до промышленного запуска |
Что стало понятно
Проблема была не в том, что AI “не работает”. Пилот был собран для демонстрационных условий: ограниченные вопросы, подготовленные источники, ручной контроль и отсутствие реальной ответственности за ошибку.
В эксплуатации контекст изменился. Пользователи задавали вопросы не по сценарию, данные расходились, часть документов не имела владельца, а спорные ответы нужно было разбирать быстро и прозрачно.
Пилот не был готов не как технология, а как процесс.
Главные разрывы между демо и эксплуатацией
| На демо | В эксплуатации |
|---|---|
| Подготовленные вопросы | Непредсказуемые пользовательские формулировки |
| Отобранные документы | Смешение актуальных, архивных и спорных источников |
| Нет критичных последствий | Ошибка влияет на сотрудника, клиента или процесс |
| Ответ проверяет демонстратор | Нужен владелец качества и порядок исправлений |
| Достаточно красивого ответа | Нужны источник, ограничение и измеримая полезность |
| Разовый показ | Постоянная поддержка базы знаний, прав и метрик |
Именно этот разрыв часто объясняет, почему AI-пилоты не внедряются, даже если первая демонстрация была сильной.
Какие решения не стали принимать сразу
До диагностики не рекомендовали:
- расширять пилот на всех пользователей;
- добавлять больше документов без проверки качества базы знаний;
- интегрировать AI в критичный процесс без ручного контроля;
- считать успешными несколько удачных ответов на демо;
- оценивать качество только по впечатлению команды;
- запускать клиентский сценарий без правил отказа и эскалации;
- обещать автоматизацию процесса, который ещё не описан.
Сначала нужно было зафиксировать границы и критерии качества.
Что предложили изменить
Пилот был переведён из режима “AI отвечает на всё” в управляемый сценарий.
Ключевые изменения:
- выбрать одну пользовательскую задачу для следующего этапа;
- отделить актуальные источники от архивных и спорных;
- назначить владельца базы знаний;
- описать роли и ограничения доступа;
- определить ситуации, где AI должен отказаться или передать вопрос человеку;
- собрать тестовый набор реальных вопросов;
- ввести метрики точности, полезности, риска и эксплуатации;
- назначить владельца процесса после запуска.
Метрики для решения о запуске
Для перехода к промышленному контуру были нужны не общие впечатления, а проверяемые показатели:
- доля ответов с корректным источником;
- доля ответов, где AI должен отказаться;
- количество исправлений в базе знаний;
- доля ответов, принятых пользователем без ручной правки;
- повторные обращения по той же теме;
- количество вопросов за пределами сценария;
- скорость исправления ошибок;
- наличие владельца процесса и правил обновления.
Такие метрики помогают решить, расширять пилот, сузить сценарий или сначала готовить данные и документы. Подробнее это описано в статье метрики качества AI-ассистента.
План действий
- Зафиксировать реальный пользовательский сценарий и границы AI-пилота.
- Проверить источники данных, документы, роли и ограничения.
- Собрать контрольные вопросы из реальной эксплуатации, а не только из демо.
- Настроить правила отказа, эскалации и ручной проверки.
- Определить метрики качества и владельца процесса.
- Запустить ограниченный эксплуатационный тест на безопасной группе пользователей.
- Принимать решение о расширении только по результатам метрик и разбора ошибок.
Что это дало бизнесу
Бизнес получил понятную развилку:
- какие части пилота можно оставить;
- какие данные и документы нужно подготовить;
- где сценарий нужно сузить;
- где нужен RAG-подход с источниками;
- какие риски нельзя выпускать пользователям;
- какие метрики покажут готовность;
- кто должен владеть качеством после запуска.
Главный результат - отказ от иллюзии, что успешное демо уже является внедрением.
Вывод для похожих проектов
AI-пилот должен проверять не модель в удобных условиях, а готовность процесса к эксплуатации. Если нет владельца данных, метрик качества, правил отказа, ограничений доступа и плана поддержки, пилот останется демонстрацией.
Для похожих ситуаций полезны AI-аудит, AI-ready архитектура, AI-ready чек-лист, статья как понять, что AI-функция нужна пользователю и материал метрики качества AI-ассистента.
