Sześć agencji rządowych Five Eyes pisze przewodnik bezpieczeństwa agentic AI. Pięć ryzyk plus lifecycle czterech etapów.

Polski adwokat lub radca radząca klientowi-spółce wdrażającej agentic AI po raz pierwszy czyta zdanie z paperu Five Eyes z dwoma agencjami USA, które brzmi banalnie, dopóki nie zostanie zestawione z polską praktyką: only use agentic AI for low-risk and non-sensitive tasks. Sześć agencji rządowych - ASD ACSC, CISA, NSA, Canadian Centre for Cyber Security, NCSC-NZ, NCSC-UK - po cichu, bez fanfar marketingowych, mówi w jednej publikacji to, co marketing wendorów AI mówi rzadko: nie używaj agentic AI do tasków sensitive lub high-risk; never granting broad lub unrestricted access. Polska kancelaria, której prawnik wkleja fragment sprawy klienta do agentic narzędzia z prywatnego konta, działa wbrew rekomendacji sześciu agencji wywiadu i cybersecurity zachodniego świata. To jest mocniejszy sygnał niż uchwała pojedynczego krajowego regulatora.

O czym jest ten materiał

Joint guidance została opracowana w 2025 roku jako wspólne stanowisko Five Eyes (sojuszu wywiadowczego USA, Wielka Brytania, Kanada, Australia, Nowa Zelandia - tradycyjnie jedna agencja per kraj) z rozszerzeniem o drugą agencję USA: oprócz NSA (National Security Agency) udział wzięła też CISA (Cybersecurity and Infrastructure Security Agency) - cywilna agencja Department of Homeland Security odpowiedzialna za ochronę krytycznej infrastruktury USA. Lead authoring agency to australijska ASD ACSC. Adresat: government, critical infrastructure i industry stakeholders. Dokument koncentruje się na agentic AI opartym na large language models (LLM), pokrywa zagrożenia, podatności w samych systemach i ryzyka wynikające z zachowania agentic AI - włącznie z ryzykami wprowadzanymi przez komponenty systemu, integracje i downstream use.

Struktura dokumentu - 28+ stron z czterema głównymi częściami: (a) Definicja agentic AI i odróżnienie od generative AI; (b) Pięć kategorii ryzyk specyficznych dla agentic AI; (c) Best practices w czterech etapach lifecycle (Designing, Developing, Deploying, Operating); (d) Defend against future risks - threat intelligence collaboration, agent-specific evaluations, system-theoretic approaches. Plus Appendix A - cyber security prerequisites before implementation of AI agents, czyli lista kontrolna gotowości środowiska IT zanim agent w ogóle wejdzie do produkcji.

Kluczowe liczby i konstrukcje paperu:

Pięć kategorii ryzyk - mapa decyzji audytowych

Privilege risks - uprawnienia agenta i ich nadużycie

Pierwsza i najbardziej operacyjna kategoria. Agentic AI z definicji wykonuje akcje w imieniu użytkownika - czyta pliki, wysyła wiadomości, modyfikuje dane, wywołuje API. Każda z tych akcji wymaga uprawnień. Privilege risks obejmują: nadmierne uprawnienia agenta (ponad to, co potrzebne do zadania), eskalacja uprawnień (agent uzyskuje dostęp do zasobów, do których nie powinien), przekazanie uprawnień osobom trzecim (agent działa w imieniu użytkownika ale faktycznie pod kontrolą atakującego), brak segmentacji dostępu między rolami. Polska kancelaria czytająca to przez pryzmat art. 32 RODO widzi operacyjne mapowanie zasady least privilege: agent obsługujący sprawy spadkowe nie ma dostępu do akt karnych, agent prowadzący kalendarz spotkań nie czyta wiadomości email klientów. Cross-reference do Aktualności 30 kwietnia 2026 (Workspace MCP scoping) staje się tu mostem - scope'y MCP to operacjonalizacja Privilege risks. Bez świadomego podziału scope'ów (drive vs drive.file, gmail.readonly vs gmail.modify) agent narusza zasadę least privilege z dnia pierwszego.

Design and configuration risks - błędy projektowe

Druga kategoria adresuje sytuacje, w których ryzyko nie wynika z błędu LLM ani złośliwości aktora, tylko z błędnej konfiguracji systemu agentic AI. Klasyczne przykłady: domyślne hasła w deployment, błędna integracja z systemami źródłowymi, nieaktualne komponenty open-source w stosie, brak walidacji wejścia, brak rate limiting, błędna interpretacja roli systemowej (system prompt) przez LLM. Polska kancelaria wdrażająca agentic AI nie potrzebuje atakującego, żeby ponieść szkodę - wystarczy własna konfiguracja. Mapping na art. 32 RODO: środki techniczno-organizacyjne adekwatne do ryzyka muszą obejmować nie tylko obronę przed atakiem, ale też walidację własnej konfiguracji.

Behaviour risks - nieprzewidywalne zachowanie LLM

Trzecia kategoria przejmuje znane ryzyka LLM (halucynacja, jailbreak, prompt injection) i przesuwa je do warstwy agenta autonomicznie wykonującego akcje. Halucynacja w czacie LLM jest niewygodna, halucynacja u agenta z dostępem do API jest niebezpieczna - agent może wygenerować fałszywą nazwę pliku i nadpisać dokument klienta, halucynować numer rachunku i przelać środki nie tam gdzie trzeba, podstawić błędną sygnaturę i wysłać pismo procesowe do niewłaściwego sądu. Cross-reference do BW/049 Uberti-Bona Marin techno-normative AI accuracy zamyka tę lukę formalnie - cztery techno-normative choices są audytem ryzyka behaviour. Polska kancelaria czytająca to widzi: halucynacja agenta nie jest błędem oprogramowania, jest właściwością modelu, którą trzeba traktować jak każde inne ryzyko zawodowe.

Structural risks - kompleksowość integracji

Czwarta kategoria adresuje fakt, że agentic AI rzadko działa w izolacji - jest częścią pipeline z bazą danych, systemem plików, zewnętrznymi API, innymi agentami. Każde połączenie to powierzchnia ataku. Każdy upgrade jednego komponentu może zerwać założenia bezpieczeństwa innego. Sześć agencji wprost wskazuje na increased complexity jako fundamentalne ryzyko agentic AI - kompleksowość integracji rośnie szybciej niż pojemność zarządzania nią. Polska kancelaria budująca pipeline LegalTech (DMS plus model lokalny plus agent obsługi klienta plus integracja z e-PUAP plus eksport do TFI) musi prowadzić rejestr struktury z mapą zależności - system-theoretic approach rekomendowany przez Five Eyes na końcu dokumentu jest nie luksusem akademickim, jest warunkiem audytu.

Accountability risks - rozproszona odpowiedzialność

Piąta kategoria to obszar najbardziej istotny dla prawnika - kto odpowiada, gdy agent popełnił błąd. Tradycyjnie odpowiedzialność jest u operatora oprogramowania. Przy agentic AI łańcuch jest dłuższy: dostawca modelu (OpenAI, Anthropic, Google), dostawca platformy agentic (Replit, AutoGPT, Anthropic Claude Computer Use), integrator wewnętrzny kancelarii, prawnik korzystający, klient końcowy. Każde ogniwo może zrzucić odpowiedzialność na poprzednie. Polski adwokat odpowiada za starania zawodowe wobec klienta (art. 7 KEA, art. 4 KERP) niezależnie od tego, czy używał agenta - argument "to model się pomylił" nie jest argumentem deontologicznym. Mapping na AI Act art. 26: deployer (kancelaria) ma obowiązki dokumentacji, nadzoru i raportowania incydentów - łańcuch odpowiedzialności kończy się u deployer dla obowiązków pod AI Act, ale rozciąga się dalej dla obowiązków cywilnoprawnych.

Lifecycle - cztery etapy bezpiecznego agenta

Designing secure agents

Najmocniejszy etap z perspektywy operacyjnej polskiej kancelarii. Sześć agencji rekomenduje principles przy projektowaniu: clear bounds of authority dla agenta, segregacja zadań pomiędzy agentami (jeden agent jeden cel), zasada least privilege wbudowana w architekturę (nie dodawana ex post), human-in-the-loop dla decyzji o wysokim ryzyku, audit logs by-design (nie jako add-on). Polska kancelaria wdrażająca agentic AI w 2026 roku dostaje gotową checklist do audit zaplanowanej architektury zanim padnie pierwsza linia kodu.

Developing secure agents

Drugi etap to bezpieczne kodowanie - secure SDLC, walidacja inputu, sanityzacja outputu, threat modeling, dependency management (w tym dla bibliotek AI/ML), code review obejmujący prompty systemowe (system prompt jako kod), testy bezpieczeństwa specyficzne dla agentic (czerwony team agentic, testy prompt injection, testy nieautoryzowanego użycia uprawnień). Procurement: SBOM (Software Bill of Materials) wymieniony w paperze jako element minimum dla agentic AI - kancelaria audytująca dostawcę musi otrzymać SBOM.

Deploying agents securely

Trzeci etap - bezpieczne wdrożenie do produkcji. Network segmentation, secrets management (klucze API nie w plain text), monitoring od dnia pierwszego, rollback plan przygotowany przed go-live, ograniczone uprawnienia (read-only initial, modyfikacja po fazie pilotażowej), mechanizmy kill-switch (możliwość natychmiastowego zatrzymania agenta). Polska kancelaria pilotująca agenta przez kwartał z ograniczonym scope to nie ostrożność - to wymóg cyber security dla critical infrastructure.

Operating agents securely

Czwarty etap - utrzymanie agenta w produkcji. Continuous monitoring (logi, anomalie, metryki użycia), incident response plan z procedurami na agentic-specific incidents (halucynacja na produkcji, prompt injection w toku, nadużycie uprawnień), regular review uprawnień (privilege creep), patching modeli (gdy dostawca aktualizuje wagi modelu - co kancelaria robi ze swoimi prompts i konfiguracjami), end-of-life plan dla agentów. Polska kancelaria która deployuje agenta i zostawia go bez monitoring na rok - działa wbrew rekomendacji Five Eyes z dwoma agencjami USA.

Mapping na polskie instrumenty

RODO art. 32 - środki techniczno-organizacyjne

Pięć ryzyk Five Eyes mapuje wprost na art. 32 RODO. Privilege risks plus Design risks plus Structural risks to obszar środków technicznych (least privilege, segmentacja, walidacja konfiguracji). Behaviour risks i Accountability risks to obszar środków organizacyjnych (polityka AI, szkolenie zespołu, łańcuch odpowiedzialności). Lifecycle czterech etapów (Designing/Developing/Deploying/Operating) to operacyjna struktura artykułu 32 - środki adekwatne do ryzyka muszą obejmować cały lifecycle, nie tylko deployment.

Dyrektywa NIS2 - nowelizacja UKSC w Polsce

NIS2 (Dyrektywa UE 2022/2555) implementowana w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa - prezydent podpisał 19 lutego 2026 roku, publikacja w Dzienniku Ustaw 2 marca 2026, wejście w życie po vacatio legis 3 kwietnia 2026. Kluczowe konsekwencje: rozszerzenie z 7 sektorów (NIS1) do 18 sektorów, dwie kategorie podmiotów (kluczowe i ważne), kary do 10 mln EUR lub 2 procent przychodu plus osobista odpowiedzialność zarządu, ex-ante supervision dla podmiotów kluczowych, publiczny rejestr S46 z obowiązkiem self-identification i self-registration do 3 października 2026, pełna implementacja wymogów do 3 kwietnia 2027. Polska kancelaria obsługująca klientów z sektorów NIS2 (energetyka, finanse, ochrona zdrowia, infrastruktura cyfrowa, dostawcy usług ICT) dziedziczy część obowiązków jako podmiot trzeci w łańcuchu dostawców. Pięć ryzyk Five Eyes plus lifecycle są dziś najmocniejszym dostępnym frameworkiem do operacjonalizacji wymagań NIS2 dla agentic AI w środowisku kancelarii - 12 miesięcy do deadline'u kwietnia 2027 to okno na zbudowanie polityki agentic AI zgodnej z NIS2.

AI Act art. 26 - deployer obligations

Polska kancelaria wdrażająca agentic AI jest deployer w rozumieniu AI Act. Art. 26 nakłada sześć obowiązków: dokumentacja użycia AI, nadzór ludzki, zapewnienie reprezentatywności danych wejściowych, monitoring działania, raportowanie incydentów, transparentność wobec osób objętych decyzją. Five Eyes lifecycle daje gotowe mapowanie - Designing pokrywa nadzór ludzki by-design, Developing pokrywa walidację danych, Deploying pokrywa transparentność, Operating pokrywa monitoring i raportowanie. Bez lifecycle Five Eyes deployer obligations są abstrakcyjne; z lifecycle stają się operacyjną listą zadań.

Tajemnica zawodowa (KEA, KERP)

Centralna rekomendacja paperu - never granting agentic AI broad or unrestricted access, especially to sensitive data; only use agentic AI for low-risk and non-sensitive tasks - w polskiej kancelarii oznacza: agent nie ma broad access do akt klientów. Tajemnica zawodowa adwokata (art. 6 prawa o adwokaturze) i radcy prawnego (art. 6 ustawy o radcach prawnych) to po pierwsze obowiązek deontologiczny, po drugie ochrona prawnie chroniona. Agent z broad access do DMS narusza obie warstwy. Polska kancelaria audytująca dostawcę agentic AI ma w ręku argument sześciu agencji - to nie nasza ostrożność, to wymóg cyberbezpieczeństwa.

Czego brakuje - z perspektywy polskiej kancelarii

Brak warstwy EU regulacyjnej. Paper Five Eyes z dwoma agencjami USA nie pokrywa AI Act, ENISA, EUCC, ETSI. Mostek do polskich realiów wymaga uzupełnienia - cross-reference do BW/049 Uberti-Bona Marin (techno-normative AI accuracy plus mapowanie na AI Act art. 9-15), BW/039 RAII (polityka AI), BW/045 Kenney runtime enforcement (continuous authorization).

Brak case studies prawnych. Adresat to government plus critical infrastructure plus industry. Branża prawnicza jako sektor nie ma osobnej analizy. Polska kancelaria dopisuje sektorową interpretację samodzielnie.

Brak danych empirycznych o incydentach agentic AI. Cross-reference do BW/052 Stanford AI Index 2026 (362 udokumentowane incydenty AI w 2025 vs 233 w 2024) zamyka tę lukę dla skali zjawiska.

Brak warstwy małej kancelarii. Solo praktyk i kancelaria 1-3 osobowa nie ma zasobów na pełen lifecycle czterech etapów. Five Eyes implicite zakłada zespół security osobny od zespołu prawniczego - co w polskiej praktyce jest możliwe dopiero od 30+ osób.

Brak warstwy lokalnych modeli LLM. Paper traktuje agentic AI jako kategorię oderwaną od konkretnych modeli. Lokalne modele LLM (Bielik, PLLuM, Llama on-premise) jako kategoria zmniejszająca część Privilege i Structural risks (brak transferu danych do zewnętrznego dostawcy) nie są analizowane. Cross-reference do BW/036 Kuśmierek i BW/051 Supesu zamyka tę lukę dla polskiego kontekstu.

Komu polecam, komu odradzam

Compliance officer / IOD kancelarii wdrażającej agentic AI - obowiązkowo. Pięć ryzyk plus lifecycle to gotowy framework audytu. Wartość: przejście z generycznych pytań RODO art. 32 do operacyjnej listy kontrolnej.

CIO / dyrektor IT kancelarii - obowiązkowo. Lifecycle czterech etapów plus Appendix A z prerequisites cyber security to operacyjny manual decyzji infrastrukturalnych.

Adwokat doradzający klientowi-spółce wdrażającej agentic AI - obowiązkowo, jako referencja wobec dostawcy. Sześć agencji rządowych w jednej publikacji to argument silniejszy niż uchwała pojedynczego regulatora krajowego.

Adwokat doradzający klientom z sektorów NIS2 (energetyka, finanse, ochrona zdrowia, infrastruktura cyfrowa) - obowiązkowo. Mapping pięciu ryzyk na obowiązki NIS2 to gotowy materiał audytowy.

Partner zarządzający dużej kancelarii (30+) - tak. Pełen lifecycle wymaga zasobów, ale dostarcza decyzję strategiczną o tym, czy budować zespół security in-house, czy outsourcować.

Solo praktyk i kancelaria 1-3 osobowa - selektywnie. Czytaj rozdział o pięciu ryzykach (s. 7-13) plus Appendix A (s. 28). Lifecycle czterech etapów może być za bardzo zasobożerny dla skali.

Klient indywidualny szukający prawnika - nie polecam bezpośrednio. To paper dla operatorów agentic AI, nie konsumentów.

Edukator LegalTech / vendor narzędzi prawniczych - obowiązkowo. Pięć ryzyk to mapa decyzji produktowych, lifecycle to mapa procesu rozwoju.

Aplikant adwokacki lub radcowski - tak. Pierwszy materiał operacyjny pokazujący, czego wymaga zarządzanie agentic AI w kancelarii w 2026 roku - argument za inwestycją w kompetencje cyber security obok kompetencji prawniczych.

Powiązanie z innymi tomami Bazy Wiedzy

Pierwszy tom Bazy Wiedzy MateMatic z kategorii joint government cyber security guidance. Autorytet wyższy niż pojedynczy regulator krajowy, niezależny od dostawcy.

Direct partner do BW/048 OASIS CoSAI agentic IAM: OASIS daje framework tożsamości agentów, Five Eyes daje pięć ryzyk plus lifecycle. Razem operacyjna mapa - tożsamość plus zarządzanie ryzykiem plus etapy bezpieczeństwa.

Direct partner do BW/045 Kenney runtime enforcement: Kenney mapuje continuous authorization w czterech reżimach, Five Eyes mapuje Privilege risks i Operating securely. Razem: jak wymuszać autoryzację w runtime przez cały lifecycle agenta.

Direct complement do BW/OWASP AIVSS agentic AI: OWASP AIVSS daje 10 specyficznych ryzyk z metryką oceny, Five Eyes daje pięć kategorii ryzyk z best practices. Razem: OWASP scoring plus Five Eyes lifecycle = pełen audyt agenta.

Direct partner do BW/046 Berkeley CLTC GPAI Risk Management Profile: Berkeley syntetyzuje NIST plus ISO plus EU GPAI Code, Five Eyes daje operacyjną stronę bezpieczeństwa. Razem: warstwa governance plus warstwa security.

Direct complement do BW/049 Uberti-Bona Marin techno-normative AI accuracy: Uberti-Bona daje cztery techno-normative choices dla audytu accuracy, Five Eyes daje Behaviour risks dla audytu zachowania agenta. Razem: accuracy plus behaviour = pełna mapa ryzyka technicznego.

Direct partner do BW/052 Stanford AI Index 2026: Stanford pokazuje skalę 362 incydentów w 2025 roku, Five Eyes daje framework prewencji. Razem: empiryka plus operacjonalizacja.

Cross-reference do Aktualności 30 kwietnia 2026 (Workspace MCP plus Gemini Enterprise): MCP scoping (drive vs drive.file, gmail.modify vs gmail.readonly) to operacyjna realizacja Privilege risks z paperu Five Eyes. Bez świadomego podziału scope'ów MCP polska kancelaria narusza zasadę least privilege z dnia pierwszego wdrożenia.

Razem z BW/051 Supesu (87 procent polskich prawników korzysta z AI) i BW/052 Stanford (88 procent adopcji organizacyjnej globalnie) Five Eyes guidance domyka triadę: empiryka adopcji w Polsce, empiryka adopcji globalnie, operacyjny framework bezpieczeństwa.