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

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

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

У этих действий разная цена ошибки. Совет «проверьте просроченные счета» ещё не меняет состояние бизнеса. Черновик письма можно исправить. Отправленное требование клиенту уже влияет на отношения, а изменение реквизитов или прав доступа может иметь более тяжёлые последствия.

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

OWASP относит чрезмерные функции, права и автономность к причинам риска Excessive Agency. Для бизнеса отсюда следует простой принцип: выдавайте агенту инструменты под согласованную работу, а не универсальный доступ на случай будущих задач. OWASP · LLM06:2025 Excessive Agency ↗

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

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

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

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

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

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

В руководстве OWASP по авторизации транзакций сформулирован принцип связи видимых пользователю значимых данных с подтверждаемой операцией. Перенос этого подхода на ИИ-агента означает: согласование относится к конкретной версии результата, а проверка разрешения выполняется на стороне системы исполнения. OWASP · Transaction Authorization Cheat Sheet ↗

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

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

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

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

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

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

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

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

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

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

Внешние документы также могут содержать попытки навязать модели инструкции — это один из вариантов prompt injection, описываемых OWASP. Поэтому текст письма или PDF следует обрабатывать как данные, а правила полномочий хранить и применять отдельно. OWASP · Prompt Injection Prevention ↗

Локальная модель не отменяет этот риск. Она может прочитать то же вредоносное вложение внутри офиса. Размещение вычислений и разрешение на действие — разные элементы защиты.

Интеграция отправила команду, но не получила ответ из-за сбоя сети. Можно ли повторить её? Если первая попытка уже сработала, повтор создаст второе письмо, дублирующую запись или ещё одну операцию. При проектировании важно различать «не выполнено» и «результат пока неизвестен».

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

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

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

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

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

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

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

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

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

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

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

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

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