Zarządzane agenty AI: jeden model polityki, kilka punktów egzekwowania w trakcie działania.
Jak kontrolować koszty, wybór modelu, dane, narzędzia oraz wywołania MCP w trakcie działania: ramy zarządzania, neutralny szkic polityki, rozwiązania awaryjne, ograniczenia bezpieczeństwa oraz śledzenie.
Źródła: Building Governed AI Agents: How to Control Cost, Data, Tools and Actions at Runtime
Pracownik obsługi klienta otrzymuje wniosek o zwrot pieniędzy. Wiadomość zawiera numer konta oraz numer telefonu. Aby go przetworzyć, pracownik potrzebuje modelu językowego do odczytania wniosku, wewnętrznego narzędzia do wyszukiwania zamówienia, systemu CRM dostępnego przez MCP w celu dodania notatki, a także ewentualnie drugiego pracownika do przeanalizowania niezwykle dużego zwrotu. Nic z tego już nie jest niczym ekskluzywnym. Trudność polega na tym, że każdy etap w tej łańcuchu przechodzi przez inną granicę zasad, a każde takie przejście rodzi własne pytanie.
- Czy dane tego klienta mogą trafić do wybranego dostawcy modeli?
- Czy wniosek mieści się w jego budżecie wydatków?
- Czy to obciążenie może korzystać z tego modelu w tym regionie?
- Czy serwer CRM powinien otrzymać całą rozmowę?
- Czy narzędzie do zwrotów może wypłacić 2000 dolarów bez zatwierdzenia przez człowieka?
Dokument polityki może w zasadzie odpowiedzieć na takie pytania, a prompt systemowy może przypomnieć agentowi o niektórych z nich. Żadne z tych rozwiązań jednak nie egzekwuje zasad w sposób spójny. Dlatego zarządzanie agentami staje się problemem w trakcie działania systemu.
Opublikowana ramowa struktura dla zarządzanych agentów dobrze opisuje tę zmianę: zarządzanie ustala zasady, a brama jest jednym z miejsc, gdzie te zasady spotykają się z ruchem danych w czasie rzeczywistym. Struktura ta dzieli pracę na pięć czynności: zarządzanie, podejmowanie decyzji, ochrona, obserwacja i zapewnienie. Ważnym aspektem jest to, że wywołania modeli, narzędzi, protokołu MCP oraz komunikacja między agentami niosą ze sobą różne ryzyka. Ta różnica umożliwia lepsze projektowanie niż próba umieszczenia wszystkich zasad kontrolnych w jednym dużym promptzie lub bramie.
Niech polityka podróżuje razem z żądaniem
Najprostszym obrazem jest „opakowanie zarządzania”, które towarzyszy interakcji w systemie. Zawiera ono wystarczająco dużo kontekstu, aby podjąć decyzję przed przekroczeniem określonej granicy:
- tożsamość i użytkownik,
- obciążenie pracą oraz agent,
- półka ryzyka i klasyfikacja danych,
- bieżące wydatki i limity,
- dozwoleni dostawcy i regiony,
- dozwolone narzędzia i zakresy działań,
- progi wymagające ludzkiej aprobaty,
- wersja polityki oraz identyfikator śladu lub decyzji.
Nie każdy komponent potrzebuje wszystkich pól. To „opakowanie” istnieje po to, aby te same rodzaje pytań mogły być odpowiadane spójnie, niezależnie od tego, dokąd udaje się agent.
- Dla wywołania modelu istotne są informacje o wydatkach, dostawcy, regionie, przechowywaniu i redagowaniu danych.
- Dla narzędzia do zwrotu pieniędzy są to tożsamość użytkownika, właściciel zamówienia, kwota oraz poziom aprobaty.
Zatem projekt nie polega na jednym uniwersalnym filtrze. Jest to pojedynczy model polityki z kilkoma punktami egzekwowania. W tym etapie zarządzanie w czasie rzeczywistym staje się konkretnym zagadnieniem, ponieważ istotne pytanie brzmi nie o to, czy istnieje jakaś polityka, ale o to, który komponent jest w stanie zatrzymać interakcję przed wystąpieniem jakichkolwiek skutków ubocznych.
Niewielki, neutralny pod względem dostawcy szkic
Do zobaczenia tego wzorca nie potrzeba żadnej platformy zarządzania. Poniższy kod w Pythonie jest celowo neutralny i nie jest powiązany z żadną API produktu. Jego zadaniem jest ujawnienie punktów podejmowania decyzji.
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
Syntaksa ma mniejsze znaczenie niż lista rzeczy, których model nigdy nie może zaakceptować. Może rozumować to, czego chce klient. Nie może orzec, że zwrot 2000 dolarów jest zgodny z polityką, ani że niezatwierdzony serwer MCP jest w porządku tylko dlatego, że prośba wygląda niewinnie. Takie wyniki to deterministyczne zmiany stanu kontrolowane przez środowisko wykonawcze.
Wersja produkcyjna powinna również dostarczać dowody na każdą decyzję: wersję polityki, zakres danych wejściowych, wynik, uzasadnienie, podmiot działający, datę i identyfikator śledzenia. To właśnie te dowody później potwierdzają, która polityka faktycznie została zastosowana, a nie tylko pokazują, że istniał dokument polityki.
Brama modelu pomaga, ale nie stanowi całego projektu
W tym kontekście brama LLM stanowi wspólną warstwę do autoryzacji, wyboru modeli, redukcji kontekstu, określania limitów wydatków, radzenia sobie z awariami oraz gromadzenia dowodów decyzyjnych. Jeden z obecnych produktów dostarczanych przez producenta narzędzi dla agentów sprawia, że jest to widoczne w praktyce. Produkt ten wszedł do fazy publicznego beta we wrześniu 2026 roku i oferuje limity wydatków oraz szybkości, alternatywne modele, kierowanie do odpowiednich dostawców, ochronę danych wrażliwych oraz integrację śledzenia. Adopcja przez zwykłe klienty modeli ma być prosta: wystarczy skierować base_url klienta na bramę, przechowywać klucze dostawców centralnie i ustalać zasady w jednym miejscu.
To ma znaczenie, ponieważ w przeciwnym razie zasady zarządzania modelami musiałyby być kopiowane do każdego agenta.
agent A → custom rate logic → OpenAI
agent B → custom PII logic → Anthropic
agent C → custom fallback → Gemini
agent D → no controls → self-hosted model
Brama może połączyć wszystkie warstwy w jedną wspólną warstwę.
agents
↓
shared model-call policy
↓
approved providers / hosts
Należy unikać tu zbyt pochopnego uogólniania. Ramy zarządzania są szersze niż jakikolwiek pojedynczy produkt typu gateway. W sposób wyraźny omawiają one wywołania narzędzi, wywołania MCP oraz interakcje między agentami, ponieważ największym zagrożeniem dla agenta jest często działanie, które może on podjąć, a nie tekst, który wytwarza. Kontrole public-beta gateway’u dotyczą głównie ruchu modeli. Nadal konieczne jest wdrożenie dodatkowych mechanizmów kontrolnych w ramach agenta, w czasie działania narzędzi, na granicy MCP lub w dedykowanym gatewayu do działań. Taki podział jest korzystny, ponieważ gateway modeli nie powinien udawać, że może zatwierdzić zmianę w bazie danych produkcyjnej, której nigdy nie widzi.
Niezawodność stanowi element zarządzania
Gdy gateway znajduje się na ścieżce krytycznej, złe zarządzanie może samo spowodować przerwę w działaniu, jeśli zachowanie w przypadku awarii jest niejasne. Pomagają tu dwie koncepcje.
Najpierw każde obciążenie pracy wymaga wyraźnej polityki działania w przypadku awarii – albo otwarcia, albo zamknięcia. Prośba o streszczenie o niskim ryzyku, która nie może dotrzeć do usługi polityk, może zostać obsłużona w sposób uprzejmy. Prośba o dostęp do ograniczonych danych, która nie może udowodnić, że zastosowano odpowiednią politykę redakcji lub przechowywania, może nie być dopuszczona do działania w trybie awaryjnym.
Z drugiej strony model awaryjny musi być równoważny pod względem polityk, a nie tylko dostępny. Załóżmy, że model główny został zatwierdzony, ponieważ przechowuje dane w wymaganej regionie zgodnie z ustaloną polityką przechowywania. Automatyczne przełączenie na tańszego lub bardziej dostępnego dostawcę, który łamie te warunki, nie zwiększa odporności systemu. To zamiana naruszenia zasad na pozór ciągłej dostępności.
Kontrole wydatków opierają się na tej samej logice. Sztywne limity pomagają, ale limit bez powiadamiania i braku ścieżki eskalacji zamienia zarządzanie w arbitralne przerywanie usług. Lepszym rozwiązaniem jest ustalenie sekwencji działań.
usage approaches threshold
↓
alert
↓
route / reduce context / downgrade model if allowed
↓
hard block when policy requires it
↓
auditable exception path if business-approved
Z tego powodu routowanie modeli jest bliższe zarządzaniu portfelem niż wysyłaniu prostych zapytań do taniego modelu. Istotny jest koszt, a także opóźnienia, obsługa danych, jakość, poziom ryzyka i dostępność.
Koszt centralnego planu sterowania
Umieszczenie polityk w jednym miejscu pozwala uniknąć konieczności przechowywania ich przez każdego agenta, ale jednocześnie skupia odpowiedzialność w tym miejscu. Warstwa działania w czasie rzeczywistym znajduje się teraz na drodze ruchu modeli i w niektórych projektach pomaga w autoryzowaniu działań, dlatego musi być zaprojektowana jak każda inna krytyczna usługa.
- Kontrole polityk muszą być wykonywane wystarczająco szybko, aby nie dominować nad opóźnieniami żądań, a sama usługa polityk wymaga redundancji.
- Dane cenowe dla każdego dostawcy muszą być aktualne i przechowywane w pamięci cache, a tokeny do przetwarzania zbiorczego i rozumowania muszą być dokładnie liczone, aby limity wydatków były wiarygodne.
Kolejnym kosztem jest aspekt organizacyjny. Centralny zespół platformy może łatwo ustawić bezpieczne domyślne wartości, ale zbyt szerokie kontrole mogą spowolnić prace zespołów produkcyjnych. Droga od widoczności, przez kontrolę, aż po zapewnienie bezpieczeństwa łagodzi ten problem: najpierw obserwuj, uruchom nową politykę w trybie ostrzegawczym lub cieniowym, zmierz efekty i blokuj ją wyłącznie tam, gdzie ryzyko na to pozwala. Ta warstwa powinna eliminować powtarzalną pracę, nie stając się jednocześnie nieprzejrzystą zależnością, której nikt nie może ominąć, naprawić ani bezpiecznie zmodyfikować.
Zasady kontrolne nie powinny decydować o konsekwentnych działaniach
Zasady ochronne dzielą się na dwa rodzaje. Reguły oparte na wzorcach nadają się do strukturyzowanych haseł i identyfikatorów. Detektory oparte na modelach radzą sobie z bardziej zmiennymi kategoriami, takimi jak niestrukturyzowane dane osobowe, próby obejścia zabezpieczeń czy kwestie związane z wiarygodnością. Żaden z tych podejść nie jest doskonały, a sprawdzania oparte na modelach mają charakter probabilistyczny, więc mogą prowadzić zarówno do fałszywie pozytywnych, jak i fałszywie negatywnych wyników.
Odpowiednia zasada tworzenia powinna brzmieć następująco: wykrywanie treści może zmniejszyć ryzyko, ale nigdy nie powinno być jedyną barierą chroniącą przed negatywnymi skutkami działania agenta.
- Limity zwrotów pieniędzy lepiej zaimplementować w formie kodu niż za pomocą klasyfikatora.
- Rozwój produktu powinien zawierać sprawdzenie uprawnień.
- Działania o wysokim ryzyku mogą wymagać zatwierdzenia przez człowieka.
- Uprawnienia powinny być ograniczone tak, aby agent nie mógł przekroczyć zakresu wymaganego przez swoje zadanie, nawet jeśli zasada ochronna coś przeoczy.
Ramka robocza określa te granice w ten sam sposób: działania konsekwentne opierają się na deterministycznych ograniczeniach lub zatwierdzeniu człowieka, a nie na samej detekcji treści. Chodzi o luki pomiędzy wykrywaniem niebezpiecznych intencji a kontrolowaniem niebezpiecznych możliwości. Wytyczne OWASP dotyczące nadmiernej samodzielności modeli dochodzą do tego samego wniosku, zalecając minimalną funkcjonalność i uprawnienia narzędzi, przy czym autoryzacja musi być realizowana w systemach poniżej poziomu modelu, a nie pozostawiana samemu osądowi modelu. Obie warstwy są konieczne.
Obserwowanie i zapewnianie bezpieczeństwa
Śledzenie staje się znacznie bardziej przydatne, gdy decyzje polityki są częścią śledzenia.
- Zablokowana prośba modelu pokazuje, która polityka wydatków została uruchomiona.
- Zdarzenie redakcji pokazuje, która wersja polityki została zastosowana, bez ujawniania wrażliwych wartości.
- Zatwierdzenie narzędzia jest powiązane z działaniem, które zostało przez nie kontrolowane.
Oceny mogą więc sprawdzać coś więcej niż tylko dokładność modelu. Mogą badać, czy mniejszy model zachowuje jakość po zmianie ścieżki przekierowania, czy redukcja kontekstu obniża koszty bez negatywnego wpływu na wyniki, czy polityka cenzury generuje zbyt wiele fałszywie pozytywnych wyników, oraz czy nowa opcja awaryjna pozostaje równoważna pod względem polityki.
Wszystko to razem tworzy pięcioetapowy cykl. Govern określa właściciela, ryzyko i politykę; Decide zarządza ścieżkami, przekierowaniami i awariami; Protect egzekwuje zasady na każdej granicy; Observe mierzy zachowanie i wyniki polityki; Assure przechowuje historię i testuje zmiany. Wdrożenie reguły nie kończy pracy – praca jest zakończona wtedy, gdy można pokazać, która reguła została uruchomiona, co zdecydowała, co nastąpiło dalej oraz czy system nadal funkcjonuje poprawnie po zmianach.
Co to oznacza dla architektury agentów
Agenty produkcyjne wymagają architektury kontroli w czasie rzeczywistym, niezależnie od wybranej bramy. Centralna brama modeli stanowi doskonałe miejsce na zarządzanie wydatkami, wyborem dostawców, redakcją danych, ograniczeniami szybkości i rozwiązaniami awaryjnymi, a także umożliwia wybór modeli bez konieczności modyfikowania każdej aplikacji. Agent zarządzany nadal potrzebuje następujących warstw:
- upoważnienia oraz stałych ograniczeń dotyczących działań narzędzi,
- decyzji dotyczących zaufania do serwerów MCP wraz z zasadami dotyczącymi danych, które mogą zostać wysłane,
- minimalizacji kontekstu oraz weryfikacji tożsamości między współpracującymi agentami,
- zatwierdzenia lub ograniczenia w przypadku działań o poważnych konsekwencjach,
- śledzonej historii zasad stojących za każdą decyzją.
W przypadku żądania zwrotu pieniędzy model nadal może rozumować, a agent nadal może działać. Architektura po prostu przestaje wymagać od modelu, aby cały program zarządzania znajdował się w jego instrukcjach. Każda istotna granica otrzymuje odpowiedź na swoje pytanie przed jej przekroczeniem:
- Kto zadaje pytanie?
- Jakie dane są przekazywane i dokąd?
- Ile zasobów czasowych jest dozwolone wykorzystać?
- Które modele i narzędzia są dozwolone?
- Jaki jest plan na wypadek awarii preferowanego ścieżki?
- Czy potrzebna jest akceptacja człowieka?
- Która wersja polityki wydała polecenie?
To właśnie odróżnia polityki AI od zautomatyzowanych agentów podlegających regulacjom.
Literatura pokrewna
- WebMCP, MCP na poziomie usług czy zwykłe użycie przeglądarki: gdzie powinny znajdować się narzędzia agentów — Szczegółowe spojrzenie na WebMCP: narzędzia strony w porównaniu z MCP na poziomie usług oraz zwykłymi agentami przeglądarki, obejmujące sesje, OAuth CIMD, odkrywanie, stan lokalny i własność.
- Minimalna platforma do eksperymentowania dla agentów AI: testy A/B i wykonywanie prób w tle — Jak zdecydować, czy wersja B agenta powinna zastąpić wersję A, przy użyciu definicji pipeline’ów, lokalnego przypisywania, zdarzeń ekspozycji, śladów działania, oceny w sandboxzie, wykonywania prób w tle oraz zasad bezpieczeństwa.