DORA i ryzyko ICT stron trzecich: kiedy dostawca AI jest krytycznym dostawcą ICT

Ryzyko ICT ze strony podmiotów trzecich według DORA oznacza obowiązek podmiotów finansowych, by aktywnie zarządzać ryzykiem wynikającym z outsourcingu usług ICT. Zgodnie z rozporządzeniem (UE) 2022/2554 (DORA, stosowanym od 17 stycznia 2025 r.) dostawcy AI i LLM mogą zostać uznani za zewnętrznych dostawców usług ICT. Korzystający z nich podmiot finansowy musi wtedy zarządzać nimi zgodnie z art. 28–30: rejestr informacji, wymogi umowne, zarządzanie ryzykiem koncentracji. Jeśli Europejskie Urzędy Nadzoru (ESA: EBA, EIOPA, ESMA) uznają dostawcę za kluczowego, sam podlega on ramom nadzoru określonym w art. 31 i nast.

• Kogo to dotyczy? DORA dotyczy podmiotów finansowych (m.in. instytucji CRR i ubezpieczycieli objętych Solvency II), a nie bezpośrednio dostawców AI. Usługa AI jest objęta regulacją za pośrednictwem podmiotu finansowego.
• Dlaczego AI? Poradnik BaFin z 18 grudnia 2025 r. klasyfikuje systemy AI jako podkategorię „sieci i systemów informatycznych” w rozumieniu art. 3 pkt 2 DORA i tym samym przenosi pełny katalog obowiązków DORA na grunt AI governance.
• Najpierw obowiązek podstawowy: każda usługa ICT świadczona na podstawie umowy, także usługa LLM używana produkcyjnie, musi trafić do rejestru informacji udostępnianego organom nadzoru.

Dlaczego dostawcy AI/LLM stają się dostawcami usług ICT

DORA nie reguluje AI jako technologii, lecz cyfrową odporność operacyjną podmiotów finansowych. Kluczową dźwignią jest szeroka definicja usług ICT oraz sieci i systemów informatycznych. Gdy tylko podmiot finansowy zaczyna produkcyjnie korzystać z usługi AI, na przykład z hostowanego modelu językowego, API do scoringu fraudowego lub asystenta dokumentów działającego w chmurze, usługa ta staje się częścią jego ryzyka ICT ze strony podmiotów trzecich.

Poradnik BaFin dotyczący ryzyk ICT przy wykorzystaniu AI w podmiotach finansowych z 18 grudnia 2025 r. wprost wskazuje ten związek w niemieckiej praktyce nadzorczej: systemy AI są podkategorią „sieci i systemów informatycznych” w rozumieniu art. 3 pkt 2 DORA. W rezultacie do obciążeń roboczych opartych na AI stosuje się obowiązki DORA dotyczące zarządzania ryzykiem związanym z ICT (art. 5–15), testów odporności, w tym testów penetracyjnych prowadzonych w oparciu o analizę zagrożeń (art. 24–27), oraz ryzyka ICT ze strony podmiotów trzecich (art. 28–30). Według własnej deklaracji poradnik jest niewiążącą pomocą i nie określa oczekiwań nadzorczych. Ma pomóc podmiotom finansowym wdrożyć wymogi DORA przy wykorzystaniu AI. Jest skierowany przede wszystkim do instytucji CRR i ubezpieczycieli objętych Solvency II.

Praktyczna konsekwencja: dostawca AI nie podlega DORA „automatycznie”. Usługa jest objęta regulacją za pośrednictwem korzystającego z niej podmiotu finansowego, który musi zarządzać swoim dostawcą, związać go umową i dokumentować współpracę tak, aby wymogi DORA dało się spełnić.

Rejestr informacji (Register of Information)

Centralnym narzędziem zarządzania ryzykiem ICT ze strony podmiotów trzecich jest rejestr informacji. Podmioty finansowe muszą prowadzić pełny wykaz wszystkich ustaleń umownych dotyczących usług ICT i udostępniać go właściwym organom nadzoru. Rejestr ten określa, jaką funkcję wspiera dana usługa, czy wspiera funkcję krytyczną lub istotną, kto jest dostawcą i jacy podwykonawcy są zaangażowani.

Dla AI oznacza to, że usługa LLM lub ML używana produkcyjnie nie jest „narzędziem z budżetu marketingowego”, lecz usługą ICT podlegającą wpisowi do rejestru, gdy tylko stanowi outsourcing na podstawie umowy. Rejestr jest zarazem bazą danych, na podstawie której ESA rozpoznają, którzy dostawcy są w sektorze tak rozpowszechnieni, że należy ich uznać za kluczowych.

Kluczowi zewnętrzni dostawcy usług ICT (CTPP) i ramy nadzoru

DORA ustanawia odrębne ramy nadzoru (Oversight Framework) dla kluczowych zewnętrznych dostawców usług ICT (Critical ICT Third-Party Providers, CTPP). Są one określone w art. 31 i nast., a więc oddzielone od katalogu obowiązków podmiotów finansowych z art. 28–30. 18 listopada 2025 r. ESA po raz pierwszy wyznaczyły 19 CTPP, w tym AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix i Bloomberg (lista ESA).

Po wyznaczeniu dostawcy ci podlegają bezpośredniemu nadzorowi na szczeblu UE. Dla każdego CTPP jeden z trzech urzędów ESA (EBA, EIOPA lub ESMA) pełni funkcję wiodącego organu nadzorczego, czyli Lead Overseer (art. 31 ust. 1 lit. b). Wspiera go wspólny zespół ds. badania (Joint Examination Team, art. 40), a sam organ może wydawać zalecenia (art. 35). Zalecenia te nie są prawnie wiążące. Dostawca musi jednak w ciągu 60 dni kalendarzowych poinformować, czy się do nich zastosuje, lub uzasadnić, dlaczego tego nie zrobi. Jeśli odpowiedź nie nadejdzie lub uzasadnienie okaże się niewystarczające, wiodący organ nadzorczy podaje to do publicznej wiadomości. W ostateczności krajowe organy nadzoru mogą zobowiązać podmioty finansowe do zawieszenia korzystania z usługi (art. 42).

Ważne dla dyskusji o AI: większość produkcyjnych obciążeń roboczych AI/LLM działa dziś u wyznaczonych hiperskalerów, takich jak AWS, Microsoft Azure czy Google Cloud. Nawet jeśli startup AI sam nie jest (jeszcze) wyznaczony jako CTPP, pod względem technicznym często działa na infrastrukturze wyznaczonego dostawcy. Nadzór nad hiperskalerem, na którym opiera się usługa, nie zmienia jednak własnej odpowiedzialności podmiotu finansowego za outsourcing, zdolność do wyjścia i ryzyko koncentracji.

Kiedy dostawca jest uznawany za kluczowego

ESA wyznaczają dostawców według czterech kryteriów z art. 31 ust. 2 DORA: systemowy wpływ awarii na dużą skalę na usługi finansowe, znaczenie systemowe zależnych podmiotów finansowych (np. globalne instytucje o znaczeniu systemowym i inne instytucje o znaczeniu systemowym, G-SII i O-SII), zależność funkcji krytycznych lub istotnych od dostawcy oraz zastępowalność. Rozporządzenie delegowane (UE) 2024/1502 przekształca to w procedurę dwuetapową. W etapie 1 dostawca musi osiągnąć wszystkie progi ilościowe. Jeden z nich: wspiera funkcje krytyczne lub istotne w co najmniej 10% podmiotów finansowych danej kategorii, a podmioty te łącznie posiadają co najmniej 10% aktywów tej kategorii. Jakościowej ocenie w etapie 2 podlega tylko ten, kto osiągnie wszystkie progi. Źródłem danych są rejestry informacji podmiotów finansowych.

Na pierwszej liście nie ma żadnego dostawcy, którego podstawową działalnością są modele AI, takiego jak OpenAI, Anthropic czy Mistral. Nasza ocena: dostawcy skupieni wyłącznie na AI i LLM rzadko osiągają obecnie te progi, ponieważ ich usługi wspierają jeszcze niewiele funkcji krytycznych lub istotnych w bankach i u ubezpieczycieli, a często są nabywane za pośrednictwem platform hiperskalerów. Dostawca, którego nie ma na liście, może na podstawie art. 31 ust. 11 sam złożyć wniosek o wyznaczenie go jako kluczowego. Nie wyznacza się wewnątrzgrupowych dostawców usług ICT ani dostawców działających tylko w jednym państwie członkowskim na rzecz podmiotów finansowych prowadzących działalność wyłącznie w tym państwie (art. 31 ust. 8).

Ryzyko koncentracji i strategia wyjścia

Ryzyko koncentracji jest w kontekście AI szczególnie wyraźne. Jeśli niemal każdy bank w UE w zakresie obciążeń roboczych AI polega na jednym z nielicznych wyznaczonych hiperskalerów lub na centralnych rozwiązaniach zrzeszeniowych, powstaje systemowe skupienie ryzyka. Dlatego DORA wymaga, aby podmioty finansowe aktywnie zarządzały swoją zależnością. Przed zawarciem umowy o usługi ICT wspierające funkcje krytyczne lub istotne sprawdzają, czy dostawcę trudno zastąpić lub czy umowy z tym samym dostawcą się kumulują (art. 29). Dla takich usług potrzebują strategii wyjścia. Plany wyjścia muszą być kompleksowe i udokumentowane, a także odpowiednio przetestowane i regularnie weryfikowane (art. 28 ust. 8). DORA nie określa tu stałej częstotliwości, w przeciwieństwie do planów ciągłości działania w zakresie ICT, które należy testować co najmniej raz w roku (art. 11 ust. 6).

W praktyce systematyczna architektura AI typu multi-cloud pozostaje w 2026 roku wymagająca pod względem technicznym i komercyjnym. Dlatego między planem wyjścia na papierze a faktycznie wykonalną zmianą dostawcy często zieje przepaść.

Wymogi dotyczące outsourcingu i umów (art. 30)

Art. 30 DORA określa obowiązkowy katalog klauzul umownych dla usług ICT. Tym samym w odniesieniu do tych usług art. 28–30 DORA mają pierwszeństwo przed wytycznymi EBA w sprawie outsourcingu (EBA/GL/2019/02) i odpowiednimi wytycznymi ESMA. Kluczowe elementy klauzul:

• Opis usług z warunkami powierzania zadań podwykonawcom (podprocesorom) (ust. 2 lit. a)
• Miejsca świadczenia usług i przetwarzania danych, w tym lokalizacja przechowywania danych, oraz uprzednie informowanie o planowanych zmianach (ust. 2 lit. b)
• Opisy poziomu usług (ust. 2 lit. e), a w przypadku funkcji krytycznych lub istotnych z precyzyjnymi ilościowymi i jakościowymi celami w zakresie wyników (ust. 3 lit. a)
• Prawa do wypowiedzenia umowy (ust. 2 lit. h), a w przypadku funkcji krytycznych lub istotnych dodatkowo strategie wyjścia z obowiązkowym okresem przejściowym (ust. 3 lit. f)
• W przypadku funkcji krytycznych lub istotnych nieograniczone prawa dostępu, kontroli i audytu dla podmiotów finansowych i organu nadzoru (ust. 3 lit. e)

DORA nie wymaga wprost zobowiązań dotyczących latencji ani mocy obliczeniowej. To, czy ich potrzebujesz, wynika z celów w zakresie wyników danej funkcji.

Naszym zdaniem u hiperskalerów te klauzule są w dużej mierze standardowym tekstem, natomiast u startupów AI często blokują proces zakupowy. W przypadku dostawców AI bez solidnych praw audytu, bez przejrzystości co do podprocesorów i bez udokumentowanych miejsc przetwarzania proces wyboru w podmiotach finansowych w UE często kończy się przed rundą finałową.

Przegląd: obowiązek, kogo dotyczy, podstawa prawna

Przykład z praktyki: asystent LLM w banku regionalnym

Średniej wielkości bank wdraża wewnętrznego asystenta wiedzy opartego na LLM, który działa przez API dostawcy AI, a ten z kolei hostuje swoją usługę w Microsoft Azure. Kroki istotne z punktu widzenia DORA:

1. Klasyfikacja: czy asystent wspiera funkcję krytyczną lub istotną? Jeśli tak, wymogi się zaostrzają.
2. Rejestracja: umowa i usługa trafiają do rejestru informacji, łącznie z podwykonawcą Azure (wyznaczonym CTPP).
3. Zabezpieczenie umowne (art. 30): prawa audytu, strategia wyjścia z okresem przejściowym, warunki dla podwykonawców, określone miejsca świadczenia usług i przetwarzania danych (bank wybiera tu UE) oraz SLA z ilościowymi celami w zakresie wyników.
4. Ocena ryzyka koncentracji: czy funkcja krytyczna opiera się na jednym hiperskalerze? Udokumentować plan wyjścia i regularnie go testować.
5. Proces obsługi incydentów: poważne incydenty związane z ICT dotyczące tej usługi, np. cytaty z przepisów będące halucynacjami modelu, stanowiące istotne zdarzenie ryzyka operacyjnego, podlegają zgłoszeniu zgodnie z DORA.

Pseudokod logiki governance:

```
jeśli usługa_AI.jest_outsourcingiem_umownym:
Rejestr.wpisz(usługa_AI, podprocesorzy=[Hiperskaler])
jeśli usługa_AI.wspiera_funkcję_krytyczną:
Umowa.sprawdź(klauzule_Art30) # audyt, wyjście, SLA, podprocesorzy
PlanWyjścia.testuj(interwał="regularnie")
RyzykoKoncentracji.oceń(dostawca, funkcja)
Incydent.aktywuj_ścieżkę_zgłoszenia(waga="poważny")
```

Odwołania do artykułów dotyczą tekstu rozporządzenia DORA, a informacje o statusie CTPP odnoszą się do listy ESA z 18 listopada 2025 r. Ten artykuł nie stanowi porady prawnej; to, czy i w jaki sposób DORA ma zastosowanie do konkretnej usługi AI, wymaga indywidualnej analizy przeprowadzonej przez wyspecjalizowanych doradców prawnych i regulacyjnych.

Dla agencji i decydentów B2B

Dla agencji marketingowych i usługodawców, którzy dostarczają funkcje AI bankom, ubezpieczycielom lub innym podmiotom finansowym, DORA jest twardym kryterium sprzedażowym, a nie dodatkiem. Jeśli chcesz sprzedawać rozwiązania oparte na LLM w regulowanym sektorze finansowym, od początku uwzględnij możliwość audytu, przejrzystość co do podprocesorów, rezydencję danych w UE i solidną ścieżkę wyjścia. W przeciwnym razie projekt polegnie nie na jakości modelu, lecz na procesie zakupowym. Blck Alpaca wspiera Cię w projektowaniu przepływów pracy AI zgodnych z DORA i w osadzaniu ich w procesach outsourcingu i zarządzania dostawcami, aby Twoja inicjatywa AI w sektorze finansowym w ogóle dotarła do finałowej rundy wyboru. Indywidualną analizę prawną uzyskasz dodatkowo u wyspecjalizowanego doradcy.