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

Microsoft Work Trend Index связывает эффективную работу с агентами с человеческим суждением и самостоятельностью.［1］ Настоящая контрольная точка превращает этот принцип в техническую границу. Человек не ставит печать на непрозрачном результате, а принимает или отклоняет одно действие по проверяемому пакету.

Ключевые выводы

Классифицируйте действие по последствиям до выбора контрольной точки.

Отделяйте создание предложения от привилегированного исполнения.

Показывайте полный и понятный пакет.

Связывайте решение с личностью, версией, масштабом и сроком.

При изменении входа, прав или эффекта запрашивайте новое решение.

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

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

Как построить процесс ИИ с одобрением человека для рискованных действий?

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

Уровень	Эффект	Контроль
Чтение	Разрешённые данные без изменения	Логирование и минимум прав
Черновик	Материал без внешней отправки	Проверка до использования
Обратимая запись	Ограниченная запись с надёжным откатом	Точное одобрение или узкое предварительное разрешение
Внешнее/привилегированное	Отправка, публикация, платёж, выдача доступа, удаление, развёртывание	Явное одобрение точного действия
Необратимое/высокое влияние	Безопасность, права, крупные финансы, массовое удаление	Независимые меры контроля или исключение из процесса

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

OWASP Excessive Agency рекомендует ограничивать функции, права и автономию и требовать одобрения для действий с серьёзными последствиями.［2］ Это один слой, а не замена минимальным правам, проверке данных, лимитам и откату.

Шаг 1. Отделите предложение от исполнения

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

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

Границы владельцев: модель предлагает; детерминированный код проверяет и упаковывает; аутентифицированный человек решает; доверенный исполнитель проверяет и проводит каждое действие; аудит хранит решение и результат.

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

Шаг 2. Процесс одобрения действий ИИ: соберите полный пакет

Экран должен отвечать «что именно произойдёт?» без реконструкции из чата. Включите:

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

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

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

Шаг 3. Свяжите личность, версию, масштаб и срок

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

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

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

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

Шаг 4. Определите отказ, тайм-аут, редактирование и повтор

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

Истечение срока должно приводить к отказу: молчание не является согласием. Уведомите владельца или переведите запрос в состояние «истёк» согласно политике. Если действие срочное, используйте отдельно управляемый путь эскалации, а не снижайте планку контроля.

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

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

Шаг 5. Проверяйте каждое действие через доверенного посредника

OWASP требует проверять каждый вызов инструмента через доверенного посредника, а не полагаться на план модели.［2］ Исполнитель проверяет операцию, аргументы, объект, авторизацию, связь с одобрением, лимиты и текущую политику.

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

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

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

Шаг 6. Защитите модель «человек в контуре ИИ» от манипуляций

OWASP AI Agent Security связывает внедрение вредоносных инструкций, злоупотребление инструментами, отравление памяти, чрезмерную автономию и недостаточный надзор.［3］ Внешнее содержание не создаёт, не оформляет и не отправляет доверенное одобрение.

Lies-in-the-Loop описывает поддельное или вводящее в заблуждение взаимодействие, заставляющее пользователя одобрить действие.［4］ Диалог, созданный страницей, письмом, документом или выводом модели, недоверен. Настоящий экран одобрения имеет ясный адрес и происхождение, аутентифицированную сессию, ID предложения и проверенные детали.

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

Фраза «действие безопасно» ничего не доказывает. Решение основывается на независимо вычисленных полях и политике.

Шаг 7. Проверьте решения, проведите аудит и подготовьте откат

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

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

Профиль NIST подчёркивает управление, документацию, измерение и контроль жизненного цикла.［5］ Связывайте тесты с версией и повторяйте после изменений модели, подсказки, схемы данных, политики, идентичности, инструмента или интерфейса.

Сделайте аудит и откат реальными

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

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

Проверяйте откат с реальными правами и зависимостями. Кнопка «отменить» не возвращает внешнее сообщение и действие пользователя. Необратимый эффект требует сильного предварительного контроля или исключения.

Для аварий и споров подготовьте ручной SOP. Холодная проверка SOP обнаруживает отсутствие владельца, прав или шага восстановления.

Как оценивать человеческий контроль в процессе с ИИ?

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

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

Часто задаваемые вопросы (FAQ)

Достаточно ли нажать «Одобрить»?

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

Какие действия всегда требуют одобрения?

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

Можно ли одним решением утвердить пакет?

Только если членство, масштаб, назначение, предел и эффект видны и фиксированы. Добавление элемента или смена цели должны делать решение недействительным либо попадать под отдельно утверждённое правило.

Что делать при изменении предложения?

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

Как долго действует одобрение?

В соответствии со скоростью изменения состояния и риска. Перед исполнением повторите проверку и запросите решение при другом эффекте.

Может ли ИИ объяснить безопасность?

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

Как защититься от поддельного диалога?

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

Что делать при тайм-ауте исполнения?

Считайте результат неизвестным до запроса целевой системы. Не повторяйте значимое действие автоматически; применяйте идемпотентность или сверку.

Рекомендуемые статьи

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

Источники:

Microsoft WorkLab — Work Trend Index: Agents, human agency, and the opportunity for every organization — https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
OWASP Cheat Sheet Series — AI Agent Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
OWASP — Lies-in-the-Loop — https://owasp.org/www-community/attacks/Lies_in_the_Loop
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 24 августа 2026 г.

Как построить процесс ИИ с одобрением человека