Производственный AI-агент — не «автономный сотрудник», а управляемый компонент бизнес-процесса с определёнными входами, разрешёнными действиями, лимитами и правилами остановки. Он может классифицировать обращения, искать утверждённый контекст, готовить черновики и вызывать ограниченные инструменты. Но до подключения к CRM, ERP, сервис-деску или хранилищу документов необходимо доказать, что агент выполняет ожидаемые действия, не выполняет запрещённые и передаёт неоднозначные либо рискованные случаи человеку.

Именно это дают AI agent evaluation services. Демонстрация может показать связный текст. Производственная оценка отвечает на более сложные вопросы: обновляет ли агент только разрешённую запись CRM? Создаёт ли дубликат заказа после повтора запроса? Меняет ли вредная инструкция внутри письма ход процесса? Не сообщает ли агент об успехе, если API ERP вернул тайм-аут? Запрашивает ли он подтверждение перед платежом, выгрузкой персональных данных или необратимым изменением?

Что оценивают при проверке AI-агента

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

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

В область проверки должна входить и безопасность. OWASP относит prompt injection и excessive agency к ключевым рискам LLM-приложений. В агентном процессе непроверенный документ, тикет или веб-страница могут содержать инструкции, конфликтующие с задачей. Слишком широкие инструменты, учётные данные и автономность способны превратить ошибочный вывод модели в реальное действие. Поэтому защита не должна находиться только в system prompt: она нужна в контрактах инструментов, контроле доступа, детерминированных правилах и точках согласования.

Соберите набор оценочных сценариев из реальной работы

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

Что должен содержать каждый тестовый сценарий

  • Исходное состояние: роль пользователя, статус клиента или кейса, доступные документы, предыдущие действия и бизнес-правила.
  • Входная задача: запрос, письмо, форма, тикет или документ, который получает агент.
  • Ожидаемое действие: разрешённый инструмент, обязательные параметры, создаваемый черновик, очередь или уточняющий вопрос.
  • Запрещённые действия: например, изменение платёжных реквизитов, выгрузка несвязанных данных, отправка внешнего письма или смена статуса без согласования.
  • Критерий приёмки: корректное выполнение, корректный отказ или эскалация, правдивый статус и трассировка, пригодная для аудита.

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

Проверка ожидаемых действий: оценивайте процесс, а не только текст

AI agent testing должна измерять видимый ответ и последовательность действий. Разные формулировки клиента могут означать одно намерение, однако исполнение должно оставаться в рамках утверждённых маршрутов.

  • Запрашивает ли агент недостающие данные вместо догадки?
  • Выбирает ли он зарегистрированный инструмент с проверяемой схемой?
  • Передаёт ли правильные идентификаторы, сумму, валюту и переход статуса?
  • Отделяет ли чтение данных от операции записи?
  • Получает ли согласование человека до действия с побочным эффектом?
  • Проверяет ли результат инструмента до заявления об успехе?

Детерминированные правила нельзя оставлять на усмотрение модели. Правило «платёж выше установленного лимита требует согласования финансового отдела» должно исполняться приложением, а не интерпретироваться языковой моделью. Агент может подготовить заявку, собрать доказательства и направить её нужному согласующему, но механизм процесса обязан заблокировать исполнение до подтверждения.

Проверяйте границы прав доступа отдельно от качества выполнения задачи

Даже при правильном намерении агент может создать инцидент, если его идентичность или токен инструмента имеют лишний доступ. Принцип наименьших привилегий нужно тестировать по агенту, инструменту, пользователю, подразделению и, если система это поддерживает, по отдельной записи.

Практическая матрица проверки прав

  • Граница роли: может ли агент поддержки продаж читать или изменять финансовые записи?
  • Граница подразделения или tenant: раскрывает ли запрос одного подразделения данные другого?
  • Граница операции: может ли учётная запись для чтения инициировать путь записи?
  • Граница суммы и объёма: превращается ли разрешение на безопасное изменение в массовое обновление или крупную операцию?
  • Граница данных: появляются ли лишние персональные или конфиденциальные данные в параметрах, ответах инструмента либо трассировках?

Такие тесты нужно проектировать вместе с интеграционной архитектурой, а не добавлять после разработки агента. В контролируемой реализации AI-решений и автоматизации CRM, ERP и система документов остаются системами учёта. Агент работает через именованные операции с ограниченными входами, проверяемой идентичностью и политиками, а не через неограниченный доступ к базе данных.

Проверяйте сбои вызовов инструментов, а не только успешный сценарий

В реальных процессах возникают тайм-ауты, rate limit, частичное завершение, устаревшие данные, повторные webhook-события и недоступность зависимостей. Безопасное поведение после ошибки вызова — это обычно не бесконечный повтор и не сообщение пользователю «всё выполнено».

В набор тестов стоит включить:

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

Для операций записи нужны correlation ID, idempotency key, подтверждённый финальный статус и сценарий восстановления. Агент не должен сообщать «заказ создан», пока система учёта не подтвердила результат. Иначе за аккуратным диалогом могут скрываться потерянная заявка, дубликат или действие, ожидающее сверки.

AI agent red teaming: тестирование prompt injection и небезопасных инструкций

Проверка prompt injection не должна сводиться к фразе пользователя «игнорируй инструкции». Агент может встретить вредные указания внутри входящего письма, вложения, веб-страницы, заметки CRM, поискового результата или статьи базы знаний. В red-team сценариях такой контент подаётся как правдоподобный рабочий артефакт, а команда наблюдает: воспринимает ли агент его как недоверенные данные или как команду.

Тесты должны включать попытки раскрыть системные инструкции, изменить банковские реквизиты, искать несвязанные записи, отправить данные на внешний адрес, обойти согласование либо подменить параметры инструмента. Успешный контроль — это не просто отказ. Агент должен по возможности завершить легитимную часть работы, зафиксировать рискованный контент и передать случай человеку, когда решение требует его участия.

До запуска определите критерии согласования и эскалации

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

Распространённые поводы для согласования человеком

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

Экран согласования должен содержать достаточно контекста: исходный запрос, предлагаемое действие, источники, параметры инструмента, причину политики, метку риска и путь отката. Проектирование такого экрана как полноценного операционного интерфейса, а не формальной кнопки «подтвердить», относится к работе по UI/UX и продуктовому дизайну.

Запускайте регрессионные проверки после каждого существенного изменения

Смена модели, system prompt, логики оркестрации, схемы инструмента, базы retrieval, политики доступа или API CRM/ERP означает изменение агента. Перед релизом необходимо прогонять фиксированный набор сценариев, сравнивать его с базовой линией и применять блокирующие пороги для критических случаев.

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

Операционный scorecard для решения о запуске

Для готовности к production используйте scorecard по классам риска, а не один агрегированный балл:

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

Профиль NIST по генеративному AI рассматривает управление рисками как работу на всём жизненном цикле, включая testing, evaluation, verification и validation. На практике это значит, что готовность агента к запуску — не решение после одной демонстрации, а повторяемый процесс доказательств: определить безопасное поведение, проверить реальные и adversarial сценарии, выпустить в ограниченном контуре, наблюдать результаты и переоценивать систему после изменений.

Как POLADO проводит оценку AI-агентов

POLADO помогает сначала описать бизнес-процесс, системы учёта и точки решений с высоким влиянием, а затем подключать агента к рабочим операциям. В объём могут входить набор сценариев из реальных случаев, контракты tool call, матрица прав, правила согласования, adversarial-тесты, regression suite и операционный scorecard. Цель не в том, чтобы сделать агента «более автономным», а в том, чтобы доказать его полезную работу в обоснованных границах.

Если вы планируете агента для CRM, ERP, поддержки, документов или внутренних операций, свяжитесь с POLADO. Мы рассмотрим целевую архитектуру и определим план AI agent testing, готовый к производственному запуску.