Berkeley CLTC syntetyzuje NIST plus ISO plus EU GPAI Code w jednym profilu. Polska kancelaria dostaje meta-mapę governance.

Polski adwokat doradzający kancelarii, która przygotowuje politykę AI dla siebie albo dla klienta korporacyjnego, ma w ostatnich dwóch latach ten sam problem: jednoczesne czytanie NIST AI RMF (cztery funkcje plus playbook), ISO/IEC 23894 (norma ISO dla AI risk), EU GPAI Code of Practice (sygnowany przez Komisję Europejską jako kodeks dobrych praktyk wedle art. 56 AI Act), International AI Safety Report Bengio z 2025 oraz powstających NIST AI 800-1 i 800-4 jest pracochłonne i nie zawsze prowadzi do spójnej polityki. Pięć źródeł, pięć terminologii, pięć priorytyzacji.

Berkeley CLTC w wersji 1.2 robi to, czego polska kancelaria potrzebuje: kompiluje pięć źródeł w jeden Profile, zorganizowany wokół czterech funkcji NIST (GOVERN/MAP/MEASURE/MANAGE) z jedenastoma high-priority subcategories i Sekcją 2.2.1 risk taxonomies (która sama syntetyzuje cztery taksonomie ryzyk: MIT Risk Repository, International AI Safety Report, NIST GAI Profile, EU GPAI Code). To nie jest kolejny standard - to profil obejmujący istniejące standardy, w tradycji NIST Cybersecurity Framework Profiles.

O czym jest ten materiał

Profile ma cztery warstwy. Warstwa konceptualna - ramowanie problemu (Sekcja 1), w tym key terms (GPAI Model wedle art. 3 ust. 63 AI Act, GPAI System wedle art. 3 ust. 66, frontier models takie jak GPT-5.4, Claude Sonnet 4.6, Gemini 3.1 Pro, Llama 4.1) plus benefits dla developerów, deployerów i regulators. Warstwa metodologiczna - components and how to use the Profile (Sekcja 2), w tym Section 2.2 Impact Areas/Harm Factors/Trustworthiness oraz Section 2.2.1 Risk Taxonomies (cztery źródła plus Profile-specific consolidated organization). Warstwa preskryptywna - Sekcja 3 Guidance jako rdzeń dokumentu: GOVERN/MAP/MEASURE/MANAGE z konkretnymi sub-kategoriami i działaniami pochodzącymi z NIST AI RMF Playbook plus dodatkami Berkeley plus EU GPAI Code mapping. Warstwa eksperymentalna - appendices, w tym Roadmap (Appendix 3) z planami przyszłych wersji.

Pięć kluczowych liczb i pojęć do zapamiętania:

Jedenaście high-priority subcategories Berkeley CLTC do zapamiętania (każda jest osobnym checklist'em audytowym):

• Govern 1.4 - oversight, risk thresholds, incident response plans
• Govern 2.1 - roles, responsibilities, lines of communication
• Govern 4.2 - documentation of risks and impacts
• Govern 5.1 (NEW v1.2) - external feedback, third-party evaluations
• Govern 6 - third-party software/data supply chain risks
• Map 1.1 - intended purposes, context-specific laws
• Map 1.5 - organizational risk tolerances
• Map 5.1 - likelihood/magnitude of impacts
• Measure 1.1, 1.3, 2.7, 2.9, 3.1 - risk metrics, red-teaming, benchmarks, transparency
• Manage 1.3 - high-priority risk responses (mitigate/transfer/avoid/accept)
• Manage 4.1 (NEW v1.2) - post-deployment monitoring, incident response, change management, decommissioning

Recenzja właściwa

Najmocniejsza warstwa - Sekcja 2.2.1 Risk Taxonomies jako synteza czterech taksonomii

Section 2.2.1 jest dla polskiej kancelarii najwartościowszą pojedynczą sekcją w Profile. Berkeley pisze otwarcie: nie ma jednej dobrej taksonomii ryzyk AI, są cztery konkurencyjne, każda ma swój punkt widzenia. MIT Risk Repository używa domain-based: dyskryminacja/toxicity, prywatność/security, misinformation, malicious actors, human-computer interaction, socioeconomic/environmental, AI system safety. International AI Safety Report Bengio agreguje przez pathways: malicious use, malfunctions, systemic issues. NIST GAI Profile wymienia 12 ryzyk specyficznych dla generatywnej AI (confabulation, information security, data privacy, abusive content). EU GPAI Code of Practice wprowadza multi-dimensional framework: affected social interests + source of risk + systemic risks (CBRN, loss of control, cyber offense, harmful manipulation).

Berkeley nie wybiera jednej - kompiluje wszystkie cztery w Profile-specific consolidated organization. Polska kancelaria stosuje to operacyjnie tak: bierze konsolidowaną listę Berkeley jako wyjściową taksonomię ryzyk AI klienta, mapuje na cztery oryginalne taksonomie (gdzie ryzyko siedzi w MIT, gdzie w EU GPAI), dolewa polską warstwę (gdzie ryzyko siedzi w art. 22 RODO zautomatyzowane decyzje, art. 9 RODO dane wrażliwe, art. 9 AI Act risk management high-risk, tajemnica zawodowa). Dostaje dokument due diligence ryzyka AI z empirycznym fundamentem czterech globalnych taksonomii plus polską warstwą.

Druga mocna warstwa - dwie nowe high-priority v1.2

Govern 5.1 (NEW v1.2): External feedback, third-party evaluations. Berkeley pisze explicit: "Recognizing the critical role of external feedback, especially third-party evaluations, in robust AI risk management, we included a dedicated sub-category to emphasize the importance of this essential step." Adwokat doradzający dostawcy LegalTech albo kancelarii kupującej LegalTech ma teraz autorytatywny argument: czy macie procedurę zbierania third-party evaluations dangerous capabilities modelu? Czy macie clear feedback channels dla użytkowników? Wedle Govern 5.1 Berkeley CLTC v1.2 to jest high-priority risk-management step, nie opcjonalny dodatek. Mapping na art. 26 ust. 5 AI Act (deployer obowiązek monitoringu) plus art. 56 AI Act (codes of practice).

Manage 4.1 (NEW v1.2): Post-deployment monitoring, incident response, change management. Berkeley pisze: "Risk management does not end following a model's deployment; continuous monitoring is required." To jest dokładnie ta sama teza, którą czytamy u Kenneya w BW/045 (Zasada 2: continuous authorization, not point-in-time) i u OASIS CoSAI w BW/043 (imperatyw #6: prove control on demand). Trzy niezależne źródła zbiegają się na ten sam wymóg architektoniczny - to jest najsilniejsza ewidencja, jaką może mieć compliance officer kancelarii w rozmowie z zarządem niedowierzającym, że post-deployment monitoring jest standard nie luksus.

Trzecia mocna warstwa - GOVERN/MAP/MEASURE/MANAGE jako szkielet polityki

Sekcja 3 (Guidance) jest operacyjnym szkieletem polityki AI dla kancelarii. Cztery funkcje NIST tworzą rozdziały polityki, jedenaście high-priority subcategories tworzy sekcje rozdziałów, szczegółowe działania z NIST AI RMF Playbook plus dodatki Berkeley dostarczają szczegółowych klauzul. Polska kancelaria 50-osobowa może wziąć ten szkielet w całości i adaptować, kancelaria 5-osobowa kompresuje do GOVERN 1.4/2.1, MAP 1.1/1.5, MEASURE 1.1, MANAGE 4.1 plus własny rozdział "Tajemnica zawodowa i AI" - i to jest minimum operacyjne.

Wartość Berkeley jest taka, że te szkielety są mapowane na konkretne źródła: każda subcategory wskazuje, gdzie odpowiednia treść siedzi w NIST AI RMF, ISO/IEC 23894 i EU GPAI Code. Compliance officer kancelarii nie musi sam mapować norm na siebie - Berkeley już to zrobił. Polski adwokat dolewa tylko piątą kolumnę: gdzie odpowiednia treść siedzi w polskim porządku prawnym (RODO, AI Act, KSH, ustawy zawodowe).

Czwarta mocna warstwa - Frontier AI Company Practices Evaluation

Berkeley wraz z Profile V1.2 publikuje osobny dokument Evaluation of Frontier AI Company Practices Using the General-Purpose AI Risk-Management Standards Profile z testami konkretnych modeli: Claude Opus 4.5, GPT-5, Llama 4, Gemini 3 Pro, porównawczo z V1.1 i V1.2. To jest empiryczny benchmark dla polskiej kancelarii doradzającej klientowi przy wyborze GPAI: jak wybrany przez was model wypada w 11 high-priority subcategories Berkeley CLTC? Gdzie są gaps - w transparency, w post-deployment monitoring, w third-party evaluations?

To jest pierwszy w pełni uniwersalny benchmark dostawców GPAI (nie LegalTech) w Bazie Wiedzy MateMatic. Komplementarny do BW/040 (King AI Vendor Assessment Guide) - King jest skryptem rozmowy z dostawcą, Berkeley Frontier Eval jest gotową oceną największych dostawców globalnych, którą kancelaria może cytować bez własnych testów.

Mapping na polskie instrumenty prawne

Warstwa AI Act

Cztery funkcje NIST mapują się bezpośrednio na obowiązki dostawców i deployerów wedle AI Act. GOVERN → art. 9 (system zarządzania ryzykiem), art. 17 (system zarządzania jakością dla dostawców high-risk), art. 26 ust. 1-2 (deployer obowiązki organizacyjne). MAP → art. 9 ust. 2 (identyfikacja i analiza ryzyk), art. 27 (FRIA - Fundamental Rights Impact Assessment dla deployerów high-risk z Załącznika III). MEASURE → art. 15 (accuracy, robustness, cybersecurity), art. 71 (registration database), art. 12 (record-keeping). MANAGE → art. 9 ust. 5 (risk mitigation measures), art. 26 ust. 4-5 (deployer monitoring i informowanie), art. 72 (post-market monitoring) - tu Manage 4.1 jest implementacyjnym wzorcem.

Berkeley w v1.2 explicit dolewa EU GPAI Code of Practice (EC 2025a) jako piąte źródło - to jest kodeks dobrych praktyk wedle art. 56 AI Act, który dla polskiego dostawcy GPAI jest reference framework po sierpniu 2026. Polski adwokat doradzający dostawcy może powiedzieć: Berkeley CLTC v1.2 mapuje EU GPAI Code na NIST AI RMF subcategories - macie gotową translację waszych obowiązków pod EU GPAI Code na operacyjny język NIST.

Warstwa RODO

GOVERN 5.1 (third-party evaluations) operacjonalizuje art. 35 ust. 9 RODO (DPIA z opinią ekspercką) i art. 25 ust. 3 RODO (certyfikacja jako dowód compliance). MAP 1.5 (organizational risk tolerances) mapuje się na art. 24 RODO (środki uwzględniające ryzyko). MANAGE 4.1 (post-deployment monitoring) - jak omówione w BW/045 Kenney - jest implementacją art. 5 ust. 2 RODO (rozliczalność) i art. 32 ust. 1 lit. d (regularne testowanie skuteczności środków technicznych).

Warstwa tajemnicy zawodowej i KSH

MANAGE 4.1 post-deployment monitoring dla kancelarii oznacza monitorowanie, czy agent nie ujawnia tajemnicy zawodowej w długim cyklu interakcji - continuously, not point-in-time. GOVERN 1.4 (incident response plan) to instrument, który zarząd kancelarii musi mieć przygotowany przed incydentem - decyzja o jego architekturze jest decyzją z art. 293 KSH (staranność). GOVERN 6 (third-party software/data supply chain) to praktyczna realizacja audytu dostawcy LegalTech - razem z BW/040 King daje pełen schemat.

Czego brakuje - z perspektywy polskiej kancelarii

Brak warstwy małego deployera (kancelaria 5-50 osób). Profile pisany jest "primarily for developers of large-scale, state-of-the-art GPAI models" plus downstream developers/deployers. Polska kancelaria 10-osobowa nie jest developerem ani large-scale deployerem; jest downstream user, dla którego wymóg implementacji 11 high-priority subcategories jest delegacyjny do dostawcy LegalTech, nie operacyjny. Wartość Berkeley dla małej kancelarii jest checklist'em zakupowym - "wybieramy dostawcę, który spełnia 11 high-priority Berkeley CLTC".

Brak polskiej warstwy regulacyjnej. Berkeley mapuje EU GPAI Code (na poziomie EU jako całości), ale nie polski porządek wykonawczy - polskie ustawy implementujące AI Act (gdy zostaną przyjęte), polskie regulacje sektorowe UODO/KNF/UKE/PUODO, kodeksy etyki zawodowej (KEA, KERP). To dopisuje sama kancelaria.

Brak warstwy odpowiedzialności cywilnoprawnej. Profile mówi o accountability w ujęciu organizacyjnym (kto za co odpowiada wewnątrz organizacji), nie o odpowiedzialności cywilnej za szkodę wyrządzoną przez GPAI. Polski adwokat dopisuje warstwę prawa cywilnego (art. 415 KC, art. 471 KC, projektowane dyrektywy o odpowiedzialności za AI).

Brak agendy autorskiej w deklaracji. Berkeley CLTC i CAIS Hendrycksa mają jasną pozycję w debacie AI safety vs AI ethics vs AI capability. Profile jest neutralny w tonie, ale wybór taksonomii (włączenie CBRN, loss of control, manipulation z EU GPAI Code) odzwierciedla kierunek safety. Polska kancelaria czyta to z świadomością, że nie wszystkie taksonomie ryzyka są neutralne politycznie.

Komu polecam, komu odradzam

Compliance officer kancelarii budujący politykę AI - obowiązkowo, jako szkielet polityki. Cztery funkcje GOVERN/MAP/MEASURE/MANAGE plus 11 high-priority subcategories tworzą gotowy spis treści.

Adwokat doradzający dostawcy GPAI lub LegalTech - obowiązkowo, plus osobny dokument Frontier AI Company Practices Evaluation jako benchmark własnego modelu wobec konkurencji.

Adwokat doradzający kancelarii kupującej LegalTech - obowiązkowo, plus użycie 11 high-priority subcategories jako kryteria wyboru obok BW/040 King.

IOD kancelarii - tak, dla mapowania GOVERN 5.1 i Manage 4.1 na art. 35 RODO (DPIA z third-party feedback) i art. 32 RODO (regularne testowanie).

Partner zarządzający kancelarii bez compliance officera - tylko Sekcja 1 (executive summary) plus Sekcja 2.3 (high-priority steps overview) plus 1.5 (limitations). Reszta dla zespołu wdrożeniowego albo dostawcy.

Klient kancelarii bez poradnika prawnego - nie polecam bezpośrednio. Profile jest dokumentem dla developerów i compliance officerów, nie dla biznesu. Klient czyta zamiast tego BW/044 (WEF/Capgemini Readiness Framework) na poziomie funkcji.

Powiązanie z innymi tomami Bazy Wiedzy

Berkeley CLTC v1.2 wpisuje się w Temat 03 (Compliance i governance regulacyjne) jako warstwa syntezy regulacyjnej - razem z BW/008 (Bird&Bird AI Act guide), BW/013 (FAQ AI Act), BW/038 (Smuha Cambridge Handbook), BW/039 (RAII Policy Template) i BW/044 (WEF/Capgemini) tworzy pełen stos dokumentów regulacyjnych. Berkeley jest jedynym z nich, który kompiluje pięć źródeł w jeden Profile.

Direct complement do BW/011 (NIST AI 800-4 Monitoring) - Berkeley rozszerza NIST AI RMF o GPAI-specific guidance i włącza NIST AI 800-1 jako jedno z pięciu źródeł. Razem dają polskiej kancelarii pełną architekturę warstwy monitoringu w trzech źródłach: NIST AI 800-4 jako specyficzny instrument, Berkeley v1.2 jako kontekst Profile, EU GPAI Code jako europejski kodeks.

Direct complement do BW/045 (Kenney Runtime Enforcement) - Manage 4.1 Berkeley to dokładnie ta sama teza co Zasada 2 Kenneya (continuous authorization, not point-in-time). Trzy niezależne źródła zbiegają się: Kenney mówi "zasada", Berkeley mówi "high-priority subcategory", OASIS CoSAI (BW/043) mówi "imperatyw #6 prove control on demand". Compliance officer kancelarii ma teraz trzy autorytatywne źródła potwierdzające tę samą architektoniczną tezę.

Razem z BW/040 (King AI Vendor Assessment Guide) tworzy parę audytową: King jest skryptem rozmowy z dostawcą (33 pytania w 12 domenach), Berkeley Frontier Eval daje gotowe oceny czterech największych dostawców GPAI globalnie. Razem dają polskiej kancelarii kompletny zestaw audytowy: rozmowa plus benchmark.

Razem z BW/035 (Laban LLMs Corrupt Documents) wzmacnia argumentację dla Manage 4.1 (post-deployment monitoring) - Laban mierzy degradację po 20 iteracjach, Berkeley czyni z post-deployment monitoring high-priority subcategory. Empiryka plus norma.

Direct complement do BW/044 (WEF/Capgemini Readiness Framework) - WEF mapuje 70 funkcji rządu do agentic AI (mapa decyzyjna), Berkeley dostarcza meta-framework risk management dla każdej funkcji wybranej z mapy. Razem pełen path: gdzie wdrożyć (WEF) plus jak zarządzać ryzykiem wdrożenia (Berkeley).

Razem z BW/043 (OASIS CoSAI Agentic IAM) i BW/045 (Kenney Runtime Enforcement) tworzy trójkąt warstwy MANAGE: OASIS dostarcza protokoły IAM, Kenney dostarcza zasady enforcement, Berkeley dostarcza profile NIST z 11 high-priority subcategories. Trzy poziomy abstrakcji jednego problemu.

Dla MateMatic to warstwa syntezy regulacyjnej obok warstwy zasad implementacyjnych (BW/045), warstwy architektury technicznej (BW/043), warstwy decyzyjnej (BW/044). Ośmiowarstwowy 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 zasady runtime enforcement, BW/046 synteza regulacyjna pięciu standardów.