Какие действия AI можно выполнять автоматически, а какие требуют подтверждения

Когда я разбираю тему «Какие действия AI можно выполнять автоматически, а какие требуют подтверждения», я бы не начинал с выбора модели или инструмента. Здесь рабочая граница: сначала мне важно понять границу решения: что действительно стоит доверить системе и сколько будет стоить ошибка.

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

Граница проходит не между «AI» и «человеком», а между действиями с разной ценой ошибки. Чем труднее отменить результат, шире внешний эффект и слабее исходные данные, тем формальнее должен быть контроль. Иногда достаточно автоматической проверки. Иногда нужен конкретный сотрудник с полномочиями. В отдельных случаях действие следует запретить независимо от уверенности модели.

Коротко: что можно автоматизировать без подтверждения

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

В этой теме я бы отдельно отметил: я бы здесь не спешил с окончательным выводом.

Но название операции — только начало. «Изменить запись» может означать добавить внутренний тег или переписать банковские реквизиты. Первое легко отменить и почти не влияет на клиента; второе способно изменить платёж. Политика должна оценивать конкретный объект, масштаб, полномочия и обратимость.

Семь классов действий

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

1. Чтение

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

2. Анализ

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

3. Создание черновика

Черновик письма, отчёта или коммерческого предложения безопаснее отправки. Важно физически отделить draft от published: отдельный статус, визуальная маркировка и отсутствие прямого канала наружу. Кнопка «создать» не должна незаметно означать «создать и отправить».

4. Обратимое внутреннее изменение

В этой теме я бы отдельно отметил: что произойдёт, если система ошибётся именно на этом шаге?

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

5. Внешняя коммуникация

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

6. Финансовое или юридически значимое действие

Платёж, возврат, изменение лимита, подписание, акцепт оферты и финальное согласование проходят формальный approval gate. Модель может подготовить параметры, проверить комплектность и показать отклонения. Подтверждает человек или детерминированная политика с явно делегированными полномочиями.

7. Удаление и управление правами

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

Тест из пяти вопросов перед выдачей полномочия

Любой новый инструмент AI-агента полезно пропустить через короткий разбор.

1. Что изменится? Внутренний черновик, запись в CRM, деньги, права или публичная информация.
2. Кого затронет? Одного сотрудника, конкретного клиента, группу клиентов или весь контур.
3. Можно ли отменить? Есть ли компенсирующая операция и восстанавливает ли она исходное состояние полностью.
4. Как проверяется основание? Пришли ли данные из доверенного источника, прошли ли формальные ограничения, нет ли конфликта.
5. Кто несёт полномочие? Какая роль вправе подтвердить действие и что увидит перед подтверждением.

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

Матрица автономности

В этой теме я бы отдельно отметил: я бы сначала отделил проверяемый факт от предположения.

Матрица применяется после проверки контекста. Возврат на 100 рублей и возврат на миллион — одна операция, но разные лимиты и роли. Публикация типового статуса сервиса и персонального ответа на претензию — один канал, но разные последствия.

Подтверждение — состояние процесса, а не всплывающее окно

Плохой approval выглядит как кнопка «ОК» без контекста. Человек видит готовое действие и по инерции подтверждает его. Хорошая контрольная точка показывает объект, изменение, основание, источник данных, уровень уверенности, последствия и способ отмены.

Запрос на подтверждение должен иметь:

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

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

Как я раскладываю решение по слоям

Модель не должна иметь прямые учётные данные от платёжной системы, CRM или IAM. Она формирует структурированную команду: тип действия, объект, параметры, основание и уверенность. Policy engine проверяет схему, лимиты, разрешённые поля, риск и требуемую роль. Approval service создаёт задачу подтверждения. Только исполнительный сервис с минимальными полномочиями вызывает внешнюю систему.

Такое разделение даёт три границы. Первая не позволяет свободному тексту превратиться в произвольный API-вызов. Вторая не позволяет модели обойти бизнес-правила. Третья не позволяет подтверждающему согласовать операцию вне своих полномочий.

Каждая попытка получает correlation ID. По нему связывают решение модели, проверку политики, подтверждение, внешний вызов и ответ системы. Подход к трассировке описан в документации OpenTelemetry. Секреты хранятся вне модели, токены имеют ограниченные scope и срок действия; актуальные рекомендации OAuth собраны в RFC 9700.

Human-in-the-loop без имитации контроля

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

В этой теме я бы отдельно отметил: где здесь проходит граница между полезной автономностью и лишним риском?

Если 98% запросов безопасны, не стоит показывать оператору все 100%. Правила могут автоматически пропустить низкорисковые случаи, а человеку оставить два исключения с понятной причиной. Иначе поток подтверждений превращается в механическое нажатие кнопки и перестаёт быть защитой.

Типовые ошибки

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

Подтверждается текст, а не команда. Красивое объяснение не гарантирует, что фактические параметры API совпадают с ним. Пользователь должен видеть итоговую структуру операции.

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

AI обладает слишком широкими правами. Даже при approval компрометация агента создаёт лишний риск. Исполнительный сервис получает минимальные scope для конкретного инструмента.

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

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

Ввод пользователя управляет политикой. Инструкция в письме или документе не может повышать полномочия. OWASP отдельно описывает риск prompt injection; границы инструментов должны быть детерминированными.

Какие метрики показывают реальный контроль

Рост автоматизации сам по себе не является целью. Если доля автоматических действий выросла вместе с возвратами, жалобами и ручным восстановлением, система стала быстрее создавать проблемы. Базовый подход NIST AI RMF — управлять риском на протяжении жизненного цикла — полезнее гонки за процентом автономности.

Как внедрить уровни автономности

1. Инвентаризируйте инструменты. Запишите объекты, параметры, внешние эффекты, права и способ отмены.
2. Разделите чтение, предложение и исполнение. Не объединяйте их одним широким API-методом.
3. Оцените цену ошибки. Добавьте сумму, масштаб, чувствительность данных и юридическое последствие.
4. Назначьте режим. Автоматически, по правилам, с подтверждением, с двойным подтверждением или запрещено.
5. Спроектируйте карточку approval. Покажите состояние до и после, основания и последствия.
6. Ограничьте полномочия исполнителя. Минимальные scope, лимиты серии, одноразовый запрос и журнал.
7. Проверьте негативные сценарии. Изменённые параметры, просроченное подтверждение, повтор, массовая серия, недоступная система.
8. Начните с теневого режима. AI предлагает команды, но не исполняет их; команда сравнивает рекомендации с реальными решениями.

Вопросы, на которых обычно спотыкаются

Достаточно ли подтверждения один раз на всю сессию?

Только для узкого класса низкорисковых действий с понятными лимитами. Финансовая, массовая или необратимая операция требует отдельного решения, связанного с конкретными параметрами.

Можно ли подтверждать действие в мессенджере?

Можно использовать мессенджер как интерфейс, если подтверждение подписано пользователем, одноразово, показывает точные параметры и возвращается в журнал процесса. Простое «да» в свободном чате недостаточно.

Что делать, если подтверждающий не отвечает?

Запрос истекает, затем передаётся назначенному заместителю или эскалируется. Процесс не должен сам трактовать молчание как согласие.

Нужны ли два подтверждения?

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

Кто отвечает за матрицу действий?

Владелец бизнес-процесса определяет последствия и полномочия; безопасность задаёт технические ограничения; продуктовая команда реализует и наблюдает исполнение. Модель не является владельцем политики.

В «Какие действия AI можно выполнять автоматически, а какие требуют подтверждения» я бы оставил последнее слово за измеримым результатом. Здесь рабочая граница: если процесс не стал устойчивее, быстрее или дешевле, сама по себе автоматизация ничего не доказывает.

Что я сверял

Рекомендации сопоставлены с NIST AI Risk Management Framework, материалами OWASP по безопасности AI-агентов и prompt injection, RFC 9700 по OAuth 2.0, документацией OpenTelemetry и официальным кейсом SanctifAI. Конкретные полномочия, лимиты и требования к подтверждению определяются регламентами компании и применимым законодательством.