Agent musi mieć tożsamość. OASIS CoSAI dostarcza brakujące ogniwo audytu wdrożeń AI w kancelarii.

Polski adwokat doradzający kancelarii, która właśnie wdrożyła pierwszego agenta AI - czy to do segregacji korespondencji, draftowania pism, sprawdzania orzecznictwa, czy do obsługi przelewów - prędzej czy później dostaje pytanie, na które dotąd odpowiadali tylko informatycy. Kto klikał? Kto miał uprawnienia? W czyim imieniu zadziałał? Skąd wiemy, że to był ten agent, a nie zmodyfikowana wersja? Jak go odetniemy, jeśli zwariuje?

To są pytania o tożsamość i autoryzację - dokładnie te, które tradycyjne IAM rozwiązuje od dwóch dekad dla ludzi i kont serwisowych. Dla agentów AI tradycyjne IAM nie działa. OASIS CoSAI mówi to wprost: agenci są autonomiczni, krótkożywotni, samoaktualizujący się, działają wieloosobowo (multi-tenant), a klasyczne podejście "uwierzytelnij raz, ufaj sesji" przestaje obowiązywać w momencie, w którym agent zaczyna chodzić po API w imieniu różnych użytkowników jednocześnie. Workstream 4 jest pierwszą próbą pokazania, jak to poskładać - i pierwszym dokumentem, w którym polski prawnik doradzający kancelarii ma jeden spójny słownik do rozmowy z dostawcą LegalTech, zarządem klienta i własnym IT.

O czym jest ten materiał

Dokument ma cztery warstwy. Warstwa zasad - osiem imperatywów Agentic Identity (Sekcja 1.2) plus dziewiąty imperatyw alignment z zero-trust i regulacjami. Warstwa diagnostyczna - cztery scenariusze awarii (Sekcja 2.1) plus siedem powtarzających się tematów zagrożeń (over-permissioning, loss of actor clarity, shadow agents, broken delegation chains, unsigned/swapped models, indirect prompt injection, agent collusion). Warstwa pojęć - capability-impact matrix, mechanizmy autoryzacji (OAuth/OIDC, OBO, RFC 8693 Token Exchange, RFC 9396 Rich Authorization Requests), cykl życia tożsamości, governance jako control plane. Warstwa praktyczna - end-to-end przykład agenta przetwarzającego faktury, fazowa adopcja w trzech krokach, oraz appendices A-G (autonomy levels L0-L5, identity i attestation, lifecycle workflows, struktury tokenów, governance i logging, gateway patterns, glosariusz).

Osiem imperatywów do zapamiętania (każdy jako pojedyncza teza, którą prawnik może usłyszeć od dostawcy i sprawdzić):

To nie jest lista życzeniowa. Każdy z imperatywów ma w dokumencie konkretne mechanizmy: SPIFFE SVID, DID, TEE-backed attestation (Intel TDX, AMD SEV-SNP, ARM TrustZone), token exchange wedle RFC 8693, ABAC/PBAC w OPA/Rego albo Cedar, OCSF/CEF schemas dla logów, korelacja przez correlation_id. To jest słownik, którego polski prawnik doradzający kancelarii dotąd nie miał - i którego brak był przyczyną tego, że audyt wdrożeń AI rozpadał się na "wymagania regulacyjne" osobno i "konfigurację techniczną" osobno, bez wspólnej warstwy.

Recenzja właściwa

Najmocniejsza warstwa - threat model jako lista pytań do dostawcy

Sekcja 2 (Risks and failure modes for agents) jest dla polskiej kancelarii najcenniejszą pojedynczą sekcją w dokumencie. Cztery scenariusze awarii są napisane tak, żeby każdy zarząd kancelarii rozpoznał własną sytuację: nadmiernie uprawniony agent finansowy zmienia dane dostawcy i inicjuje płatności (kancelaria z agentem księgowym); agent supportu wychodzi z PII przez łańcuch CRM-baza wiedzy-mail (kancelaria z agentem do recepcji); shadow devops używa zapamiętanych haseł SRE i wprowadza zmiany w produkcji ze wspólnego konta (każda kancelaria, w której informatyk podłączył agenta przez własne konto admin); cross-tenant propagation - agent przesącza dane jednego klienta do workflow innego (każda kancelaria z prawdziwą wieloklientelą).

Siedem threat themes - over-permissioning, loss of actor clarity, shadow agents, broken delegation chains, unsigned/swapped models, indirect prompt injection, agent collusion - to siedem pytań, które prawnik kancelarii powinien zadać dostawcy LegalTech zanim podpisze umowę powierzenia. Każde z pytań ma w polskim kontekście prawny zaczep:

• Over-permissioning → art. 5 ust. 1 lit. c RODO (zasada minimalizacji) i art. 25 ust. 2 RODO (privacy by default - tylko niezbędne dane).
• Loss of actor clarity → art. 5 ust. 2 RODO (zasada rozliczalności) i art. 30 RODO (rejestr czynności).
• Shadow agents → art. 32 RODO (środki bezpieczeństwa) i art. 12 AI Act (record-keeping).
• Broken delegation chains → art. 28 RODO (umowa powierzenia, sub-przetwarzanie) i tajemnica zawodowa (art. 6 PoA, art. 3 ustawy o radcach prawnych) - kto ostatecznie był "actorem" w transakcji?
• Unsigned / swapped models → art. 5 lit. f RODO (integralność i poufność) plus tajemnica zawodowa - czy mamy dowód, że to jest ten model, na który zgodził się klient?
• Indirect prompt injection → art. 32 RODO i art. 9 AI Act (risk management) - prompt injection jest dziś klasą podatności znaną i mającą wzorce mitygacji; brak mitygacji to zaniechanie.
• Agent collusion → art. 22 RODO (zautomatyzowane decyzje) - jeśli dwóch agentów łącznie podejmuje decyzję, której pojedynczy agent nie mógłby podjąć, to wymaga osobnej kwalifikacji prawnej.

To jest argumentacja, która łączy język inżyniera bezpieczeństwa z polskimi instrumentami prawnymi. Adwokat nie pyta dostawcy "czy macie shadow agents" - pyta "jak realizujecie art. 30 RODO w sytuacji, w której agent chodzi po naszym API". Dostawca, który zna Workstream 4, odpowie "rejestr agentów + immutable logs". Dostawca, który nie zna, zacznie improwizować - i to jest pierwszy sygnał audytowy.

Najmocniejsza warstwa decyzyjna - capability-impact matrix i drabina L0-L5

Sekcja 3.2 i Appendix A wprowadzają dwie warstwy klasyfikacji ryzyka, które razem dają polskiej kancelarii jednoznaczny język rozmowy z zarządem klienta o tym, co właściwie wdrażamy. Capability-impact matrix dzieli agentów na cztery kwadranty (low cap/low risk, high cap/low risk, low cap/high risk, high cap/high risk) i dla każdego kwadrantu definiuje required controls. Drabina autonomii L0-L5 (od stałych skryptów po fully autonomous open-ended agents) mapuje się na te kwadranty - L3 i wyżej to automatycznie "high capability".

Polska kancelaria stosuje to operacyjnie tak: wdrażamy agenta L0 (cron job draftujący raporty) - low cap/low risk - service account z wąskim scopem wystarczy. Wdrażamy agenta L3 (semi-autonomous - planowanie wielokrokowe z review człowieka) - high cap/low risk lub high cap/high risk zależnie od danych - wymagamy ephemeral identity, OBO, attestation. Wdrażamy agenta L5 (fully autonomous open-ended) - dokument wprost mówi "not recommended unchecked" i to jest teza, którą prawnik może postawić zarządowi.

Wartość dwuwymiarowej klasyfikacji jest taka sama jak matrycy ryzyka w due diligence M&A - dostarcza narzędzia, w którym zarząd, prawnik i informatyk umieszczają konkretne wdrożenie i widzą, jakie kontrole są wymagane. Nie ma już rozmowy "agent jest niebezpieczny" przeciw "agent jest bezpieczny" - jest rozmowa "agent jest L3 high cap/high risk i potrzebuje ephemeral identity, OBO, attestation, ABAC".

Najmocniejsza warstwa praktyczna - end-to-end invoice agent

Sekcja 4 (End-to-end example: invoice-processing agent) dostarcza polskiej kancelarii działający szablon audytu pojedynczego wdrożenia. Dokument prowadzi czytelnika od deploymentu agenta, przez jego rejestrację i wydanie identity z agent card (kod + konfiguracja + polityka), wystawienie krótkożywotnych zakresowanych credentials dla trzech MCP servers (Document, ERP, Payment), uwierzytelnienie użytkownika SSO, OBO token z claimami, enforcement w bramkach, immutable logs zdarzeń, monitoring, anomaly detection i revocation.

Polska kancelaria czyta to jako checklist audytowy: dostajemy od klienta opis wdrożenia agenta i przechodzimy przez listę punktów z Sekcji 4 - czy jest agent card, czy jest runtime instance identity z atrybutami, czy credentials są short-lived, czy są narrowly scoped per-MCP-server, czy SSO faktycznie wystawia OBO, czy tokeny zawierają actor i subject claims, czy gateway enforce'uje delegation depth, czy są logi z correlation_id, czy jest anomaly detection, czy jest revocation z cascade. Brak każdego z tych elementów to rubryka w raporcie audytowym.

Najmocniejsza warstwa adopcyjna - trzy fazy 1-2-3

Sekcja 5.2 definiuje fazową adopcję, która jest realistyczna dla polskiej kancelarii 10-50 osobowej. Faza 1 (Visibility): odkryj i zarejestruj wszystkich agentów jako tożsamości, wyeliminuj współdzielone konta, ustanów immutable action logging. Faza 2 (Contextual access): krótkożywotne tokeny i ABAC/PBAC dla agentów wyższego ryzyka, intent i kontekst w decyzjach autoryzacyjnych. Faza 3 (Full Agentic IAM): cross-domain delegation chains, continuous evaluation, human-in-the-loop dla krytycznych akcji, automatyczne wykrywanie nowych i zmienionych agentów.

Kancelaria czyta to jako plan trzyletni. W roku pierwszym - inwentaryzacja (kto z partnerów uruchomił którego agenta na czyim koncie, na jakich danych klienta). W roku drugim - przejście na konta serwisowe per-agent z krótkimi tokenami, ABAC dla wrażliwych typów danych. W roku trzecim - pełna fazowa architektura. Każda faza ma w dokumencie jasno zdefiniowany outcome, więc adwokat doradzający compliance officerowi może odhaczyć kamień milowy.

Mapping na polskie instrumenty prawne

Warstwa RODO

Imperatyw #1 (first-class identity) i #6 (prove control on demand) operacjonalizują art. 5 ust. 2 RODO (zasada rozliczalności) i art. 30 RODO (rejestr czynności przetwarzania). Dotąd rejestr czynności był prowadzony per-system albo per-proces; agentowe wdrożenia rozsadzają tę logikę, bo agent działa w imieniu wielu podmiotów jednocześnie. Workstream 4 mówi: rejestr agentów + immutable logs z agent ID, subject ID, scope, decision, policy version. To jest art. 30 w wersji dla agentów - i polski adwokat doradzający IOD ma teraz słownik do uzupełnienia rejestru czynności o tę warstwę.

Imperatyw #2 (Zero Standing Privilege) operacjonalizuje art. 5 ust. 1 lit. c (minimalizacja) i art. 25 RODO (privacy by design and by default). Imperatyw #4 (bind do kodu i modelu) operacjonalizuje art. 5 lit. f (integralność i poufność) - w sposób, w jaki prawnicy dotąd nie mieli mechanizmu sprawdzić: signed manifest plus runtime attestation to dowód, że "to jest ten model, na który zgodził się klient", a nie zamieniony w nocy przez kogokolwiek z zespołu IT.

Warstwa AI Act

Wszystkie osiem imperatywów mapuje się bezpośrednio na art. 9 AI Act (system zarządzania ryzykiem dla high-risk AI), art. 12 AI Act (automatic recording of events / record-keeping) i art. 26 AI Act (obowiązki deployerów). Imperatyw #6 (prove control on demand) jest praktyczną realizacją art. 12 - immutable logs ze schematem OCSF/CEF i correlation_id pozwalają odtworzyć "what the agent did and with whose authority" w razie kontroli organu nadzorczego.

Imperatyw #5 (enforce na każdym hopie i last-mile) pokrywa się z art. 14 AI Act (human oversight) - szczególnie w ujęciu "high-impact or irreversible actions SHOULD require human-in-the-loop or step-up controls" (Sekcja 3.4). To jest miejsce, w którym prawnik doradzający dostawcy LegalTech może powiedzieć: jeśli wasz agent generuje pisma procesowe, to ostateczne wysłanie pisma do sądu MUSI być human-in-the-loop, niezależnie od tego, jak dobrze agent draftuje.

Warstwa KSH i tajemnica zawodowa

Imperatyw #3 (separacja praw agenta i OBO) plus immutable logs z delegation chain ma kluczowe znaczenie dla tajemnicy zawodowej adwokackiej i radcowskiej (art. 6 ust. 1 PoA, art. 3 ust. 5 ustawy o radcach prawnych, KEA, KERP). Pytanie brzmi: kiedy agent działa "w imieniu" klienta, czy klient zgodził się na to, że jego dane przepłyną przez agenta dostawcy LegalTech? OBO token z actor/subject claims jest technicznym dowodem, że agent nie udaje klienta, tylko działa w jego imieniu - i że delegation chain jest widoczna w logach. Bez tego prawnik nie ma jak udowodnić, że tajemnica nie została naruszona.

Dla zarządów spółek kapitałowych imperatyw #6 (prove control on demand) operacjonalizuje art. 293 KSH (staranność członka zarządu). W razie incydentu z udziałem agenta zarząd musi udowodnić, że działał z należytą starannością wynikającą z zawodowego charakteru - czyli że wdrożył kontrole proporcjonalne do ryzyka. Workstream 4 dostarcza mapy tych kontroli; brak ich wdrożenia to dziś już nie "zaniedbanie informatyczne", to potencjalna ekspozycja na art. 293 KSH.

Pytania audytowe do dostawcy LegalTech

Razem z BW/040 (King AI Vendor Assessment Guide) Workstream 4 daje polskiej kancelarii komplementarny zestaw pytań do dostawcy. King jest skryptem rozmowy o organizacji dostawcy (governance, dane, ryzyko); Workstream 4 jest skryptem rozmowy o architekturze technicznej. Konkretne pytania, które kancelaria powinna zadać przed podpisaniem umowy z dostawcą agentowego LegalTech:

• Czy każda instancja waszego agenta otrzymuje osobne identity z agent card (kod + konfiguracja + polityka), czy wszystkie chodzą pod jednym service account?
• Czy credentials, których agent używa do wywołań naszych systemów, są short-lived (TTL minutowy) czy długożywotne?
• Czy wasze tokeny zawierają osobne claimy actor (agent) i subject (użytkownik), zgodnie z OAuth OBO?
• Czy prowadzicie signed manifest swojego modelu z runtime attestation? Jeśli wymienicie model na nowszą wersję, zostaniemy o tym poinformowani z attestation proof?
• Czy enforcement uprawnień zachodzi tylko na bramce, czy także na poziomie pojedynczego API i pojedynczego narzędzia?
• Czy macie immutable logs z correlation_id, ABAC/PBAC policies w OPA/Rego albo Cedar, integrację z naszym SIEM?
• Czy używacie istniejących standardów (OAuth/OIDC, SPIFFE, RFC 8693, RFC 9396) czy zbudowaliście parallel stack?
• Czy wasze MCP endpoints (jeśli macie) terminują nasze tokeny i forwardują tylko scoped OBO downstream, zgodnie z CoSAI MCP Security?

Dostawca, który odpowie spójnie na osiem pytań, jest dostawcą gotowym na audyt. Dostawca, który nie odpowie spójnie albo zacznie improwizować, jest sygnałem dla kancelarii: jeszcze nie tu i jeszcze nie teraz.

Czego brakuje - z perspektywy polskiej kancelarii

Brak warstwy AI Act i RODO. Dokument eksplicytnie się od tego dystansuje (Sekcja 0 - "does not attempt to define... broader AI governance frameworks"). To uczciwa deklaracja zakresu, ale dla polskiego prawnika znaczy, że Workstream 4 jest warstwą stack'u governance, nie samym stack'iem. Bez warstw nadrzędnych (BW/008 Bird&Bird AI Act, BW/013 FAQ AI Act, BW/038 Smuha, BW/039 RAII Policy Template) Workstream 4 jest zestawem kontroli technicznych bez kontekstu regulacyjnego.

Brak warstwy tajemnicy zawodowej. Dokument nie omawia OBO w kontekście tajemnicy zawodowej, choć sam mechanizm (osobne actor/subject claims) jest dla niej kluczowy. Polska kancelaria dopisuje tę warstwę - OBO token nie jest tylko mechanizmem technicznym; jest dowodem prawnym, że agent działa w imieniu klienta na podstawie wyrażonej zgody, a nie udaje klienta.

Brak warstwy odpowiedzialności cywilnej. Workstream 4 mówi o "accountability" w sensie audytowalności, nie w sensie odpowiedzialności cywilnoprawnej za szkody wyrządzone przez agenta. Polski adwokat dopisuje to czytając razem z dyrektywą o odpowiedzialności za AI (jeśli wejdzie w życie) i polskim kodeksem cywilnym - kto odpowiada, gdy agent w autoryzowany sposób, w ramach swoich uprawnień, wyrządzi szkodę?

Brak warstwy małej kancelarii. Dokument adresuje "enterprise" - kancelarie 10-50 osobowe nie mają własnego SIEM, dedykowanego policy engine ani Vault. Wartość Workstream 4 dla nich jest delegacyjna: wymagaj od dostawcy LegalTech wdrożenia tych kontroli po jego stronie, bo sam ich nie zbudujesz. To zmienia rolę dokumentu z "checklisty wdrożeniowej" na "checklistę zakupową".

Komu polecam, komu odradzam

Compliance officer kancelarii budujący wewnętrzną politykę AI - obowiązkowo. Workstream 4 jest brakującą warstwą techniczną pięciowarstwowego stack'u governance: BW/039 (struktura polityki - RAII), BW/040 (audyt dostawców - King), BW/041 (monitoring trajektorii - RAND), BW/042 (benchmark globalny - AICDI), BW/043 (architektura techniczna - Workstream 4). Bez niej polityka AI kancelarii ma dziurę dokładnie tam, gdzie agent dotyka API klienta.

Adwokat doradzający dostawcy LegalTech - obowiązkowo, zwłaszcza jeśli klient buduje produkt z agentami autonomicznymi. Osiem imperatywów to baseline, którego niezachowanie jest dziś już nie "wyborem architektonicznym", tylko zaniechaniem audytowalnym przy najbliższej kontroli.

Adwokat doradzający kancelarii kupującej LegalTech - obowiązkowo. Osiem pytań audytowych z poprzedniej sekcji powinno wejść do każdej procedury wyboru dostawcy obok pytań z BW/040 King.

IOD kancelarii - obowiązkowo. Imperatyw #1, #2, #4 i #6 mapują się bezpośrednio na art. 5, 25, 30, 32 RODO; rejestr czynności bez warstwy agentów jest dziś już niekompletny.

Partner zarządzający kancelarii bez compliance officera - tylko Sekcje 1 (executive summary) i 5 (transitioning). Reszta jest dla zespołu IT albo dostawcy. Wartością dla partnera jest świadomość, że taka warstwa istnieje i że dostawca powinien ją mieć - reszta jest delegacyjna.

Klient kancelarii - nie polecam bezpośrednio. Workstream 4 jest dokumentem inżynierskim, choć dobrze wprowadzonym. Klient czyta zamiast tego BW/042 (AICDI - Investor Engagement Checklist), która operuje na właściwym poziomie abstrakcji dla zarządu.

Powiązanie z innymi tomami Bazy Wiedzy

Workstream 4 wpisuje się w Temat 02 (Audyt dostawców LegalTech) jako warstwa techniczna obok organizacyjnej z BW/040 (King). Razem dają komplementarny zestaw pytań - King o organizację dostawcy, Workstream 4 o architekturę agentową. Temat 03 (Compliance i governance regulacyjne) - Workstream 4 jest implementacyjną warstwą BW/039 (RAII Policy Template) w domenie Risk i Procurement; tam, gdzie RAII pyta "jak macie politykę", Workstream 4 pyta "jak macie kontrole".

Direct complement do BW/012 (OWASP AIVSS Agentic AI) - OWASP definiuje dziesięć kategorii podatności agentów (warstwa zagrożeń), Workstream 4 definiuje kontrole, które te zagrożenia mitigują (warstwa zabezpieczeń). Razem stanowią klasyczną parę threat-model + control-framework.

Warstwa techniczna pokrywa się też z BW/030 (ENISA Security-by-Design and -by-Default) - ENISA daje 22 praktyki i 16 zasad dla AI security w ujęciu europejskim, Workstream 4 daje konkretne wzorce IAM. ENISA + Workstream 4 to pełen technical baseline. BW/032 (Secure AI Sandboxes) komplementuje w warstwie testowania nowego agenta przed wdrożeniem produkcyjnym - sandbox jako etap przed Fazą 1 Workstream 4.

Razem z BW/042 (AICDI Responsible AI in Practice) tworzy parę empiryczno-architektoniczną: AICDI mówi 13 procent firm globalnie ma framework, Workstream 4 mówi oto jak ten framework wygląda w warstwie technicznej. Polski adwokat używa AICDI w rozmowie z zarządem (gdzie jesteśmy względem populacji), a Workstream 4 w rozmowie z IT i dostawcą (jak to konkretnie zaimplementować).

Dla MateMatic to warstwa techniczna pięciowarstwowego stack'u governance. BW/039 daje strukturę polityki, BW/040 audyt dostawcy, BW/041 monitoring trajektorii, BW/042 benchmark globalny, BW/043 architekturę techniczną. Pierwsze cztery były napisane z perspektywy zarządu i prawnika; piąty mówi do informatyka tym samym językiem co prawnik - i to jest brakujące ogniwo, którego stack dotąd nie miał.