Enforcement nie jest szóstą warstwą. Kenney rozprasza go po pięciu istniejących i tłumaczy dlaczego.

Kenney pisze ten paper z motywacji praktyka, nie akademika. "Even with all five layers in place, a system can still execute actions that should not occur. A model can be validated, a system can be monitored, and an audit trail can be maintained, yet the system may still take an action at a moment when conditions no longer justify it." Polski adwokat doradzający kancelarii, która właśnie wdrożyła agenta autonomicznego, czyta to zdanie i poznaje sytuację, w której był sam: wszystko zostało zrobione zgodnie z polityką i procedurami, ale jeden konkretny przebieg agenta poszedł nie tak, jak powinien. Pytanie brzmi nie czy system jest governowany - tylko czy execution jest dopuszczalny w tej minucie, w tym kontekście, dla tych danych. To jest pytanie operacyjne, na które dotąd brakowało zorganizowanej odpowiedzi.

O czym jest ten materiał

Paper ma osiem sekcji w gęstym wykonaniu - około ośmiu stron. Sekcja 1-2 - postawienie problemu i przejście od advisory do agentic AI (kiedy human-in-the-loop był naturalnym enforcement point, a teraz przestał być). Sekcja 3 - kluczowa teza papieru: enforcement nie jest szóstą warstwą, jest cross-cutting capability, z analogią do bezpieczeństwa (które też jest cross-cutting, nie warstwowe). Sekcja 4 - enforcement capabilities w każdej z pięciu warstw Stack'a (Data Governance, Model Governance, System Integration, Control & Monitoring, Audit & Evidence). Sekcja 5 - sześć zasad design dla embedded enforcement. Sekcja 6 - regulatory alignment z AI Act i NIST AI RMF. Sekcja 7 - cztery developments na ścieżce do dojrzałości (policy-as-code, industry standards, regulatory shift compliance-at-deployment → compliance-in-operation, organizational maturity). Sekcja 8 - conclusion.

Pięć kluczowych pojęć do zapamiętania - mapy odwzorowywanych przez Kenneya w pięciu warstwach Stack'a:

Recenzja właściwa

Najmocniejsza warstwa - teza "cross-cutting, not localized"

Sekcja 3.1 jest dla polskiej kancelarii najwartościowszym pojedynczym argumentem w paperze. Kenney pokazuje na przykładzie credit decisioning agent, że żadna z pięciu warstw sama nie wie, czy konkretna akcja jest dopuszczalna - bo admisibility zależy od pytań rozłożonych po wszystkich pięciu naraz. Czy dane są aktualne (L1). Czy model nie zdryfował (L2). Czy downstream API są dostępne i kontraktowo ważne (L3). Czy nie zostało wystawione human override (L4). Czy mamy verifiable evidence chain (L5). To jest argument, który zamyka instynktowną pokusę zarządu kancelarii: "dodajmy szóstą warstwę, niech to ona enforce'uje". Nie da się. Enforcement musi siedzieć w każdej z pięciu, bo każda z pięciu ma inny rodzaj informacji.

Polska kancelaria stosuje to operacyjnie tak: nie próbujemy zbudować "działu enforcement AI" - próbujemy uzbroić każdą z pięciu warstw naszej polityki AI w mechanizmy weryfikacyjne. Compliance officer nie staje się szóstym warstwowym strażnikiem; staje się architektem rozproszonej weryfikacji. To zmienia kierunek myślenia o roli IOD w kancelarii wdrażającej agentic AI.

Druga mocna warstwa - sześć zasad design

Sekcja 5 dostarcza operacyjnego szkieletu polityki kancelarii w sześciu zasadach, które dosłownie można przepisać do regulaminu wewnętrznego. Każdą cytuję w nawiasie polskim z mapowaniem prawnym:

• Zasada 1: Enforcement musi być rozproszony, nie scentralizowany. Żaden komponent ani warstwa nie powinny ponosić wyłącznej odpowiedzialności za constraint. (Mapping: art. 32 ust. 1 RODO - środki techniczne i organizacyjne uwzględniając stan techniki; pojedynczy punkt awarii narusza tę zasadę.)
• Zasada 2: Autoryzacja musi być ciągła, nie point-in-time. Warunki, które uzasadniały deployment, muszą być continuously verified. (Mapping: art. 5 ust. 2 RODO rozliczalność i art. 26 AI Act deployer obligations - obowiązek monitoringu trwa.)
• Zasada 3: Dowody muszą być contemporaneous, nie reconstructed. Justification musi być captured at the moment of execution. (Mapping: art. 12 AI Act automatic recording of events; rekonstrukcja post-hoc nie spełnia tej normy.)
• Zasada 4: Constraints muszą być proporcjonalne do consequences. Rygor enforcement skaluje z potencjalnym impactem akcji. (Mapping: art. 9 AI Act risk management proportional do severity; art. 14 human oversight mocniejszy dla high-impact.)
• Zasada 5: Mechanizmy enforcement muszą być context-specific. One-size-fits-all nie sprawdzi się w różnorodności AI applications i regulatory environments. (Mapping: kancelaria adwokacka i radcowska ma inny enforcement context niż kancelaria notarialna - tajemnica zawodowa pod art. 6 PoA / art. 3 ustawy o radcach prawnych ma inną granicę niż tajemnica notarialna.)
• Zasada 6: Governance musi degradować z gracją. Gdy mechanizm enforcement zawodzi, system defaultuje do bardziej restrykcyjnego zachowania, nie mniej. "The failure mode of a governance system should be constraint, not permission." (Mapping: fail-closed jako wymaganie audytowalne; w polskim kontekście to oznacza, że agent w razie utraty łączności z policy engine wyłącza akcje, a nie kontynuuje "po staremu".)

Te sześć zasad to najczystsze CTA w stylu compliance officera, jakie ostatnio przeszło przez Bazę Wiedzy. Każda zasada jest jednozdaniowa, jednoznaczna, ma kontrapunkt ("nie scentralizowany", "nie point-in-time", "nie reconstructed", "nie one-size-fits-all", "nie permission") i mapuje się na konkretny artykuł AI Act lub RODO. Kancelaria podpisująca politykę AI z klientem korporacyjnym może wziąć te sześć zasad jako pierwszy rozdział w sekcji "Zasady runtime" - bez tłumaczenia, bez negocjacji, bez korekt.

Trzecia warstwa - analogia bezpieczeństwa

Sekcja 3.2 wprowadza analogię, którą polska kancelaria może wykorzystać w rozmowie z zarządem nieinformatycznym. Kenney pisze: "Organizations do not treat security as a single layer in their technology stack. Security is embedded in the network layer (firewalls, segmentation), the application layer (input validation, authentication), the data layer (encryption, access controls), and the operational layer (monitoring, incident response)." Zarząd kancelarii rozumie, dlaczego security jest cross-cutting - bo doświadczył tego empirycznie (firewall plus access control plus encryption plus monitoring, nie jeden z czterech). Kenney pokazuje, że enforcement w AI to dokładnie ta sama logika - i ta analogia działa w pięciu minutach rozmowy z partnerem zarządzającym.

Czwarta warstwa - regulatory alignment z AI Act

Sekcja 6 jest miejscem, w którym Kenney robi pracę za polskiego adwokata. "The EU AI Act requires providers of high-risk AI systems to implement risk management systems that operate throughout the system's lifecycle (Article 9), technical documentation that reflects the system's current state (Article 11), and post-market monitoring systems that actively collect and analyze data on system performance (Article 72)." To nie jest filler - to jest wskazanie, że artykuły 9, 11 i 72 AI Act razem definiują wymóg continuous governance, na który embedded enforcement jest właściwą odpowiedzią architektoniczną. Polski adwokat cytujący ten paper może wzmocnić argument: "art. 72 AI Act post-market monitoring nie jest abstrakcją; jest praktycznym wymogiem runtime evidence generation w warstwie L5 Stack'a Kenneya".

Mapping na polskie instrumenty prawne

Warstwa RODO

L1 (Data Governance freshness gates) operacjonalizuje art. 5 ust. 1 lit. d RODO (prawidłowość danych) - dane muszą być aktualne na moment akcji, nie tylko na moment ingestion. L1 (dynamic data authorization) operacjonalizuje art. 5 ust. 1 lit. b RODO (ograniczenie celu) - purpose limitation at runtime, nie static use agreement. L4 (monitoring jako constraint) plus L5 (contemporaneous evidence) operacjonalizują art. 5 ust. 2 RODO (rozliczalność) i art. 32 ust. 1 lit. d (regularne testowanie i ocena skuteczności środków technicznych).

Warstwa AI Act

Wszystkie sześć zasad design mapuje się na konkretne artykuły. Zasada 2 (continuous authorization) → art. 9 AI Act risk management throughout lifecycle plus art. 26 AI Act deployer obligations. Zasada 3 (contemporaneous evidence) → art. 12 AI Act automatic recording of events. Zasada 4 (proportional constraints) → art. 9 AI Act risk-based proportionality. Zasada 6 (graceful degradation - fail-closed) → wymóg art. 14 AI Act human oversight effective ("preventing or minimising") plus art. 26 ust. 4 deployer SHALL inform provider o serious incidents.

Sam Kenney explicit cytuje art. 72 AI Act post-market monitoring - to jest miejsce, w którym L5 (Audit & Evidence z runtime evidence generation) jest technologiczną implementacją prawnego wymogu, nie alternatywą. Polski adwokat doradzający dostawcy LegalTech może powiedzieć: jeśli wasz system jest high-risk wedle Załącznika III AI Act, art. 72 wymaga od was post-market monitoring; bez runtime evidence generation w warstwie L5 nie spełniacie tego wymogu.

Warstwa tajemnicy zawodowej

To jest miejsce, w którym Kenney milczy, a polska kancelaria mówi. Tajemnica adwokacka (art. 6 PoA, KEA) i radcowska (art. 3 ustawy o radcach prawnych, KERP) nie są at-design constraint; są at-execution constraint. Adwokat nie udostępnia akt klienta agentowi raz - musi się upewnić, że agent nie udostępnia ich nikomu z zewnątrz w kolejnych setkach interakcji. Zasada 2 (continuous authorization) Kenneya jest dokładnie tym mechanizmem - continuously verified, not point-in-time. Tajemnica zawodowa potrzebuje runtime enforcement, nie at-deploy enforcement; bez tej warstwy każda kolejna minuta agentowej interakcji jest potencjalnym ujawnieniem.

Czego brakuje - z perspektywy polskiej kancelarii

Brak warstwy odpowiedzialności cywilnoprawnej. Paper mówi o accountability w sensie audytowalności, nie w sensie odpowiedzialności za szkodę. Polski adwokat dopisuje warstwę: gdy fail-closed Zasady 6 zawiedzie i agent działa nie tak jak powinien, kto odpowiada cywilnie - dostawca systemu, kancelaria-deployer, czy konkretny prawnik nadzorujący sesję? Bez tej warstwy mamy mapę architektoniczną bez mapy odpowiedzialności.

Brak warstwy KSH dla zarządu kancelarii jako spółki. Zasada 6 (fail-closed default) wymaga decyzji zarządu, że ryzyko utraty produktywności (system zatrzymuje się, gdy enforcement zawodzi) jest mniejsze niż ryzyko nieautoryzowanej akcji. To jest decyzja z art. 293 KSH (staranność członka zarządu) - i Kenney jej nie omawia. Polska kancelaria dopisuje, że fail-closed musi być uchwałą zarządu, nie domyślnym ustawieniem inżyniera.

Brak warstwy małej kancelarii. Sześć zasad to wymóg organizacyjny dla kancelarii z compliance officerem i polityką AI. Kancelaria 5-10 osobowa nie ma zasobów na samodzielną implementację. Wartość Kenneya dla nich jest delegacyjna - zasady stają się checklist'ą zakupową ("nasz dostawca LegalTech musi spełniać te sześć zasad runtime, inaczej nie kupujemy"). To zmienia framing z architektonicznego na kontraktowy.

Brak link do oryginału w paperze. Drobne, ale operacyjne: paper nie wskazuje, gdzie czytelnik może pobrać Governing Intelligence jako freely available textbook. Kontakt to digital520.com - na tej stronie wymaga się szukać linku do książki, co utrudnia szybką weryfikację. Polski adwokat dopisuje to do referatu klientowi.

Komu polecam, komu odradzam

Compliance officer kancelarii budujący politykę AI runtime - obowiązkowo. Sześć zasad (Sekcja 5) wprost do regulaminu wewnętrznego, bez tłumaczenia. To jest jeden z najczystszych instrumentów w całej Bazie Wiedzy.

Adwokat doradzający dostawcy LegalTech - obowiązkowo. Sekcja 4 (enforcement capabilities per warstwa) plus Sekcja 6 (regulatory alignment z AI Act) dostarczają dwóch list pytań architektonicznych do zadania zespołowi inżynieryjnemu.

Adwokat doradzający kancelarii kupującej LegalTech - obowiązkowo. Sześć zasad jako kryteria wyboru dostawcy plus art. 72 AI Act argumentacja dla "dlaczego musimy mieć runtime, nie tylko at-deploy".

IOD kancelarii - obowiązkowo. L1 freshness gates plus L1 dynamic data authorization to operacjonalizacja art. 5 ust. 1 lit. b i d RODO; bez nich rejestr czynności jest niekompletny.

Partner zarządzający kancelarii bez compliance officera - tak, ale tylko Sekcja 1 (motywacja), Sekcja 3 (cross-cutting nie discrete) i Sekcja 5 (sześć zasad). Reszta jest dla zespołu wdrożeniowego albo dostawcy. Wartość: świadomość, że zasada 6 (fail-closed) wymaga decyzji zarządu.

Klient kancelarii bez poradnika prawnego - nie polecam bezpośrednio. Język techniczny, abstrakcja na poziomie architektonicznym. Klient czyta zamiast tego BW/044 (WEF/Capgemini - decyzja na poziomie funkcji).

Powiązanie z innymi tomami Bazy Wiedzy

Direct kontynuacja BW/001 (Kenney - Governing Agents: cztery reżimy regulacyjne) - ten sam autor, rok później, z architektoniczną odpowiedzią na pytanie postawione w BW/001. Cztery reżimy mówią KIM agent musi się rozliczyć; runtime enforcement mówi KIEDY i JAK. Polski adwokat czyta oba tomy razem - są komplementarne na poziomie autorskiej myśli.

Direct complement do BW/043 (OASIS CoSAI Agentic IAM) - imperatyw #5 OASIS ("enforce na każdym hopie i last-mile") jest technicznym wykonaniem Zasady 1 Kenneya ("distributed not centralized"). Imperatyw #6 OASIS ("prove control on demand") jest implementacją Zasady 3 Kenneya ("contemporaneous evidence"). OASIS dostarcza protokoły IAM (SPIFFE, RFC 8693, OCSF/CEF); Kenney dostarcza zasady, dla których te protokoły są właściwym wyborem. Sekcja 4.3 Kenneya o circuit-breaker architectures, policy-as-code engines i capability-based authorization mapuje się 1:1 na imperatywy OASIS.

Razem z BW/035 (Laban - LLMs Corrupt Your Documents When You Delegate) tworzy parę empiryczno-zasadniczą: Laban mierzy degradację jakości po 20 iteracjach delegacji do LLM (50% utrata zawartości, frontierowe modele 25%); Kenney tłumaczy, że to jest empiryczny argument za Zasadą 2 (continuous authorization) - bo punkt-in-time validation nie wykryje 20-iteracyjnej degradacji. Bez Kenneya teza Labana jest diagnozą; bez Labana teza Kenneya jest postulatem.

Razem z BW/030 (ENISA Security-by-Design and -by-Default) potwierdza analogię security cross-cutting - ENISA daje 22 praktyki rozłożone na cykl życia produktu, Kenney pokazuje, że enforcement powinien rozłożyć się tak samo. BW/011 (NIST AI 800-4 Monitoring) rozszerza Zasadę 2 i 3 Kenneya w wymiarze monitoringu.

Razem z BW/044 (WEF/Capgemini - Readiness Framework) tworzy parę poziomów decyzyjnych: WEF/Capgemini odpowiada "gdzie wdrożyć" (mapa funkcji), Kenney odpowiada "jak wdrożyć z runtime constraint" (zasady architektoniczne). Razem dają sektorowi publicznemu w Polsce kompletną mapę decyzyjno-architektoniczną.

Direct complement do BW/039 (RAII Policy Template) - RAII daje strukturę polityki, Kenney daje warstwę implementacyjnych zasad runtime, których RAII nie szczegółowił. Wzorzec polityki AI w polskiej kancelarii: szkielet RAII plus rozdział "Runtime enforcement" oparty na sześciu zasadach Kenneya.

Dla MateMatic to warstwa zasad implementacyjnych obok warstwy architektury technicznej (BW/043) i warstwy decyzyjnej (BW/044). Sześciowarstwowy stack governance MateMatic: BW/039 polityka, BW/040 vendor assessment, BW/041 forecasting, BW/042 benchmark globalny, BW/043 architektura techniczna, BW/044 mapa decyzyjna sektora publicznego. BW/045 Kenney rozszerza go do siódmej warstwy: zasady runtime enforcement spinające pierwszych sześć w wymiarze "kiedy i czemu".