Соответствие для агентного ИИ: как защищать, контролировать и наблюдать за ИИ-агентами

Чат-бот может дать плохой ответ. Агент может принять плохое решение и исполнить его.

Годами добавить ИИ на сайт означало добавить чат-бот. Посетитель задавал вопрос. Модель генерировала ответ. Разговор заканчивался.

Эта архитектура меняется.

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

В момент, когда ИИ-система получает способность действовать, а не отвечать, меняется архитектура. Вместе с ней меняется и задача соответствия.

Чат-бот даёт плохой ответ. Агент исполняет плохое решение.

Аргумент этой статьи идёт в одном направлении, и его стоит назвать до всего остального.

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

Соответствие здесь не тема. Это следствие.

От ответов к действиям

От ответов к действиям

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

Ключевое слово здесь, действия.

Классическое управление ИИ фокусировалось на модели и её выводе. Точна ли она? Уместны ли обучающие данные? Даёт ли она предвзятые результаты? Можно ли объяснить её вывод? Эти вопросы остаются важными.

Агент добавляет совершенно другой слой. К каким системам у него есть доступ? Какими инструментами он может пользоваться? Какие решения он может принимать? Что он может изменить? Кто это разрешил? Когда ему нужен человек? Сможет ли организация восстановить, что именно произошло?

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

Две архитектуры

Разницу легко показать.

Классический ИИ-ассистент работает по схеме пользователь → модель → ответ. Модель получает информацию и генерирует что-то для пользователя.

Агентная система работает иначе: пользователь → агент → рассуждение → выбор инструмента → API → бизнес-система → результат → следующее действие. ИИ теперь работает внутри более крупной системы.

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

Вторая система куда полезнее. Ею также значительно труднее управлять.

Если возврат оформлен неверно, проблема больше не в том, что ИИ сгенерировал неправильное предложение. Изменился бизнес-процесс.

Момент, когда появляются права

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

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

Каждую возможность агента кто-то ему выдал.

В этом и состоит сдвиг. Соответствие перестаёт быть документом и становится свойством системы.

Три разных вопроса

Три разных вопроса

Три понятия используют как взаимозаменяемые, и это неверно.

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

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

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

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

Стек контроля

Стек контроля

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

1. Идентичность

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

2. Авторизация

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

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

Минимальные привилегии ограничивают доступ. Минимальная автономия ограничивает решения.

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

3. Инструменты

Реальную поверхность агента задают инструменты. Не модель и не промпт, а инструменты.

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

4. Политика вне модели

Инструкции в промпте, это не контроль. Это просьбы.

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

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

5. Доказательства

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

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

Кто отвечает

Кто отвечает

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

Регуляторы не создавали отдельную категорию «ИИ-агенты». Служба поддержки AI Act Европейской комиссии формулирует это прямо: ИИ-агенты не являются отдельной категорией ИИ в рамках AI Act, а существующих определений ИИ-системы и модели общего назначения достаточно, чтобы их охватить.

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

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

Вопрос не в том, как это называется. Вопрос в том, что оно может сделать.

Что применяется и когда

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

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

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

С 2 декабря 2027 и 2 августа 2028 года соответственно агенты, классифицированные как высокорисковые системы, подпадают под дополнительные требования Главы III.

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

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

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

Что это меняет для разработки

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

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

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

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

Прозрачность сообщает людям что-то о системе. Управление определяет, что система может делать.

Три слоя риска

Три слоя риска

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

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

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

Риск системы, это то, что происходит дальше. Действие распространяется. Меняется заказ, срабатывает интеграция, реагирует другой процесс, уходит уведомление. Вопрос здесь не в том, был ли ИИ прав, а в том, каковы бизнес-последствия сбоя.

Риск движется цепочкой

Эти слои не независимы. Небольшая ошибка модели становится решением агента, которое становится изменением в системе, которое становится бизнес-последствием.

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

Ошибка модели, это предложение. Ошибка системы, это транзакция.

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

Восемь способов сломаться

Восемь способов сломаться

1. Избыточная автономия

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

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

2. Избыточные привилегии

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

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

3. Злоупотребление инструментами

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

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

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

4. Подмена цели

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

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

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

5. Отравление памяти и контекста

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

Сбой тихий, потому что ничего не сломалось. Агент просто верит в то, чего нет, и последовательно на этом действует. О том, насколько убедительно это происходит, мы писали в статье Четыре ИИ согласились. Мы так ничего и не проверили.

6. Каскадные отказы

Один агент вызывает API, который запускает процесс, который вызывает другого агента, который пишет в базу, которая шлёт уведомление.

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

7. Злоупотребление идентичностью и правами

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

Журнал должен сохранять весь путь: пользователь → агент → процесс → инструмент → авторизация → изменение в системе.

8. Эксплуатация доверия человека к агенту

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

Шаг согласования, который всегда прокликивают, это не надзор. Это запись в журнале.

Надзор должен следовать за риском

Участие человека должно масштабироваться вместе с последствиями, а не применяться равномерно.

• Низкий риск: автономное исполнение оправдано
• Умеренный риск: может хватить ограниченных прав и наблюдения
• Высокий риск: может требоваться одобрение человека
• Критический или необратимый: системе может понадобиться полностью запретить автономное исполнение

Автономия должна уменьшаться по мере роста необратимости.

Почему в коммерции сложнее

Почему в коммерции сложнее

Описанные сбои применимы везде. В e-commerce они острее по конкретной причине: системы, до которых дотягивается агент, хранят цены, остатки и деньги, и почти всё, что они хранят, попадает к клиенту за секунды.

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

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

Одна интеграция. Семь коммерческих решений. Без различий между ними.

Проблема множителя

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

В магазине, продающем в нескольких странах, у товара нет одной цены, одного остатка и одного описания. У него есть по одному на рынок, и эти состояния должны оставаться согласованными. Мы разбирали это отдельно в статье Мультистрановый e-commerce для больших каталогов.

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

Агент, авторизованный менять цену, авторизован менять её где-то. Значит ли это один рынок или восемь, это архитектурное решение, и если его никто не принял, его принял инструмент.

Скорость убирает запас прочности

Коммерческие системы к тому же необычно неумолимы ко времени.

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

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

Какие контроли здесь действительно важны

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

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

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

Наблюдение и доказательства

Наблюдение и доказательства

Наблюдать за агентом, это не то же самое, что наблюдать за приложением, потому что сбои устроены иначе.

Обычная система ломается ошибкой. Агент ломается тем, что успешно делает не то. Каждый вызов API возвращает 200. Каждая интеграция работает. Бизнес-результат при этом неверный.

Успешный вызов API не означает успешного бизнес-действия.

За чем следить

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

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

Аудируемость, это не логирование

Логи фиксируют, что что-то произошло. Журнал аудита восстанавливает, почему.

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

Цель не в том, чтобы закрыть чек-лист. Цель в том, чтобы получить пригодные доказательства.

Автоматизация обеспечивает политику, но не определяет её

Часть соответствия автоматизируется: инвентаризация систем, сбор логов, проверка прав, обнаружение аномалий, применение политик, формирование отчётов.

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

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

Фреймворки, это не архитектура

Фреймворки, это не архитектура

Полезный способ думать об агентной системе:

Соответствие = Политика + Полномочия + Контроли + Доказательства + Надзор

Политика, это что должно происходить. Полномочия, это кто или что вправе это сделать. Контроли, это то, что технически предотвращает неразрешённое поведение. Доказательства, это возможность потом подтвердить. Надзор, это точка, где может вмешаться человек.

Уберите любой элемент, и система ослабнет вполне определённым и предсказуемым образом.

Задача перевода

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

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

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

Этот перевод и есть основная работа, и он инженерный, а не нормативный.

Агенту нужен слой управления

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

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

Модель остаётся важной. Но модель больше не является архитектурой.

Слой управления, это то, что превращает возможность ИИ в систему, на которую бизнес может положиться.

Референсная архитектура

Референсная архитектура

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

ПОЛЬЗОВАТЕЛЬ → ИДЕНТИЧНОСТЬ → АГЕНТ → МЕХАНИЗМ ПОЛИТИК → АВТОРИЗАЦИЯ ИНСТРУМЕНТА → ИНСТРУМЕНТ → БИЗНЕС-СИСТЕМА → АУДИТ И НАБЛЮДЕНИЕ

Что даёт каждый слой, в том порядке, в каком запрос с ним встречается:

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

Агент. Рассуждает о задаче и предлагает действие. Это единственный вероятностный компонент пути, и именно поэтому всё после него детерминировано.

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

Агент предлагает. Система разрешает.

Авторизация инструмента. Сводит решение к конкретной именованной возможности. Не доступ к базе, а getCustomerOrder, updateSupportTicket, createRefundRequest, approveRefund. Четыре именованных инструмента с разными требованиями авторизации, это другой уровень защищённости, чем одна строка подключения.

Бизнес-система. Исполняет. К этому моменту решение уже принято и проверено, в чём и состоит смысл предыдущих слоёв.

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

Где подключается человек

Одобрение, существующее как шаг процесса, рано или поздно пропустят. Одобрение, существующее как токен исполнения, пропустить нельзя.

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

Обратимость как проектное ограничение

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

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

Объяснимость, это не цепочка рассуждений

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

Это структурированная запись того, что произошло, а не рассказ о том, что думала модель.

Тестировать на отказ, а не на успех

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

Неверная информация. Вредоносная информация. Отказ инструмента. Отказ прав. Противоречивые инструкции. Отравление контекста. Каскадный отказ. Таймаут человека.

Агент, протестированный только на успехе, не протестирован.

Жизненный цикл и зрелость

Жизненный цикл и зрелость

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

Discovery устанавливает, для чего агент и что он может изменить. Архитектура определяет идентичность, полномочия и границы контроля. Разработка реализует инструменты и обеспечение политик. Тестирование покрывает режимы отказа. Развёртывание налаживает наблюдение. Эксплуатация следит за бизнес-результатами, а не только за техническими. Пересмотр проверяет, соответствуют ли выданные полномочия фактическому использованию.

Модель зрелости

Большинство организаций могут найти себя на короткой шкале.

• Уровень 0, эксперимент: промпт и модель
• Уровень 1, ассистент: модель, интерфейс, ограниченный доступ к данным
• Уровень 2, интегрированный агент: агент с инструментами и API
• Уровень 3, контролируемый агент: механизм политик, ограниченные инструменты, журнал аудита
• Уровень 4, управляемая система: всё перечисленное плюс наблюдение, надзор, восстановление и пересмотр

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

Кому это действительно нужно

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

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

Ассистенту, который достаёт закрытые данные, нужны идентичность, контроль доступа и работа с данными. Действовать он по-прежнему не может, но уже может раскрыть то, что не должен.

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

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

Риск начинается не со слова ИИ. Он начинается с полномочий.

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

Начинать с последствий, а не с соответствия

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

Что делает агент? Что может пойти не так? Что агент может изменить? Каким будет последствие? Какой контроль предотвратит или ограничит это последствие? Какое доказательство подтвердит, что контроль сработал?

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

Новая граница ПО

Новая граница ПО

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

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

Ново то, что в ответ теперь входит участник, который рассуждает и чьё поведение вероятностно, а не детерминировано. Где этот участник стоит в более широкой коммерческой цепочке, разобрано в статье SEO приводит к вам. AEO делает так, чтобы вас рекомендовали., а нужен ли он вообще, в статье Нужен ли мне разработчик, или хватит ИИ?

Строить слой контроля до масштабирования агента

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

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

Вопрос, который стоит задать первым

Не «какую модель нам взять?», а:

Какие решения и действия мы готовы делегировать?

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

К чему это ведёт

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

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

Модель даёт интеллект. Агент даёт автономию. Архитектура даёт контроль.

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

Когда софт может действовать за бизнес, соответствие становится архитектурой.

Частые вопросы

Что такое соответствие для агентного ИИ?

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

Чем ИИ-агент отличается от чат-бота?

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

Регулирует ли EU AI Act ИИ-агентов?

Да, хотя и не как отдельную категорию. Служба поддержки AI Act Европейской комиссии указывает, что ИИ-агенты не являются отдельной категорией в рамках Акта, и что существующих определений ИИ-системы и модели общего назначения достаточно, чтобы их охватить. Обязательства поэтому зависят от системы, её назначения и классификации риска. Комиссия также описывает свои соображения по агентам как предварительные на данном этапе.

Когда вступают в силу обязательства?

Запреты на вредоносные манипуляции и эксплуатацию уязвимостей уже действуют. Правила прозрачности применяются с 2 августа 2026 года там, где агент взаимодействует с людьми или генерирует контент. Дополнительные требования для высокорисковых систем применяются с 2 декабря 2027 и 2 августа 2028 года соответственно.

Каковы главные риски?

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

Должны ли ИИ-агенты требовать одобрения человека?

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

Что такое минимальная автономия?

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