Многостадийный контроль ИИ-агентов: полномочия, ответственность и независимый надзор

Шкала «зелёный — жёлтый — красный» удобна для отчёта руководителю. Но как архитектура управления ИИ-агентами она слишком груба.

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

Главная проблема трёхцветной шкалы в том, что она смешивает семь разных вопросов:

1. Что агент технически может сделать?
2. Насколько тяжёлым будет худший правдоподобный исход?
3. Сколько уровней контроля должно стоять над исполнителем?
4. На каких стадиях — от постановки цели до восстановления — действие проверяется?
5. Насколько независимы исполнитель, проверяющие и аварийный контур?
6. Кто отвечает за правило, решение, исполнение и инцидент?
7. В каком режиме система работает прямо сейчас?

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

Цвет должен показывать текущее состояние системы, а не постоянный «уровень доверия» к агенту.

В этой статье предложены два связанных инструмента. Первый — карточка системы из шести координат:

A — полномочия
C — критичность последствий
S — уровень надзора
I — независимость контуров
R — распределение ответственности
M — текущий режим работы

Запись A3 · C2 · S2 · I1 · R2 · M1 говорит о системе намного больше, чем слово «жёлтый». Она показывает, что агент может ограниченно менять внутренние данные, ошибка имеет умеренные последствия, действие проходит автоматическую проверку, контролёр пока не полностью независим, у рабочего процесса есть названный владелец решения, а система работает в контролируемом пилоте.

Второй инструмент — матрица реализации: шесть уровней контроля L0–L5 × семь стадий T0–T6. Карточка определяет, какой контроль нужен, а матрица показывает, где именно он срабатывает. Это центральная идея статьи: одно финальное согласование не заменяет непрерывную цепочку барьеров.

Это авторская операционная модель Methodfield, а не стандарт сертификации и не гарантия соответствия закону. Её задача — превратить разговор о «доверии к ИИ» в проверяемую архитектуру решений, доступа, контроля и восстановления.

Чему действительно стоит учиться у авионики

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

Дорожная карта EASA по ИИ 2.0 (откроется в новой вкладке) делит применения ИИ не просто на три группы. В ней выделены уровни 1A и 1B для усиления возможностей человека, 2A и 2B для разных форм совместной работы человека и ИИ и предполагаемые 3A и 3B для действий, которые человек может или не может перехватить. При этом EASA отдельно подчёркивает: глубина подтверждения надёжности зависит и от уровня ИИ, и от критичности применения.

Для бизнес-агентов отсюда следуют пять принципов.

1. Сначала опасность, потом уровень автоматизации

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

Автоматическая расстановка внутренних тегов и автоматическое изменение банковских реквизитов могут использовать одну модель и одинаковое количество шагов. Но им необходимы разные контуры управления.

2. Резервирование имеет смысл только при достаточной независимости

Три агента на одной модели, с одним системным промптом, одинаковым контекстом и общим доступом к инструментам — это не три независимых барьера.

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

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

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

В статье 14 Закона ЕС об ИИ (откроется в новой вкладке) для систем ИИ высокого риска предусмотрена возможность вмешаться, прервать работу и привести систему в безопасное состояние. Статья 15 отдельно указывает на техническое резервирование, запасные средства и планы безопасного отказа как возможные меры устойчивости к ошибкам и сбоям. Не каждый корпоративный агент юридически относится к системам ИИ высокого риска, но инженерный принцип полезен намного шире этой правовой категории.

4. Контроль продолжается после запуска

До ввода в эксплуатацию тестируют ожидаемые сценарии. После запуска появляются новые данные, новые атаки, изменения моделей, API, политик и поведения пользователей.

Профиль NIST для генеративного ИИ (откроется в новой вкладке) связывает управление риском с независимыми оценками, постоянным мониторингом, реагированием на инциденты, восстановлением и управлением изменениями. Поэтому уровень контроля — не разовая наклейка при запуске, а поддерживаемое свойство системы.

5. Человек остаётся частью системы, но не её универсальным предохранителем

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

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

Две оси контроля: уровни L0–L5 и стадии T0–T6

Многоуровневый и многостадийный контроль — не одно и то же.

• Уровень отвечает на вопрос, какой тип барьера принимает решение и насколько он независим от рабочего агента.
• Стадия отвечает на вопрос, в какой момент траектории этот барьер видит риск и может вмешаться.

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

ИИ-агенты особенно полезны на L2 и L3: они способны читать контекст, сравнивать доказательства, находить семантические противоречия и наблюдать длинную цепочку действий. Но именно поэтому их следует делать контрольными агентами, а не вторыми исполнителями. Их власть асимметрична: остановить, сузить, запросить данные, направить человеку — но не расширить область действия и не выполнить спорное действие самостоятельно.

Контроль должен покрывать всю траекторию:

Надёжная схема размещает несколько разных барьеров в разных ячейках этой матрицы. Для C3 недостаточно одного ИИ-судьи на T3: нужен как минимум детерминированный L1-барьер, независимый L2-контролёр, отдельное исполнение на T4 и сторожевой контур на T5–T6. Для C4 добавляется L4, а L5 проверяет, что вся конструкция не деградировала после изменения модели или данных.

Не каждый барьер должен быть ИИ-агентом

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

1. Детерминированная математика и обычный код, если правило можно выразить точно.
2. Классическое машинное обучение, если нужен устойчивый вероятностный прогноз или распознавание паттерна на размеченных данных.
3. ИИ-агент, если задача требует интерпретации языка, неоднозначного контекста, адаптивного плана и оркестрации инструментов.
4. Человек, если решение включает ценностное суждение, юридическую или фидуциарную ответственность, исключение из правил либо тяжёлое необратимое последствие.

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

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

Первая координата: шесть уровней полномочий A0–A5

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

Уровень назначается не «агенту вообще», а конкретному рабочему процессу и конкретному инструменту. Один и тот же агент может иметь A1 к почте, A2 к коммерческим предложениям и вообще не иметь доступа к платежам.

Полномочие должно быть связано с намерением

Формулировки «имеет доступ к CRM» или «может использовать почту» слишком широки. Реальная авторизация должна включать как минимум:

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

NIST NCCoE в концепции идентичности и авторизации программных и ИИ-агентов (откроется в новой вкладке) отдельно ставит вопросы идентификации, авторизации, аудита и невозможности отказаться от совершённого действия. Это важное изменение перспективы: агент становится отдельным операционным субъектом, а не невидимым продолжением аккаунта сотрудника.

Вторая координата: критичность последствий C0–C5

Класс последствий отвечает на вопрос: насколько тяжёлым будет худший правдоподобный исход одного действия или их накопленной серии?

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

Что повышает критичность

При оценке нужно рассматривать не только тяжесть одной ошибки:

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

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

Третья координата: уровни надзора S0–S5

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

Эти уровни кумулятивны. S3 не отменяет журнал, схемы, лимиты и детерминированную валидацию из предыдущих уровней.

Контролёр должен иметь асимметричные права

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

Контрольный агент может:

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

Он не должен:

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

Контрольная власть — это прежде всего право остановить, а не право сделать больше.

ИИ-проверка полезна, но не равна доказательству

Работа Greenblatt и коллег «Контроль ИИ: повышение безопасности при намеренном саботаже» (откроется в новой вкладке) показала на задачах генерации кода, что протоколы с доверенным мониторингом, редактированием и выборочным участием доверенного проверяющего могут заметно улучшить безопасность относительно простых базовых схем. Это аргумент в пользу многостадийных протоколов контроля, но не универсальная гарантия для любого бизнес-процесса.

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

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

Четвёртая координата: независимость I0–I3

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

В исследовании Apple 2026 года «Девять судей, два независимых голоса» (откроется в новой вкладке) панель из девяти передовых моделей семи семейств на трёх наборах задач логического вывода на естественном языке дала примерно две независимые единицы информации: модели часто ошибались на одних и тех же примерах. Это не универсальная оценка всех панелей, но сильное предупреждение против формулы «добавим ещё судей и получим надёжность».

Другой эксперимент, опубликованный в Scientific Reports (откроется в новой вкладке), показал, что в исследованной схеме многоагентной дискуссии один убедительный злонамеренный участник мог снизить точность группы и создать ложный консенсус. Следовательно, свободная дискуссия агентов — не то же самое, что независимая верификация.

Как снижать риск общего отказа по единой причине

Для существенных действий полезны следующие разделения:

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

Разные названия ролей — «планировщик», «критик», «судья» — сами по себе не создают независимость.

Три копии одной ошибки — не резервирование. Защиту создаёт различие методов, источников, полномочий и путей отказа.

Пятая координата: распределение ответственности R0–R5

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

Координата R показывает не «насколько виноват агент», а насколько явно закреплён человеческий и организационный контур ответственности.

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

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

Шестая координата: режим работы M0–M4

Первые пять координат описывают спроектированную систему. Шестая показывает, в каком режиме она находится сейчас.

Именно здесь светофор снова становится полезен:

• зелёный — M2, все обязательные контуры здоровы и действие остаётся внутри установленных границ;
• жёлтый — M1 или M3, требуется усиленная проверка либо система работает с деградацией;
• красный — M4, исполнение остановлено и полномочия отозваны.

Цвет становится индикатором текущего состояния, а не заменой оценки риска.

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

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

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

1. Рабочий агент

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

2. Детерминированный шлюз правил

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

Решение агента не может отменить этот барьер.

3. Независимый ИИ-контролёр

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

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

4. Координатор риска

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

5. Отдельный исполнитель

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

6. Сторожевой контур и контролёр восстановления

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

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

Как выбрать требуемый уровень надзора

Базовое правило можно сформулировать так:

Это отправная точка, а не автоматическое решение. Уровень нужно повышать, если:

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

Первый пункт соответствует практическому «Правилу двух свойств» для агентов от Meta (откроется в новой вкладке): до появления надёжной защиты от подмены инструкций агенту не следует автономно совмещать все три свойства — недоверенный вход, доступ к чувствительным системам или данным и возможность менять состояние либо коммуницировать наружу.

«Десять главных рисков агентных приложений на 2026 год» от OWASP (откроется в новой вкладке) расширяет картину рисками перехвата поведения, неправильного использования инструментов и злоупотребления учётными данными и привилегиями, небезопасным взаимодействием агентов и каскадными отказами. Поэтому контроль одной финальной кнопки не закрывает всю траекторию.

Пример: агент готовит и отправляет предложение клиенту

Исходная идея звучит просто:

Агент читает письмо, определяет потребность, рассчитывает цену, отвечает клиенту и обновляет CRM.

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

Разложение процесса

1. A1: прочитать новое обращение из разрешённого ящика.
2. A2: извлечь требования и подготовить черновик.
3. A2: сформировать расчёт по утверждённым правилам.
4. A4: отправить письмо внешнему получателю.
5. A3: обновить конкретные поля CRM.

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

Где здесь агент, математика и машинное обучение

• ИИ-агент извлекает намерение из письма, сопоставляет неоднозначные требования и готовит текст.
• Детерминированный расчётный сервис, а не языковая модель, рассчитывает цену, налог, валюту, округление и срок действия.
• Обычная модель машинного обучения может дать оценку аномальности, если есть достаточная история предложений и понятная разметка; при отсутствии таких данных её лучше не имитировать агентом.
• Независимый ИИ-контролёр проверяет семантику: соответствует ли обещание запросу, договору и фактическим возможностям компании.
• Механизм правил и отдельный исполнитель проверяют точные лимиты и отправляют только утверждённую версию письма с той же контрольной суммой.
• Человек принимает нестандартную скидку, новое договорное условие или другое исключение из правил.

Контур управления

1. Рабочий агент создаёт структурированное предложение и перечисляет источники цены.
2. Детерминированный шлюз проверяет валюту, диапазон цены, обязательные поля, получателя и срок действия.
3. Независимый контролёр заново сравнивает запрос клиента, прайс и подготовленный текст, не полагаясь на объяснение автора.
4. Стандартный случай внутри узких лимитов может быть разрешён только после доказанного пилота; исключение, скидка или нестандартное обещание идёт человеку.
5. Человек видит точное письмо, получателя, цену, источники, отклонения и последствия, а не общий вопрос «Одобрить?».
6. Отдельный исполнитель отправляет именно подтверждённую версию.
7. CRM обновляется идемпотентно; конечное состояние сверяется с отправленным предложением.
8. Сторожевой контур блокирует повторную отправку, превышение лимита и неожиданный новый инструмент.

Карточка такого пилота может выглядеть так:

Рабочий процесс: стандартное предложение клиенту
Полномочия: A4 — фиксация обязательства
Критичность: C3 — существенная
Надзор: S3 — независимый контроль
Независимость: I2 — разнородный контроль
Ответственность: R2 — владелец делегированного решения
Режим: M1 — контролируемый пилот

Покрытие контроля: L0–L3 на стадиях T1–T6; L4 для исключений; L5 для независимого подтверждения

Границы автоматического исполнения:
- только разрешённый почтовый ящик и утверждённые поля CRM;
- утверждённая версия прайс-листа 12;
- без скидок и нестандартных юридических условий;
- один получатель из исходной переписки;
- одна попытка отправки;
- контрольная сумма точного содержания перед исполнением;
- переход на ручной процесс не более чем за 30 минут.

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

Кто контролирует контролирующих агентов

Контрольный агент тоже является ИИ-системой и требует собственной оценки. Для него нужны:

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

Если контролёр недоступен, правильный резервный режим для C3 — не «пусть рабочий агент продолжает один», а M3: черновик, очередь или проверка человеком.

Метрики управляемости

Количество успешно завершённых запусков мало говорит о безопасности. Для каждого уровня нужны проверяемые показатели.

Полномочия

• число отклонённых запросов за пределами установленных полномочий;
• использование временных и постоянных учётных данных;
• доля действий с полной связью инициатор → намерение → решение → результат;
• число вызовов инструментов и объектов на один бизнес-результат.

Контроль

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

Независимость

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

Ответственность

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

Восстановление

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

Показатели контролёра нужно калибровать на представительном эталонном наборе и регулярно перепроверять после изменений. Самооценка модели не является независимой валидацией.

Ошибки, которые создают видимость многоуровневого контроля

«Раз исполнитель — ИИ, все контролёры тоже должны быть агентами»

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

«У нас пять агентов, значит система надёжнее»

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

«Проверяющий агент прочитал рассуждение исполнителя»

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

«Согласование человеком закрывает высокий риск»

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

«Правило записано в системном промпте»

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

«Контролёр может сам исправить и выполнить»

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

«Все действия есть в логах»

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

«Риск оценили при запуске»

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

Как внедрить модель без авиационной бюрократии

Для первого рабочего контура достаточно десяти шагов.

1. Разложить рабочий процесс на атомарные действия. Не «обработать клиента», а прочитать письмо, извлечь данные, рассчитать, отправить, изменить CRM.
2. Выбрать механизм для каждого действия. Использовать математику и код для точных правил, машинное обучение для калибруемой закономерности, агента для неоднозначного контекста, человека для ответственного исключения.
3. Назначить каждому действию A-уровень. Проверить реальные области доступа программных интерфейсов и учётные данные, а не только описание в промпте.
4. Определить C-класс. Зафиксировать худшее правдоподобное последствие, масштаб, обратимость, обнаруживаемость и окно для вмешательства.
5. Заполнить матрицу L × T. Отметить, какой барьер работает на каждой стадии от изменения правил до восстановления; найти пустые стадии и общую единственную точку отказа.
6. Выбрать минимальный S-уровень. Сначала детерминированные ограничения, затем ИИ-проверка и только потом дополнительные согласующие роли.
7. Проверить I-уровень. Нарисовать общие модели, данные, инструкции, учётные записи, владельцев и инфраструктуру.
8. Назначить R и переходы M. Зафиксировать владельцев рабочего процесса, правил, решения и инцидента; определить, что переводит систему в режим деградации и безопасной остановки и кто может вернуть её обратно.
9. Запустить теневой режим и контролируемый пилот. Собрать исходные показатели, ошибки, расхождения и время восстановления до расширения автономии.
10. Пересматривать карточку после изменений и инцидентов. Решение о повышении уровня требует доказательств, а не ощущения, что агент «стал умнее».

Итоговая позиция

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

Рабочая модель разделяет:

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

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

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

Источники и дальнейшее чтение

• Агентство Европейского союза по авиационной безопасности, «Дорожная карта по искусственному интеллекту 2.0» (откроется в новой вкладке), 2023.
• Агентство Европейского союза по авиационной безопасности, «Концептуальный документ по ИИ, выпуск 2: руководство для применений машинного обучения уровней 1 и 2» (откроется в новой вкладке), март 2024 года.
• SAE International, «ARP4761A: руководство по оценке безопасности гражданских воздушных судов, систем и оборудования» (откроется в новой вкладке), декабрь 2023 года.
• NASA, «NPR 8715.3B — общие требования программы безопасности» (откроется в новой вкладке), требования о функциональном резервировании, отказах по общей причине и безопасной конфигурации.
• Европейский союз, «Регламент (ЕС) 2024/1689 — Закон об искусственном интеллекте» (откроется в новой вкладке), статьи 9, 14 и 15.
• NIST, «Система управления рисками ИИ: профиль генеративного искусственного интеллекта» (откроется в новой вкладке), NIST AI 600-1, июль 2024 года.
• NIST, «Сводный анализ ответов о вопросах безопасности ИИ-агентов» (откроется в новой вкладке), NIST AI 800-5, май 2026 года.
• NIST NCCoE, «Ускорение внедрения идентификации и авторизации программных и ИИ-агентов» (откроется в новой вкладке), проект концептуального документа, февраль 2026 года.
• Проект OWASP по безопасности генеративного ИИ, «Десять главных рисков агентных приложений на 2026 год» (откроется в новой вкладке), декабрь 2025 года.
• Meta, «Правило двух свойств: практический подход к безопасности ИИ-агентов» (откроется в новой вкладке), октябрь 2025 года.
• OpenAI, «Проектирование ИИ-агентов, устойчивых к подмене инструкций» (откроется в новой вкладке), 2026.
• Ryan Greenblatt, Buck Shlegeris, Kshitij Sachan, Fabien Roger, «Контроль ИИ: повышение безопасности при намеренном саботаже» (откроется в новой вкладке), ICML 2024.
• Guneet Kohli, «Девять судей, два независимых голоса: коррелированные ошибки подрывают панели оценки языковых моделей» (откроется в новой вкладке), исследовательская группа Apple по машинному обучению, июнь 2026 года.
• Insaf Kraidia и соавторы, «Когда сотрудничество терпит неудачу: убеждающее вредоносное влияние в многоагентной дискуссии языковых моделей» (откроется в новой вкладке), Scientific Reports, 2026.