Как выбрать процесс для первого AI-агента: чек-лист перед пилотом
Первый AI-агент в компании чаще всего проваливается не из-за модели, а из-за выбора задачи. Берут самый заметный процесс, самый «умный» сценарий или то, что красиво смотрелось на демонстрации. Через пару месяцев оказывается, что эффект нечем измерить, данные недоступны, а ошибку агента никто не замечает до жалобы клиента.
Ниже — чек-лист, по которому мы отбираем процессы для первого пилота. Он подходит и для того, чтобы честно решить: ИИ здесь не нужен.
Начните с процесса, а не с модели
Вопрос «какую модель взять» стоит задавать последним. Сначала нужно ответить на три других:
- Какое действие должно измениться? Не «внедрить ИИ в поддержку», а «первичная классификация обращения и подготовка черновика ответа для сотрудника».
- Кто владелец процесса? Человек, который отвечает за результат и сможет принять решение по итогам пилота.
- Как вы поймёте, что стало лучше? Время обработки, доля ошибок, объём ручной работы, скорость ответа — любая метрика, которую можно посчитать до и после.
Если на эти вопросы нет ответа, разрабатывать агента рано. Сначала стоит описать процесс.
Признаки хорошего кандидата
Процесс стоит проверять, если выполняется большинство условий.
Большой поток однотипной информации
Обращения, заявки, документы, отзывы, письма, записи в CRM. Когда сотрудники ежедневно разбирают десятки и сотни похожих единиц, даже частичная автоматизация заметна. Редкая задача, которая возникает раз в месяц, почти никогда не окупает разработку.
Решения принимаются по понятным критериям
Если опытный сотрудник может объяснить новичку, как он относит обращение к категории или проверяет договор, эти правила можно передать агенту и проверить. Если решение держится на интуиции одного человека и его невозможно сформулировать, качество работы агента будет не с чем сравнить.
Есть данные для проверки качества
Нужен набор реальных примеров с правильными ответами: размеченные обращения, проверенные документы, история решений. На этом наборе агента тестируют до запуска и после каждого изменения. Без него «работает хорошо» остаётся мнением.
Результат можно измерить
Зафиксируйте текущее значение метрики до пилота. Иначе через месяц не получится отличить эффект агента от сезонности, нового сотрудника или изменения потока.
Ошибку можно обнаружить и исправить
Агент будет ошибаться — вопрос в цене ошибки и в том, кто её заметит. Хороший первый сценарий тот, где результат агента проверяет человек или система: сотрудник видит черновик перед отправкой, документ проходит сверку, задача попадает в очередь на подтверждение.
Когда лучше обойтись без ИИ
Честный отбор отсекает часть идей. Скорее подойдёт более простое решение, если:
- задача решается правилом или интеграцией. Переложить данные из формы в CRM, отправить уведомление по статусу, посчитать остатки — это обычная автоматизация. Она дешевле, быстрее и предсказуемее;
- процесс редкий или ещё не устоялся. Сначала его нужно описать и стабилизировать;
- нет данных и способа проверить ответ. Качество агента окажется непроверяемым;
- цена ошибки исключает автоматическое действие. Платежи, юридически значимые решения, изменения в учётных системах без подтверждения человеком;
- у процесса нет владельца и метрики. Пилот некому будет принять.
Отказ от ИИ по итогам разбора — нормальный результат. Он экономит бюджет, который иначе ушёл бы на прототип без применения.
Как оценить экономику до разработки
Грубой оценки достаточно, чтобы отбросить слабые сценарии:
| Что посчитать | Откуда взять |
|---|---|
| Сколько единиц работы в месяц | CRM, почта, учётная система |
| Сколько времени уходит на одну единицу | Замер на выборке или оценка владельца процесса |
| Какую часть работы реально передать агенту | Разбор 30–50 реальных примеров |
| Сколько стоит ошибка и её исправление | История инцидентов, оценка владельца |
| Сколько стоит эксплуатация | API модели, сервер, поддержка, время на проверку |
Если даже при оптимистичных допущениях сэкономленное время не покрывает эксплуатацию и контроль, сценарий лучше отложить.
Как устроить пилот
Пилот — это проверка одной гипотезы на ограниченном контуре, а не маленькое внедрение. Перед стартом зафиксируйте шесть пунктов:
- Гипотеза. Что именно должно измениться в процессе.
- Данные. На каком наборе примеров проверяем и какие доступы нужны.
- Критерии качества. Какую долю ответов считаем приемлемой и как оцениваем.
- Экономика. С чем сравниваем результат.
- Ошибки. Как агент сообщает о неуверенности, кто проверяет результат, что происходит при сбое.
- Решение. При каких результатах масштабируем, дорабатываем или останавливаем.
Агенту на пилоте дают минимальные права: только те данные и действия, которые нужны сценарию. Критичные операции подтверждает человек, а все действия записываются в журнал — так проще разбирать ошибки и доказывать эффект.
Короткий чек-лист
Перед тем как заказывать разработку, проверьте:
- сформулировано конкретное действие, которое изменится;
- есть владелец процесса;
- поток регулярный и достаточно большой;
- критерии правильного решения можно объяснить;
- есть реальные примеры для тестового набора;
- известно текущее значение метрики;
- ошибку агента заметит человек или система;
- задачу нельзя проще решить правилом или интеграцией;
- понятно, при каком результате пилот считается успешным.
Если большинство пунктов отмечено — процесс подходит для пилота. Если нет, начните с описания процесса и сбора данных: это пригодится при любом варианте автоматизации.
Подробнее о том, как мы проводим диагностику и пилоты, — на страницах «ИИ для бизнеса» и «Подход». Если сценарий уже понятен и нужен готовый агент в Telegram или рабочих системах, посмотрите развёртывание OpenClaw и Hermes.