Nie jestem prawnikiem. Nie udzielam porady prawnej. Ten tekst jest próbą uporządkowania, jak DORA i AI Act wyglądają z perspektywy osoby, która projektuje i wdraża produkty AI w bankowości — i rozmawia o tym z zarządami, compliance, IT i audytem. Pełna interpretacja wymaga zawsze konsultacji z własnym działem prawnym i, w razie potrzeby, z KNF.
Jednocześnie widzę, że wiele zespołów AI w polskich bankach pracuje bez jasnego obrazu tego, co regulacja wymaga. Prawnicy znają regulację; inżynierowie znają technologię; zarządy znają cele biznesowe. Przepływ między tymi trzema warstwami jest zwykle słaby. Ten tekst jest próbą zmniejszenia tej luki.
DORA: co faktycznie wymaga od banków w kontekście AI
DORA nie jest regulacją o AI. Jest regulacją o odporności operacyjnej ICT w sektorze finansowym. Ale ponieważ większość systemów AI w bankowości jest systemami ICT istotnymi dla działalności banku — DORA ich dotyczy w pełni.
Z perspektywy projektu AI DORA wymaga pięciu rzeczy.
Zarządzanie ryzykiem ICT — identyfikacja, klasyfikacja, monitoring, ograniczanie ryzyk. System AI musi mieć przypisaną klasyfikację ryzyka (krytyczny, istotny, inny), odpowiednie procedury zarządzania, zestaw metryk monitorowanych w czasie rzeczywistym.
Zarządzanie incydentami — procedury wykrywania, klasyfikacji i raportowania incydentów ICT. Dla systemu AI incydentem jest nie tylko awaria — jest nim też istotne pogorszenie jakości modelu, zachowanie nieprzewidziane, manipulacja danymi wejściowymi. Procedury muszą to uwzględniać.
Testowanie odporności — regularne testy, w tym dla systemów krytycznych testy pod kątem scenariuszy skrajnych (TLPT — threat-led penetration testing). AI wprowadza nowe kategorie testów: testy na odporność na adversarial attacks, testy driftu modelu, testy spójności decyzji.
Zarządzanie relacjami z dostawcami zewnętrznymi — zagadnienie szczególnie ważne dla AI. Każdy dostawca modelu, infrastruktury, danych używanych w systemie AI podlega ramom zarządzania dostawcami ICT. Umowy muszą zawierać określone elementy (prawo audytu, exit strategy, service levels, ciągłość), a krytyczni dostawcy podlegają dodatkowym wymaganiom.
Information sharing — obowiązek wymiany informacji o cyberzagrożeniach, w tym relevantnych dla AI (nowe typy ataków na modele, odkryte podatności).
AI Act: klasyfikacja systemów w bankowości
AI Act wprowadza piramidę ryzyka z czterema poziomami. W bankowości rozkład wygląda następująco.
Niedopuszczalne ryzyko (zakazane). Systemy manipulacji kognitywnej, social scoring rządowy, określone kategorie identyfikacji biometrycznej w czasie rzeczywistym. W bankowości europejskiej praktycznie nie występują; zakaz obowiązuje od lutego 2025.
Wysokie ryzyko. To kategoria, która realnie decyduje. W bankowości pod nią podpadają systemy oceny zdolności kredytowej klientów indywidualnych (credit scoring), systemy scoringu ubezpieczeniowego (zdrowotnego i życiowego), systemy wykorzystywane w rekrutacji, systemy biometryczne do zdalnej identyfikacji. Pełne wymagania obowiązują od sierpnia 2026.
Ograniczone ryzyko. Chatboty, systemy generujące treści, systemy rozpoznawania emocji (z wyjątkami). Wymagane głównie obowiązki transparentności — klient musi wiedzieć, że rozmawia z AI; treści wygenerowane muszą być oznaczone.
Minimalne ryzyko. Większość pozostałych zastosowań AI w bankowości — automatyzacja backoffice, fraud detection, analiza dokumentów wewnętrznych, asystenci pracowników. Bez szczególnych obowiązków wynikających z AI Act, ale oczywiście nadal podlegające innym regulacjom (GDPR, DORA, rekomendacje KNF).
Kluczowe dla praktyki: dla większości projektów AI w bankowości wysokiego ryzyka jest klasyfikacja dość jasna. Szary obszar dotyczy systemów pomocniczych w procesach kredytowych — np. agent AI, który analizuje dokumentację, ale nie podejmuje decyzji. Interpretacja, czy to jest system oceny zdolności kredytowej, czy narzędzie wspomagające, wymaga oceny prawnej.
Praktyczne wymagania dla systemów wysokiego ryzyka
Dla systemów klasyfikowanych jako wysokie ryzyko AI Act wprowadza rozbudowane wymagania. Z perspektywy wdrożenia wymagają one zbudowania w projekt kilku elementów od samego początku.
System zarządzania ryzykiem AI — proces identyfikacji i łagodzenia ryzyk specyficznych dla AI (bias, drift, niewłaściwe wykorzystanie, adversarial attacks). Dokumentowany, powtarzalny, aktualizowany w cyklu życia systemu.
Zarządzanie danymi — wymagania dotyczące jakości danych treningowych, walidacyjnych i testowych. Dane muszą być istotne, reprezentatywne, wolne od błędów w miarę możliwości, adekwatnie opisane. Dla bankowości szczególnie ważne: wykazanie, że zbiór treningowy jest reprezentatywny dla populacji, na której system będzie działał.
Dokumentacja techniczna — szczegółowa dokumentacja systemu, w tym: architektura, dane, proces trenowania, metryki, ograniczenia, środki łagodzące. Dokument obszerny, tworzony równolegle z rozwojem, nie po jego zakończeniu.
Automatyczne logowanie — system musi automatycznie rejestrować zdarzenia umożliwiające audyt działania i prześledzenie decyzji. Dla systemu scoringu kredytowego oznacza to: każda decyzja z podaniem cech wejściowych, użytego modelu, uzyskanego score'u, uzasadnienia.
Przejrzystość i dostarczanie informacji użytkownikom — użytkownicy systemu (w praktyce: pracownicy banku) muszą rozumieć, jak system działa, jakie są jego ograniczenia. Oznacza to zbudowanie procesu szkolenia, dokumentacji operacyjnej, procedur eskalacji.
Nadzór człowieka — systemy wysokiego ryzyka muszą umożliwić efektywny nadzór człowieka. Oznacza to nie tylko human-in-the-loop w decyzjach, ale też możliwość interwencji, zatrzymania systemu, override'u decyzji.
Dokładność, odporność, cyberbezpieczeństwo — wymagania techniczne dotyczące jakości systemu, odporności na adversarial attacks, zabezpieczeń cyberbezpieczeństwa.
Ocena zgodności — przed wprowadzeniem systemu do użytku wymagana jest formalna ocena zgodności z wymaganiami AI Act. Dla większości systemów AI bankowych możliwa przez wewnętrzną ocenę; dla niektórych kategorii (biometria) wymaga zewnętrznego certyfikatora.
Rejestracja w bazie EU — systemy wysokiego ryzyka muszą być zarejestrowane w unijnej bazie danych przed wprowadzeniem do użytku.
Modele zewnętrzne — co to oznacza dla banków
Większość polskich banków używa lub rozważa użycie modeli AI dostarczanych przez zewnętrznych dostawców — OpenAI, Anthropic, Google, Microsoft, mniejsi dostawcy specjalistyczni. To wprowadza dodatkowy layer regulacyjny.
DORA wymagania wobec dostawców ICT. Umowa z dostawcą modelu musi spełniać wymagania DORA artykuł 28 i następne — określone elementy kontraktowe, prawo audytu, warunki ciągłości, exit strategy. Standardowe komercyjne warunki ToS typu OpenAI Enterprise nie wystarczają — wymagana jest dedykowana umowa.
Critical Third-Party Providers. Najwięksi dostawcy modeli AI będą oznaczeni jako CTPP przez European Supervisory Authorities. Oznacza to dodatkowe wymagania — bank musi brać pod uwagę ryzyko zakłócenia dostawcy krytycznego, mieć plany awaryjne, dywersyfikację dostawców.
AI Act wymagania dla providerów modeli GPAI. Dostawcy dużych modeli językowych ogólnego przeznaczenia mają własne obowiązki pod AI Act — dokumentacja techniczna, polityki zgodności praw autorskich, ujawnienia trenowania. Dla banku oznacza to, że może żądać odpowiedniej dokumentacji od dostawcy.
GDPR i dane w promptach. Dane wprowadzane do modelu zewnętrznego to przetwarzanie danych osobowych. Wymaga odpowiedniej podstawy prawnej, umowy powierzenia, oceny, czy dostawca daje wystarczające gwarancje ochrony.
Ścieżka on-premise jako uproszczenie. Wiele polskich banków świadomie wybiera modele open-source deployowane w środowisku banku (on-premise lub private cloud) — bo eliminuje to większość obciążeń regulacyjnych związanych z dostawcą zewnętrznym. To racjonalna strategia, ale wymaga osobnej oceny (model źródłowy ma swoje wymagania licencyjne, musi być zakwalifikowany pod DORA).
Rekomendacje KNF i polska specyfika
Urząd Komisji Nadzoru Finansowego w Polsce nie wydał dedykowanej rekomendacji dotyczącej AI. Jednak kilka istniejących rekomendacji bezpośrednio dotyka obszaru wdrożeń AI.
Rekomendacja D (zarządzanie obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego) — fundament dla wszystkich wdrożeń ICT, w tym AI. Obejmuje zarządzanie zmianą, bezpieczeństwo, architektę systemową, zarządzanie dostępem.
Rekomendacja dotycząca korzystania z usług chmury obliczeniowej — istotna dla wdrożeń AI opartych na zewnętrznych platformach chmurowych. Wymaga określonych elementów w umowie z dostawcą chmury, lokalizacji danych, procedur zarządzania.
Wytyczne dotyczące outsourcingu — w kontekście AI szczególnie istotne, gdy bank korzysta z modelu zewnętrznego lub delegowania usług ICT.
Guidance EBA, ESMA, EIOPA — europejskie agencje nadzoru wydają wytyczne, które obowiązują w Polsce przez transpozycję. W 2026 szczególnie istotne są wytyczne EBA w zakresie DORA i interpretacji ich wymagań w sektorze bankowym.
Jak projektować AI pod zgodność od początku
Na koniec praktyka — jak budować projekty AI w banku tak, żeby zgodność nie była problemem na końcu.
Klasyfikacja w dzień pierwszy. Zanim zaczniemy pisać kod, prawnicy i zespół projektu ustalają: do której kategorii AI Act podpada system, jaka jest klasyfikacja DORA, jakie rekomendacje KNF są istotne. Ten dokument jest fundamentem, z którego wynikają wszystkie dalsze decyzje architektoniczne.
Compliance by design. Od początku projekt ma architekturę umożliwiającą spełnienie wymagań. Logowanie, audytowalność, explainability — nie dodane na końcu, tylko zaprojektowane na starcie. To oznacza wybór frameworków, formatów danych, wzorców architektonicznych, które wspierają wymagania.
Równoległa dokumentacja. Dokumentacja techniczna powstaje równolegle z rozwojem, nie po jego zakończeniu. To jedna z najczęściej zaniedbywanych rzeczy — a prace nad nią, dodane na końcu, często wydłużają projekt o miesiące.
Early engagement z compliance. Zespół compliance banku jest zaangażowany od fazy koncepcji, nie od fazy gotowego produktu. Compliance, które wchodzi na końcu, wymaga przeróbek. Compliance, które wchodzi od początku, kieruje decyzje w dobrą stronę.
Data governance jako fundament. Wszystkie wymagania DORA i AI Act wobec danych (jakość, reprezentatywność, governance) są realnie wymaganiami data governance banku. Projekt AI, który nie ma za sobą silnego data governance, będzie spędzał większość czasu na problemach z danymi.
Testowanie odpowiedniego typu. Testy pokrywają nie tylko funkcjonalność, ale też bias, drift, adversarial robustness, zgodność regulacyjną. To nowy zestaw kompetencji dla zespołów QA bankowych.
Cykl życia, nie projekt. System AI nie kończy się wdrożeniem. Monitoring, retraining, aktualizacje dokumentacji, rekalibracja — to część kosztu, która musi być zaplanowana z góry. Bank, który traktuje AI jak tradycyjny projekt IT (zbuduj, wdróż, utrzymuj), spotka się z nieprzyjemnymi niespodziankami w drugim i trzecim roku operacji.