Керовані штучні інтелектуальні агенти: одна модель політики, кілька точок її застосування під час роботи.

Агент підтримки отримує запит на повернення грошей. У повідомленні вказані номер рахунку та номер телефону. Щоб обробити його, агенту потрібна модель мови для читання запиту, внутрішній інструмент для пошуку замовлення, CRM, до якого можна отримати доступ через MCP для додавання примітки, а також, можливо, другий агент для перевірки надзвичайно великого повернення грошей. Усе це вже не є чимось незвичайним. Складність полягає у тому, що кожен етап у цьому ланцюзі перетинає межу різної політики, і кожне таке перетинання створює власне питання.

• Чи дозволено передавати ці дані клієнта до обраного постачальника моделей?
• Чи залишається запит у межах його бюджету витрат?
• Чи може цей обсяг роботи використовувати цю модель у цьому регіоні?
• Чи повинен сервер CRM отримувати всю розмову?
• Чи може інструмент для повернення грошей виплатити 2 000 доларів без схвалення людини?

Якщо бажаний модель не працює, чи забезпечує альтернативний варіант еквівалентне розміщення даних та безпеку?

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

Опублікована схема для керованих агентів добре описує цей процес: управління встановлює правила, а шлюз є місцем, де ці правила застосовуються до реального трафіку. Вона організовує роботу на п’ять етапів: керування, прийняття рішень, захист, спостереження та підтвердження. Важливим моментом є те, що виклики моделей, інструментів, 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

Синтаксис має менше значення, ніж перелік речей, які модель ніколи не може допустити. Вона може аналізувати, чого хоче клієнт. Вона не може вирішити, що повернення 2 000 доларів зараз відповідає правилам, або що неперевірений сервер 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 щодо надмірної автономії також приходять до того ж висновку, радячи використовувати мінімальні функції та права інструментів, причому авторизація має здійснюватися в наступних системах, а не залишатися на розсуд самої моделі. Обидва ці елементи є необхідними.

Спостереження та забезпечення безпеки

Відстеження стає набагато кориснішим, коли рішення щодо політик входять до складу цього відстеження.

• Заблокований запит до моделі показує, яка політика витрат була активована.
• Подія видалення інформації показує, яка версія політики була застосована, не розкриваючи конфіденційних даних.
• Схвалення інструменту пов’язане з дією, яку він контролював.

Резервний варіант фіксує причини невдачі основного рішення та чому замінний варіант вважається прийнятним.

Оцінки можуть враховувати не лише точність моделі. Вони можуть перевіряти, чи зменшена модель зберігає якість після зміни маршрутизації, чи скорочення контексту знижує витрати без негативного впливу на результати, чи політика редагування створює занадто багато хибних позитивів, та чи новий резервний варіант залишається еквівалентним по політиці.

Разом це утворює п’ятиетапний цикл. Govern визначає власність, ризики та політику; Decide відповідає за маршрутизацію, ескалацію та перехід на резервні варіанти; Protect забезпечує дотримання правил на кожному етапі; Observe вимірює поведінку та результати дії політик; Assure зберігає історію змін та тестує їх. Розгортання правила — це не кінець роботи. Робота завершується тоді, коли можна показати, яке правило було застосоване, що воно вирішило, що відбулося далі, та чи продовжує працювати система контролю після змін.

Що це означає для архітектури агентів

Для продакшн-агентів необхідна архітектура керування під час виконання, незалежно від обраного шлюзу. Центральний шлюз моделей є ідеальним місцем для контролю витрат, вибору постачальників, обробки конфіденційної інформації, встановлення лімітів та запобіжних заходів; він забезпечує можливість використання різних моделей без необхідності змінювати кожен додаток. Однак агент, який підпорядковується правилам, все одно потребує наступних шарів:

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

Щодо запиту на повернення коштів, модель все ще може міркувати, а агент — діяти. Архітектура просто перестає вимагати від моделі, щоб та містила всю програму керування у своєму запиті. Кожен важливий кордон отримує відповідь на своє запитання ще до перетину:

• Хто ставить запит?
• Які дані передаються та куди?
• Скільки ресурсів дозволено використати?
• Які моделі та інструменти дозволені?
• Який план у разі збою обраного шляху?
• Чи потрібна підтверджувальна подпись людини?
• Яка версія політики здійснила цей запит?

Саме це відрізняє наявність політик ШІ від наявності керованих агентів.