AI-агент прочитал письмо, нашёл сделку и предложил поменять сумму. Самая опасная кнопка здесь не «Запустить», а незаметное автоматическое подтверждение. Модель может правильно понять задачу и всё равно выбрать не тот объект, повторить запрос после timeout или получить вредную инструкцию из входного текста.
Первое, что я бы проверил: какие инструменты агента только читают данные, а какие меняют состояние. Пока этого списка нет, агенту рано выдавать write-доступ.
Разделите инструменты по риску
| Класс | Пример | Режим |
|---|---|---|
| Чтение | Получить карточку сделки | Автоматически, с лимитом |
| Обратимая запись | Создать черновик задачи | Preview или отмена |
| Внешнее действие | Отправить письмо | Подтверждение |
| Необратимое | Удалить запись | Строгое подтверждение или запрет |
Риск определяет серверная политика. Не просите модель самой решить, нужен ли ей контроль: исполнитель не должен отключать собственный предохранитель.
Соберите preview, который нельзя подменить
- Модель формирует вызов инструмента.
- Сервер валидирует JSON Schema и права.
- Из аргументов строится preview: объект, поля, старые и новые значения.
- Сериализованные аргументы хешируются.
- После approval сервер проверяет hash и состояние объекта.
- Запись выполняется с idempotency key.
{
"tool": "crm.deal.update",
"object_id": 4812,
"changes": { "NEXT_STEP": "Позвонить 12 сентября" },
"expected_version": 17,
"idempotency_key": "run_8f2:call_03"
}expected_version в примере — поле интеграционного слоя, а не универсальный параметр CRM. Оно блокирует запись в карточку, которую менеджер уже изменил после preview.
Как выглядит PASS и FAIL
- PASS: пользователь видит объект и изменения.
- PASS: одинаковый ключ не создаёт второе действие.
- PASS: журнал хранит tool call id, actor, время и outcome.
- FAIL: окно спрашивает только «Разрешить AI продолжить?».
- FAIL: после approval модель формирует новые аргументы.
- FAIL: сетевой повтор отправляет второе письмо.
Проверка на стенде
Создайте тестовую сделку и прогоните обычное подтверждение, отказ, изменение карточки между preview и approval и timeout после успешной записи. В последнем сценарии клиент повторяет запрос с тем же ключом. Сервер возвращает исходный outcome, а не повторяет действие.
На практике здесь чаще всего ломается граница между предложением и исполнением. UI показывает красивое резюме, а backend принимает новый JSON от модели. Подтверждайте байты операции, не пересказ.
Частые ошибки
Один approval на весь запуск. Согласие прочитать письмо не разрешает удалить контакт.
Нет повторной проверки прав. Между preview и кликом роль могла измениться.
Решение только в памяти. После рестарта нельзя объяснить действие.
Нет срока. Старое approval применяют к изменившейся карточке.
Чек-лист перед production
- Инструменты классифицированы по риску.
- Write-аргументы валидирует сервер.
- Preview связан с hash.
- Есть срок approval.
- Права проверяются перед исполнением.
- Повтор защищён idempotency key.
- Audit trail не содержит секреты.
Матрица решений для реального процесса
Не все изменения в CRM одинаковы. Добавление внутренней заметки можно сделать обратимым: агент пишет черновик, менеджер видит автора и удаляет запись при ошибке. Отправка письма уже выходит за границу системы. Изменение суммы или реквизитов влияет на документы. Удаление сущности может оборвать связи. Для каждого инструмента запишите владельца риска, условия автоматического режима и максимальный радиус ошибки.
Полезный тест: дайте агенту две сделки с похожими названиями и попросите обновить одну. Preview обязан показать числовой идентификатор, клиента и текущую стадию. Если человек видит только название, выбор нельзя проверить. Для массовой операции показывайте количество объектов и несколько примеров, а при превышении лимита требуйте отдельное подтверждение.
Повторная проверка перед execute
Между решением человека и записью может пройти минута. За это время менеджер перевёл сделку на другую стадию. Сервер повторно читает объект и сравнивает версию или значимые поля. Несовпадение переводит действие в статус stale; агент строит новый preview, но не исполняет старый. Это защищает от корректного по форме, но уже неверного по контексту действия.
Что записать в протокол испытаний
Для каждого теста сохраните исходный запрос, выбранный инструмент, нормализованные аргументы, hash preview, решение человека и ответ CRM. Секреты и персональные данные маскируйте до записи. Отдельно фиксируйте причину автоматического допуска read-only операции. Если политика дала разный результат на одинаковых аргументах, запуск нельзя считать стабильным.
Проверьте отказ интерфейса: пользователь открыл preview и закрыл вкладку. Действие остаётся pending до срока, после чего переходит в expired. Оно не должно выполниться при следующем входе само. Затем проверьте явный reject: модель получает контролируемый результат отказа и не пытается вызвать другой write-инструмент с тем же смыслом.
Для bulk-операций добавьте лимит объектов и денег на один approval. Сто сделок нельзя прятать за одной строкой «обновить воронку». Сервер показывает выборку, точное количество и параметры фильтра. Если набор изменился, старое решение аннулируется.
Последний контроль выполняйте не на happy path. Подставьте неизвестный идентификатор, пустое обязательное поле, объект без прав и повтор уже исполненного call id. Во всех четырёх случаях система должна остановиться до CRM API или вернуть прежний outcome. Только после этого approval gate можно считать рабочим.
Что делать, если не помогло
Отключите write-инструменты и оставьте агенту режим рекомендаций. Сохраните run state, tool call id, hash, решение и ответ CRM. Дубли разбирает статья про двойной AI-webhook, а входной текст — материал про prompt injection. CTR1 может спроектировать AI-автоматизацию с контролируемой записью в CRM.
