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

Сотрудник службы поддержки получает запрос на возврат средств. В сообщении указаны номер счета и номер телефона. Чтобы обработать его, агенту нужна модель языка для прочтения запроса, внутренний инструмент для поиска заказа, CRM-система, к которой можно получить доступ через MCP для добавления примечания, а также, возможно, второй агент для проверки чрезмерно крупного возврата. Ничего из этого уже не является чем-то экзотическим. Сложность заключается в том, что каждый этап в этой цепочке связан с разными правилами, и каждое такое соединение порождает собственный вопрос.

• Разрешено ли передавать эти данные клиента поставщику моделей?
• Не превышает ли запрос установленный бюджет на расходы?
• Может ли этот инструмент использовать данную модель в данном регионе?
• Должен ли сервер CRM получать всю переписку?
• Может ли инструмент для возврата средств выплатить 2000 долларов без одобрения человека?

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

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

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

Пусть правила передаются вместе с запросом

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

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

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

• Для вызова модели релевантными данными являются расходы, поставщик, регион, срок хранения и процедура удаления данных.
• Для инструмента возврата средств — идентификация пользователя, право собственности на заказ, сумма и уровень одобрения.

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

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

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

Краткий описательный пример, нейтральный по отношению к поставщикам

Для анализа этой структуры не требуется никакой платформы управления. Приведенный ниже пример на Python преднамеренно нейтрален и не связан с API какого-либо конкретного продукта; его задача — показать точки принятия решений.

from dataclasses import dataclass
from enum import Enum

class Decision(str, Enum):
    ALLOW = "allow"
    BLOCK = "block"
    APPROVAL = "approval"
    FALLBACK = "fallback"

@dataclass(frozen=True)
class PolicyContext:
    user_id: str
    workload: str
    risk_tier: str
    data_class: str
    spend_usd: float
    spend_limit_usd: float
    policy_version: str

def before_model_call(ctx: PolicyContext, model: str) -> Decision:
    if ctx.spend_usd >= ctx.spend_limit_usd:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
        return Decision.FALLBACK
    return Decision.ALLOW

def before_tool_call(
    ctx: PolicyContext,
    tool: str,
    amount: float = 0,
) -> Decision:
    if tool not in TOOL_SCOPES[ctx.workload]:
        return Decision.BLOCK
    if tool == "issue_refund" and amount > 500:
        return Decision.APPROVAL
    return Decision.ALLOW

def before_mcp_call(
    ctx: PolicyContext,
    server: str,
) -> Decision:
    if server not in APPROVED_MCP_SERVERS:
        return Decision.BLOCK
    if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
        return Decision.BLOCK
    return Decision.ALLOW

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

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

Шлюз модели помогает, но он не является всей структурой дизайна

В рамках этой архитектуры шлюз LLM представляет собой общий слой для аутентификации, выбора модели, сокращения объема контекста, управления расходами, обработки сбоев и формирования оснований для принятия решений. Один из существующих продуктов поставщика инструментов для агентов делает это концепцию практически реальной. Он вышел в общественную бета-версию к августу 2026 года и предоставляет ограничения на расходы и скорость обработки, альтернативные модели, маршрутизацию по поставщикам, защиту конфиденциальных данных и возможность отслеживания действий. Интеграция с обычными клиентами моделей должна быть простой: достаточно настроить параметр base_url клиента на шлюз, централизованно хранить ключи поставщиков и задавать правила управления в одном месте.

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

agent A → custom rate logic → OpenAI
agent B → custom PII logic  → Anthropic
agent C → custom fallback   → Gemini
agent D → no controls       → self-hosted model

Шлюз может объединить стопку в один общий слой.

  agents
     ↓
shared model-call policy
     ↓
approved providers / hosts

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

Надежность также является частью управления

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

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

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

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

usage approaches threshold
        ↓
      alert
        ↓
route / reduce context / downgrade model if allowed
        ↓
hard block when policy requires it
        ↓
auditable exception path if business-approved

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

Стоимость центральной плоскости управления

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

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

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

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

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

Регулирующие механизмы не должны принимать решения с серьезными последствиями

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

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

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

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

Наблюдение и обеспечение безопасности

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

• Заблокированный запрос к модели показывает, какое правило использовалось для блокировки.
• Событие удаления данных показывает, какая версия правила была применена без раскрытия конфиденциальных данных.
• Одобрение инструмента связано с действием, которое он контролировал.

Резервный вариант фиксирует причины сбоя основного решения и обоснования того, почему замена считается приемлемой.

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

Всё это вместе образует пятиэтапный цикл. Регулирование определяет ответственность, риски и политику; Принятие решений отвечает за маршрутизацию, эскалацию и переключение на резервные варианты; Защита обеспечивает соблюдение правил на всех уровнях; Наблюдение измеряет поведение и результаты действия политик; Гарантии сохраняют историю изменений и тестируют нововведения. Развертывание правила — это не конец работы. Работа считается завершённой, когда можно показать, какое правило было применено, что оно решило, что произошло дальше, и продолжает ли система работать корректно после изменений.

Что это означает для архитектуры агентов

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

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

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

• Кто задаёт вопрос?
• Какие данные передаются и куда?
• Сколько ресурсов можно использовать?
• Какие модели и инструменты разрешены?
• Каков план на случай сбоя предпочтительного пути?
• Требуется ли подтверждение человека?
• Какая версия политики приняла решение?

Именно это отличает наличие политик ИИ от наличия управляемых агентов.