Как обучить ИИ-агента для бизнеса: пошаговый план первого пилота

АвторАлександр Гран

Если в компании уже пробовали «внедрить ИИ» и получили красивый чат-бот, который отвечает на вопросы, но ничего не делает — вы не одиноки. Разница между чат-ботом и рабочим ИИ-агентом не в мощности модели, а в том, кто управляет процессом. И «обучить» первого агента для бизнеса — значит не натренировать модель с нуля, а спроектировать вокруг готовой LLM систему, которую можно проверить на одном конкретном процессе.

Что значит «обучить ИИ-агента» в этом плане

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

Anthropic проводит похожую границу между workflow и агентом: в workflow модель и инструменты идут по заранее прописанному маршруту, в агенте — LLM сама решает, что делать дальше. Здесь же — важная поправка от Anthropic: не каждой задаче нужен именно агент. Компания прямо советует искать максимально простое решение и усложнять архитектуру только при необходимости, потому что агентные системы обменивают скорость и стоимость на лучшее выполнение задачи. Для многих сценариев достаточно одного оптимизированного вызова LLM с поиском по данным и примерами в контексте — без всякой автономии. Прежде чем проектировать агента, стоит проверить: не решается ли задача проще.

Шаг 1. Выберите один процесс для пилота

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

Чтобы не потерять фокус, полезно сразу описать пилот в виде карточки — это же станет техническим заданием для последующих шагов.

Поле карточки Что туда пишем
Вход Что получает агент: документ, сообщение, расшифровка, запрос
Ожидаемый результат Что должно получиться на выходе процесса
Решения агента Какие развилки он проходит самостоятельно
Используемые системы Откуда берёт данные и куда пишет результат
Действия с подтверждением Что нельзя делать без согласия сотрудника
Условия остановки/передачи человеку Когда агент обязан прекратить и передать задачу
Метрики Как поймём, что пилот работает

Шаг 2. Опишите роль, правила и запреты

Агент должен понимать не только что делать, но и чего делать нельзя. Здесь фиксируются источники, на которые он опирается, действия, которые он выполняет от имени пользователя, и — отдельно — действия, которые ему запрещены без участия человека. Сюда же входит условие остановки: если агент столкнулся с ситуацией, которую правила не покрывают, или процесс дал сбой, правильное поведение — остановиться и вернуть управление сотруднику, а не импровизировать. Это прямо согласуется с тем, как OpenAI описывает надёжного агента: он действует в заданных границах и передаёт решение человеку, когда выходит за них.

Шаг 3. Подготовьте корпоративные знания

Загрузить несколько PDF в модель — не значит подготовить знания. Для выбранного процесса нужно определить конкретный набор утверждённых источников — регламенты, шаблоны, внутренние правила — и, что важнее, явно связать каждый источник с решением, которое агент должен на его основе принимать. Если агент решает, отправлять ли клиенту повторное письмо, у него должен быть не общий доступ к базе документов, а конкретное правило, к какому документу обращаться в этой развилке.

Шаг 4. Определите инструменты и разрешённые действия

Инструменты агента делятся на два типа: те, что дают контекст (чтение карточки клиента, поиск по базе знаний, просмотр истории переписки), и те, что меняют состояние системы (создание задачи, обновление записи, отправка письма). Но деление на «чтение» и «запись» — не то же самое, что деление на «безопасно» и «опасно»: OpenAI отдельно рекомендует по умолчанию запрашивать подтверждение пользователя на каждую операцию инструмента — включая операции чтения, а не только записи. Доступ к CRM, почте, документам и другим корпоративным данным стоит ограничивать по тому же принципу минимальных прав (least privilege), который рекомендует Anthropic: агенту нужен доступ ровно к тем данным, которые требуются для конкретного шага процесса, — просто чтение чувствительных сведений тоже может обернуться утечкой, если они попадут в текст, который агент затем куда-то передаст. Изменяющие состояние действия — тем более зона риска, и здесь работает принцип из шага 2: значимое действие требует подтверждения человека. На примере CRM это выглядит так: агент получает доступ на чтение ровно к тем карточкам и полям, которые нужны для процесса, может предложить, что обновить, но фактически создавать задачу или менять данные — только после того, как сотрудник подтвердил предложение.

Риски: недоверенные данные и prompt injection

Если агент читает письма, веб-страницы, документы или любой другой внешний текст, вместе с полезной информацией в систему может попасть скрытая инструкция, рассчитанная не на человека, а на модель, — это называется непрямым prompt injection. Anthropic описывает базовые меры защиты в документации по защите от джейлбрейков и prompt injection, и для пилота из них складывается короткий чек-лист:

  • Считать письма, сайты, документы и любой другой внешний текст, который читает агент, потенциально недоверенным — там может быть скрытая инструкция для агента, а не сообщение для человека.
  • Ограничивать права инструментов, доступных агенту: чем уже доступ, тем меньше ущерб от одной успешной инъекции.
  • Для чувствительных действий использовать подтверждение человеком (approval), а не полагаться на то, что агент сам распознает подделку.
  • Там, где возможно, использовать structured outputs и валидацию данных между этапами агентного пайплайна вместо свободного текста — OpenAI приводит тот же принцип: структурированные каналы между шагами убирают свободный текст, которым может воспользоваться атака.

Шаг 5. Соберите маршрут пилота на сквозном примере

Удобный ориентир для проверки всей цепочки — обработка результатов встречи с клиентом. На входе агент получает расшифровку звонка. Дальше он выделяет из неё договорённости, готовит на их основе итоговое письмо и формирует предложения по обновлению CRM. На выходе — не автоматическое изменение данных, а предложения, которые превращаются в задачи только после того, как менеджер их подтвердил. Этот пример хорош тем, что в нём видны сразу все элементы карточки из шага 1: вход, обработка с решениями, действие с подтверждением и точка, где человек остаётся последней инстанцией.

Шаг 6. Проверьте агента на тестовых сценариях

В терминологии Anthropic такая проверка называется eval: агенту дают входные данные и применяют логику оценки к результату, чтобы измерить успех. Отдельный тест-кейс — это конкретные входные данные и заранее заданные критерии успеха. Для агентов оценивать сложнее, чем для обычного чат-бота: агент делает несколько шагов, использует инструменты, меняет состояние системы и подстраивается под промежуточные результаты, а ошибка на одном шаге может распространиться на следующие. Поэтому проверять нужно не только итоговый текст, но и весь маршрут — какие инструменты были вызваны и в каком порядке.

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

Шаг 7. Проведите первый запуск и стройте цикл улучшений

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

Чек-лист готовности первого ИИ-помощника

  • Выбран один конкретный процесс, а не общая задача «внедрить ИИ»
  • Заполнена карточка пилота: вход, результат, решения, системы, метрики
  • Проверено, что задачу нельзя решить проще — одним вызовом LLM или предопределённым workflow
  • Описана роль агента и список запрещённых действий
  • Определены условия, при которых агент останавливается или передаёт решение человеку
  • Знания привязаны к конкретным решениям процесса, а не просто загружены как файлы
  • Инструменты разделены на «для контекста» и «для действий», действия с подтверждением помечены отдельно
  • Собран сквозной пример пилота от входа до подтверждённого результата
  • Написаны тест-кейсы: обычный путь, передача человеку, запретное действие, сбой с остановкой
  • Метрики зафиксированы до запуска, а не после

Источники

Читайте также

Похожие записи