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

Начните не с списка инструментов, а с последствий

Перед запуском агента команда часто обсуждает, к каким сервисам его подключить. Полезнее начать с другого вопроса: что произойдёт, если агент неправильно поймёт запрос? Ошибка при поиске документа обычно исправима. Неверно отправленное клиенту письмо, удалённая запись или изменённый платёжный реквизит могут иметь внешние последствия. Эти действия нельзя помещать в одну категорию «агент умеет работать с API».

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

Разделите работу на уровни

Первый уровень — чтение. Агент ищет информацию в ограниченном наборе документов, формирует краткое резюме и указывает источники. Второй — подготовка черновика: он может предложить письмо, таблицу или изменения, но не сохраняет их во внешней системе. Третий — действие после подтверждения: человек просматривает diff или полный текст и нажимает отдельную кнопку. Последний уровень — автономное выполнение. Для первого пилота обычно достаточно первых двух; третий подключают только для безопасных, обратимых задач.

Сделайте перечень операций в формате «можно», «только с подтверждением», «запрещено». Например: читать заявки — можно; создавать черновик ответа — можно; отправлять клиенту — только после проверки; менять сумму возврата — запрещено. Уточните, кто выдал доступ и как его отозвать. Используйте отдельную учётную запись с минимальными правами, а не персональный токен сотрудника с доступом ко всему.

Спроектируйте подтверждение, которое действительно защищает

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

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

Подготовьте тестовый набор до первой демонстрации

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

Измеряйте не абстрактную «точность», а конкретные ошибки: выдуманные поля, пропущенные ограничения, неверного адресата, повторный вызов, лишний доступ и время ручной проверки. Сохраняйте исходный результат отдельно от исправленного. Тогда можно сравнивать модели и версии без впечатления, что «в этот раз ответ звучал убедительнее». Подход к минимальным тест-кейсам мы разбирали в статье о проверке агентов; для поиска уязвимого поведения пригодится практика тестирования prompt injection.

Проведите пилот короткими циклами

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

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

После пилота решайте, что масштабировать

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

FAQ

Можно ли дать агенту право только на чтение?

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

Какое действие первым автоматизировать?

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

Сколько примеров нужно для пилота?

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

Вывод

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