У провалившихся AI-проектов есть общий сценарий, и он на удивление устойчив. Компания покупает или собирает универсального ассистента. Его торжественно запускают. У него нет доступа к реальным данным, нет владельца и нет определения успеха. Через три месяца его тихо выключают, а организация делает вывод, что «AI ещё не готов».
Технологии здесь почти никогда ни при чём. У проекта просто не было границ.
Начинайте с процесса, а не с возможности
Полезный вопрос звучит не «что нам может дать AI», а «какая конкретная, повторяющаяся, массовая работа съедает ресурс, нужный нам в другом месте».
Хорошего кандидата определяют три свойства:
Объём. Работа происходит достаточно часто, чтобы её улучшение имело значение. Автоматизация того, что случается дважды в месяц, не окупит усилий, каким бы приятным ни был результат.
Повторяемость. Одно и то же решение на разных входных данных. Если каждый случай требует по-настоящему нового суждения, перед вами экспертиза, а не поток, и AI вас разочарует.
Приемлемая цена ошибки. Не нулевая — приемлемая. Именно здесь чаще всего ошибаются. Процесс, где ошибку ловит уже существующая проверка ниже по потоку, — гораздо лучший первый кандидат, чем тот, где ошибка доходит до клиента или до бухгалтерской проводки.
Есть и четвёртое свойство, которое легко упустить: процесс должен быть стабильным. Если его вот-вот перепроектируют, автоматизация сейчас — это деньги, потраченные дважды.
Проведите границу до разработки
Любому агенту нужны три категории, зафиксированные письменно до начала реализации:
- Что он решает сам. Классификация, извлечение данных, черновики, маршрутизация — обратимые и наблюдаемые действия.
- Что он предлагает на утверждение. Всё, что имеет финансовые, договорные или юридические последствия. Агент готовит, человек подтверждает.
- Чего он не касается вообще. Удаление, необратимые внешние действия, всё, что закрыто регламентом, появившимся раньше проекта.
Это должен быть документ, а не разговор. Он становится техническим заданием, планом тестирования и готовым ответом на вопрос, который неизбежно задаст ваша служба безопасности.
Границы — не ограничение полезности системы. Именно они делают её внедрение возможным в принципе.
Опирайтесь на источники и разрешите отказ
Агент, который отвечает по вашей задокументированной базе и ссылается на источники, поддаётся проверке. Агент, который отвечает из общих знаний модели, — это риск, носящий ваш логотип.
Отсюда следствие, которому команды сопротивляются: агенту нужно разрешить говорить «не знаю». Отказ — правильный ответ, если источники не покрывают вопрос. Система, настроенная всегда что-нибудь выдавать, будет выдавать уверенные, правдоподобные и неверные ответы, а они обходятся куда дороже, чем молчание, которое они заменили.
На практике первый запуск, который отвечает «по этому вопросу у меня нет документированного ответа, спросите Марию», ценнее того, который отвечает на всё с точностью 80%: первому можно доверять, второму — нет.
Сначала помощь, потом замена
Самая надёжная последовательность внедрения, которую мы видели:
Этап первый — черновики. Агент готовит ответ, человек проверяет и отправляет. Клиенту ничего не уходит без проверки. Это выстраивает доверие и, что важнее, даёт данные о правках, которые показывают реальные слабые места.
Этап второй — узкая автономность. Категории, где измеренная точность высока, а цена ошибки низка, переводятся в автоматический режим. Остальное остаётся на проверке.
Этап третий — расширение по данным. Категории переходят в автономность тогда, когда так говорят цифры, а не дорожная карта.
Команды, которые пропускают первый этап ради экономии времени, почти всегда возвращаются к нему после инцидента — потеряв за это время внутренний кредит доверия.
Определите, как вы поймёте результат
Договоритесь об измерении до разработки и сделайте его сравнением с текущим процессом на тех же случаях:
- какая доля обработана без эскалации;
- какая доля оказалась ошибочной и насколько;
- сколько времени занял полный цикл, включая проверку;
- сколько стоит обработка одного случая.
Последний пункт важнее, чем принято думать. Система, которая прекрасно работает и стоит за случай дороже, чем заменённый сотрудник, — это исследовательский проект, а не улучшение.
Если такую метрику для процесса сформулировать не выходит — это веский довод пока его не автоматизировать. Не потому, что измерения это бюрократия, а потому, что невозможность определить успех обычно означает: сам процесс понят плохо.
Как выглядит успех
Неэффектная версия: конкретная очередь, которая раньше росла линейно с числом клиентов, теперь растёт заметно медленнее. Сложные случаи по-прежнему разбирает человек — и теперь у него есть время делать это как следует. Каждое автоматическое действие записано вместе с обоснованием, поэтому на вопрос «почему так произошло» есть ответ.
Никакой истории про трансформацию. Один процесс, который стал работать лучше, и человек, за которым остались значимые решения.
Так выглядит успешный AI-проект, и он доступен практически любой компании, готовой выбрать один процесс и довести его до конца.