Как контролировать ИИ-агента: права и проверки

Контроль нужен не только ответу, но и действию

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

Ниже — проектный чек-лист для обсуждения внедрения. Он не описывает уже установленную клиентскую систему и не обещает защиту от всех ошибок.

1. Выдавайте права по задаче

Для составления сводки не нужен доступ к удалению исходных данных. Для черновика КП не требуется право отправлять его клиентам. Начинайте с чтения нужных источников и добавляйте операции только после отдельной проверки.

Разделяйте инструменты по последствиям. Лучше иметь узкую операцию «сохранить черновик в согласованную папку», чем один универсальный инструмент с возможностью менять всё в аккаунте.

В OWASP LLM06:2025 Excessive Agency избыточные возможности, права и автономность рассматриваются как источники риска. Среди мер — ограничение полномочий и участие человека перед значимыми действиями. Это основа для проектирования контроля, а не сертификат безопасности системы.

2. Подтверждайте конкретную версию

Фраза «можно отправлять» слишком общая. Для важной операции ответственному нужно увидеть получателя или объект, содержание, параметры и последствия. Подтверждение привязывают к этой версии действия.

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

3. Не превращайте входящий файл в инструкцию

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

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

4. Различайте отказ и неизвестный результат

Условный пример: инструмент отправил запрос на создание записи, но ответ не пришёл вовремя. Это ещё не доказывает, что запись не создана. Слепой повтор может сделать дубль.

Перед повторной важной операцией полезно сверить идентификатор и фактический статус. Если сервис не позволяет надёжно установить результат, нужна остановка и ручная проверка, а не бесконечные повторные запросы.

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

5. Ограничьте работу и расходы

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

Подход к выбору простой схемы вместо лишней автономности описан и в материале Anthropic Building effective agents: фиксированные процессы и агенты решают разные задачи. Если путь заранее известен, сложный агент может быть не нужен.

6. Ведите журнал без лишних секретов

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

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

7. Проверьте отказы до рабочего запуска

• В исходных данных нет обязательного поля — агент уточняет, а не выдумывает его.
• Предложен недопустимый объект — инструмент отказывает.
• После утверждения изменился файл — требуется новое подтверждение.
• API не ответил — число повторов ограничено, статус сохранён.
• Результат предыдущего запроса неизвестен — сначала выполняется сверка.
• Во входящем документе есть вредная инструкция — права не расширяются.
• Достигнут лимит — процесс останавливается и передаёт вопрос человеку.

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

С чего начать

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

Подробности внедрения — разработка ИИ-агентов для бизнеса. Для конкретного примера подготовки черновика посмотрите КП из прайса и шаблона.

Схема и чек-лист — проектные рекомендации. Они не являются результатом аудита конкретной системы. Обложка создана с помощью ИИ; технические примеры условные.