Google uczy agentów AI oceniać intencje, nie tylko reguły

• Google opisał drugą część serii o agentach AI budowanych w modelu zero-trust, opartą na Gemini Enterprise Agent Platform.
• Statyczne zabezpieczenia z części pierwszej (podpisywanie zapisów kluczem Cloud KMS, izolacja gVisor, bramka wejścia/wyjścia z testami CI) łapią tylko to, co ktoś wcześniej zdążył przewidzieć i zapisać w regułach.
• Nowe podejście przenosi kontrolę na poziom platformy: Model Armor sprawdza zapytania na wejściu, Semantic Governance Policies oceniają sens działania agenta, a Agent Anomaly Detection wyłapuje podejrzane wzorce w wielu turach rozmowy.
• Scenariusz demonstracyjny to ten sam agent obsługi zwrotów z części pierwszej, zbudowany na Agent Development Kit (ADK), teraz działający pod nadzorem administratora platformy, a nie samego programisty.

Za pół roku firmy wdrażające agentów AI do obsługi klienta czy finansów będą musiały odpowiedzieć na jedno pytanie: co się stanie, gdy ktoś owinie oszustwo w poprawną gramatycznie prośbę? Google pokazuje, że odpowiedź nie tkwi w lepszym regexie - liczy się zupełnie inne podejście do nadzoru nad agentami.

Reguły, które łapią tylko to, co ktoś wcześniej przewidział

W pierwszej części tej serii Google opisał trzy twarde, deterministyczne zabezpieczenia dla autonomicznych agentów: podpisywane zapisy do bazy danych z użyciem Cloud KMS (czyli kryptograficznego klucza potwierdzającego, że to na pewno agent, a nie ktoś podszywający się pod niego, wykonał operację), izolację na poziomie systemu operacyjnego dzięki gVisor oraz bramkę wejścia i wyjścia opartą na testach jednostkowych CI.

Te mechanizmy działają dobrze, ale mają jeden wspólny problem: łapią wyłącznie to, co dało się z góry opisać w regułach. Parser SQL nie odróżni socjotechnicznie wyłudzonego zwrotu pieniędzy od legalnego, jeśli składnia zapytania jest poprawna. Reguła oparta na wzorcu tekstowym nie odróżni fizycznego kabla USB od otwartej licencji na oprogramowanie - a to właśnie na takich niuansach opiera się realne oszustwo. Test jednorazowej sesji nie wykryje z kolei sytuacji, w której cała flota agentów jest powoli drenowana w wielu kolejnych turach rozmowy.

To dokładnie ten sam problem, z którym mierzą się firmy wdrażające agentów działających autonomicznie w repozytoriach kodu - im więcej swobody dostaje agent, tym trudniej opisać z góry wszystkie sposoby, w jakie ktoś może go oszukać.

Nadzór przenosi się z kodu na platformę

Druga część serii zachowuje ten sam scenariusz: agenta obsługi klienta i zwrotów zbudowanego z użyciem Agent Development Kit (ADK), tego samego frameworka od Google co w części pierwszej. Zmienia się jednak miejsce, w którym dzieją się kontrole bezpieczeństwa - zamiast żyć w kodzie agenta, przenoszą się na poziom platformy, gdzie mogą oceniać intencję i reagować na zachowanie w czasie rzeczywistym.

To ma konkretną konsekwencję organizacyjną: nadzór definiuje i zarządza nim administrator platformy albo bezpieczeństwa, a nie programista, który pisał agenta. Platforma egzekwuje reguły z zewnątrz, poza kodem agenta - deweloper przestaje być jedyną osobą odpowiedzialną za to, żeby nic złego się nie wydarzyło.

Google wdraża to na Gemini Enterprise Agent Platform, zastępując samodzielnie hostowaną infrastrukturę kontenerów i ręcznie zarządzane listy reguł tekstowych (regex) trzema zarządzanymi mechanizmami:

• Model Armor - filtruje zapytania na styku z użytkownikiem, zanim jeszcze trafią głębiej do systemu.
• Semantic Governance Policies - polityki, które oceniają sens i cel działania agenta, a nie tylko poprawność formalną zapytania.
• Agent Anomaly Detection z Closed-Loop Remediation - wykrywanie nietypowych wzorców zachowania w czasie oraz automatyczna reakcja naprawcza, gdy coś odbiega od normy.

To podejście przypomina filozofię, którą widać już u firm powierzających całe systemy produkcyjne agentom AI - im więcej odpowiedzialności dostaje agent, tym więcej warstw nadzoru musi działać niezależnie od jego własnego kodu.

Ten sam agent zwrotów, ale pod nowym nadzorem

Google zachował ten sam przykład co w części pierwszej: agenta, który sprawdza zamówienia, liczy opłaty za zwrot towaru i wypłaca refundacje z konta sprzedawcy. Kiedy klient prosi o zwrot, agent odczytuje zamówienie funkcją verify_order, wylicza finalną kwotę zwrotu funkcją calculate_restocking_fee (ta operacja działa wewnątrz Agent Sandbox - zarządzanej piaskownicy platformy dla kodu generowanego przez model), a jeśli wszystko się zgadza, wywołuje issue_refund, podpisując żądanie tym samym kluczem asymetrycznym Cloud KMS, co w części pierwszej.

W realnym wdrożeniu agent wywoływałby te funkcje przez Model Context Protocol albo backendowe API, ale w demonstracyjnej wersji Google zaimplementował je jako lokalne funkcje w Pythonie - dla uproszczenia i czytelności przykładu.

Jeśli zarządzasz wdrożeniem agentów w firmie, a nie piszesz kodu, zapamiętaj jeden fakt: przesunięcie nadzoru z kodu na platformę oznacza, że polityki bezpieczeństwa można zmieniać i zaostrzać bez dotykania samego agenta. To podobny kierunek co u firm budujących infrastrukturę specjalnie pod agentów - agenci przestają być pojedynczymi programami, a stają się elementem większego systemu z własną warstwą kontroli.

Firmy, które dziś wdrażają agentów AI do obsługi klienta, finansów czy zwrotów, za jakiś czas będą musiały wybrać: albo zostać przy statycznych regułach i mieć nadzieję, że nikt ich nie ominie, albo przenieść nadzór na poziom platformy, gdzie system ocenia intencję, a nie tylko poprawność zapytania. Google pokazuje tu jeden konkretny kierunek, ale mechanizm - oddzielenie nadzoru od kodu agenta - to coś, co prawdopodobnie zobaczymy też u innych dostawców platform agentowych, bo problem jest wspólny dla całej branży, nie tylko dla jednej firmy.

Najczęstsze pytania

Czym różni się nadzór na poziomie platformy od zabezpieczeń wbudowanych w kod agenta?

Zabezpieczenia w kodzie agenta, jak testy jednostkowe czy reguły tekstowe, sprawdzają tylko to, co programista przewidział z góry. Nadzór na poziomie platformy działa niezależnie od kodu agenta, ocenia intencję działania w czasie rzeczywistym i może być zarządzany przez administratora bezpieczeństwa bez ingerencji w samego agenta.

Co to jest Gemini Enterprise Agent Platform?

To platforma Google do budowania i wdrażania agentów AI w firmach, która zapewnia zarządzane mechanizmy bezpieczeństwa, takie jak Model Armor, Semantic Governance Policies i Agent Anomaly Detection, zamiast konieczności samodzielnego hostowania infrastruktury i pisania reguł od zera.

Czym jest Agent Development Kit (ADK)?

ADK to framework od Google do budowania agentów AI, opisany szerzej w pierwszej części tej serii. W drugiej części ten sam agent obsługi zwrotów zbudowany na ADK zostaje wdrożony z nowymi, zarządzanymi mechanizmami nadzoru na poziomie platformy.

Czy to podejście jest dostępne dla firm poza USA, w tym w Polsce?

Gemini Enterprise Agent Platform jest częścią oferty chmurowej Google Cloud, dostępnej globalnie, w tym w Polsce. Dla firm w Unii Europejskiej wdrażających agentów AI z dostępem do danych klientów taki nadzór na poziomie platformy może ułatwić spełnienie wymogów dotyczących odpowiedzialności za automatyczne decyzje.