Сколько свободы дать ИИ-агенту: решаем по действиям, а не по впечатлению от демо
Какие действия ИИ-агенту разрешить самому, какие подтверждать человеку и какие запретить? Матрица прав, последствий и проверки ограничений перед пилотом.
Агент может хорошо подготовить ответ на обращение. Это ещё не повод дать ему кнопку «Отправить». Черновик можно исправить до того, как его увидит адресат; отправленное сообщение уже меняет отношения с клиентом. Поэтому руководителю полезно назначать права для каждого действия отдельно: что агент только предлагает, что выполняет после подтверждения и что может делать сам в узких границах.
Даже удачный тест ответов не говорит, какие полномочия допустимы. Режим зависит от данных, возможного ущерба, возможности заметить ошибку и отменить действие. Технический доступ должен соответствовать решению: фразы «не отправляй без спроса» в инструкции недостаточно, если у агента уже есть рабочий ключ с правом отправки.
Три режима для одного действия
Это редакционная шкала для принятия решения, а не универсальный стандарт безопасности.
- Только предлагает. Агент читает разрешённый вход и делает черновик. Человек сам переносит его в рабочую систему или отклоняет.
- Выполняет после подтверждения. Агент подготавливает конкретную операцию, человек видит содержание, адресата и последствия и разрешает вызов инструмента до его выполнения. Одного общего согласия «можно работать с CRM» недостаточно для всех будущих операций.
- Выполняет в заданных границах. Агенту разрешено конкретное повторяемое действие с техническими лимитами, журналом и способом остановки. Подходит лишь там, где ошибка достаточно быстро обнаруживается, ущерб ограничен, а результат можно исправить приемлемой ценой.
Есть и четвёртый исход: не выдавать доступ. Если действие затрагивает деньги, персональные данные, права людей или необратимые изменения, сначала нужен разбор с владельцем процесса и профильным специалистом. Подтверждающий клик не исправит плохие исходные данные и не делает любую операцию безопасной. Для чувствительного вызова инструмента OpenAI описывает остановку на подтверждение человека. Для других значимых цепочек OWASP допускает человеческое одобрение или автоматический контроль по заранее заданной политике. Выбор зависит от последствий конкретного действия: автоматическая проверка не является согласием человека и не должна обходить назначенную точку подтверждения.
Матрица полномочий: заполните до подключения системы
Для каждой строки укажите не абстрактную «степень доверия агенту», а точное действие и доступ. Таблица ниже — заготовка; добавьте свои ресурсы и владельцев решения.
| Действие и ресурс | Что будет при ошибке | Как обнаружить и можно ли отменить | Доступ и режим | Кто подтверждает / пересматривает | Журнал и остановка |
|---|---|---|---|---|---|
| Прочитать разрешённый вход | Какие данные могут раскрыться? | Кто увидит лишний доступ? | Только нужные записи; режим ___ | Владелец данных ___ | Где видны обращения к данным; как отозвать ключ ___ |
| Сделать черновик | Какой неверный факт попадёт в текст? | Проверка человеком до использования | Без права отправки; режим ___ | Редактор/сотрудник ___ | Сохранить исходный текст и версию черновика ___ |
| Создать/изменить запись | Кому помешает неверная запись? | Сверка и откат ___ | Только нужный тип записи; режим ___ | Владелец процесса ___ | Журнал изменения; остановка записи ___ |
| Отправить наружу / удалить | Каков максимальный ущерб? | Возможно ли реально вернуть действие? | Режим ___ или запрет | Ответственный ___ | Подтверждение до вызова; отзыв доступа ___ |
Проверьте две вещи, которые легко упустить. Во-первых, агенту может быть достаточно чтения отдельных полей, хотя интеграция по умолчанию просит более широкий доступ. Во-вторых, срок действия ключа и отзыв прав должны быть технически осуществимы. Принцип минимальных привилегий и одобрения значимых необратимых цепочек описан в рекомендациях OWASP по AI Security and Privacy. Применимость конкретного механизма зависит от системы, которую вы подключаете.
Как выглядит решение на одном учебном процессе
Учебный пример, не случай из компании. Допустим, сотрудник разбирает обезличенные входящие вопросы и ведёт тестовую доску задач. Цель — сократить ручное переписывание, не отдавая агенту переписку с реальными людьми.
| Действие | Режим в пробном запуске | Почему |
|---|---|---|
| Прочитать обезличенный текст, который сотрудник сам передал для теста | Выполняет в заданных границах: читает только переданный текст | Нет доступа ко всей почте; сотрудник контролирует вход |
| Составить черновик ответа | Только предлагает | Сотрудник проверит факты и тон до использования |
| Создать карточку в тестовой доске | В заданных границах: только одна тестовая карточка за запуск, с журналом и возможностью удаления | Ошибку видно и можно исправить; доступ ограничен тестовой доской, ответственный просматривает записи и останавливает запуск при ошибке |
| Изменить действующую запись о клиенте | После подтверждения конкретного изменения либо запрет | Ошибка повлияет на дальнейшую работу команды; сначала нужен способ сверки и отката |
| Отправить письмо клиенту или удалить рабочую запись | Не разрешать в этой пробе | Последствия выходят за пределы теста, а отправленное письмо нельзя забрать обратно |
Если агент создал карточку с неверным сроком, остановите автоматическую запись, сохраните вход и выход, исправьте запись и разберите причину. Возможно, достаточно правила «срок не указан» или обычной формы без ИИ. Повторяющаяся операция с чёткими правилами иногда надёжнее выполняется простой автоматизацией; свободный текст и неопределённость — повод для черновика и человеческой проверки, а не автоматического расширения прав.
Проверьте ограничители перед реальным пилотом
В тестовой среде попытайтесь выполнить запрещённое действие и проверьте, что его блокирует сама система: отсутствие права, необходимость подтверждения перед вызовом или отдельный технический лимит. Затем отзовите ключ и убедитесь, что новое действие не проходит. Проверьте журнал: видны ли вход, предложенное действие, решение человека, время и результат. Для автоматического режима заранее задайте предел объёма и уведомление при его превышении. Назначьте ответственного за уведомления и просмотр журнала, иначе он может остаться без внимания.
Разработчик может предусмотреть шаг подтверждения, но руководителю всё равно нужно назначить человека, который способен понять последствия. NIST AI RMF Measure предлагает оценивать систему в конкретном контексте, включая человеческий контроль, исключения и решение о продолжении. Здесь практический вывод прост: если вы не можете назвать, кто заметит ошибку, как быстро и что сделает после неё, оставьте действие в режиме предложения.
Когда агент стабильно проходит проверку качества, пересматривайте отдельные строки матрицы, а не выдавайте ему «полную автономию». Даже при переносе агента на другой компьютер или сервер права нужно задавать заново для конкретных ресурсов. Для проверки самих ответов, прежде чем обсуждать рабочие доступы, используйте сценарии проверки помощника.
Комментарии
Обсуждение этой статьи пока закрыто.