Агент окупается там, где задача состоит из нескольких шагов, порядок шагов заранее неизвестен, а результат проверяем. Ниже пятнадцать сценариев, сгруппированных по сложности внедрения: от тех, что запускаются за недели, до требующих серьёзной подготовки. В конце — сценарии, где агент не нужен, хотя его часто предлагают.
Сложность оценивается по трём признакам: число внешних систем, цена ошибки и наличие готового API.
Простые: одна система, ошибка обратима
1. Маршрутизация обращений. Агент определяет тему и срочность входящего письма или заявки, ставит теги и назначает ответственного. Ошибка исправляется переназначением, объём высокий, эффект измеряется сразу.
2. Первичная квалификация лида. Задаёт уточняющие вопросы, заполняет карточку в CRM, помечает готовность к передаче менеджеру. Человек видит результат до контакта с клиентом.
3. Сбор данных для карточки клиента. Находит и сводит информацию из нескольких доступных источников в одну запись. Только чтение вовне, запись — в свою систему.
4. Подготовка ответа на типовое обращение. Находит нужное в базе знаний, формирует черновик, оставляет отправку человеку. Формально это ассистент, но реализуется теми же средствами.
5. Проверка полноты документа. Сверяет комплект по чек-листу, отмечает недостающее. Ошибка — ложное срабатывание, легко замечается.
Средние: две-три системы или заметная цена ошибки
6. Обработка входящих заявок под ключ. Разбирает письмо, создаёт заявку в CRM, прикрепляет файлы, уведомляет ответственного. Разбор — в статье «ИИ-агент для обработки заявок».
7. Извлечение данных из документов в учётную систему. Счета, накладные, анкеты. Требует контроля на первом этапе — см. «ИИ-агент для работы с документами».
8. Сопровождение сделки по этапам. Отслеживает, что просрочено, напоминает, обновляет статусы, готовит сводку руководителю.
9. Подбор из каталога по запросу клиента. Уточняет параметры, ищет по номенклатуре, формирует подборку с ценами и наличием.
10. Подготовка регулярной отчётности. Собирает данные из нескольких систем, сводит, формирует документ. Цена ошибки зависит от того, кто и как отчёт использует.
11. Обработка возвратов и рекламаций. Проверяет условия, определяет применимое правило, готовит решение. Часть шагов почти всегда требует подтверждения.
Сложные: много систем, необратимые действия или регулируемая область
12. Ассистент сотрудника с доступом к внутренним системам. Отвечает на вопросы и выполняет действия от имени сотрудника — оформляет заявку на отпуск, находит документ, создаёт задачу. Сложность в разграничении прав: агент не должен видеть больше, чем сам сотрудник.
13. Онбординг клиента. Проверка документов, создание учётной записи, настройка доступов, серия уведомлений. Много систем и необратимых шагов.
14. Управление закупками в рамках лимита. Отслеживает остатки, формирует заявку поставщику. Финансовые последствия требуют жёстких лимитов и подтверждений.
15. Разбор инцидентов в ИТ. Собирает данные из мониторинга и логов, формирует гипотезу, выполняет типовые проверки. Требует зрелого мониторинга — иначе агенту неоткуда брать данные.
Сравнение по сложности
| Группа | Систем | Цена ошибки | Подтверждения | Срок запуска |
|---|---|---|---|---|
| Простые (1–5) | одна | низкая, обратима | не обязательны | недели |
| Средние (6–11) | две-три | заметная | на части операций | месяцы |
| Сложные (12–15) | много | высокая, часть необратима | обязательны | долго, поэтапно |
Практический вывод: первый агентский проект стоит брать из первой группы, даже если самая ценная задача лежит в третьей. Провал на видном месте закрывает тему внутри компании надолго, а простой сценарий даёт организации опыт при низком риске. Логика выбора первого проекта разобрана в статье «Как выбрать процесс для первого ИИ-проекта».
Где агент не нужен
Четыре ситуации, в которых агента предлагают, а он избыточен:
Последовательность шагов фиксирована. Если порядок действий известен заранее и не зависит от промежуточных результатов, это обычная автоматизация. Она дешевле, предсказуемее и проще тестируется.
Задача решается одним запросом. «Ответить на вопрос по документам» — работа для бота на базе знаний, а не для агента.
Правила описываются однозначно. Если условия формализуются полностью, скрипт справится лучше: он не ошибается и стоит копейки.
Нет API у нужных систем. Агент не может работать с системой, к которой нет программного доступа. Интеграция через эмуляцию интерфейса хрупка и обычно не оправдывает себя.
Что проверить до выбора сценария
- Есть ли API у всех систем, которые агент должен трогать, и какого качества.
- Обратима ли ошибка на каждом шаге. Необратимые действия требуют подтверждения.
- Сколько исключений в процессе. «Обычно так, но бывает иначе» — каждое такое правило придётся выяснить и заложить.
- Есть ли владелец процесса, который примет решения о полномочиях агента.
- Можно ли измерить эффект. Без показателя «до» результат нечем будет доказать — см. «Как измерить эффект от внедрения ИИ».
Пример расчёта окупаемости на одном сценарии
Возьмём сценарий 1 — маршрутизацию обращений. Числа условные, метод важнее значений.
Исходные данные, которые нужно собрать до проекта:
| Что измеряем | Пример значения |
|---|---|
| Обращений в месяц | 2 000 |
| Время на разбор и назначение | 3 минуты |
| Доля неверных назначений сейчас | 12 % |
| Стоимость переназначения | 5 минут |
Считаем «до»:
```
разбор: 2 000 × 3 мин = 100 часов
переназначения: 2 000 × 0,12 × 5 мин = 20 часов
итого = 120 часов в месяц
```
Считаем «после», приняв по результатам проверки на архиве, что агент верно классифицирует 90 % обращений:
```
проверка агента: 2 000 × 0,5 мин = 17 часов
ручной разбор остатка: 2 000 × 0,10 × 3 мин = 10 часов
переназначения: 2 000 × 0,05 × 5 мин = 8 часов
итого = 35 часов в месяц
```
Разница — 85 часов. Но это ещё не деньги.
Третий шаг, который чаще всего пропускают. Высвобожденные 85 часов становятся экономией только если превращаются в отказ от планового найма или в дополнительный объём работы. Если люди остались те же и объём не вырос, в бюджете ничего не изменилось — есть удобство, но не эффект. Подробно — в статье «Как измерить эффект от внедрения ИИ».
Из полученного вычитается эксплуатация. 2 000 обращений × 3–5 обращений к модели на каждое — это регулярный расход, который нужно посчитать до разработки, а не после запуска.
Ключевой параметр — доля верных классификаций. Она не берётся из обещаний, а замеряется на выборке ваших реальных обращений до начала работ. При 90 % расчёт выше сходится; при 70 % ручного разбора остаётся втрое больше, и экономия падает до величины, не окупающей проект.
Частые вопросы
С какого сценария начать внедрение ИИ-агентов?
С простого: одна система, обратимая ошибка, высокий объём. Маршрутизация обращений или квалификация лидов дают измеримый результат за недели при низком риске. Самая ценная задача обычно оказывается и самой сложной — её стоит брать третьим-четвёртым проектом, когда накоплен опыт.
Какие задачи агенту противопоказаны?
Те, где ошибка необратима, а проверить результат некому: финансовые операции без подтверждения, юридически значимые решения, действия с последствиями для клиента без участия человека. Также бессмысленно поручать агенту процессы с фиксированной последовательностью шагов — там дешевле обычная автоматизация.
Нужен ли API у всех систем?
Для систем, где агент меняет данные, — практически обязательно. Работа через эмуляцию пользовательского интерфейса технически возможна, но хрупка: любое изменение вёрстки ломает сценарий. Для чтения иногда допустимы обходные пути, но и они увеличивают стоимость сопровождения.
Сколько шагов должно быть в задаче, чтобы был нужен агент?
Дело не в количестве, а в предсказуемости. Задача из десяти жёстко заданных шагов — это автоматизация. Задача из трёх шагов, где второй зависит от результата первого и заранее неизвестен, — уже агентская. Признак агентской задачи: последовательность определяется по ходу.
Можно ли поручить агенту сразу несколько сценариев?
Не в первом проекте. Универсальный агент дольше разрабатывается, сложнее тестируется и рискованнее: провал одной части ставит под сомнение всё решение. Один узкий сценарий даёт результат быстрее и служит основой для расширения по подтверждённому эффекту.
Что дальше
Убедиться, что задача действительно агентская, — «Агент или чат-бот». Оценить объём работ — «Разработка ИИ-агента: этапы и стоимость». Понять, хватит ли готовой платформы, — «Платформа или разработка». Типичные ошибки — «ИИ-агенты: 14 типичных ошибок внедрения».
Подбор сценария под ваши процессы и проверка готовности систем — задача аудита процессов перед разработкой и внедрением ИИ-агента.