Governance AI ma ulubione ryzyka.
MIT liczy, o których milczy.

Spotkanie zarządu kancelarii regionalnej, środa, druga kawa. Partner odpowiedzialny za IT melduje, że wdrożenie asystenta AI dla działu compliance jest "pełni zgodne z AI Act". DPO pyta grzecznie, o które z dwudziestu czterech subdomen ryzyka chodzi. Cisza, która nastąpiła, była pouczająca - nie dlatego, że partner IT nie wiedział, co odpowiedzieć, tylko dlatego, że pytanie po raz pierwszy zostało zadane w tej formie.

Kwietniowy update MIT FutureTech dostarcza pod tę ciszę dane. Tysiąc dokumentów governance AI, sześć taksonomii, jeden pipeline LLM. Nie kolejna analiza, kogo AI Act obejmuje. Analiza, czego nie obejmuje - i czego nie obejmują inne reżimy razem z nim.

O czym jest ten materiał

Simon Mylius, Peter Slattery i zespół MIT FutureTech w kwietniu 2026 publikują drugą odsłonę projektu, którego pierwsza część - AI Risk Repository - złożyła w jedną bibliotekę 1725 ryzyk AI z siedemdziesięciu czterech taksonomii. Obecny raport odwraca pytanie. Zamiast: "jakie są ryzyka AI", stawia: "do których ryzyk governance w ogóle się odnosi".

Materiałem analitycznym jest zbiór AGORA (AI Governance Observatory Repository Analytics - nazwa robocza) - około tysiąca dokumentów governance AI, przeważająco amerykańskiego pochodzenia. Mieszanka hard law (ustawy, rozporządzenia wykonawcze, executive orders), soft law (kodeksy dobrych praktyk, deklaracje, standardy ISO/IEC), literatury branżowej, listów otwartych i białych ksiąg. Każdy dokument został sklasyfikowany automatycznie przez LLM według sześciu taksonomii.

Te sześć osi to: (1) subdomeny ryzyka z MIT AI Risk Taxonomy, dwadzieścia cztery pozycje; (2) sektory gospodarki, od publicznej administracji po usługi konsumenckie; (3) aktorzy w ekosystemie AI (deweloper, deployer, aktor governance, użytkownik, dostawca infrastruktury, interesariusze pośrednio dotknięci); (4) fazy cyklu życia AI według definicji OECD/NIST - sześć etapów od Plan and Design po Operate and Monitor; (5) status legislacyjny - hard law versus soft law; (6) zakres techniczny - od ogólnego "AI System" po konkretne podkategorie jak frontier AI, open-weight, modele o progach mocy obliczeniowej.

Najbardziej niewygodne zdanie raportu pada w sekcji o pokryciu subdomen: dominują AI system security vulnerabilities and attacks oraz Governance failures. Najrzadziej adresowane to dobrostan AI (3% pokrycia już w bazie ryzyk z 2024), ryzyka wielo-agentowe i - najważniejsze z perspektywy polskiej kancelarii - ryzyka socjoekonomiczne: dewaluacja ekonomiczna, koncentracja władzy, wypieranie pracowników.

Jednym zdaniem: governance AI pokrywa, co łatwo zmierzyć i łatwo napisać po angielsku. Trudne zostawia w bazie 1725 ryzyk z dopiskiem "otwarte".

Recenzja właściwa

Regulacja ma ulubieńców

Figura pierwsza raportu ustawia hierarchię, której nie widziałem zestawionej tak przejrzyście w żadnym innym materiale. Subdomeny pokryte przez największą liczbę dokumentów to te, które od 2020 roku weszły na pierwsze strony - bezpieczeństwo modeli, ataki adversarial, governance failures, przejrzystość modeli fundacyjnych. Rzeczy, o których mówi się na konferencjach, które mają swoje grupy robocze w NIST i w Unii, i które łatwo zmieścić w formule "risk management process".

Na drugim biegunie - dobrostan AI (3%), ryzyka wielo-agentowe (7%), socioekonomia i koncentracja władzy. Te trzy obszary łączy jedna cecha, której raport nie nazywa wprost, a która dla kancelarii jest operacyjnie kluczowa. Nie da się ich zmierzyć standardowym audytem technicznym. Nie mieszczą się w art. 9 AI Act (risk management system) ani w art. 26 (obowiązki deployera) w sposób oczywisty. Wymagają spojrzenia, którego audytor SOC-2 zwykle nie ma.

Konsekwencja dla DPIA z art. 35 RODO: jeśli framework regulacyjny, z którego wybiera się wskaźniki ryzyka, sam w sobie ignoruje dwadzieścia procent subdomen, to wyprowadzona z niego analiza wpływu będzie systemowo ślepa w tym samym miejscu. MIT nie pisze tego wprost, bo pisze dla regulatorów globalnych. Dla compliance officera w Bydgoszczy ten pasaż powinien być przeczytany dwa razy.

Publiczna administracja i R&D dominują. Konsument zostaje w tle.

Rozkład sektorowy w AGORA powtarza wzorzec podobny do subdomen ryzyka. Dokumenty governance najczęściej adresują sektor publiczny (z wyłączeniem ogólnej administracji) oraz badania naukowe i rozwój. Znacznie rzadziej - usługi konsumenckie, sektory pracochłonne, sprzedaż, handel detaliczny.

Paradoks jest łatwy do przeoczenia. Sektor konsumencki to właśnie ten, w którym model AI dotyka największej liczby ludzi. Chatboty, asystenci w bankowości, rekomendacje zakupowe, wstępny triaż w ochronie zdrowia. To są miejsca, w których ryzyko wywiera rzeczywisty wpływ na prawa i wolności osób, a gdzie governance pisze się najmniej konkretnymi słowami.

Dla kancelarii obsługującej klientów z sektora finansowego, medycznego albo e-commerce brzmi to jak deja vu z RODO 2016 roku - papier normatywny dogania realność z pewnym opóźnieniem, a w międzyczasie odpowiedzialność operacyjną nosi administrator danych (tu: deployer). Wniosek praktyczny: jeśli klient jest deployerem modelu AI w sektorze konsumenckim, standardowy audyt compliance oparty na cytatach z AI Act i NIST zostawi nieadresowane dokładnie te ryzyka, które w jego sektorze są najistotniejsze. Trzeba wejść głębiej, zwykle do literatury sektorowej, czasem do Code of Federal Regulations, czasem do wewnętrznych polityk samego dostawcy.

Cykl życia: gdzie patrzy governance

Najciekawszy wniosek raportu dotyczy rozkładu uwagi wzdłuż cyklu życia AI. OECD i NIST operują definicją sześciu faz: Plan and Design, Collect and Process Data, Build and Use Model, Verify and Validate, Deploy, Operate and Monitor. Większość dokumentów AGORA pokrywa kilka faz jednocześnie, ale - i to jest istotne - fazy końcowe (wdrożenie, eksploatacja, monitoring) otrzymują relatywnie mniejszą uwagę w stosunku do faz środkowych (budowa modelu, walidacja).

Rezonuje to z wcześniejszym spostrzeżeniem z raportu o samych ryzykach: trzynaście procent ryzyk w bibliotece MIT dotyczy etapu przed wdrożeniem, pozostałe dotyczą faz post-deployment. Jeśli teraz okazuje się, że governance też koncentruje się raczej na fazach projektowania i walidacji niż na codziennym monitorowaniu - operacyjny ciężar monitorowania spada głównie na deployera. W polskim kontekście: na kancelarię, która wdraża asystenta AI, a nie na dostawcę SaaS z Kalifornii.

Art. 26 AI Act tego nie zmienia - nakłada obowiązki na deployera niezależnie od tego, ile mówi o nich literatura governance. Ale mówi o nich mniej szczegółowo, niż można by sądzić czytając tabelki compliance. Kancelaria, która spodziewa się, że znajdzie w publicznie dostępnej literaturze gotowe playbooki do monitorowania produkcji, znajdzie tylko ułamek tego, czego potrzebuje. Resztę trzeba będzie napisać samemu, albo zamówić u kogoś, kto napisał to w innej jurysdykcji i lakieruje polskiemu klientowi.

Hard law, soft law i obserwowane przechylenie

Jedna z sześciu taksonomii klasyfikuje dokumenty AGORA według statusu legislacyjnego - hard law (akty z mocą prawną) versus soft law (niewiążące zasady, deklaracje, standardy). Raport nie podaje procentowego rozkładu w sekcji wniosków głównych, ale sam fakt, że dominującymi subdomenami są governance failures i security vulnerabilities, sugeruje, że większość materiału to dokumenty o charakterze rekomendacyjnym, nie bezpośrednio wykonawczym.

Praktyczny skutek dla polskiej kancelarii: znacząca część literatury, którą klient słusznie uznaje za "standard branżowy" (NIST AI RMF, ISO/IEC 42001, OECD AI Principles, Bletchley Declaration) to soft law. Nie zobowiązuje samodzielnie, ale zobowiązuje przez odwołania w kontraktach, przez obowiązki należytej staranności, przez oczekiwania regulatora sektorowego. Audyt compliance, który traktuje je jako opcjonalne, nie dostrzega 80% rzeczywistego pola gry.

Z kąta AI Act sprawa jest jeszcze bardziej subtelna. Art. 40-43 odwołuje się do zharmonizowanych standardów; na dziś większość z nich dopiero powstaje w CEN-CENELEC. Do momentu, gdy powstaną, kancelaria i jej klient poruszają się po soft law jako efektywnym proxy - nie dlatego, że mają taki wybór, tylko dlatego, że nie ma innego materiału.

Amerykański ślad w zbiorze

Raport otwarcie przyznaje: dataset AGORA jest "przeważająco amerykańskiego pochodzenia". To nie jest krytyka autorów - polskich zbiorów porównywalnej skali po prostu nie ma. Ale jest to punkt uwagi dla polskiego recenzenta.

Governance AI w Stanach 2026 roku ma inne priorytety niż europejski. Mniej mówi się tam o prawach podstawowych, więcej o bezpieczeństwie narodowym i frontier models. Mniej o DPIA, więcej o safety evaluation. Mniej o odpowiedzialności deployera w sensie RODO, więcej o odpowiedzialności developera w sensie executive orders. Jeśli polska kancelaria bierze mapę MIT i czyta ją dosłownie, dostaje kształt amerykańskiego dyskursu z lakierem jurysdykcyjnej neutralności.

To nie dyskwalifikuje raportu. Pokazuje natomiast, że mapa trzeba przeczytać z czerwonym długopisem w ręce i doznaczyć na niej kilka subdomen, które w polskim kontekście są mocniejsze niż w amerykańskim: tajemnica zawodowa art. 6 Prawa o adwokaturze, art. 22 RODO w kontekście profilowania klienta, art. 9 RODO w kontekście danych szczególnej kategorii w sprawach sądowych. Żadna z tych trzech pozycji nie pojawia się w dominujących subdomenach AGORA.

Czego autor nie dostrzegł

Raport jest szczery wobec własnych ograniczeń w sekcji Limitations. Problem automatycznej klasyfikacji LLM, ograniczony zasięg AGORA, przewaga języka angielskiego. Jest jedna luka, której jednak MIT nie wymienia, a która z polskiej perspektywy jest mocna.

Zbiór nie odróżnia governance wewnętrznego (polityki korporacyjne, kodeksy etyczne dostawców, wewnętrzne regulaminy kancelarii) od governance publicznego. W realnym wdrożeniu kancelarii te dwa poziomy współtworzą reżim zgodności: polityka DPIA kancelarii jest wewnętrzna, ale opiera się na RODO; wewnętrzny kodeks użytkowania AI jest dobrowolny, ale realnie definiuje blast radius. MIT ten podział pomija, co sprawia, że w subdomenie "Governance failures" w statystyce mieści się zarówno awaria Executive Order, jak i złe wewnętrzne szkolenie personelu kancelarii. To nie są zjawiska tej samej natury.

Drugi brak: raport nie łączy się wprost z rachunkiem ekonomicznym. Obserwacja, że consumer-facing sektor ma małe pokrycie governance, pozostaje opisowa. Nie pyta, dlaczego. Odpowiedź, którą widzę w polskich rozmowach z compliance officerami: governance consumer-facing jest trudne do zmonetyzowania dla dostawcy technologii, więc nie powstaje. Prosty mechanizm rynkowy. MIT tego nie nazywa, bo nazywanie tego oznaczałoby zadanie pytań, na które MIT nie chce odpowiadać w raporcie akademickim.

Co z tego wynika

Raport warto przeczytać, ale czytać go trzeba w sprzężeniu z TOM 009 - bez mapy ryzyk, mapa governance jest pusta, bez mapy governance, mapa ryzyk jest nieoperacyjna. Razem tworzą pierwsze narzędzie, w którym da się odpowiedzialnie rozmawiać o tym, co kancelaria powinna pokryć własną polityką, a co powinien pokryć dostawca.

Dla kogo ten materiał. Dla DPO piszącego DPIA dla wdrożenia asystenta AI, który chce sprawdzić, czy jego framework analizy obejmuje subdomeny rzeczywiście pokrywane przez governance, czy tylko te, o których łatwo się pisze. Dla partnera odpowiedzialnego za compliance, który negocjuje umowę z dostawcą SaaS AI i chce zrozumieć, które subdomeny dostawca standardowo adresuje w swoim pakiecie, a które zostawi kancelarii. Dla regulatora sektorowego, który chce zrozumieć, dlaczego wdrożenie AI w sektorze konsumenckim systemowo wymyka się narzędziom governance napisanym dla sektora publicznego.

Dla kogo nie. Dla nikogo, kto szuka gotowych odpowiedzi "jak wdrożyć AI zgodnie z AI Act". Raport tego nie daje i nie udaje, że daje. Daje natomiast inwentaryzację. Jak wszystkie dobre mapy - nie pokazuje, dokąd iść, tylko gdzie się znajduje.