Правильный признак для разделения прав ИИ-агента — не важность операции и не её тема, а обратимость: можно ли вернуть систему в прежнее состояние, если агент ошибся. Неверно посчитанная скидка в черновике коммерческого предложения — рабочий момент. Та же скидка в письме, ушедшем клиенту, — обязательство компании. Действие одно, разница только в том, что второе нельзя отменить.
Это меняет постановку задачи. Обсуждать надо не то, насколько хороша модель и как часто она ошибается, — ошибаться она будет всегда, вопрос только в доле. Обсуждать надо, что произойдёт с конкретной ошибкой: она останется строкой в журнале, которую поправят за минуту, или превратится в проведённый документ, отправленное письмо и разговор с клиентом. Ограничители ставятся исходя из второго ответа, а не из первого.
Дальше — три класса действий по обратимости, список из двенадцати операций, которые не отдаются агенту без подписи человека, четыре ограничителя, которые живут в коде, а не в промпте, разбор того, как сделать подтверждение неформальным, три сценария отказа и расчёт стоимости контура отката в рублях.
Три класса действий по обратимости
Классификация нужна не ради классификации: от класса зависит, что именно строится вокруг действия. Для первого класса не строится ничего, для второго — лимиты и журнал, для третьего — обязательная остановка на человеке.
| Класс | Примеры | Правило | Что нужно для возврата |
|---|---|---|---|
| Полностью обратимые | Прочитать данные, создать черновик, поставить задачу, добавить комментарий, найти документ | Агент делает сам, без подтверждения | Удалить созданное или отредактировать — состояние восстанавливается целиком |
| Обратимые с потерями | Изменить поле в карточке, переставить сделку по воронке, создать непроведённый документ, поменять статус заявки | Агент делает сам в пределах лимитов, каждое действие пишется в журнал с прежним значением | Откат по журналу возможен, но время потрачено, а внутренние отчёты за период уже посчитаны |
| Необратимые | Платёж, отправленное сообщение, проведённый документ, удалённая запись, публикация во внешнем канале | Только через подтверждение человека; агент готовит, человек подписывает | Возврата нет. Есть компенсирующее действие: письмо с извинением, сторно, возврат денег |
То, что делают вместо отката, когда откат невозможен: сторнирующая проводка вместо удаления, письмо с исправлением вместо отзыва отправленного, возврат денег вместо отмены платежа. Компенсация никогда не возвращает состояние полностью — она оставляет след в учёте, в переписке с клиентом и в чужой почте. Именно поэтому третий класс отделён от второго: не потому, что там дороже ошибка, а потому, что там нечем её убрать.
Полезное следствие: граница проходит не там, где её обычно рисуют. «Изменить цену в карточке товара» звучит серьёзнее, чем «отправить клиенту сообщение», но цена откатывается за секунду, а сообщение — нет. Поэтому в списке ограничений отправка сообщений оказывается строже, чем правка справочника, и это регулярно удивляет заказчиков на этапе согласования.
Схема с тремя дорожками слева направо. Верхняя «Полностью обратимые» — стрелка идёт напрямую в блок «Выполнено», подпись «без подтверждения». Средняя «Обратимые с потерями» — стрелка проходит через блок «Лимиты» и блок «Журнал с прежним значением», подпись «откат по журналу». Нижняя «Необратимые» — стрелка упирается в закрытые ворота «Подтверждение человека», после ворот блок «Выполнено», ниже подпись «возврата нет, только компенсация». Чертёжный стиль, подписи по-русски.
Двенадцать операций, которые не отдаются агенту без человека
Список закрытый и короткий — это его главное свойство. Попытка описать запреты через темы («не обещай скидок», «не говори о возвратах») не работает: тем бесконечно много, и каждая новая формулировка проходит мимо запрета. Операций же конечное число, и они перечисляются один раз.
| Операция | Почему её не откатить | Что ставится вместо |
|---|---|---|
| 1. Платёж, перевод, списание с расчётного счёта | Деньги ушли; возврат — отдельная процедура с чужой стороной | Агент готовит платёж, проводит человек в банк-клиенте |
| 2. Изменение платёжных реквизитов контрагента | Следующий платёж уйдёт по новым реквизитам и уже необратим | Только черновик с подтверждением бухгалтерии, сверка с первичным документом |
| 3. Отправка сообщения клиенту в почту или мессенджер | Прочитано; отзыв сообщения не отменяет прочтения | Черновик в карточке, отправка по кнопке сотрудника |
| 4. Массовая рассылка | Ошибка умножается на размер базы за секунды | Тестовая отправка на внутренний список, лимит на размер партии, подтверждение на запуск |
| 5. Изменение цены и скидки в каталоге или прайсе | Заказы, оформленные по ошибочной цене, придётся исполнять | Черновик изменения, лимит на отклонение от базовой цены, подтверждение |
| 6. Проведение и распроведение документа в учётной системе | Едут остатки, взаиморасчёты и отчётность за период | Агент создаёт документ в статусе черновика, проводит человек |
| 7. Удаление документа, карточки, файла | Данные исчезают вместе с историей | Пометка на удаление вместо удаления; физическое удаление — только человеком |
| 8. Публикация во внешнем канале: сайт, соцсети, карточка товара | Опубликованное индексируется и копируется в тот же час | Черновик публикации и подтверждение ответственного за канал |
| 9. Изменение прав доступа, создание и удаление учётных записей | Расширение прав тихо ломает весь остальной контур ограничений | Агент такого инструмента не имеет вообще |
| 10. Отмена или перенос заказа, записи, брони | Слот отдан другому клиенту, товар ушёл в другую отгрузку | Черновик с показом разницы «было / стало», подтверждение сотрудника |
| 11. Возврат денег и оформление рекламации | Возврат запускает цепочку в учёте и в платёжном сервисе | Агент собирает пакет документов, решение принимает человек |
| 12. Выгрузка данных наружу и передача в сторонний сервис | Данные, ушедшие за периметр, не возвращаются | Белый список получателей, лимит на объём, подтверждение на всё сверх него |
Двенадцатая строка стоит особняком: она про персональные данные. Выгрузка контактов клиентов во внешний сервис — это не только необратимое действие, но и обработка, за которую отвечает компания как оператор. Что можно и чего нельзя отправлять в облачные модели, мы разбирали отдельным материалом; здесь достаточно правила: список получателей у агента закрытый, и добавить в него новый адрес может только человек.
Сравнение в три колонки. «Делает сам»: найти документ, ответить по базе знаний, создать черновик, поставить задачу, добавить комментарий. «Готовит на подпись»: платёж, сообщение клиенту, рассылка, изменение цены, проведение документа, публикация, отмена заказа, возврат, выгрузка данных. «Не умеет вовсе»: изменение прав доступа, создание учётных записей, физическое удаление, изменение платёжных реквизитов без первичного документа. Под третьей колонкой подпись: «инструмента нет — не потому, что запрещено инструкцией». Чертёжный стиль, подписи по-русски.
Четыре ограничителя, которые ставятся всегда
Эти четыре вещи закладываются до того, как агент получит право что-либо менять, и не зависят ни от выбранной модели, ни от задачи. Суммарно они дают 64 часа работы инженера — расчёт ниже.
- 11. Белый список инструментов
Агенту перечисляется, что он умеет: посмотреть остаток, найти документ, создать черновик заказа, поставить задачу. Всё, чего в списке нет, недоступно физически — не по инструкции, а потому что такого инструмента у агента не существует. Отдельно проверяется, что у инструментов чтения и записи разные учётные данные: агент, который читает и пишет одним доступом, при ошибке в логике пишет туда, куда собирался только смотреть.
- 22. Числовые лимиты и стоп-кран
Количество операций в час и в день, максимальная сумма одной операции, размер партии для массовых действий, отклонение цены от базовой. Превышение не правит действие, а останавливает его и отдаёт человеку. Плюс стоп-кран — одна настройка, которая выключает все записывающие инструменты сразу, и сотрудник, который умеет ей пользоваться без разработчика.
- 33. Черновик со статусом «на проверке» по умолчанию
Любая операция третьего класса рождается черновиком. Это не режим на время пилота, а постоянное состояние: агент готовит, человек подписывает. Технически это означает, что у документа и у сообщения есть отдельный статус, который виден в интерфейсе и по которому можно отфильтровать всё, что ждёт проверки.
- 44. Журнал с ключом идемпотентности и кнопкой отката
В журнал пишется каждое действие: что сделано, по какому запросу, какие данные были до изменения, кто подтвердил. Прежнее значение в журнале — это и есть кнопка отката для второго класса действий. Ключ идемпотентности защищает от повтора при сбое связи: одинаковый ключ означает, что операция уже выполнена, и второй документ не создаётся.
Почему в промпте это не ограничитель, а пожелание
Фраза «никогда не отправляй письмо без подтверждения», написанная в системной инструкции, — это текст, который модель взвешивает наравне с сообщением клиента. Достаточно настойчивой формулировки, ссылки на несуществующую договорённость или простого повторения просьбы в третий раз, чтобы баланс сместился. Условие в программе не смещается ни от настойчивости, ни от повторения — в этом единственная разница между ограничителем и пожеланием, и мы подробно разбирали её в материале про три контура защиты ИИ-агента.
Практическая проверка при приёмке занимает пять минут и не требует читать код. Попросите показать место, где перечислены белый список инструментов и числовые лимиты, и убедитесь, что это отдельный файл или настройка, а не абзац внутри текста промпта. Второй вопрос: кто на вашей стороне сможет поменять лимит после сдачи и что для этого нужно. Если ответ «напишите нам, мы обновим промпт» — ограничителей у вас нет, есть их описание.
Подтверждение, которое действительно читают
Подтверждение человеком — самый хрупкий из четырёх ограничителей, потому что он ломается не технически, а по-человечески. На сотом однотипном уведомлении сотрудник нажимает «ок», не читая, и формально контроль есть, а фактически его нет. Проектировать поэтому надо не окно подтверждения, а количество подтверждений.
- Считайте их заранее. Больше 20–30 подтверждений в день на одного человека — контроль формален. Если расчёт даёт больше, сокращайте не проверку, а класс операций: часть из них должна выполняться по правилу без агента вообще.
- Показывайте разницу, а не намерение. Не «агент предлагает изменить цену», а «было 4 500 ₽, станет 3 800 ₽, отклонение 15,6 % от базовой, основание — запрос клиента от 2 сентября». Человек проверяет не текст, а два числа.
- Дефолт — не подтверждать. По истечении времени ничего не происходит, черновик остаётся черновиком. Автоматическое подтверждение по таймауту превращает ограничитель в задержку.
- Подтверждает тот, кто отвечает за результат. Цену — руководитель направления, платёж — бухгалтерия, письмо клиенту — менеджер, который ведёт сделку. Дежурный, который подтверждает всё подряд, — это способ формально закрыть требование, а не контроль.
- Собирайте однотипное в партии. Тридцать похожих черновиков одним экраном со сводкой и выборочной проверкой лучше, чем тридцать отдельных уведомлений: человек видит закономерность и замечает выбивающуюся строку.
- Замеряйте долю правок. Если из ста подтверждений сто уходят без единого исправления — либо проверка формальна, либо эта операция уже созрела для автоматического выполнения по правилу. И то и другое стоит обсудить, а не оставлять как есть.
Нарисованный (не скриншот) экран подтверждения. Сверху заголовок «Изменение цены — на проверке». В центре две колонки «Было: 4 500 ₽» и «Станет: 3 800 ₽», между ними подпись «отклонение 15,6 % от базовой, лимит 20 %». Ниже строка «Основание: запрос клиента от 02.09.2026, диалог №1841» со ссылкой на источник. Внизу две одинаковые по размеру кнопки «Подтвердить» и «Отклонить», рядом пометка «по таймауту остаётся черновиком». В углу счётчик «подтверждений сегодня: 12 из 30». Чертёжный стиль, подписи по-русски.
Три сценария отказа, которые проигрывают заранее
Эти три сценария повторяются в проектах независимо от отрасли и от модели. Их стоит проговорить с подрядчиком до начала работ и получить ответ, что именно в системе им противостоит.
- 1Агент неверно понял запрос
Клиент пишет «отмените вторую позицию», агент отменяет заказ целиком. Модель поняла фразу неоднозначно, и это нормальное свойство языка, а не дефект конкретной модели. Противостоит этому не улучшение промпта, а класс операции: отмена относится к необратимым, значит рождается черновиком с показом разницы. Человек видит «отменяется весь заказ на 34 000 ₽» и исправляет за пять секунд.
- 2Повтор после сбоя связи
Агент отправил запрос на создание документа, ответ не дошёл из-за обрыва, агент повторил. В учётной системе два одинаковых документа, оба проведены, остатки уехали вдвое. Это самый частый технический отказ и самый недооценённый: он не связан с качеством модели вообще. Закрывается ключом идемпотентности — уникальным признаком операции, по которому система понимает, что такой запрос уже выполнен, и возвращает прежний результат вместо создания нового документа.
- 3Действие по устаревшим данным
Цена изменилась две недели назад, а в базе знаний агента лежит старый прайс — агент называет старую цену и оформляет по ней заказ. Правило простое: цены, остатки, статусы и сроки берутся из учётной системы в момент действия, а не из базы знаний. База знаний хранит правила и описания, а не изменяемые числа; у каждого её документа есть дата актуальности и владелец, иначе она стареет незаметно.
Сколько стоит контур обратимости
Ограничители — это не «настройки», а работа, которую видно в смете отдельной строкой. Если её там нет, значит, её не делали. Модельный расчёт для агента с правом записи в CRM и учётную систему, ставка инженера 3 500 ₽/ч.
Теперь другая сторона. Модельный инцидент: агент запустил рассылку по базе в 4 000 клиентов с ценой из устаревшего прайса. Отозвать письма нельзя, часть клиентов уже оформила заказы по объявленной цене. Считаем прямые расходы, без гипотез о репутации.
Соотношение здесь не такое драматичное, как хотелось бы продающей статье, и это честно: контур обратимости не окупается «в двадцать раз», он окупается примерно с первого предотвращённого эпизода. Именно поэтому его не имеет смысла строить там, где агент вообще не касается необратимых операций, — и обязательно нужно там, где касается хотя бы одной из двенадцати.
Столбиковая диаграмма из двух столбцов почти одинаковой высоты. Левый «Контур обратимости — 224 000 ₽» с разбивкой на четыре сегмента: белый список 42 000 ₽, черновик и подтверждение 70 000 ₽, лимиты 28 000 ₽, журнал и откат 84 000 ₽; под столбцом подпись «+ 4 800 ₽/мес контроль». Правый «Одна ошибочная рассылка — 262 800 ₽» с тремя сегментами: поддержка 43 200 ₽, исполнение по ошибочной цене 210 000 ₽, разбор 9 600 ₽. Между столбцами подпись «окупается с первого эпизода». Чертёжный стиль, подписи по-русски.
Где выигрыш в скорости не окупает риск
Есть операции, которые сегодня надёжно выполняются агентом, и есть те, где выигрыш в минутах не стоит хвоста последствий. Граница проходит примерно так.
- Надёжно: чтение и поиск, подготовка черновиков, заполнение полей карточки по разговору, классификация обращений, сводки и напоминания. Здесь ошибка стоит минуты правки, и подтверждение только замедляет процесс.
- С оговорками: изменение данных в учётной системе в пределах лимитов, создание непроведённых документов, перестановка статусов. Работает при живом журнале и еженедельном выборочном контроле; без них накапливается тихий дрейф данных, который обнаруживают через квартал по расхождению в отчётах.
- Не отдаём: всё, где ошибка становится обязательством перед клиентом, деньгами или проведённой операцией в учёте. Скорость здесь выигрывается на секунды, а разбирается днями.
И отдельно — ситуации, в которых контур ограничителей строить рано. Если поток операций меньше 30–50 в день, дешевле оставить человека: контур на 224 000 ₽ не окупится, а сотрудник справится без очереди подтверждений. Если процесс не описан и решения принимаются по-разному в зависимости от того, кто сегодня работает, агент просто зафиксирует этот разнобой и начнёт воспроизводить его быстрее. Если данные о ценах и остатках живут в трёх местах и расходятся между собой, любые ограничители будут срабатывать на верных данных и пропускать неверные — сначала порядок в данных, потом право записи.
Право на ошибку у агента есть всегда. Вопрос только в том, останется ли ошибка строкой в журнале или станет письмом у клиента.
