Rozporządzenie DORA i AI w sektorze finansowym

Czym jest DORA i dlaczego dotyczy AI w sektorze finansowym?

Akt o operacyjnej odporności cyfrowej (Digital Operational Resilience Act, w skrócie DORA), formalnie rozporządzenie (UE) 2022/2554, jest bezpośrednio stosowany od 17 stycznia 2025 r. i po raz pierwszy tworzy jednolite w całej UE ramy operacyjnej odporności cyfrowej sektora finansowego. Zgodnie z art. 2 DORA rozporządzenie obejmuje 20 kategorii podmiotów finansowych: od instytucji kredytowych i zakładów ubezpieczeń, przez firmy inwestycyjne i instytucje płatnicze, po dostawców usług w zakresie kryptoaktywów. DORA łączy pięć filarów, które wcześniej były rozproszone w różnych wymogach nadzorczych: zarządzanie ryzykiem związanym z ICT (art. 5-16), zgłaszanie poważnych incydentów związanych z ICT (art. 17-23), testowanie operacyjnej odporności cyfrowej, w tym testy penetracyjne prowadzone w oparciu o analizę zagrożeń (TLPT, art. 24-27), zarządzanie ryzykiem związanym z zewnętrznymi dostawcami usług ICT wraz z nadzorem nad kluczowymi dostawcami (art. 28-44) oraz wymianę informacji (art. 45). Wymiana informacji jest dobrowolna. W przypadku systemów AI liczą się przede wszystkim pierwsze cztery filary.

Decydujące znaczenie dla AI mają wytyczne BaFin dotyczące ryzyk ICT przy wykorzystaniu AI w podmiotach finansowych z 18 grudnia 2025 r., które wprost kwalifikują systemy AI jako szczególny przypadek „sieci i systemów informatycznych” w rozumieniu art. 3 pkt 2 DORA. W efekcie pełny katalog obowiązków DORA obejmuje także obciążenia robocze AI i agentów AI: od pozyskiwania danych, przez rozwój modelu i wdrożenie, po bieżące działanie z monitorowaniem dryfu i wycofanie z użycia. Kto wdraża produkcyjnie agenta AI w banku lub zakładzie ubezpieczeń, buduje więc regulowany system ICT ze wszystkimi obowiązkami dotyczącymi odporności, testów i dostawców zewnętrznych.

Cztery obowiązkowe filary DORA w kontekście agentów AI

Zarządzanie ryzykiem związanym z ICT (art. 5-16). Systemy AI muszą zostać włączone do zarządzania ryzykiem ICT w całej instytucji. Wytyczne BaFin formułują podejście oparte na cyklu życia jako oczekiwanie nadzorcze: pozyskiwanie danych → rozwój modelu → wdrożenie → bieżące działanie z monitorowaniem dryfu → wycofanie z użycia. Wprost oczekiwane są trening adwersarialny i monitorowanie dryfu modelu. Wytyczne są formalnie niewiążące, ale w praktyce nadzorczej faktycznie odwracają ciężar dowodu: instytucja, która ich nie stosuje, musi podczas kontroli BaFin udokumentować równoważność alternatywnych środków.

Testy odporności (art. 24-27). Systemy oparte na AI podlegają obowiązkowi regularnego testowania operacyjnej odporności cyfrowej, aż po testy penetracyjne prowadzone w oparciu o analizę zagrożeń (TLPT) w przypadku istotnych instytucji. Dla stochastycznych agentów opartych na LLM to metodologiczne wyzwanie, ponieważ klasyczne procedury testowe są projektowane dla systemów deterministycznych.

Zgłaszanie incydentów (art. 17-23). Specyficzne dla dostawców ryzyka AI, takie jak halucynowane cytaty z przepisów, halucynowane dane portfeli klientów czy dryf modelu w produkcyjnych systemach scoringowych, są w kontekście BFSI uznawane za istotne ryzyka operacyjne. Zgłoszeniu podlegają jednak tylko wtedy, gdy jako incydent związany z ICT spełniają kryteria z art. 18 DORA i tym samym są uznawane za poważne (art. 19 DORA). Skala jest znacząca: w pierwszych trzech kwartałach 2025 r. do BaFin zgłoszono 525 poważnych incydentów związanych z ICT, z czego ok. 70% pochodziło od instytucji kredytowych.

Ryzyko związane z zewnętrznymi dostawcami usług ICT (art. 28-44). W przypadku AI to najmocniejsza dźwignia i temat kolejnej sekcji.

Ryzyko związane z zewnętrznymi dostawcami ICT i wyznaczanie CTPP

AI w sektorze finansowym działa dziś niemal zawsze na infrastrukturze zewnętrznej: w chmurach hyperscalerów, u zewnętrznych dostawców modeli i LLM albo w centrach danych zrzeszeń bankowych. Właśnie tu wkracza DORA: art. 28-30 regulują, jak podmioty finansowe zarządzają ryzykiem związanym z zewnętrznymi dostawcami usług ICT, a art. 31-44 bezpośredni nadzór nad kluczowymi dostawcami. 18 listopada 2025 r. Europejskie Urzędy Nadzoru (ESA) po raz pierwszy wyznaczyły 19 kluczowych zewnętrznych dostawców usług ICT (Critical ICT Third-Party Providers, CTPP), wśród nich według listy ESA AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix i Bloomberg. Dla każdego z tych dostawców jeden z trzech organów pełni rolę wiodącą (wiodący organ nadzorczy, Lead Overseer: EBA, EIOPA lub ESMA). Może on żądać informacji, prowadzić dochodzenia i inspekcje oraz wydawać zalecenia (art. 35 DORA). Zalecenia te nie są wiążące: dostawca musi w ciągu 60 dni kalendarzowych poinformować, czy zamierza się do nich zastosować, albo uzasadnić, dlaczego tego nie zrobi (art. 42 ust. 1 DORA). Jeśli nie odpowie w terminie lub wiodący organ nadzorczy uzna uzasadnienie za niewystarczające, organ ten podaje to do publicznej wiadomości (art. 42 ust. 2 DORA). W ostateczności właściwe organy mogą zobowiązać podmioty finansowe do czasowego zawieszenia korzystania z usługi, a w razie potrzeby do wypowiedzenia umowy (art. 42 ust. 6 DORA).

Dla banków i zakładów ubezpieczeń występujących w roli podmiotu stosującego ma to konkretne konsekwencje:

• Plany wyjścia dla funkcji krytycznych lub istotnych trzeba odpowiednio testować i regularnie weryfikować, a nie tylko dokumentować (art. 28 ust. 8 DORA).
• Ryzyko koncentracji należy ocenić przed zawarciem umowy (art. 29 DORA, dla funkcji krytycznych lub istotnych); dlatego rośnie znaczenie architektur multi-cloud i architektur umożliwiających wyjście.
• Obciążenia robocze agentów AI u hyperscalerów pozostają pod dodatkową obserwacją nadzorczą.

Ryzyko koncentracji jest szczególnie widoczne w regionie DACH (Niemcy, Austria, Szwajcaria): w przypadku obciążeń AI niemal każdy bank jest zależny albo od jednego z wyznaczonych hyperscalerów, albo od rozwiązań swojego zrzeszenia. W Niemczech Finanz Informatik (FI) dla kas oszczędnościowych (Sparkassen) i Atruvia AG dla Volksbanken i Raiffeisenbanken celowo utrzymują własne, suwerenne stacki AI działające on-premise (m.in. modele open source, takie jak Mixtral/Llama, we własnych centrach danych). S-KIPilot FI został w 2025 r. wdrożony w wersji 6 na ok. 60 000 stanowisk pracy w Sparkassen. Logika CTPP w DORA systemowo wzmacnia te modele zrzeszeniowe, dopóki wyznaczenie CTPP i wytyczne BaFin zachowują obecną ostrość.

Art. 30 DORA: katalog klauzul umownych jako filtr zakupowy

Art. 30 DORA określa obowiązkowe elementy umów z zewnętrznymi dostawcami usług ICT, przez co wybór dostawców AI staje się twardą bramką compliance. Obowiązkowe są m.in. prawa audytu, klauzule wyjścia, kontrola podwykonawców, opisy usług z ilościowymi i jakościowymi celami w zakresie wyników oraz wskazanie miejsc, w których przetwarzane są dane (art. 30 ust. 2 lit. b, ust. 3 lit. a DORA). Art. 30 ust. 3 wymaga praw audytu, strategii wyjścia i precyzyjnych celów w zakresie wyników w przypadku usług ICT wspierających funkcje krytyczne lub istotne. U uznanych hyperscalerów klauzule te są dziś częścią standardowych umów; u młodych startupów AI często blokują proces zakupowy.

Art. 30 DORA nie jest przy tym jedynym punktem odniesienia. W przetargach na AI organizowanych przez banki i ubezpieczycieli dochodzą kolejne kryteria oceny:

BSI Test Criteria Catalogue for AI Systems in Finance (wersja wstępna z czerwca 2025 r., pełna wersja 2.0 z czerwca 2026 r.) obejmuje blisko 100 kryteriów oceny w dziesięciu obszarach tematycznych, w tym bezpieczeństwo i solidność, przejrzystość, sprawiedliwość, jakość danych i ład zarządczy. Z doświadczenia wynika, że poświadczenia zgodności z BSI AIC4, ISO 42001, SOC 2 lub ISO 27001 zwiększają szanse dostawców AI w przetargach BFSI.

Obowiązki DORA dla agentów AI w bankach i zakładach ubezpieczeń

W przypadku agentów AI w sektorze finansowym trzeba uwzględnić sześć obszarów ryzyka specyficznych dla tego sektora, wykraczających poza DORA; w horyzontalnym compliance AI pojawiają się one tylko na marginesie:

1. Zarządzanie ryzykiem modeli. Od nowelizacji z lat 2023/2024 MaRisk AT 4.3.5 wprost obejmuje także modele AI/ML i wymaga dokumentacji cyklu życia, niezależnej walidacji, backtestingu i okresowego przeglądu. Wytyczne BaFin oczekują dodatkowo dokumentacji treningu adwersarialnego i monitorowania dryfu modelu.
2. Wyjaśnialność decyzji kredytowych. Zgodnie z art. 22 RODO decyzje kredytowe wywołujące skutki prawne mogą być podejmowane wyłącznie w sposób zautomatyzowany tylko wyjątkowo; osoby, których dane dotyczą, mają wtedy prawo do interwencji człowieka, do wyrażenia własnego stanowiska i do zakwestionowania decyzji (art. 22 ust. 3 RODO). Do tego dochodzi klasyfikacja scoringu kredytowego jako AI wysokiego ryzyka zgodnie z załącznikiem III pkt 5 lit. b AI Act, której obowiązki według pakietu Digital Omnibus obowiązują od 2 grudnia 2027 r. W Niemczech § 505a i § 505b BGB wymagają ponadto oceny zdolności kredytowej przed udzieleniem kredytu konsumenckiego. Łącznie RODO i AI Act prowadzą do tego, że właściwa osoba musi umieć wskazać czynniki decydujące. Scoring kredytowy end-to-end oparty na LLM jest więc praktycznie wykluczony; AI pozostaje w rolach triażu i wyjaśniania.
3. Kompletność ścieżki audytu. Na potrzeby nadzorczych kontroli specjalnych (kontrola specjalna BaFin, kontrola na miejscu FINMA, inspekcja OeNB) każde wywołanie inferencji musi być rejestrowane w sposób niezmienialny i audytowalny, wraz z promptem, kontekstem, źródłami użytymi w retrievalu, wersją modelu i wynikiem.
4. Wymagania dotyczące opóźnień. Compliance w tradingu wymaga <10 ms, wykrywanie oszustw <1 s. Umieszczenie agentów LLM w hot path rzadko jest wykonalne.
5. Rezydencja danych. W Niemczech i Austrii nadzorcy coraz mocniej akcentują przechowywanie danych treningowych i inferencyjnych AI w UE lub w danym kraju; w Szwajcarii tajemnica bankowa (art. 47 BankG) w praktyce wymusza przechowywanie danych klientów w Szwajcarii.
6. Ryzyko koncentracji wynikające z wyznaczenia CTPP (zob. wyżej).

W rezultacie w 2026 r. w pełni autonomiczne decyzje kredytowe i w pełni autonomiczne wieloagentowe przepływy pracy w tradingu nie działają produkcyjnie. Standardem są natomiast agenci obsługi klienta pierwszej linii (Tier 1), wykrywanie oszustw, triaż AML/KYC i raportowanie regulacyjne, zawsze z udziałem człowieka (human-in-the-loop) tam, gdzie decyzje wywołują skutki prawne.

Kontekst DACH: trzy ścieżki zamiast jednej linii

W Niemczech i Austrii DORA obowiązuje bezpośrednio jako część dorobku prawnego UE; Szwajcaria przejmuje te regulacje autonomicznie, sektor po sektorze. Prowadzi to do zgodności w trzech ścieżkach, którą muszą uwzględniać instytucje działające w całym regionie DACH:

Ankieta FINMA z kwietnia 2025 r. przeprowadzona wśród ok. 400 instytucji pokazuje poziom adopcji: około 50% szwajcarskich banków i ubezpieczycieli już korzysta z AI lub rozwija aplikacje, a kolejne 25% planuje wdrożenie w ciągu trzech lat; średnio ok. 5 aplikacji działa produkcyjnie, a ok. 9 jest w fazie rozwoju. 91% instytucji korzystających z AI stosuje generatywną AI. Komunikat nadzorczy FINMA wyprzedził wytyczne BaFin dokładnie o dwanaście miesięcy, ale nie pokrywa się z nimi w pełni: FINMA wymaga np. centralnych rejestrów AI z klasyfikacją ryzyka oraz rozwiązań awaryjnych.

Austriacka luka regulacyjna jest ambiwalentna: daje swobodę działania, ale zwiększa niepewność podczas kontroli na miejscu, ponieważ oczekiwania nie są skodyfikowane ex ante. W 2024 r. przy RTR-GmbH utworzono centralny punkt obsługi ds. AI, który ma doradzać, a nie sprawować nadzór sektorowy.

Perspektywy i wskazówki praktyczne

Regulacyjne punkty odniesienia wciąż się przesuwają: warto obserwować kolejne wersje wytycznych BaFin i ich interpretację podczas kontroli specjalnych, ewentualne doprecyzowania FINMA wykraczające poza komunikat 08/2024 oraz oczekiwane formalne wytyczne dotyczące AI od austriackiej FMA. Otwarte pozostaje też pytanie, czy pierwsze zalecenia wiodących organów nadzorczych dla CTPP rzeczywiście skłonią instytucje z regionu DACH do prawdziwego multi-cloudu, czy skończy się na symbolicznych planach wyjścia.

W praktyce: jeśli w 2026 r. wdrażasz produkcyjnie AI w sektorze finansowym, traktuj wytyczne BaFin jako normę wewnętrzną (także tam, gdzie FMA nie ma jeszcze własnych wytycznych), wprowadź do codziennej praktyki kanał zgłaszania incydentów DORA i TLPT, używaj BSI Test Criteria Catalogue Finance jako filtra dostawców i od początku myśl o AI jako o systemie ICT z pełnym zarządzaniem cyklem życia. Z doświadczenia wynika, że w regulowanych branżach regionu DACH compliance odpowiada za 30-50% nakładu pracy przy wdrożeniu, co jest jednocześnie ryzykiem i przewagą konkurencyjną.

Wyłącznie w celach informacyjnych, nie stanowi porady prawnej. Stan źródeł: maj 2026 r., niektóre dane zaktualizowano w październiku 2026 r.; tymczasowe terminy i zapowiedziane wytyczne należy traktować jako zmienne.