Почему AI-проект начинается не с модели, а с процесса

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

Модель в этой истории почти ни при чём. Она отвечает ровно так, как её спросили, на тех данных, которые дали. Всё остальное — процесс.

Роли и действия

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

Когда действия выписаны, обычно сразу видно, где узкое место. Иногда оно вовсе не там, где ждали: время уходит не на формулировку ответа, а на поиск актуальной версии документа. Тогда и задача другая.

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

Источники данных

AI отвечает по тому, что ему дали. Значит, до запуска нужно назвать конкретные источники: эти регламенты, этот раздел базы знаний, эти карточки в CRM. Не «все наши документы» — их обычно больше, чем кажется, и половина устарела.

• у каждого источника есть владелец, который его обновляет
• понятно, как часто он меняется и что делать при изменении
• видно, какие данные закрыты и для кого
• есть решение, что делать с противоречиями между источниками

Ограничения

Ограничения — это не список запретов ради безопасности, а описание области, в которой сценарий вообще имеет смысл. О чём AI отвечает, о чём молчит, что делает при отсутствии данных, кому передаёт вопрос, если он вне области.

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

Ограничения проще формулировать через примеры, чем через правила. Соберите десяток реальных обращений, которые сценарий обязан обработать, и десяток тех, которые он обрабатывать не должен. Граница между этими стопками и есть область применения — и она обычно оказывается уже, чем предполагали на старте.

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

Качество ответа

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

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

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

Безопасный MVP

Безопасный первый шаг устроен просто: AI подсказывает, человек решает, всё видно в логах. Никаких действий во внешних системах, никакой отправки клиенту напрямую. На этом уровне ошибка стоит нескольких секунд, а данных для оценки набирается достаточно быстро.

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

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