82% компаний за последний год обнаружили в своей инфраструктуре неизвестных AI-агентов, а 65% уже столкнулись с инцидентами, связанными с такими системами. На этом фоне тема полномочия AI-агентов быстро выходит из разряда архитектурных дискуссий в зону прямого операционного риска: проблема все чаще не в том, что модель ошиблась, а в том, что ей дали сделать лишнее.
Об этом сообщает VentureBeat в колонке продуктового руководителя Nixal Patel. Его тезис звучит неприятно, но очень по-деловому: контентные фильтры, safety-guardrails и защита от токсичных ответов не отвечают на главный вопрос бизнеса. Даже если агент технически действует корректно, имел ли он право возвращать деньги клиенту, менять заказ, трогать production или подтверждать условия у поставщика без человека в контуре?
Patel разбирает это на понятных примерах из коммерческих сценариев. Сервисный агент может верно посчитать сумму возврата, но выдать кредит выше лимита, который компания готова доверить автоматике. Агент обработки заказов может аккуратно внести запрошенное изменение, но не учесть условие финансирования или исполнения. Закупочный агент может найти самого дешевого поставщика, а потом молча перейти грань между рекомендацией и фактическим согласием на контрактные условия. Формально логика не сломалась. Сломалась система делегирования.
Для русскоязычных команд это важный сдвиг оптики. До сих пор значительная часть обсуждения AI в компаниях вращалась вокруг качества ответов, утечек данных и ограничений промпта. Но у production-агентов другая зона риска: они вызывают инструменты, запускают workflow и меняют состояние внешних систем. Здесь полномочия AI-агентов становятся не абстрактной политикой, а такой же инженерной сущностью, как IAM, RBAC или лимиты в платежном шлюзе.
Почему guardrails уже недостаточно
VentureBeat проводит простую, но полезную границу: поведенческие guardrails ограничивают, как агент себя ведет, а модель полномочий отвечает, что именно ему разрешено делать от имени компании. Это не одно и то же. Можно идеально отфильтровать вредный вывод, запретить утечки PII и контролировать вызов инструментов, но все равно не заметить, что агент оформил действие, на которое бизнес ему полномочий не давал.
Эта проблема уже перестала быть теорией. По данным Cloud Security Alliance, опубликованным 21 апреля 2026 года, 82% организаций нашли в своей среде ранее неизвестных AI-агентов. 65% респондентов сообщили хотя бы об одном инциденте за последние 12 месяцев. В опросе участвовали 418 IT- и security-специалистов, исследование спонсировала Token Security. Дополнительные цифры выглядят еще менее уютно: 61% инцидентов привели к раскрытию данных, 43% — к операционным сбоям, 35% — к финансовым потерям. Если переводить это на язык ИТ-директора, рынок уже зашел в фазу, где «мы пока тестируем агентов в песочнице» все чаще расходится с реальностью.
На этом фоне неудивительно, что тему подхватили и институциональные игроки. World Economic Forum в playbook от 26 мая 2026 года предложил профиль Agent Capability and Authorization Profile — по сути, формализованный способ описать, какие действия агенту делегированы, в каких границах и как это потом аудировать. Похожую логику использует и Сингапур: обновленная 20 мая 2026 года Model AI Governance Framework for Agentic AI отдельно разводит контроль доступа, поведенческие ограничения и человеческое одобрение. Для enterprise-архитекторов это сигнал: вопрос уже не в красивом промпте, а в дизайне механизма делегирования.
Что бизнесу и разработке делать с этим прямо сейчас
Ключевое предложение Patel — ввести для каждого production-агента своего рода контракт полномочий. Не декларацию на Confluence и не строчку в system prompt, а машинно-исполняемую запись, которая отвечает минимум на семь вопросов: кто владеет результатом, что агенту разрешено делать, к каким системам и данным он может обращаться, какие лимиты по суммам или масштабу операции действуют, что считается триггером эскалации, можно ли откатить действие и когда делегированные права истекают. Смысл здесь жесткий: доступ к системе еще не означает право совершать конкретное действие в конкретном контексте.
Дальше автор предлагает раскладывать любые значимые действия агента всего на четыре исхода: Allow, Approve, Recommend и Deny. Низкорисковые и обратимые операции можно выполнять автономно. Платежи, изменения в production, действия с заметным влиянием на клиента или сотрудника должны ждать одобрения человека или детерминированного policy-сервиса. Где нужен контекст и суждение, агенту лучше оставить роль советника. А часть действий вообще должна быть вынесена в безусловный запрет. И здесь есть важная деталь, которую в индустрии любят недооценивать: запрет, записанный только естественным языком в промпте, не является запретом. Это пожелание.
Самая практичная часть этой схемы — принятие решения во время исполнения, а не только в статической конфигурации. Небольшой сервисный кредит можно разрешить автоматически, пока сумма ниже порога, аккаунт не находится под проверкой, а клиент не подпадает под особый регуляторный режим. Но стоит измениться контексту — и тот же агент должен переключиться с автономии на согласование. В инженерных терминах это означает отдельный policy layer между намерением агента и фактическим вызовом инструмента, плюс обязательный аудит решения и телеметрия, которая со временем либо расширяет, либо сужает полномочия AI-агентов.
Для разработчиков и продуктовых команд вывод довольно приземленный. Метрики качества ответа уже недостаточно. Придется считать, как часто человек отменяет или существенно правит решение агента, насколько точно агент эскалирует действительно рискованные случаи, сколько раз он пытается выйти за границы разрешенного, каков реальный ущерб от формально авторизованных действий и не убивает ли approval flow ту самую эффективность, ради которой автоматизацию и затевали. Иначе компания получит не «цифрового сотрудника», а очень старательного исполнителя без чувства субординации.
Главный вопрос для рынка теперь звучит не так уж футуристично: не насколько автономным может быть агент, а что именно бизнес готов ему делегировать, как это проверять в рантайме и кто будет нажимать стоп-кран, когда агент окажется слишком полезным. Исходная колонка VentureBeat ценна как раз тем, что сдвигает разговор с магии модели на скучную, но критически важную тему операционной власти: .