AI Act Artykuł 11 Technical File dla bankowości: Przewodnik gotowości na 2027

Odroczenie Digital Omnibus: dlaczego rok 2027 to operacyjna rzeczywistość

Unijny Akt o Sztucznej Inteligencji wszedł formalnie w życie w sierpniu 2024 roku, wyznaczając dwuletni okres wdrożenia dla większości przepisów. Jednak CDO i szefowie Model Risk w polskich bankach muszą zrozumieć specyficzną oś czasu dla systemów AI wysokiego ryzyka (High-Risk AI Systems), do których zaliczane są m.in. modele scoringu kredytowego i systemy oceny ryzyka hipotecznego. Pierwotny termin egzekwowania tych przepisów, wyznaczony na **2 maja 2026 r.**, został deferred w ramach inicjatywy Digital Omnibus.

To przesunięcie, ogłoszone po negocjacjach w 2024 r., wyznacza nową, twardą datę na **2 grudnia 2027 r.** dla egzekwowania rygorystycznych wymogów zgodności dla systemów wysokiego ryzyka. To odroczenie nie jest jednak sygnałem do wstrzymania prac. Jest ono operacyjnym ułatwieniem (clarifier), dającym instytucjom finansowym niezbędny czas na przygotowanie, w szczególności w zakresie inżynierii danych i dokumentacji. ECB i KNF w swoich nieoficjalnych guidance papers z lat 2025-2026 jasno wskazują, że ECB Supervisory Priorities 2025-2027 traktują zgodność systemów AI jako priorytet nadzorczy. Bank znaczący (SI) w Polsce nie może czekać do listopada 2027 roku. ECB oczekuje audytowalnych planów wdrożenia (remediation plans) już podczas przeglądów SREP w latach 2026-2027.

Odroczenie na grudzień 2027 r. oznacza, że banki muszą mieć gotową, operacyjną infrastrukturę danych do generowania artefaktów regulacyjnych w trybie ciągłym. AI Act w Artykule 11 wymaga dokumentacji technicznej, która jest audytowalna i "gotowa dla nadzorcy" (KNF-ready documentation context), a nie tylko fragmentarycznego wyciągu z kodu modelu. Ten rygorystyczny audit trail wymaga użycia syntetycznych danych testowych, które nie tylko wiernie odwzorowują produkcję, ale także posiadają audytowalne Lineage Danych niezbędne dla audytorów KNF.

Artykuł 11 vs Artykuł 10: rozpakowanie wymagań dotyczących danych i dokumentacji

Artykuł 11 AI Act nie działa w izolacji. Jest on nierozerwalnie związany z Artykułem 10, który definiuje rygorystyczne wymogi dotyczące governance danych (Data Governance) dla systemów AI wysokiego ryzyka. Zrozumienie tego związku jest kluczowe dla Chief AI Officerów (CAIOs). Artykuł 10 wymaga, aby zestawy danych treningowych, walidacyjnych i testowych były reprezentatywne, dokładne, kompletne i wolne od błędów. Artykuł 11 wymaga natomiast, aby to wszystko było udokumentowane w Technical File.

Technical File w myśl Artykułu 11 musi zawierać szczegółowe informacje o pochodzeniu danych treningowych, zastosowanych metodach wstępnego przetwarzania danych, a także dowody na to, że bank przeprowadził rygorystyczne testowanie stronniczości (bias testing). Bank nie może udowodnić KNF, że jego model jest zgodny z Artykułem 10, jeśli nie posiada danych, na których te kontrole Data Engineering zostały przeprowadzone.

Używanie danych produkcyjnych do walidacji Artykułu 10 niszczy DORA Artykuł 28 i RODO third-party risk management, ponieważ Risk Data Supply Chains często angażują zewnętrznych Systems Integrators (Accenture, Capgemini). Co więcej, użycie danych produkcyjnych w UAT grozi naruszeniem RODO Artykuł 32, ponieważ nawet zmaskowane (masked) dane transakcyjne niosą wysokie ryzyko re-identyfikacji. Rozwiązaniem jest użycie danych syntetycznych Klassen regulacyjnych, takich jak Structurally realistic banking data generowane przez Infundum's CAUSA AI Data Engine. CAUSA pozwala na walidację kontroli Artykułu 10 (np. reprezentatywności, biasu) na matematycznie bezpiecznych, ale operacyjnie wiernych syntetycznych proxy.

Szczegóły naszej zastrzeżonej architektury są dostępne pod NDA podczas formalnej ewaluacji. CAUSA engine gwarantuje wierność wielotabelową niezbędną do walidacji złożonych modeli kredytowych, spełniając najtrudniejsze wymogi KNF bez narażania PII.

Inwentaryzacja systemów AI wysokiego ryzyka w banku: ramy dla CAIO

Pierwszym krokiem do gotowości na grudzień 2027 roku jest rygorystyczna inwentaryzacja systemów AI w myśl AI Act Załącznik III (Annex III). CAIO musi wejść w ścisłą współpracę z szefami Model Risk w celu klasyfikacji. W polskim banku detalicznym systemy AI wysokiego ryzyka obejmują:

• **Modele Scoringu Kredytowego:** Wszystkie systemy AI używane do oceny zdolności kredytowej i prawdopodobieństwa niewypłacalności (PD) klienta detalicznego lub SME.
• **Modele Walidacji Hipotecznej:** Systemy oceny ryzyka hipotecznego w myśl KNF Rekomendacja S.KNF Rekomendacja S a syntetyczne dane.
• **Systemy Stress Testingu Agregacji Danych Ryzyka:** Jeśli systemy te wykorzystują zaawansowane modele ML, mogą zostać uznane za high-risk w kontekście BCBS 239.BCBS 239 — priorytet ECB 2025-2027.
• **Wybrane modele antyfraudowe/AML:** Jeśli ich decyzje niosą istotne skutki dla klienta, KNF może je zaklasyfikować jako high-risk.

AI Act w Załączniku III, punkt 5, klasyfikuje jako high-risk systemy AI przeznaczone do oceny kredytowej lub oceny zdolności kredytowej osób fizycznych. To rygorystyczna klasyfikacja, która nie pozostawia bankom miejsca na hedging. Każdy system scoringowy musi posiadać audytowalny Artykuł 11 Technical File.

Implikacje procurementowe: walidacja dostawców systemów scoringowych

DORA Artykuł 28, dotyczący zarządzania ryzykiem ze strony dostawców ICT, wchodzi w grę podczas audytowania systemów AI wysokiego ryzyka dostarczanych przez zewnętrzne podmioty (MDR). Bank, jako administrator (user) systemu, jest odpowiedzialny za zgodność z AI Act. Zatem bank musi udowodnić KNF, że model zakupiony od dostawcy (np. FICO lub Systems Integrator (Accenture)) jest zgodny z wymogami Artykułu 10 w zakresie Data Governance.

To tworzy critical challenge. Dostawcy MD niechętnie udostępniają dane treningowe audytorom banku. Bank, korzystając z Infundum's CAUSA AI Data Engine, może wygenerować Structurally realistic bazy danych syntetycznych klasy produkcyjnej i zmusić dostawcę do przeprowadzenia walidacji Artykułu 10 na tych danych *wewnątrz bezpiecznej infrastruktury banku*. To pozwala CAIO na walidację braku stronniczości i wierności modelu przed wdrożeniem produkcyjnym, bez narażania wrażliwych danych banku, fulfilling Third-Party Risk Management demands.

Skład i mandat Komitetu ds. AI Governance w banku

Wdrożenie AI Act Artykuł 11 Technical File wymaga trwałej struktury ładu zarządczego (governance structure). Banki muszą powołać Komitet ds. AI Governance (lub wbudować te kompetencje w istniejące Komitety ds. Ryzyka/Danych).

Mandat komitetu musi obejmować:

• **Klasyfikację Systemów High-Risk:** Ostateczną autoryzację High-Risk System Inventory.
• **Przegląd Technical File przed wdrożeniem:** Formalną autoryzację Technical File wygenerowanego dla każdego systemu wysokiego ryzyka.
• **Zarządzanie biasem:** Nadzór nad metodologią testowania stronniczości zgodnie z RODO Artykuł 9.
• **Komunikację z KNF:** Komitet jest punktem kontaktu dla regulatora w sprawach AI Act.

KNF będzie audytować, czy Komitet ds. AI posiada audytowalne dowody swoich decyzji (evidentiary trail). W tym celu, Komitet wymaga automated regulatory artefact generation pipeline, który CAUSA engine dostarcza, automatycznie dokumentując zgodność Artykułu 10.

Metodologia testowania stronniczości bez naruszenia RODO Artykuł 9

Artykuł 10(4) AI Act narzuca paradoksalny wymóg: banki muszą testować systemy scoringowe pod kątem stronniczości (bias testing), w tym stronniczości opartej na szczególnych kategoriach danych, takich jak rasa lub pochodzenie etniczne. Jednak RODO Artykuł 9 generalnie zabrania przetwarzania tych danych wrażliwych.

Ten paradoks stwarza krytyczne ryzyko compliance. Jeśli bank przetwarza Art. 9 PII do testowania AI Act, ryzykuje karę RODO do **20 mln euro** lub **4%** całkowitego rocznego światowego obrotu. Jeśli bank *nie przetwarza* Art. 9 PII do testowania, ryzykuje karę AI Act do **35 mln euro** lub **7%** całkowitego rocznego światowego obrotu za naruszenie danych Data Governance dla systemów wysokiego ryzyka w myśl Artykułu 99(2) EU AI Act.

Infundum rozwiązuje ten dylemat. CAUSA engine nie przetwarza produkcyjnych wrażliwych cech RODO Art. 9. Zamiast tego, kauzalny silnik CAUSA (Causal AI banking infrastructure) modeluje fundamentalne zależności przyczynowo-skutkowe governing data (structurally realistic banking data). CAUSA generuje Structurally realistic proxy dla wrażliwych atrybutów wewnątrz syntetycznego zestawu danych (regulatory-grade synthetic data). Pozwala to na rygorystyczne testowanie stronniczości bez narażania danych produkcyjnych, spełniając najtrudniejsze wymogi regulacyjne DORA vs AI Act paradox.

Konkretne case study: walidacja modelu scoringu detalicznego dla banku średniej wielkości

Wyobraźmy sobie mid-tier polski bank z portfelem 1 miliona klientów detalicznych i zróżnicowanym portfelem 50 połączonych tabel. Bank wdraża nowy, oparty na XGBoost model scoringu detalicznego zakupiony od zewnętrznego dostawcy.

CAIO banku, przed wdrożeniem, musi udowodnić KNF Artykuł 11 Technical File, w tym rygorystyczne bias testing. CAIO wykorzystuje CAUSA engine. CAUSA engine uczy się kauzalnej struktury z produkcyjnego Oracle. Następnie generuje 10 milionów syntetycznych rekordów (regulatory-grade synthetic data) dla całego schematu 50 tabel, w tym Structurally realistic proxy dla cech RODO Art. 9 (rasa, pochodzenie etniczne) wygenerowane *bezpośrednio* na podstawie kauzalnych wzorców produkcyjnych (structurally realistic banking data). Dostawca modelu scoringowego wgrywa swój model XGBoost do środowiska UAT wypełnionego przez CAUSA.

Model Risk Management przeprowadza rygorystyczne bias testing na tych danych, potwierdzając, że model nie posiada stronniczości. Cały ten proces, Lineage Danych dla syntetycznych wrażliwych proxy, raporty wierności danych (fidelity reports) i certyfikaty Differential Privacy są auto-generowane przez rurociąg generowania artefaktów regulacyjnych CAUSA engine i włączane do Artykuł 11 Technical File. Bank w grudniu 2027 r. submituje ten audytowalny Technical File do KNF, spełniając wszystkie wymagania regulatora.

CAUSA AI Data Engine: inżynieryjne rozwiązanie dla Technical File

Infundum's CAUSA AI Data Engine jest jedyną audytowalną drogą dla CDO do gotowości na grudzień 2027 r. w zakresie Artykułu 11 AI Act. CAUSA engine, wdrożony w modelu self-hosted wewnątrz infrastruktury banku, zapewnia inżynieryjne rozwiązanie problemu Data Governance dla systemów wysokiego ryzyka.

CAUSA engine to:

• **Kauzalna wierność wielotabelowa:** Produkująca structurally realistic bazy danych syntetycznych klasy regulacyjnej dla 100+ tabelcore banking, co jest niezbędne do rygorystycznej walidacji Artykułu 10 zgodności.
• **Zarządzanie paradoksem RODO/AI Act:** Generowanie matematycznie bezpiecznych, ale operacyjnie wiernych syntetycznych proxy cech wrażliwych w myśl RODO Art. 9 dla bias testing.
• **Zautomatyzowane Artefakty Regulacyjne:** Auto-generowanie technicznych plików audit trails, certyfikatów wierności i Differential Privacy, niezbędnych dla KNF-ready documentation context.

• **Data Engineering Governance dla AI:** Dostarczanie audytowalnego Lineage Danych dla synthetic data, co jest kluczowe dla audytowalności Artykułu 11.

Bez produkcyjnej infrastruktury syntetyzacji bankowej (production-grade synthetic banking infrastructure), takiej jak CAUSA, banki nie mogą audytowalnie wygenerować Technical File w trybie ciągłym. Użycie konwencjonalnych metod generowania danych testowych lub naiwnych makiet (Statistical Generation context, legacy synthetic data) doprowadzi do odrzucenia dokumentacji przez audytorów KNF.

Wewnętrzne podlinkowanie i kontekst regulacyjny

Dla głębszej analizy wymogów DORA w zakresie zabezpieczenia rurociągów testowych, zobacz nasz towarzyszący artykuł o DORA Artykuł 26 TLPT: dane testowe dla polskich banków. Zrozumienie, jak automatyzujemy dokumentację audytową niezbędną dla BCBS 239 i RODO, jest kluczowe także dla BCBS 239..

AI Act, MDR, i DORA stanowią spójny unijny Digital Omnibus framework. DORA wszedł w życie **17 stycznia 2025 r.**, a pełna zgodność jest wymagana do **stycznia 2028 r.** dla TLPT. Banki nie mogą audytowalnie wygenerować Technical File dla high-risk AI, bez rygorystycznych danych testowych, pozycjonując Infundum jako krytyczną produkcyjną infrastrukturę syntetyzacji bankowej (production-grade synthetic banking infrastructure) dla polskich banków SIs.

Wniosek

AI Act w Artykule 11 nakłada na polskie banki niemożliwy wymóg: wygenerowanie audytowalnego Technical File dla high-risk AI w trybie ciągłym. Odroczenie Digital Omnibus na grudzień 2027 r. to nie jest sygnał do czekania. Banki znaczące, nadzorowane bezpośrednio przez ECB, ryzykują kary AI Act do **35 mln euro** lub **7%** obrotu za naruszenie danych Data Governance dla systemów wysokiego ryzyka. CAIO banku, który używa maskowanych danych lub naiwnych makiet dla Data Governance systemów high-risk, marnuje zasoby i unieważnia audyt Technical File. Jedyną audytowalną drogą jest wdrożenie produkcyjnej infrastruktury syntetyzacji danych, takiej jak CAUSA, która jako jedyna potrafi rygorystycznie reproduce kauzalne dependencies i wrażliwe Art. 9 proxy niezbędne do walidacji Artykułu 10, zachowując 100% szczelność danych osobowych audytowalną przez regulatora.