Zarządzanie agentami AI w przedsiębiorstwach przechodzi od polityk do kontroli w czasie rzeczywistym
Zarządzanie agentami AI w przedsiębiorstwach przekroczyło pierwszą granicę operacyjną: same dokumenty polityk nie są w stanie kontrolować oprogramowania, które niezależnie podejmuje działania w rzeczywistym świecie. Wyłaniający się model przenosi egzekwowanie zasad do chwili tuż przed wysłaniem danych przez agenta, zmianą rekordu, wywołaniem narzędzia lub wydaniem pieniędzy.
Ta zmiana stanowi główną tezę niedawnej koncepcji kontroli w punkcie działania. Zarządzanie nie polega już wyłącznie na zatwierdzaniu modelu, dokumentowaniu jego ryzyk ani przeglądaniu wyników po wdrożeniu. Staje się problemem bezpieczeństwa w czasie rzeczywistym.
Presja spada na zespoły bezpieczeństwa, dostawców tożsamości, właścicieli aplikacji i każdego dostawcę budującego platformy agentowe. Konflikt jest wyraźny. Firmy chcą, aby agenci realizowali dłuższe przepływy pracy przy mniejszym nadzorze, podczas gdy zespoły bezpieczeństwa muszą zapewnić, że każde istotne działanie pozostanie możliwe do przypisania i odwrócenia.
Nie jest to kolejna debata o tym, czy sztuczna inteligencja potrzebuje zasad. Pilniejsze pytanie brzmi: gdzie te zasady muszą działać. W przypadku systemów autonomicznych odpowiedź coraz częściej znajduje się bardzo blisko samego działania.
Co zmieniło się w zarządzaniu agentami AI w przedsiębiorstwach
Obiektem zarządzania nie jest już wyłącznie model ani aplikacja. Jest nim działająca tożsamość wyposażona w narzędzia, pamięć, uprawnienia i zmienny kontekst.
Tradycyjny nadzór nad AI koncentruje się na względnie stabilnej sekwencji. Osoba przekazuje dane wejściowe, model generuje wynik, a następnie ktoś ten wynik przegląda lub wykorzystuje. Zarządzanie może analizować model, jego dane treningowe, zamierzone zastosowanie, wyniki ewaluacji i generowane treści.
Agent AI zmienia tę sekwencję. Może podzielić cel na kroki, wybierać narzędzia, pobierać informacje, wywoływać usługi zewnętrzne i modyfikować systemy. Może również powtarzać ten proces, dopóki nie uzna, że cel został osiągnięty.
Każdy krok może zmienić ryzyko kolejnego. Niewinne polecenie podsumowania opinii klientów staje się bardziej wrażliwe, gdy agent otwiera bazę danych klientów. Ryzyko zmienia się ponownie, jeśli eksportuje rekordy, przygotowuje wiadomości lub wysyła je bez weryfikacji.
Powstaje w ten sposób luka między zatwierdzeniem na etapie projektowania a zachowaniem w czasie działania. Komitet ds. zarządzania może zatwierdzić agenta do wsparcia sprzedaży, lecz taka etykieta niewiele mówi o konkretnym zapytaniu do bazy danych. Nie może też rozstrzygnąć, czy określony e-mail powinien zostać wysłany o 2:00 w nocy z konta osoby zarządzającej.
Ramy AI NIST zapewniają organizacjom szeroką strukturę do zarządzania, mapowania, mierzenia i kontrolowania ryzyk związanych z AI. Struktura ta pozostaje użyteczna, ale agenci zmuszają zespoły do wdrażania jej zasad ze znacznie większą szczegółowością.
Klasyfikacja ryzyka przypisana całej aplikacji nie może odpowiedzieć na każde pytanie pojawiające się w czasie działania. System musi wiedzieć, kto zlecił zadanie, który agent działa, do jakich danych uzyskał dostęp i jakie narzędzie wybrał. Musi również wiedzieć, czy żądane działanie przekracza uprawnienia użytkownika.
To jest praktyczne znaczenie zarządzania w punkcie działania. Kontrola ocenia próbę wykonania działania na podstawie bieżących sygnałów dotyczących tożsamości, uprawnień, danych i środowiska. Następnie zezwala na działanie, blokuje je, ogranicza lub eskaluje.
Kontrola może wymagać zatwierdzenia przez człowieka, zanim nastąpi transfer pieniędzy. Może redagować wrażliwe pola, zanim informacje trafią do modelu. Może uniemożliwić agentowi wysłanie wiadomości na zewnętrzny adres, nawet jeśli ten sam agent może utworzyć wewnętrzny szkic.
Decyzje te muszą zapadać podczas wykonywania procesu. Kwartalny przegląd polityki nie może przerwać niebezpiecznego wywołania API. Audyt przeprowadzony po wdrożeniu może wyjaśnić incydent, ale nie może zapobiec pierwotnemu działaniu.
Zmiana ta przekształca również rozumienie dowodów. Organizacje potrzebują czegoś więcej niż zapisu potwierdzającego, że agent został zatwierdzony. Potrzebują dzienników łączących pierwotne żądanie z decyzjami modelu, wywołaniami narzędzi, pobranymi danymi, zatwierdzeniami i końcowym rezultatem.
Ten łańcuch ma znaczenie, gdy agent działa w kilku usługach. Jeden przepływ pracy może rozpocząć się w interfejsie czatu, pobrać umowę, zaktualizować rekord klienta i utworzyć wniosek o płatność. Każde przejście tworzy kolejne miejsce, w którym uprawnienia mogą się rozszerzyć lub kontekst może zniknąć.
Zarządzanie w punkcie działania traktuje te przejścia jako granice bezpieczeństwa. Podejście to nie zakłada, że zatwierdzony agent pozostaje bezpieczny przez cały przepływ pracy. Weryfikuje, czy każde istotne działanie nadal odpowiada pierwotnemu celowi i przekazanym uprawnieniom.
Dlaczego statyczne polityki AI tracą kontrolę w czasie działania
Spisana polityka opisuje dopuszczalne zachowanie, lecz autonomiczny przepływ pracy potrzebuje egzekwowalnych decyzji przed każdym istotnym krokiem.
Statyczne zarządzanie sprawdza się najlepiej, gdy systemy działają przewidywalnie. Zespoły mogą definiować zatwierdzone zastosowania, zakazywać wprowadzania wrażliwych danych, testować stały przepływ pracy i szkolić pracowników. Środki te stają się mniej niezawodne, gdy agent sam wybiera trasę przez połączone narzędzia.
Agent może rozpocząć od dozwolonego celu, a mimo to wykonać niedopuszczalne działanie. Może błędnie zinterpretować instrukcję, zastosować się do złośliwej treści pobranej z dokumentu albo połączyć pojedynczo nieszkodliwe uprawnienia. Wynikające z tego możliwości mogą przekroczyć to, co sugeruje jakiekolwiek pojedyncze uprawnienie.
Wstrzykiwanie poleceń ilustruje ten problem. Wroga instrukcja może pojawić się na stronie internetowej, w e-mailu, dokumencie lub zgłoszeniu wsparcia, które agent pobiera. Treść nakazuje agentowi zignorować pierwotny cel, ujawnić informacje lub uruchomić inne narzędzie.
Konwencjonalny filtr może sprawdzić początkowy prompt użytkownika i nie wykryć niczego niebezpiecznego. Szkodliwa instrukcja pojawia się później, gdy przepływ pracy już się rozpoczął. Zarządzanie musi zatem podążać za agentem wraz ze zmianami jego kontekstu.
Wytyczne OWASP dotyczące systemów agentowych opisują ryzyka związane z nadmierną autonomią, niewłaściwym użyciem narzędzi, manipulacją pamięcią, kaskadowymi awariami i skompromitowanymi interakcjami agentów. Są to ryzyka wykonawcze, a nie jedynie niepożądane wyniki tekstowe.
Nadmierna autonomia występuje, gdy agent otrzymuje więcej uprawnień, niż wymaga jego zadanie. Asystent do planowania spotkań może potrzebować odczytu kalendarzy i proponowania terminów. Rzadko potrzebuje nieograniczonego dostępu do usuwania wydarzeń, zapraszania zewnętrznych uczestników lub odczytywania wszystkich prywatnych załączników.
Rozróżnienie wydaje się proste, dopóki przepływy pracy nie staną się dynamiczne. Agent może zasadnie potrzebować rozszerzonego dostępu do jednego zadania, ale nie do innego. Stałe, szerokie uprawnienie rozwiązuje problem operacyjny, jednocześnie tworząc trwałą ekspozycję bezpieczeństwa.
Kontrole w czasie działania oferują inne podejście. System może wydać wąskie, tymczasowe upoważnienie po ocenie zadania i jego kontekstu. Takie upoważnienie może wygasnąć po jednym działaniu lub wymagać zatwierdzenia, gdy żądany zakres się zmieni.
Ta sama zasada dotyczy danych. Agent przygotowujący kwartalne podsumowanie może potrzebować zagregowanych informacji o przychodach, ale nie pełnego rekordu osobowego każdego klienta. Kontrola blisko źródła danych może ograniczyć to, co agent pobiera, zanim model w ogóle zobaczy te dane.
Ma to znaczenie, ponieważ zabezpieczenia na poziomie modelu są tylko jedną warstwą. Model można poinstruować, aby nie ujawniał wrażliwych informacji, lecz instrukcje mogą być sprzeczne lub zawieść. Minimalizacja danych i autoryzacja narzędzi ograniczają konsekwencje, gdy zachowanie modelu staje się niewiarygodne.
Podejście oparte na czasie działania oddziela również rozumowanie o niskim ryzyku od wykonania o wysokim ryzyku. Agent może analizować opcje, przygotować rekomendację i symulować działanie bez otrzymywania uprawnień do jego wykonania. Uprawnienie pojawia się dopiero, gdy przepływ pracy osiągnie kontrolowaną granicę.
Zatwierdzenie przez człowieka pozostaje ważne, ale nie może być uniwersalną odpowiedzią. Wymaganie zatwierdzenia każdego wywołania narzędzia eliminuje znaczną część efektywności obiecywanej przez agentów. Może również prowadzić do zmęczenia zatwierdzaniem, gdy ludzie akceptują żądania bez sprawdzania ich kontekstu.
Dobre zarządzanie rezerwuje interwencję dla istotnych progów. Odczyt publicznej strony produktu może odbywać się automatycznie. Eksport rekordów klientów, zmiana kodu produkcyjnego lub wysłanie środków powinny uruchamiać silniejsze kontrole.
Dokładna granica zależy od organizacji i zadania. Mechanizm pozostaje jednak spójny: należy ocenić działanie, jego cel, inicjatora oraz potencjalny wpływ. Następnie należy zastosować najwęższe uprawnienie, które pozwala kontynuować uzasadnioną pracę.
Profil generatywnej AI opracowany przez NIST podkreśla zarządzanie ryzykiem w całym cyklu życia AI. Systemy agentowe rozszerzają ten cykl o łańcuch decyzji, które mogą wywoływać natychmiastowe skutki.
Zarządzanie staje się zatem mniej podobne do publikowania zbioru zasad, a bardziej do obsługi systemu autoryzacji. Polityki nadal określają, co powinno się wydarzyć. Kontrole w czasie działania przekładają te polityki na techniczne decyzje podejmowane, zanim konsekwencje staną się realne.
Tożsamość staje się płaszczyzną kontroli agentów AI
Agent potrzebuje odrębnej, możliwej do prześledzenia tożsamości, ponieważ pożyczone poświadczenia pracowników zacierają odpowiedzialność i osłabiają każdą dalszą kontrolę.
Wiele wczesnych agentów działa za pośrednictwem istniejącego konta użytkownika. Agent dziedziczy sesję, token API lub poświadczenie usługi. Taka konstrukcja ułatwia tworzenie prototypów, ale powoduje niejednoznaczność podczas dochodzeń i przeglądów dostępu.
Dziennik systemowy może wskazywać, że pracownik pobrał plik. Może nie ujawniać, czy osoba kliknęła pobranie, czy zatwierdzony agent go pozyskał, ani czy skompromitowany przepływ pracy działał za pośrednictwem jej konta. W zapisie autoryzacji brakuje faktycznego wykonawcy.
Odrębna tożsamość agenta rozwiązuje część tego problemu. Umożliwia administratorom przypisywanie uprawnień agentowi, monitorowanie jego zachowania i cofanie jego dostępu bez wyłączania ludzkiego sponsora. Pozwala również politykom odróżniać działania ludzi od działań maszyn.
Tożsamość nadal musi być powiązana z odpowiedzialną osobą lub procesem biznesowym. W przeciwnym razie organizacje tworzą rosnącą populację kont maszynowych bez jasno określonego właściciela. Nieaktywne agenty mogą wówczas zachowywać dostęp długo po zakończeniu pierwotnego projektu.
Microsoft przedstawił kontrole Agent ID jako warstwę tożsamości służącą do wykrywania, zarządzania i zabezpieczania agentów. Kierunek ten odzwierciedla szerszy wniosek branżowy: agenci potrzebują zarządzania cyklem życia porównywalnego z innymi tożsamościami niebędącymi ludźmi.
Wykrywanie jest pierwszym krokiem, ponieważ zespoły bezpieczeństwa nie mogą zarządzać agentami, których nie widzą. Jednostki biznesowe mogą tworzyć agentów na platformach programowych, w systemach low-code, frameworkach programistycznych i usługach chmurowych. Każda ścieżka może tworzyć kolejną tożsamość, token lub integrację.
Rejestracja powinna obejmować właściciela agenta, jego cel, środowisko, zatwierdzone narzędzia i oczekiwany dostęp do danych. Powinna również wskazywać, czy agent może działać automatycznie, czy wymaga potwierdzenia. Te atrybuty dają systemom działającym w czasie rzeczywistym podstawę do autoryzacji.
Uwierzytelnianie odpowiada na pytanie, czy wywołujący jest zarejestrowanym agentem. Autoryzacja odpowiada na pytanie, czy ten agent może wykonać dane działanie w tych warunkach. Zarządzanie zawodzi, gdy zespoły rozwiązują pierwsze pytanie, lecz w przypadku drugiego przyznają szeroki, trwały dostęp.
Kontekst pozwala precyzyjniej określać uprawnienia. Polityka może analizować użytkownika składającego żądanie, stan urządzenia, klasyfikację danych, cel, wartość transakcji i ostatnie zachowanie agenta. Może następnie stosować różne mechanizmy kontroli bez konieczności redefiniowania całego agenta.
Asystent może odczytywać własne notatki pracownika ze spotkań podczas zwykłej pracy. To samo żądanie powinno podlegać bliższej kontroli, gdy dotyczy plików z ograniczonym dostępem należących do innego działu. Nagłe masowe pobieranie powinno być traktowane inaczej niż pobranie jednego dokumentu.
Pamięć tworzy kolejny problem związany z tożsamością. Agenci mogą przechowywać historię zadań, preferencje, pozyskane fakty i decyzje pośrednie. Taka pamięć może przetrwać po zakończeniu pierwotnej sesji użytkownika, wpływając jednocześnie na przyszłe działania w ramach innego żądania.
Zespoły muszą wiedzieć, która tożsamość jest właścicielem pamięci i kto może ją zmieniać. Potrzebują również informacji o pochodzeniu danych, czyli zapisu, skąd pochodziły przechowywane informacje i jak się zmieniały. Bez informacji o pochodzeniu zatruta pamięć może po cichu przekierowywać późniejsze przepływy pracy.
Systemy wiedzy mogą wspierać bezpieczniejsze wyszukiwanie, gdy zachowują granice źródeł i mechanizmy kontroli dostępu. Baza wiedzy dla zespołów inżynieryjnych jest najbardziej użyteczna, gdy agent otrzymuje wyłącznie dokumenty, do których dostęp ma jego aktualny zleceniodawca.
Wielu agentów w jednym przepływie pracy sprawia, że tożsamość staje się jeszcze ważniejsza. Jeden agent może zlecić drugiemu przeprowadzenie researchu, a następnie poprosić trzeciego o aktualizację systemu. Usługa odbierająca musi wiedzieć, czy przekazane uprawnienia pozostają ważne w całym tym łańcuchu.
Delegowanie nie powinno przypadkowo tworzyć nowych uprawnień. Jeżeli pierwszy agent nie może zatwierdzić płatności, agent, któremu przekazano zadanie, również nie powinien zyskiwać takiej możliwości. Każde przekazanie powinno zachowywać pierwotne ograniczenia, cel i termin wygaśnięcia.
Wymóg ten przypomina utrwalone koncepcje bezpieczeństwa tożsamości, lecz agenci działają z nietypową szybkością i skalą. Człowiek może wykonać kilka wrażliwych działań podczas jednej sesji. Zautomatyzowany agent może zainicjować wiele działań w kilku systemach, zanim osoba nadzorująca je zauważy.
Płaszczyzna kontroli musi więc łączyć tożsamość z limitami szybkości, monitorowaniem zachowań i polityką transakcyjną. Tożsamość informuje organizację, kto podjął działanie. Nadzór w czasie działania określa, czy temu podmiotowi należy pozwolić kontynuować.
Kontrola w punkcie działania tworzy własne kompromisy
Egzekwowanie zasad w czasie działania ogranicza niekontrolowane uprawnienia, ale wprowadza też opóźnienia, złożoność polityk, ryzyko integracyjne i nowe punkty kontroli, które mogą stać się celem ataków.
Najmocniejsza wersja argumentu za zarządzaniem może brzmieć zwodniczo kompletnie. Nadaj każdemu agentowi tożsamość, oceniaj każde działanie, rejestruj każdą decyzję i wymagaj zatwierdzenia dla niebezpiecznych operacji. W praktyce każdy z tych elementów może zawieść.
Jakość polityk jest pierwszym ograniczeniem. Silnik działający w czasie rzeczywistym nie może egzekwować intencji, których zespoły nie przełożyły na precyzyjne reguły. Określenia takie jak wrażliwy, odpowiedni, istotny lub zaufany często wymagają oceny biznesowej różniącej się między działami.
Zbyt szerokie reguły pozostawiają dostępne niebezpieczne działania. Zbyt restrykcyjne zasady zakłócają legalną pracę i zachęcają pracowników do obchodzenia systemu. Organizacja musi dostrajać polityki na podstawie rzeczywistych przepływów pracy, a nie tylko abstrakcyjnych kategorii ryzyka.
Kontekst również może być niepełny. Usługa bezpieczeństwa może widzieć żądanie API, nie rozumiejąc rozmowy, która je wywołała. Brama modelu może rozumieć prompt, lecz nie posiadać informacji o klasyfikacji danych systemu docelowego.
Atakujący mogą wykorzystywać te luki. Mogą podzielić zabroniony cel na kilka dozwolonych działań. Każdy krok wydaje się nieszkodliwy, gdy jest analizowany osobno, podczas gdy cała sekwencja prowadzi do nieautoryzowanego rezultatu.
Mechanizmy kontroli uwzględniające sekwencje mogą wykrywać niektóre wzorce, ale wymagają bogatszego stanu i dłuższego przechowywania danych. Rodzi to obawy dotyczące prywatności i operacji. Szczegółowe ślady mogą zawierać żądania pracowników, dane klientów, wyniki modeli i poufne decyzje biznesowe.
Organizacje muszą chronić telemetrię zarządzania równie starannie jak systemy, które monitoruje. Przejęty log może ukryć atak lub fałszywie obciążyć użytkownika. Ujawniony ślad może odsłonić właśnie te informacje, które mechanizmy kontroli miały chronić.
Wydajność stanowi kolejny kompromis. Agent może wykonywać wiele drobnych wywołań narzędzi podczas realizacji jednego zadania. Przepuszczanie każdego wywołania przez kilka silników polityk może zwiększać opóźnienia, koszty i liczbę dodatkowych punktów awarii.
Egzekwowanie oparte na ryzyku może zmniejszyć to obciążenie. Działania o niewielkim wpływie i odwracalne otrzymują lekkie kontrole. Działania o dużym wpływie lub nieodwracalne podlegają silniejszej autoryzacji, bardziej szczegółowemu rejestrowaniu lub weryfikacji przez człowieka.
To rozróżnienie wymaga starannej klasyfikacji. Wysłanie szkicu do wewnętrznej kolejki recenzji jest odwracalne. Opublikowanie tego samego tekstu dla klientów już nie. Odczyt jednego rekordu klienta różni się od wyeksportowania całej bazy danych.
Agenci mogą również zachowywać się inaczej po aktualizacjach modeli. Nowy model może wybierać narzędzia w innej kolejności, generować inne argumenty lub podejmować więcej kroków. Istniejące polityki mogą blokować nowe zachowanie albo nie zauważyć nowo wprowadzonej ścieżki.
To sprawia, że ciągłe testowanie staje się częścią zarządzania. Zespoły powinny odtwarzać reprezentatywne przepływy pracy na zaktualizowanych modelach, narzędziach i politykach. Testy powinny obejmować złośliwe dokumenty, niejednoznaczne instrukcje, cofnięte uprawnienia i niedostępne usługi.
Interoperacyjność wnosi kolejną niepewność. Branża rozwija protokoły pomagające agentom wykrywać możliwości i komunikować się między systemami. Google przedstawił protokół Agent2Agent, aby wspierać współpracę między agentami zbudowanymi w różnych frameworkach.
Interoperacyjność może ograniczyć nakład pracy związany z integracją, lecz poszerza też relacje zaufania. Lokalny agent może polegać na opisie możliwości, tożsamości lub wykonanej pracy przedstawionym przez zdalnego agenta. Takie twierdzenie wymaga technicznej weryfikacji.
Wspólny protokół nie tworzy automatycznie wspólnego zarządzania. Organizacje nadal potrzebują zasad przyjmowania delegowanych zadań, przekazywania wrażliwego kontekstu i walidowania zwracanych wyników. Muszą zdecydować, którzy zdalni agenci należą do poszczególnych granic zaufania.
Koncentracja dostawców stwarza powiązane ryzyko. Jeżeli jedna platforma tożsamości lub polityk pośredniczy w każdym działaniu agenta, awaria może zatrzymać krytyczne przepływy pracy. Błąd konfiguracji może zablokować całą organizację albo przyznać nadmierny dostęp na dużą skalę.
Zespoły potrzebują zachowań awaryjnych przed wdrożeniem. Niektóre działania powinny być domyślnie blokowane, co oznacza, że system zatrzymuje je, gdy mechanizm kontroli jest niedostępny. Inne operacje niskiego ryzyka mogą być kontynuowane przy bardziej rygorystycznych limitach i rozszerzonym rejestrowaniu.
Zarządzanie w punkcie działania należy więc traktować jako obronę warstwową, a nie gwarancję. Działa najlepiej w połączeniu z ograniczonymi narzędziami, minimalnym dostępem do danych, izolowanym wykonywaniem, walidacją wyników, monitorowaniem i reagowaniem na incydenty.
Sceptyczny wniosek jest prosty. Przeniesienie kontroli bliżej wykonania poprawia zdolność organizacji do zapobiegania szkodom. Nie czyni autonomicznego zachowania przewidywalnym ani nie eliminuje potrzeby weryfikacji na etapie projektowania.
Presja wykracza poza zespoły bezpieczeństwa
Zarządzanie agentami AI zmusza dostawców aplikacji i właścicieli procesów biznesowych do udostępniania mechanizmów kontroli, których zespoły bezpieczeństwa nie mogą dodać spoza przepływu pracy.
Zespół bezpieczeństwa może zarządzać tożsamościami i dostępem sieciowym, ale nie zawsze potrafi zrozumieć znaczenie biznesowe aplikacji. Wywołanie API zmieniające pole może zatwierdzać zwrot, publikować dokument lub zamykać konto klienta.
Dostawcy aplikacji muszą oznaczać działania o istotnych konsekwencjach i udostępniać wokół nich punkty autoryzacji. Muszą też zwracać wystarczająco dużo kontekstu, aby systemy polityk mogły odróżnić podgląd od zobowiązania. Bez tych szczegółów egzekwowanie pozostaje zbyt ogólne.
Dostawcy platform agentowych stoją przed podobnym obowiązkiem. Potrzebują trwałych zapisów kroków planowania, wyborów narzędzi, argumentów, odpowiedzi i zatwierdzeń. Zespoły bezpieczeństwa muszą móc przeszukiwać te zapisy bez ujawniania nieograniczonych danych chain-of-thought.
Dostawcy modeli nadal odpowiadają za zabezpieczenia, ewaluacje i przewidywalne zachowanie przy korzystaniu z narzędzi. Nie mogą jednak decydować o polityce autoryzacji każdego klienta. To samo działanie modelu może być nieszkodliwe w jednym środowisku, a zabronione w innym.
Właściciele procesów biznesowych muszą definiować te rozróżnienia. Liderzy finansowi wiedzą, które transakcje wymagają rozdziału obowiązków. Zespoły HR wiedzą, które rejestry pracowników wymagają ściślejszego dostępu. Zespoły prawne wiedzą, kiedy wygenerowany szkic staje się oficjalną komunikacją.
Deweloperzy przekładają następnie te wymagania na granice techniczne. Decydują, które narzędzia agent może wywoływać, jakie parametry może podawać i jakie odpowiedzi może otrzymywać. Określają również, co dzieje się, gdy mechanizm kontroli odrzuca krok.
Ten podział odpowiedzialności wywiera presję, ponieważ żaden uczestnik nie może samodzielnie rozwiązać problemu. Platformy tożsamości nie znają pełnego znaczenia zadań. Dostawcy aplikacji nie mają kompletnego kontekstu organizacyjnego. Dostawcy modeli nie mają uprawnień do decydowania o politykach klientów.
Najsłabsza integracja może podważyć cały łańcuch. Agent może mieć silną tożsamość, ale wywoływać narzędzie za pośrednictwem współdzielonego konta usługi. Narzędzie może egzekwować uprawnienia, lecz przyjmować niezwalidowane instrukcje z zewnętrznego dokumentu.
Zespoły zakupowe powinny oczekiwać od dostawców agentów bardziej konkretnych odpowiedzi. Ogólne stwierdzenie o odpowiedzialnej AI nie wystarczy. Kupujący muszą wiedzieć, jak produkt obsługuje tożsamości, delegowanie, zatwierdzenia, logi, pamięć i cofanie uprawnień.
Powinni również pytać, czy mechanizmy kontroli pozostają skuteczne we wszystkich konektorach. Agent może respektować ograniczenia na swojej podstawowej platformie, ale tracić je przy wywołaniu usługi zewnętrznej. Dziedziczenie uprawnień musi przetrwać tę zmianę.
Własność operacyjna ma znaczenie po zakupie. Ktoś musi przeglądać dostęp, badać anomalie, usuwać nieużywanych agentów i aktualizować polityki, gdy zmieniają się przepływy pracy. Inwentarz agentów bez procesu operacyjnego staje się kolejną nieaktualną listą zasobów.
Deweloperzy i pracownicy wiedzy powinni się tym interesować, ponieważ bardziej rygorystyczne zarządzanie ukształtuje doświadczenie korzystania z produktów. Niektórzy agenci będą zatrzymywać się przed wrażliwymi działaniami. Inni będą oferować podglądy, ograniczone tryby lub wyraźne prośby o uprawnienia.
Takie przerwy nie zawsze są wadami. Widoczny krok zatwierdzenia może wyjaśnić, co agent zamierza zrobić i jakich danych użyje. Daje użytkownikowi szansę na wychwycenie źle zrozumianego celu przed wykonaniem.
Źle zaprojektowane mechanizmy kontroli przyniosą odwrotny efekt. Powtarzające się niejasne komunikaty nauczą użytkowników automatycznego zatwierdzania żądań. Interfejs musi prostym językiem wyjaśniać konkretne działanie, cel, zakres i konsekwencję.
Presja rynkowa sprzyja więc produktom łączącym użyteczną autonomię ze zrozumiałymi granicami. Skuteczność realizacji zadań pozostanie ważna. Zaufane delegowanie stanie się równie istotne, gdy agenci będą uzyskiwać dostęp do wartościowych systemów.
Trzy sygnały pokażą, czy zarządzanie w czasie działania działa
Kolejnym testem nie będzie następne ogłoszenie polityki. Będzie nim to, czy tożsamość, autoryzacja i dowody pozostają nienaruszone w rzeczywistych, wieloetapowych przepływach pracy.
Pierwszym sygnałem będzie wdrażanie odrębnych tożsamości agentów na głównych platformach korporacyjnych. Istotne dowody będą obejmować mechanizmy kontroli cyklu życia, wskazanych właścicieli, wąskie uprawnienia, wygaśnięcie i cofanie uprawnień.
Sama etykieta produktu nie wystarczy. Zespoły bezpieczeństwa muszą odróżniać agenta od sponsorującego go pracownika oraz od kont usług stojących za jego narzędziami. Szersze wsparcie wzmocniłoby tezę o zarządzaniu w czasie działania.
Drugim sygnałem będzie egzekwowanie zasad na granicach aplikacji. Dostawcy oprogramowania dla przedsiębiorstw powinni udostępniać polityki dla działań o istotnych konsekwencjach, w tym wiadomości zewnętrznych, zmian rekordów, wdrażania kodu i operacji finansowych.
Obserwuj, czy te mechanizmy kontrolne rozumieją kontekst biznesowy, czy jedynie filtrują tekst. Autoryzacja uwzględniająca kontekst pokazałaby, że zarządzanie zostało przeniesione do warstwy wykonawczej. Ogólne ostrzeżenia i opcjonalne dzienniki wskazywałyby, że ta zmiana wciąż nie została w pełni zrealizowana.
Trzecim sygnałem są dowody płynące z awarii i niezależnych testów. Badacze powinni sprawdzać odporność na wstrzykiwanie promptów, delegowane uprawnienia, zatrutą pamięć, nadmierne uprawnienia oraz interakcje między zdalnymi agentami.
Przejrzyste raporty z incydentów będą równie istotne jak udane demonstracje. Mogą pokazać, czy mechanizmy kontrolne zablokowały szkodliwe działania, ograniczyły ich zakres, czy jedynie udokumentowały szkody po fakcie. Powtarzające się obejścia osłabiłyby twierdzenia, że egzekwowanie zasad w punkcie działania jest dojrzałe.
W ciągu najbliższych kilku miesięcy nabywcy powinni prosić dostawców o zademonstrowanie jednego kompletnego łańcucha. Należy zacząć od wskazanego użytkownika, delegować ściśle określone zadanie, pobrać chronione dane, wywołać narzędzie, wymagać zatwierdzenia i odebrać dostęp.
Następnie trzeba przeanalizować dowody. Czy dostawca potrafi wykazać, kto zainicjował zadanie, który agent działał, do czego uzyskał dostęp, która polityka miała zastosowanie oraz czy delegowanie zmieniło zakres uprawnień?
Zarządzanie agentami AI w przedsiębiorstwie odniesie sukces tylko wtedy, gdy odpowiedzi na te pytania sprawdzą się w rzeczywistych wdrożeniach. Jeśli Twoja organizacja prowadzi pilotaż agentów, zidentyfikuj pierwsze nieodwracalne działanie w każdym procesie. Umieść tam najsilniejszy mechanizm kontrolny, przetestuj ścieżkę odrzucenia i potwierdź, że każdą decyzję można przypisać do konkretnego podmiotu.
