Obowiązki DORA dla dostawców AI obsługujących podmioty finansowe

Obowiązki DORA dla dostawców AI to wymogi regulacyjne wynikające z rozporządzenia (UE) 2022/2554 (Digital Operational Resilience Act), które za pośrednictwem zlecających podmiotów finansowych przechodzą w umowach na dostawców AI. Kto dostarcza systemy AI bankom, ubezpieczycielom lub dostawcom usług płatniczych, jest traktowany jako zewnętrzny dostawca usług ICT i musi spełnić minimalne wymogi umowne, zapewnić prawa audytu i dostępu, uczestniczyć w raportowaniu incydentów oraz przestrzegać zasad dotyczących wyjścia i podwykonawstwa. DORA stosuje się od 17 stycznia 2025 r.

• Nie bezpośrednio, ale w pełnym zakresie: DORA nie reguluje dostawców AI wprost, ale zmusza podmioty finansowe do przeniesienia na nich w umowach wszystkich wymogów.
• AI to ICT: systemy AI są sieciami i systemami informatycznymi w rozumieniu art. 3 pkt 2 DORA, przez co zastosowanie ma pełny katalog obowiązków. BaFin wyraźnie wyjaśnił to w swoich wytycznych z 18 grudnia 2025 r.
• Dźwignią jest umowa: bez klauzul zgodnych z DORA (art. 30) dostawcy AI w przetargach BFSI w Niemczech i Austrii zazwyczaj nie docierają do finałowej rundy wyboru.

Dlaczego DORA dotyczy dostawców AI

Formalnie rozporządzenie DORA jest skierowane do nadzorowanych podmiotów finansowych. Art. 2 ust. 1 lit. a–t DORA wymienia 20 rodzajów podmiotów finansowych, w tym instytucje kredytowe, instytucje płatnicze i instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów, zakłady ubezpieczeń oraz instytucje pracowniczych programów emerytalnych. Dostawcy AI nie są regulowani bezpośrednio, lecz są objęci przepisami jako zewnętrzni dostawcy usług ICT. Mechanizm jest pośredni, ale skuteczny: podmioty finansowe mają obowiązek przekazać wymogi DORA w umowach swoim dostawcom. Kto więc sprzedaje regulowanej instytucji algorytm wykrywania nadużyć, asystenta pracowników opartego na RAG albo model underwritingowy, dziedziczy obowiązki poprzez umowę.

Systemy AI są ICT w rozumieniu DORA. W swoich wytycznych dotyczących ryzyk ICT związanych z wykorzystaniem AI w podmiotach finansowych z 18 grudnia 2025 r. BaFin traktuje system AI jako sieć i system informatyczny w rozumieniu art. 3 pkt 2 DORA. Obowiązki wynikają z samego DORA, a nie z wytycznych. Jak zaznaczono w samych wytycznych, są one niewiążącą pomocą, a nie wiążącą wykładnią DORA dokonaną przez BaFin, pokazują jednak, w jaki sposób BaFin przenosi wymogi DORA na systemy AI. Dla systemów AI obowiązuje pełny katalog obowiązków DORA:

• Art. 5-15: zarządzanie ryzykiem związanym z ICT
• Art. 17-23: zarządzanie incydentami związanymi z ICT, ich klasyfikacja i zgłaszanie
• Art. 24-27: testy odporności, w tym Threat-Led Penetration Testing (TLPT)
• Art. 28-30: zarządzanie ryzykiem ze strony zewnętrznych dostawców usług ICT

W Szwajcarii funkcjonalnie porównywalną rolę pełni komunikat nadzorczy FINMA 08/2024 z 18 grudnia 2024 r., który nie jest jednak w pełni zbieżny z linią BaFin. W Austrii, według stanu analizy, na której opiera się ten artykuł (maj 2026 r.), nie istnieją formalne sektorowe wytyczne FMA dotyczące AI; austriackie instytucje w praktyce opierają się na BaFin i EBA.

Pięć grup obowiązków w szczegółach

Dla dostawców AI DORA konkretyzuje się przede wszystkim w reżimie dotyczącym podmiotów zewnętrznych (art. 28-30) oraz w katalogu klauzul umownych z art. 30. Poniższa tabela przekłada kluczowe wymogi na ich znaczenie dla dostawców AI.

Minimalne postanowienia umowne i prawa audytu

Katalog klauzul umownych z art. 30 stanowi praktyczny rdzeń. Wymaga obowiązkowych praw audytu, klauzul wyjścia, kontroli podwykonawców oraz umów o poziomie usług ze zobowiązaniami dotyczącymi rezydencji danych, opóźnień i mocy obliczeniowej. Dla dostawców AI oznacza to konkretnie, że architektura od początku musi być zbudowana tak, aby każdą inferencję można było rejestrować w sposób nienaruszalny i audytowalny. Podczas nadzorczych kontroli doraźnych organ nadzoru oczekuje, że wewnętrznie odpowiedzialna osoba będzie w stanie odtworzyć wynik AI i wskazać czynniki, które go determinują. W praktyce wyklucza to czyste modele typu black box w rolach bliskich podejmowaniu decyzji.

Raportowanie incydentów

W kontekście BFSI błędy specyficzne dla AI traktuje się jako ryzyka operacyjne i mogą one podlegać obowiązkowi zgłoszenia. Skalę dobrze pokazują liczby: w pierwszych trzech kwartałach 2025 r. samemu BaFin zgłoszono łącznie 525 poważnych incydentów związanych z ICT, z czego około 70 procent pochodziło od instytucji kredytowych. Dostawcy AI rzadko sami podlegają obowiązkowi zgłoszenia, muszą jednak umownie i technicznie zapewnić, aby podmiot finansowy na czas otrzymał niezbędne informacje.

Strategie wyjścia i podwykonawstwo

W przypadku usług ICT wspierających funkcje krytyczne lub istotne plany wyjścia należy zgodnie z art. 28 ust. 8 DORA odpowiednio testować i regularnie weryfikować; w połączeniu z wyznaczeniem CTPP w praktyce wymusza to strategie multicloud. Dla dostawców AI oznacza to konieczność wykazania przenoszalności danych, udokumentowanych procesów przekazania i odwracalności. W przypadku podwykonawstwa cały łańcuch musi być ujawniony i kontrolowalny, co ma znaczenie zwłaszcza wtedy, gdy dostawca AI sam kupuje od podmiotów trzecich inferencję modeli bazowych, bazy danych wektorowych lub moc obliczeniową GPU.

Ryzyko koncentracji i 19 CTPP

18 listopada 2025 r. Europejskie Urzędy Nadzoru, czyli ESA (EBA, EIOPA, ESMA), po raz pierwszy wyznaczyły 19 kluczowych zewnętrznych dostawców usług ICT (CTPP), w tym AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix i Bloomberg (lista ESA). Tych 19 dostawców podlega od 2026 r. bezpośredniemu nadzorowi UE. Nadzór nad każdym CTPP sprawuje wiodący organ nadzorczy (Lead Overseer), czyli EBA, EIOPA lub ESMA. Oversight Forum przewidziane w art. 32 DORA przygotowuje wspólne stanowiska i ocenia wyniki, ale samo nie kontroluje dostawców. Zalecenia Lead Overseera nie są wiążące. CTPP musi jednak w ciągu 60 dni kalendarzowych poinformować, czy się do nich zastosuje, albo uzasadnić, dlaczego tego nie zrobi (art. 42 DORA). Dla dostawców AI, których obciążenia działają u jednego z tych dostawców, oznacza to dodatkową obserwację i zaostrzone ryzyko koncentracji po stronie zleceniodawcy. W 2025 r. BSI opublikował ponadto katalog kryteriów oceny systemów AI w sektorze finansowym (Test Criteria Catalogue for AI Systems in Finance). Ocenia on systemy AI m.in. pod kątem solidności, sprawiedliwości, przejrzystości, jakości danych i bezpieczeństwa IT, a przy tym sprawdza się jako schemat oceny dostawców.

Ważne dla kontekstu: wytyczne EBA dotyczące outsourcingu (EBA/GL/2019/02) i wytyczne ESMA dotyczące outsourcingu (ESMA50-164-4285) nadal obowiązują, jednak art. 28-30 DORA istotnie je zmodyfikowały. DORA nie jest więc jedynym, ale decydującym reżimem dotyczącym podmiotów zewnętrznych.

Przykład z praktyki: agent wiedzy AI w przetargu (RFP) średniego banku

Dostawca AI oferuje średniej wielkości niemieckiej instytucji (o sumie bilansowej rzędu kilkunastu miliardów) asystenta pracowników opartego na RAG do wewnętrznego wyszukiwania informacji. W postępowaniu przetargowym nie zawodzi model, lecz umowa. Typowe blokery i sposoby ich usunięcia:

```text
Etap RFP (wymogi DORA) Status startupu Wymagane (art. 30 / 28)
_________________________________ _________________ _________________________________
Prawa audytu/dostępu dla BaFin brak zagwarantować w umowie
Nienaruszalny log inferencji częściowo prompt + źródło + wersja modelu
Klauzula wyjścia + eksport danych brak regularnie testowalna, odwracalna
Przejrzystość podwykonawców niejasna ujawnić łańcuch + prawo kontroli
Rezydencja danych (UE/suwerenna) hyperscaler z USA opcja chmury UE/suwerennej
AIC4 / ISO 42001 / 27001 / SOC 2 tylko ISO 27001 uzupełnić atestacje
```

Dopiero gdy dostawca zagwarantuje w umowie rezydencję danych w UE, pełne logowanie inferencji i uporządkowany proces wyjścia, dociera do rundy finałowej. Dostawcy AI bez BSI AIC4, ISO 42001, SOC 2 lub ISO 27001 w 2026 r. zazwyczaj nie przechodzą do ostatecznego wyboru w przetargach BFSI w regionie DACH (Niemcy, Austria, Szwajcaria). Preferowane są chmury suwerenne (np. STACKIT, Open Telekom Cloud, IONOS Sovereign Cloud w Niemczech; Swisscom, Exoscale, Infomaniak w Szwajcarii) lub wspólne rozwiązania on-premise.

Uwaga: ten artykuł służy orientacji merytorycznej i nie stanowi porady prawnej. Konkretny zakres obowiązków wynikających z DORA, odniesienia do artykułów i terminy należy w każdym przypadku zweryfikować z wykwalifikowanymi działami prawnymi i compliance; źródła regulacyjne w latach 2025/2026 wciąż się zmieniają.

Dla agencji i dostawców B2B

Kto tworzy produkty AI lub treści dla sektora finansowego, powinien od początku traktować zgodność z DORA jako warunek architektury i strategii go-to-market, a nie jako kwestię prawną na samym końcu. Z doświadczenia wynika, że warstwa compliance w regulowanych branżach regionu DACH odpowiada za 30 do 50 procent nakładu pracy wdrożeniowej, więcej niż w branżach horyzontalnych. Dla agencji marketingowych i technologicznych to podwójny sygnał: po pierwsze, decydenci w bankach i firmach ubezpieczeniowych szukają treści, które precyzyjnie i rzetelnie wyjaśniają wymogi DORA dla dostawców AI. Po drugie, o przyjęciu lub odrzuceniu oferty w RFP decydują wykazana zdolność do audytu, rezydencja danych i testowalna ścieżka wyjścia. Blck Alpaca pomaga Ci tak zaplanować i komunikować projekty AI dla regulowanych zleceniodawców, aby przeszły przez bariery zakupowe sektora finansowego.