NIST mówi: monitorować musicie.
I dodaje: nie do końca potrafimy.

Dokument dostałem w środę rano. Pierwsza kawa nie wystarczyła, druga też niezupełnie. NIST nie publikuje często standardów, które w polskiej kancelarii trzeba przeczytać tego samego dnia, w którym się je zobaczy, ale ten jest z tej kategorii. Nie dlatego, że NIST obowiązuje nas formalnie - nie obowiązuje, bo nie jesteśmy administracją federalną USA. Dlatego, że amerykański rząd publikuje pierwszy raz w tej skali rzetelny dokument, w którym opisuje, czego w post-deployment monitoringu systemów AI dzisiaj nie umie nikt - i dlaczego. A wymagają tego od nas RODO, AI Act, ISO/IEC 42001 i wszystko, co dopiero nadejdzie.

O czym jest ten materiał

NIST AI 800-4 w wersji Initial Public Draft jest flagową publikacją Center for AI Standards and Innovation - nowej komórki wewnątrz NIST powołanej w 2025 roku do prac nad standardami bezpieczeństwa i niezawodności systemów AI. Autorzy (zespół dziewięcioosobowy, mieszanka praktyków z big tech i urzędników federalnych) przeprowadzili w kwietniu i maju 2025 trzy warsztaty eksperckie z łączną liczbą około 250 uczestników i przejrzeli 87 publikacji naukowych. Efekt: dokument ramowy, który nie jest standardem w sensie ISO, tylko strukturalnym opisem, czego nie umiemy monitorować i dlaczego każda z tych luk ma znaczenie praktyczne.

Struktura dokumentu układa się w sześć rodzin monitoringu po wdrożeniu. Monitoring funkcjonalny - czy model nadal działa tak, jak w momencie zatwierdzenia. Monitoring operacyjny - latencja, koszt, dostępność. Czynnik ludzki - czy użytkownik ufa wynikom w sposób, który nie prowadzi do błędu. Bezpieczeństwo - prompt injection, wycieki danych, jailbreaks. Zgodność regulacyjna - czy system mieści się w granicach prawa, które obowiązuje. Oddziaływania wielkoskalowe - co się dzieje, gdy wdrożony model oddziałuje na rynek pracy, rynek informacji, opinii publicznej. Do tego osobny rozdział cross-cutting challenges: niedeterminizm modeli, sycophancy, deceptive behavior, modele wykrywające moment oceny, monitorability tax, asymetria informacji dostawca-wdrażający, open-weight "impossible to retract".

Autorzy nie proponują rozwiązań. Proponują uczciwą mapę tego, co jest trudne, co jest otwarte i czego wymagać dzisiaj nie można. To jest ten typ dokumentu, który technolodzy nazwą skromnym, a compliance officerowie - wybuchowym.

Materiał w pierwszej warstwie jest porządny, drobiazgowy i neutralny. W drugiej warstwie jest bardzo niepokojący, bo opisuje rzeczywistość, w której ciężar obowiązku prawnego nie ma pokrycia w dostępnej technice.

Recenzja właściwa

Perspektywa compliance i ochrony danych

RODO od 2018 roku wymaga od administratora prowadzenia oceny ryzyka, oceny skutków dla ochrony danych i regularnej weryfikacji skuteczności środków technicznych i organizacyjnych (Art. 24, 25, 32, 35). AI Act od 2 lutego 2026 dokłada do tego obowiązek post-market monitoringu w odniesieniu do systemów wysokiego ryzyka (Art. 72), rejestr incydentów (Art. 73), oraz ciągłą aktualizację systemu zarządzania ryzykiem (Art. 9, Art. 17). W obu reżimach słowo kluczowe jest to samo - ciągły. Nie jednorazowy. Nie co rok. Ciągły.

NIST w tej publikacji mówi bez ogródek, że znaczna część tego, co regulator z Brukseli nazywa ciągłym monitoringiem, nie jest dzisiaj możliwa do wykonania w sposób powtarzalny i pełny. Niedeterminizm modeli generatywnych sprawia, że ten sam prompt w tym samym tygodniu daje różne odpowiedzi. Sycophancy - tendencja modelu do "przytakiwania" użytkownikowi - wykrywana jest dopiero w zagregowanych statystykach, nigdy w pojedynczym logu. Deceptive behavior udokumentowano w kilkudziesięciu badaniach: model, który wykrywa, że jest oceniany, zachowuje się inaczej niż w produkcji. Open-weight model raz udostępniony publicznie "jest nie do odzyskania" (impossible to retract) - dostawca nie może go cofnąć nawet wtedy, kiedy sam zidentyfikuje poważne zagrożenie.

To rodzi bardzo konkretne pytanie compliance, którego NIST nie zadaje wprost, bo nie jest to rolą CAISI, ale zadać muszą je w Polsce. Kto jest administratorem ryzyka, kiedy ryzyka w pełni monitorować się nie da. Prawna odpowiedź brzmi: administrator, a w rozumieniu AI Act podmiot wdrażający (deployer). Praktyczna odpowiedź: kancelaria, szpital, bank, którzy dany model wdrożyli, muszą być przygotowani udowodnić, że monitorowali tyle, ile można, dokumentowali dlaczego reszty nie dało się monitorować, i eskalowali braki w odpowiednim czasie do właściwego organu (UODO, a przy AI Act do krajowego organu notyfikującego).

Perspektywa bezpiecznej architektury

Najciekawszy analitycznie fragment NIST-u dotyczy czegoś, co nazwano monitorability tax. Każdy mechanizm monitorujący zabiera część zasobów, które mogłyby służyć wykonywaniu zadania. Im głębszy monitoring, tym wyższy koszt latencji, pamięci i obliczeń. Monitoring płytki - łatwy, tani, mało użyteczny. Monitoring głęboki - drogi, wolny, ale wykrywa rzeczy, których płytki nie zobaczy.

Dla kancelarii implikacja jest prosta i niewygodna. Jeśli wdrażamy system AI, który miał być szybki i tani (bo tak sprzedawał dostawca), a w umowie mamy wymóg pełnego monitoringu, to te dwa wymogi stoją w sprzeczności. Nie z powodu złej woli. Z powodu architektury. Co oznacza, że albo płacimy więcej za wdrożenie pełnowartościowe, albo redukujemy zakres zastosowania, albo akceptujemy ryzyko i dokumentujemy decyzję. Trzecia opcja tylko wtedy, kiedy mamy do czego się odwołać - bazy compliance decyzyjnej, komisji etyki, opinii compliance officera.

Druga architektoniczna perspektywa: open-weight impossible to retract. Kancelaria, która zbudowała pipeline na modelu open-weight udostępnionym publicznie, działa w reżimie, w którym autor modelu nie ma technicznej możliwości naprawić go w użyciu - nawet gdyby chciał. Poprawki trafiają tylko do nowych wersji. Stara wersja zostaje na dyskach. W compliance oznacza to jedno: kancelaria bierze na siebie odpowiedzialność za pozostanie przy starej wersji, z pełnymi jej wadami, a nie dostawca. To nie jest argument przeciw open-weight. To argument za tym, żeby polityka aktualizacji była w kancelarii zapisana, a nie domyślna.

Czego autorzy nie dostrzegli: polska skala i tajemnica zawodowa

NIST pisze do instytucji federalnych USA i do dużych korporacji, które mają zespoły AI governance liczone w dziesiątkach osób. Sześć rodzin monitoringu, każda z własnym katalogiem ryzyk, każda wymagająca specjalistów - to model operacyjny dostępny dla dwóch procent światowego rynku. Co z resztą. Co z polską kancelarią piętnastoosobową w Katowicach, w której compliance officer jest jedną osobą na pół etatu, a dział IT - jedną osobą na cały, ale tylko od poniedziałku do piątku.

Odpowiedź, której NIST nie formułuje, ale którą da się z tego dokumentu wyciągnąć: jeśli nie da się zrobić wszystkiego z sześciu rodzin, trzeba wybrać dwie najkrytyczniejsze dla danego typu wdrożenia i zrobić je porządnie. Dla kancelarii pracującej z dokumentami klienta najkrytyczniejsze jest prawie zawsze bezpieczeństwo (wyciek danych) i zgodność regulacyjna (tajemnica zawodowa, RODO, dane szczególnej kategorii). Reszta - jeżeli starczy zasobów, po nich.

Drugi brak autorski: tajemnica zawodowa nie istnieje w słowniku NIST-u. Attorney-client privilege pojawia się przelotnie w kontekście discovery, ale polska tajemnica adwokacka z art. 6 prawa o adwokaturze, radcowska z art. 3 ustawy o radcach prawnych, bankowa, medyczna, notarialna - cała ta warstwa, która w europejskim compliance stanowi niezależne źródło obowiązku, u NIST-u znika. Monitoring zaproponowany przez CAISI zakłada, że wszystkie dane w systemie można zindeksować, zlogować i analizować. W polskim modelu tajemnic zawodowych takiego założenia nie wolno przyjąć domyślnie. Część logów trzeba zredagować już na etapie ich powstawania, a nie w retrospektywie. To wymaga decyzji architektonicznej, nie politycznej.

Ósmy głos w kompozycji compound regime

Motyw wraca. TOM 001 (Kenney) zbudował cross-walk regulacyjny. TOM 005 (Levy) pokazał lukę amerykańskich Model Rules wobec RODO. TOM 006 (MindForge) dał singapurski playbook operacyjny. TOM 007 (CETaS) brytyjski handbook kryzysowy. TOM 008 (Bird & Bird) polski AI Act. TOM 009 (MIT) meta-taksonomia. TOM 010 (Boise) głos klienta.

NIST AI 800-4 wnosi ósmy głos - amerykański rząd federalny w roli obserwatora własnych ograniczeń. To ważny i rzadki rejestr. Większość dokumentów rządowych opisuje, co trzeba zrobić. Ten opisuje, czego zrobić się nie da. W kompozycji compound regime (RODO × AI Act × ISO/IEC 42001 × NIST) ta publikacja pełni rolę sygnału: wymagania się nie zmniejszają, zdolność operacyjna zmienia się wolniej niż oczekiwanie regulatora. Luka między jednym a drugim jest polem, w którym dzisiaj mieści się odpowiedzialność wdrażającego.

Jedno pytanie, którego autorzy nie zadali

Dokument w rozdziale "Open Questions" wymienia kilkanaście kwestii, które wymagają dalszych badań. Brakuje jednego pytania, i to być może najważniejszego z perspektywy europejskiej. Jak długo regulator powinien czekać z egzekwowaniem wymogu monitoringu, którego stan techniki jeszcze nie umie wykonać. W amerykańskim modelu enforcement jest reaktywny - urząd działa po incydencie. W europejskim jest proaktywny - UODO i krajowy organ AI Act mogą kontrolować bez incydentu. To oznacza, że luka opisana przez NIST w Polsce przekłada się na konkretną ekspozycję administracyjną szybciej, niż w USA. Warto o tym pamiętać, układając harmonogram wdrożeń w drugiej połowie 2026.

Co z tego wynika

NIST AI 800-4 jest dokumentem, który warto mieć w bibliotece zarządu kancelarii. Nie jako standard do wdrożenia - CAISI go tak nie pomyślał. Jako mapę terenu, po którym poruszają się dzisiaj obowiązki z RODO i AI Act. Kto tej mapy nie ma, wdraża AI w trybie nadziei, że nikt nie zapyta. Kto ma - wdraża świadomie, z jasnym zapisem w dokumentacji, które rodziny monitoringu pokrywa, które pokrywa częściowo, i które pozostają otwarte. To nie jest ideał. To jest stan realizmu.

Dla kogo ten materiał. Dla compliance officerów kancelarii i działów IT odpowiedzialnych za wdrożenia AI. Dla partnerów zarządzających, którzy negocjują z dostawcami systemów. Dla DPO, którzy podpisują DPIA pod system wykorzystujący modele generatywne. Dla rad nadzorczych, które odpowiadają za system zarządzania ryzykiem w podmiocie wdrażającym.

Dla kogo nie. Dla nikogo, kto szuka w tym recepty na prosty checklist. Recepty nie ma, a każdy, kto obiecuje checklist obejmujący sześć rodzin monitoringu w jednym arkuszu, nie przeczytał NIST-u do końca. Warto przeczytać osobiście, co najmniej rozdziały o cross-cutting challenges i open questions. Reszta pomocna, ale te dwa są obowiązkowe.