Как проверить ИИ-агента перед доступом к рабочей системе

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

Шаг 1. Опишите единственный результат

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

Шаг 2. Нарисуйте карту разрешений

Разделите операции на чтение, подготовку черновика и необратимое изменение. Каждой операции назначьте отдельный токен или роль. Агенту для классификации не нужен доступ к отправке писем; агенту для отчёта не нужен ключ к биллингу. Разрешайте только конкретные каталоги и методы API, задавайте срок жизни ключа и фиксируйте владельца.

Шаг 3. Соберите безопасный набор данных

Скопируйте десять–двадцать реальных примеров, удалите имена, телефоны и секреты, добавьте пограничные случаи. Включите письмо с неверным номером, пустое вложение и инструкцию внутри документа, которая пытается изменить правила агента. Такой набор проверяет не красоту ответа, а способность остановиться и попросить человека.

Шаг 4. Введите режим предварительного просмотра

Первые запуски должны только показывать план действий: какие файлы прочитаны, какой вызов будет сделан и какие поля изменятся. Кнопка подтверждения должна быть отдельной от текста модели. Если инструмент не объясняет причину действия, не подключайте его к боевой системе. Сценарий первого процесса автоматизации поможет разложить пилот по дням.

Шаг 5. Проверьте отказ и повтор

Отключите внешний API, подмените ответ пустым, верните тайм-аут и повторите один и тот же запрос несколько раз. Агент не должен создавать дубли, уходить в бесконечный цикл или считать отказ успешной операцией. Для каждого повтора задайте предел, после которого управление возвращается оператору.

Шаг 6. Включите журнал и откат

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

Шаг 7. Примите решение по метрикам

Сравните не количество выполненных шагов, а долю корректных результатов, число остановленных опасных действий, среднее время до подтверждения и стоимость ручной проверки. Если агент экономит три минуты, но создаёт один трудный для расследования сбой в неделю, пилот ещё не готов. Для очистки входных файлов используйте локальный CSV-санитайзер, а спорные ответы прогоняйте через проверку источников.

Вывод

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

Перед публикацией

Сохраните исходный пример, версию модели и дату проверки. Уберите персональные данные и секреты, дайте результат прочитать человеку, который не участвовал в постановке задачи. Если ответ нельзя быстро подтвердить по исходным данным, пометьте его черновиком. Такой простой контроль защищает от тихих ошибок лучше, чем уверенный тон модели.

FAQ

С какого действия начать проверку агента?

С узкого результата, который можно отменить: например, подготовить черновик, но не отправить его. Так граница риска видна до выдачи полномочий.

Нужен ли отдельный ключ для каждого инструмента?

Желательно. Раздельные роли упрощают аудит и позволяют отключить один вызов, не меняя остальные разрешения.

Когда расширять права?

После повторяемого теста на новых данных, включая отказы и запрещённые инструкции. Один удачный сценарий не является основанием.

Минимальный протокол приёмки

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