Какие полномочия я готов дать AI-агенту

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

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

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

Начинаю с конкретного действия

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

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

Такую границу можно проверить технически. Общая инструкция «будь осторожен» не заменяет ограничения в самой системе.

Здесь важна роль владельца процесса: именно он объясняет, какие последствия допустимы и какие решения нельзя передавать автоматически.

Разделяю режимы работы

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

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

Проверяю, что именно подтверждает человек

Кнопка «одобрить» полезна только тогда, когда сотрудник видит существенные детали. Для письма это адресат, окончательный текст и вложения. Для изменения записи — объект, прежнее значение и новое значение.

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

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

Конкретная реализация зависит от системы, но смысл один: согласие должно быть связано с понятной операцией.

Задаю условия остановки

Полезный агент не обязан всегда доводить действие до выполнения. Иногда правильный результат — объяснить, почему продолжение невозможно.

В условном процессе обработки заказа я бы выделил такие ситуации:

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

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

Разбираю повторные попытки

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

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

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

Хочу видеть журнал и возможность отключения

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

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

Расширять полномочия проще, когда эти вопросы решены заранее. Сначала ограниченная задача, затем проверка и наблюдение, после этого — обоснованное изменение границ.

Моя цель здесь — сделать поведение системы объяснимым для бизнеса. Когда понятно, что агент вправе сделать и когда обязан остановиться, с ним гораздо проще работать и оценивать его пользу.

Учебный тест: согласование действует на конкретный объект

Этот пример дополняет авторский разбор полномочий. Используются вымышленные заказ и черновик; никаких реальных писем или изменений заказа упражнение не выполняет.

Меняйте только одно условие за попытку

Зафиксируйте объект DEMO-ORDER, версию черновика и адресата, которые разрешил человек. Затем отдельно измените каждое поле. Проверка показывает, привязано ли разрешение к конкретному действию или случайно стало общим правом выполнять любые похожие действия.

Сохраните разрешённый набор полей и результаты отказов. Этот тест не заменяет проверку доступа к данным и общего контура безопасности; он проверяет одну границу действия.