Powrót
    31 sierpnia 2026 13:31

    Dane rządzą działaniami agentów

    Dane rządzą działaniami agentów

    Artykuł EDB zwraca uwagę na kluczowe wyzwanie związane z autonomią agentów AI: jak zapewnić, że nie podejmą działań, do których nie są uprawnieni, i kto ponosi za to odpowiedzialność.

    Dane rządzą działaniami agentów

    W miarę jak przedsiębiorstwa nadają agentom sztucznej inteligencji coraz większą autonomię – zdolność do planowania, decydowania i działania w różnych systemach bez konieczności zatwierdzania każdego kroku przez człowieka – w centrum każdej analizy architektury pojawia się trudne pytanie: Co zatrzyma agenta, gdy ten podejmie się działania, do którego nie był upoważniony? To oni, Twoi agenci, działają na Twoich modelach, uzyskują dostęp do Twoich danych w Twojej infrastrukturze – i odpowiedzialność za ich działania spoczywa na Tobie.

    Ta odpowiedzialność nie może być realizowana z perspektywy czasu ani z wykorzystaniem abstrakcyjnych polityk, które istnieją na papierze, ale nie w praktyce. Agenci potrzebują zasad w kontekście danej chwili, ponieważ nie wykazują oni własnego, nadrzędnego osądu co do swoich działań.

    Rozważmy prostą zasadę: Nigdy nie otwieraj drzwi samochodu. Ścisłe przestrzeganie tej zasady uniemożliwiłoby agentowi wejście do samochodu lub wyjście z niego. Jednakże, jeśli zmienisz kontekst (samochód uległ wypadkowi, wybuchł pożar, ktoś jest ranny i musi wyjść), to zasada, której naprawdę należy przestrzegać, to jej przeciwieństwo. Kontekst danej chwili jest wszystkim.

    Prosimy agentów o wykonywanie inteligentnych zadań; wymaga to inteligentnych zasad.

    Ochrona agentów: więcej niż tylko warunki brzegowe

    Naturalną reakcją jest dodawanie zabezpieczeń wokół agenta: instrukcji, zasad i monitoringu warstwowo nakładanych na model. Te mechanizmy są ważne, ale dzielą wspólną wadę strukturalną: Zasada dotycząca otwierania drzwi samochodu jest prawdopodobna aż do momentu, w którym faktycznie musisz zdecydować, czy otworzyć te drzwi. Kontrola na poziomie agenta jest tak niezawodna, jak przewidywalne jest wyjście z agenta, a właśnie autonomia jest tą właściwością, która utrudnia przewidywanie tego wyjścia.

    Zarządzanie, które opiera się na przeglądzie działania przed jego wykonaniem, nie nadąża za systemem, który działa w milisekundach, w wielu systemach jednocześnie. Zarządzanie musi stać się wykonywalne i egzekwowane tam, gdzie agenci faktycznie wykonują swoją pracę: na warstwie operacyjnych danych, w kontekście i dokładnie w momencie jego wystąpienia.

    Warstwa danych jako punkt egzekwowania

    Agenci tworzą wartość, uzyskując dostęp do danych. Przeglądają je, pobierają, przekształcają i coraz częściej na nich działają. Polityka mówiąca, że agent nie powinien uzyskiwać dostępu do określonej klasy danych, ma sens tylko wtedy, gdy system może odmówić mu tego dostępu w momencie, gdy agent o nią prosi. Podobnie, zasada mówiąca o konieczności audytowalności AI ma sens tylko wtedy, gdy organizacja może odtworzyć, co agent zrobił, do jakich danych uzyskał dostęp, w imieniu którego użytkownika działał i jakie były rezultaty. Kiedy zarządzanie istnieje na warstwie danych, jest ono niezależne od sposobu budowy agenta lub jego zachowania, ponieważ kontrola jest właściwością bazy danych, a nie obietnicą złożoną przez agenta.

    Zachowanie agenta może być probabilistyczne. Zarządzanie nie może być. Przedsiębiorstwo nie powinno polegać na modelu, który decyduje się przestrzegać polityki. Polityka musi być egzekwowana przez system. To jest różnica między nadzieją, że aktor pozostanie w granicach, a konstruowaniem granic, których nie może przekroczyć.

    Kontrole, które sprawiają, że to się stanie, to te, które wiele przedsiębiorstw już uruchamia na warstwie danych: kontrola dostępu oparta na rolach i atrybutach, bezpieczeństwo na poziomie wierszy i kolumn, klasyfikacja i maskowanie, polityka jako kod i pełne ślady audytowe.

    Zarządzanie tożsamością w kontekście agentów

    To, co się zmienia w przypadku agentów, to nie mechanizm, ale to, kto musi go rozpoznawać. Zarządzanie tożsamością musi traktować agenta jako główną jednostkę, z jego własną tożsamością i celem zadeklarowanym podczas otwarcia sesji.

    Po powiązaniu celu z tożsamością, silnik polityki może ocenić go w ten sam sposób, w jaki ocenia rolę lub dział, i zapis o tym, co się stało, może rejestrować nie tylko, kto działał i do czego uzyskał dostęp, ale także, w jakim celu zadeklarował to.

    Dziewięć kluczowych kontroli

    Można je pogrupować w trzy główne obszary:

    • Enforce it
    • See it and prove it
    • Unify and harden
    • Kontrola dostępu oparta na rolach i atrybutach egzekwowana w czasie wykonywania zapytań, dla agentów i użytkowników
    • Dynamiczne maskowanie kolumn napędzane tą samą ścieżką polityki
    • Tożsamość agenta jako główna jednostka, z zadeklarowanym celem powiązanym z rozpoczęciem sesji i zachowaniem działającego użytkownika
    • Klasyfikacja i tagowanie, które napędzają politykę
    • Rejestrowanie sesji, które rejestruje, który agent działał, w imieniu którego użytkownika i w jakim zadeklarowanym celu
    • Pochodzenie wzdłuż potoków, dzięki czemu wynik można prześledzić do żądania, które go wygenerowało
    • Centralne, przenośne zarządzanie polityką
    • Szyfrowanie w spoczynku i w tranzycie
    • Spójne egzekwowanie w środowiskach lokalnych, chmurowych i suwerennych lub odizolowanych

    „Zadeklarowany cel robi różnicę. Staje się to atrybut, który warstwa dostępu już rozumie, oceniając go w tej samej ścieżce polityki, co rola i bezpieczeństwo na poziomie wiersza. Mechanizm egzekwowania się nie zmienia. Zmienia się fakt, że cel agenta jest częścią tego, co ocenia, i częścią tego, co udowadnia się później” – mówi Priyanka Jain, wiceprezes ds. zarządzania produktem, zarządzania danymi i AI, EDB.

    Niezależnie od etapu, na którym jesteś w swojej ścieżce adopcji AI, egzekwowanie na warstwie danych pozwala na szybsze działanie, a nie na jego spowolnienie.

    Kluczowa Funkcjonalność Opis
    Role-Based Access Control (RBAC) Umożliwia kontrolowanie dostępu agentów do danych na podstawie przypisanych ról.
    Attribute-Based Access Control (ABAC) Pozwala na dynamiczne kontrolowanie dostępu na podstawie atrybutów agenta, użytkownika i danych.
    Row-Level Security (RLS) Ogranicza dostęp agentów tylko do konkretnych wierszy danych w tabeli.
    Column-Level Security (CLS) Zapewnia dostępność tylko określonych kolumn danych dla agentów.
    Policy as Code Definiowanie zasad zarządzania danymi w kodzie, co zapewnia powtarzalność i wersjonowanie.

    źródło inteligentnego przedruku: VentureBeat AI