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

ИИ-ассистент становится агентом, когда получает возможность вызывать инструменты: читать базу, менять настройки, создавать задания или отправлять сообщения. Граница между советом и действием должна быть определена заранее. Фраза «действуй осторожно» в инструкции не заменяет технические ограничения.

Разделите задачу и полномочия

В OWASP риск Excessive Agency описан через избыточные функции, права и самостоятельность системы. Рекомендации включают минимально необходимые инструменты, проверку полномочий вне языковой модели и дополнительное согласование значимых действий. Это инженерные меры ограничения риска, а не обещание полной безопасности.

Практическое применение CRM Lab — строить доступ от конкретного процесса. Если задача помощника — подготовить черновик, ему не нужен инструмент отправки. Если нужно объяснять показатели, ему не обязательно видеть адреса и телефоны клиентов. Передачу клиентских данных в ИИ-сервис оценивают отдельно от удобства интерфейса.

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

Составьте матрицу действий

ДействиеРазумная граница для первого внедрения
Объяснить агрегированный отчётЧитать разрешённые показатели без персональных строк
Подготовить текст и условия сегментаСохранить отдельный черновик
Изменить действующую кампаниюСоздать предложение новой версии
Запустить отправку или выдать скидкуВыполнить после установленного согласования и проверок
Изменить права или снять запрет на контактИсключить из инструментов помощника

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

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

Согласовывайте конкретную версию

Кнопка «Одобрить» имеет смысл, если человек видит, что именно произойдёт: аудитория, канал, текст, условия предложения, время и предельный объём. Формулировки «помочь с реактивацией» недостаточно для разрешения реальной кампании.

Условный пример. Маркетолог одобрил письмо 5 000 клиентам со скидкой 10%. После одобрения помощник уточнил сегмент и получил 18 000 адресатов. Старое согласование не должно разрешать новую отправку. Система связывает разрешение с неизменяемой версией задания и требует повторного согласования при изменении существенных параметров.

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

Сделайте ограничения исполнимыми

Инструмент принимает только заранее описанные параметры. Сервер проверяет тип действия, допустимые значения, права пользователя и состояние объекта. Свободный текст из ответа модели не должен превращаться в произвольную команду к базе или платформе.

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

Лимиты объёма, суммы скидок и частоты вызовов помогают ограничить масштаб ошибки. Их значения определяют по реальным процессам. Они не доказывают правильность операции: отправка 100 неверных писем остаётся неверной, даже если лимит равен 1 000.

Подготовьте наблюдение и остановку

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

Механизм аварийной остановки должен отключать дальнейшие действия и останавливать ещё не обработанную очередь. Уже отправленное письмо вернуть нельзя, поэтому план реакции включает оценку последствий и решение о корректирующей коммуникации.

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

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

Источники

OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. OWASP Top 10 for Large Language Model Applications. Редакция 2025.