Разбираемся, почему контент-фильтры не спасают от бизнес-инцидентов и как построить систему делегирования прав для агентов.
Первое, что приходит на ум при словосочетании «ошибка ИИ» — галлюцинации. Чат-бот что-то выдумал, назвал несуществующий фильм или перепутал дату. Но в корпоративных системах куда страшнее другой сценарий: агент-ассистент прекрасно справился с задачей, вот только делал он то, что ему никто не разрешал. Возврат средств без одобрения, изменение заказа в обход финансовых условий, обещание доставки без учёта ограничений перевозчика. Такое поведение не сбои в рассуждениях, а отсутствие границ полномочий.
По мере перехода от «советчиков» к агентам, которые сами дёргают инструменты и запускают процессы, старых методов контроля становится мало. Контент-фильтры отсекают вредные ответы, но не могут сказать, санкционировано ли действие. Нужен другой подход — формальные контракты полномочий, рантайм-политики и метрики, которые превращают права агента в управляемый процесс. Рассказываем, как это работает.
Инциденты с ИИ-агентами: превышение полномочий вместо галлюцинаций
Представьте картину: ИИ-агент получает четкую задачу, идеально ее выполняет, не отклоняясь ни на йоту от инструкции. И при этом совершает действие, которое бизнес никогда не санкционировал. Контент-фильтры блокируют вредные ответы, но они совершенно беспомощны, когда речь идет о том, имел ли агент право оформить возврат средств или достучаться до производственной системы. Это принципиально разные проблемы, и большинство предприятий пока решает только одну из них.
В сфере коммерции этот паттерн проявляется пугающе часто. Сервисный процесс идеально вычисляет сумму возврата, но в нем отсутствует ограничение на размер кредитов, которые бизнес одобрил для автономного действия. Агент онлайн-заказов прекрасно применяет запрошенное изменение, но напрочь игнорирует условие финансирования или этап выполнения заказа. Закупочный агент находит поставщика с самой низкой ценой — и тут выясняется, что никто не определил, может ли он принимать договорные условия или его удел лишь рекомендовать вариант человеку. Агент продолжает работать. Проблема всплывет только тогда, когда что-то сломается вниз по цепочке.
Гардрейлы не определяют авторитет
Ключевой момент: это не сбой в рассуждениях искусственного интеллекта. Это неспособность архитекторов системы отделить техническую возможность от бизнес-полномочий. Когда предприятие переходит от консультационных copilot-систем к агентам, которые самостоятельно вызывают инструменты и запускают рабочие процессы, каждому производственному агенту требуется прописанный набор прав на принятие решений. Что он может исполнять автоматически? Что требует одобрения человека? Что допустимо лишь предложить? А к чему нельзя прикасаться в принципе?
Ветераны индустрии безопасности ИИ бьют тревогу не просто так. Опрос Cloud Security Alliance в апреле 2026 года вскрыл пугающую статистику: 65% респондентов за предыдущий год столкнулись с инцидентами, связанными с ИИ-агентами в своих системах. А 82% и вовсе обнаружили у себя ранее неизвестных агентов, работающих в обход каких-либо регламентов. В исследовании участвовали 418 ИТ-специалистов и профессионалов по безопасности, а спонсором выступила компания Token Security. Проще говоря, агенты-призраки расплодились быстрее, чем предприятия успели построить для них зоны ответственности.
Гардрейлы ограничивают поведение. Права на решения определяют законную власть. Это два разных инструмента, и подмена одного другим приводит к катастрофам. Даже Всемирный экономический форум в мае 2026 года выпустил плейбук, где представил Agent Capability and Authorization Profile — профиль, который призван сделать делегированные действия проверяемыми, исполнимыми и подотчетными.
Показательно, как быстро индустрия осознала разницу между «безопасно для выполнения» и «разрешено к выполнению». Ложный ответ модели — неприятность. Технически корректное действие, которое агент не имел права совершать, — уже катастрофа. И эта катастрофа начинает весить куда больше, чем все старые страхи о галлюцинациях.
Контракт полномочий: как формализовать границы действий агента
Каждому производственному агенту перед подключением к корпоративным инструментам нужна машиночитаемая запись того, какие полномочия бизнес готов ему делегировать. Звучит как бюрократия? Пусть так. Но без такой бумажки — пусть и виртуальной — любой автономный ИИ превращается в курьера, которому выдали ключи от склада и не сказали, что именно он должен привозить, а что трогать запрещено. Индустрия называет это Agent Authority Contract, и это не просто красивое название, а рабочий инструмент, который спасает от катастроф.
Семь вопросов, которые задаёт контракт полномочий
Контракт полномочий — это машиноисполняемый документ, который обязан отвечать на семь вопросов. Первый: кто владеет результатом? Назван конкретный человек или бизнес-роль, а не «другая система». Второй: что именно агент имеет право делать — читать, рекомендовать, писать или коммитить. Третий: к каким системам и данным он вообще может прикасаться. Четвёртый: какие лимиты существенности стоят — финансовые пороги, количество записей, охват клиентов, операционное влияние. Пятый: что должно запускать эскалацию — неопределённость, аномалия, чувствительные данные или потенциальный ущерб. Шестой: можно ли отменить действие и кто именно имеет право на откат. Седьмой: когда полномочия истекают и как их отзывают. Хотя бы один отсутствующий ответ — и агент работает вслепую, а бизнес узнаёт о проблеме постфактум.
Тут важно разделить две проверки, которые постоянно путают. Контроль доступа проверяет, может ли агент технически достичь системы. А контракт полномочий определяет, есть ли у него разрешения на конкретное действие в текущем контексте. Это не одно и то же: можно иметь доступ к базе данных и не иметь права удалять из неё записи. Обновлённая Сингапурская модель управления ИИ для агентных систем проводит ровно ту же границу: доступ, поведенческие ограничения и человеческие одобрения там разведены по разным категориям, а требования к надзору зависят от масштаба действия, его обратимости и потенциального влияния.
Четыре исхода для любого действия
Когда речь заходит об управлении агентами, вся работа в итоге сводится к простому сопоставлению: каждое значимое действие должно попасть в одну из четырёх корзин.
Allow — это автономия для низкорисковых, ограниченных и обратимых действий. Получить одобренную информацию, классифицировать входящий запрос, обновить несущественное поле. Здесь агент действует без предварительной проверки, потому что потенциальный ущерб минимален, а откат тривиален.
Approve означает, что агент готовит или инициирует действие, но исполнение замораживается до авторизации человека или детерминированного сервиса политик. Сюда попадают платежи, изменения в продакшн-системах и любые операции, способные существенно повлиять на клиента, сотрудника или третью сторону.
Recommend — самая честная категория: агент анализирует, ранжирует, составляет черновик или предлагает, а финальное решение принимает человек. Это выбор для ситуаций, где важен контекст и где юридические, финансовые или личные последствия делают автоматическое исполнение неприемлемым.
Deny — категория абсолютного запрета. Действие остаётся вне полномочий агента независимо от его уверенности в собственной правоте. Удаление критических данных, окончательное решение о найме или обход обязательного контроля не должны исполняться даже тогда, когда рассуждения агента выглядят безупречно. И вот здесь инженеры чаще всего спотыкаются.
Deny обязан обеспечиваться на уровне технических границ, а не системного промпта. Инструкция на естественном языке, которая запрещает агенту что-то делать, — это не жёсткое ограничение, а вежливая просьба. С таким же успехом можно повесить табличку «не входить» на дверь, к которой у агента есть действующий ключ. Пусть в его «голове» стоят идеальные правила, но если технически он способен выполнить запрещённое действие — рано или поздно он его выполнит.
Контракт полномочий — это скучно ровно до момента, когда кто-то не спросит, кто разрешил агенту менять статус в производственной системе. И вот тогда становится очень интересно.
Динамическое управление полномочиями: рантайм-политики и метрики контроля
Динамическое управление полномочиями: рантайм-политики и метрики контроля
Статической конфигурации здесь явно недостаточно. Один и тот же небольшой кредит может быть вполне разрешён в обычных условиях, но требовать одобрения, когда сумма переваливает за порог, по счёту идёт расследование или клиент относится к регулируемой категории. Каждый такой сценарий нужно просчитывать заранее, а решения принимать на лету.
Как это выглядит на практике? Последовательность в рантайме примерно такая: агент предлагает действие; слой политик оценивает его идентичность, делегирующего принципала, запрошенный инструмент, данные, контекст транзакции и потенциальное влияние; политика возвращает один из четырёх вердиктов — Allow, Approve, Recommend или Deny; система записывает и само решение, и его результат; а накопленная телеметрия со временем расширяет, сужает или вовсе отзывает полномочия.
Самый опасный ИИ-промах в коммерции — не ложный ответ, а технически корректное действие, которое агент не имел права совершать. Возврат рассчитан точно, но превышает лимит одобрения. Изменение заказа соответствует запросу, но нарушает условие финансирования. Обещание доставки отражает наличие товара, но игнорирует ограничение перевозчика, применённое часом ранее. Агент может вообще не ошибиться в логике — просто бизнес забыл определить, где заканчиваются его полномочия.
Требование человеческого одобрения для каждого действия выглядит консервативным и безопасным, но в масштабе вырождается в механическое «резиновое» утверждение. Когда ревьюеры штампуют тысячи рутинных операций, внимание притупляется, а действительно нетипичные случаи теряются в потоке. Сингапурский фреймворк прямо признаёт: постоянный человеческий надзор за каждым рабочим процессом непрактичен, и вместо этого рекомендует значимые контрольные точки для высокорисковых или необратимых действий.
Куда более рабочая модель — пропорциональная авторизация. Низкорисковые действия выполняются в узких границах, высокорисковые или необратимые требуют одобрения, неожиданное поведение вызывает эскалацию, а любое значимое действие без определённой политики запрещено по умолчанию. Цель здесь — не максимальная автономия, а наивысший уровень автономии, который предприятие может ответственно наблюдать, контролировать и отзывать.
Как понять, что полномочия откалиброваны правильно? Одной точности ответов мало. Нужны метрики: частота переопределений, когда человек отклоняет или существенно меняет решение агента; точность эскалаций — поднимает ли агент действительно рискованные кейсы или гоняет рутину по кругу; попытки неавторизованных действий; частота ошибок, которые аукаются финансами, комплаенсом или репутацией; и наконец задержка решений — не превратились ли согласования в тормоз для автоматизации, которая и так безопасна.
Эти метрики превращают полномочия из абстрактной идеи в управляемую переменную. Стабильно надёжная работа — повод расширить границы. Частые переопределения, сбои эскалации или нарушения политики — сигнал сужать.
И вот ключевой момент: разрыв управления — не в модели. Контроль безопасности, выходные фильтры, защита данных — всё это важно, но ни один из этих механизмов не отвечает на вопросы: кто делегировал полномочия, сколько их передано, на каких условиях и кто в итоге отвечает за результат, если что-то пошло не так.
Поэтому более полезный вопрос звучит не «каким автономным может стать агент», а «что предприятие действительно готово делегировать и как это делегирование будет обеспечиваться, наблюдаться и отзываться». Демо агента работает — это уже не сложная часть.
Пока одни ждут, когда ИИ научится всему, enterprise-разработчикам приходится объяснять ему, чего делать нельзя. Пожалуй, это самый важный навык для внедрения агентов в ближайшие годы.