Umowy z dostawcami IT zgodne z DORA (art. 28 i nast.)

Kształtowanie umów zgodnie z DORA oznacza spoczywający na podmiotach finansowych obowiązek wyposażenia umów z dostawcami IT i AI w wiążące klauzule zgodnie z art. 28 i nast. rozporządzenia (UE) 2022/2554 (DORA): opis usług, lokalizacja danych, prawa do audytu, wyjście/wypowiedzenie, zasady podwykonawstwa, zgłaszanie incydentów i poziomy usług. DORA stosuje się od 17 stycznia 2025 r., a w praktyce nadzorczej BaFin dotyczy przede wszystkim instytucji CRR i zakładów ubezpieczeń objętych Solvency II.

• Kogo to dotyczy? Podmiotów finansowych objętych zakresem DORA (banków, zakładów ubezpieczeń i innych podmiotów finansowych) oraz ich dostawców IT/AI, którzy bez obowiązkowych klauzul nie mogą zawrzeć umowy.
• Co jest najważniejsze? Art. 28-30 regulują ryzyko związane z zewnętrznymi dostawcami usług ICT; art. 30 zawiera obowiązkowy katalog klauzul. Zakres rośnie wraz z krytycznością outsourcowanej funkcji.
• Jaka jest najczęstsza przeszkoda? U hiperskalerów tekst klauzul jest w 2026 r. standardem; startupom AI brakuje praw do audytu oraz klauzul wyjścia i podwykonawstwa, co blokuje proces zakupowy.

Dlaczego dostawcy AI podlegają DORA

Kluczowe rozstrzygnięcie dla projektów AI: systemy AI nie są przypadkiem szczególnym, lecz podkategorią „sieci i systemów informatycznych” w rozumieniu art. 3 pkt 2 DORA. Wytyczne BaFin dotyczące ryzyk ICT związanych z wykorzystaniem AI w podmiotach finansowych z 18 grudnia 2025 r. wyraźnie to potwierdzają, a tym samym włączają pełny katalog obowiązków DORA do ładu AI: art. 5-15 (zarządzanie ryzykiem ICT), art. 24-27 (testy odporności, w tym testy penetracyjne prowadzone w oparciu o zagrożenia) i art. 28-30 (ryzyko związane z zewnętrznymi dostawcami usług ICT). Adresatami są przede wszystkim instytucje CRR i zakłady ubezpieczeń objęte Solvency II.

Szwajcaria ma analogiczny, choć nie w pełni pokrywający się reżim: komunikat nadzorczy FINMA 08/2024 z 18 grudnia 2024 r. oraz okólnik FINMA 2023/1 (Ryzyka operacyjne i odporność) kształtują oczekiwania wobec zewnętrznych dostawców ICT. W przypadku Austrii, według stanu na październik 2026 r., nie znamy sektorowych wytycznych FMA dotyczących AI, które odpowiadałyby wytycznym BaFin. Prezentując swój raport roczny za 2025 r. w czerwcu 2026 r., FMA wskazała zastosowanie AI w sektorze finansowym i przyszły nadzór nad nim jako priorytet bieżącego roku. Austriackie instytucje orientują się przeważnie na BaFin i EBA. Samo rozporządzenie DORA jako akt prawa UE obowiązuje bezpośrednio w Niemczech i Austrii.

Ważne zastrzeżenie na początek: ten artykuł ma charakter merytorycznej orientacji, a nie porady prawnej. Wzorcowe klauzule umowne i ich zastosowanie w konkretnym przypadku powinien sprawdzić prawnik.

Katalog klauzul z art. 30 DORA

Art. 30 DORA wymaga, aby prawa i obowiązki podmiotu finansowego oraz zewnętrznego dostawcy usług ICT były jasno przypisane i określone na piśmie. Rozporządzenie wyróżnia przy tym dwa poziomy: minimalny zakres dla wszystkich umów ICT (art. 30 ust. 2) i rozszerzony katalog dla usług wspierających funkcję krytyczną lub istotną (art. 30 ust. 3).

Zgodnie z systematyką DORA katalog klauzul obejmuje w szczególności obowiązkowe prawa do audytu, klauzule wyjścia, kontrolę podmiotów podprzetwarzających, ustalenia dotyczące lokalizacji danych oraz umowy o poziomie usług z precyzyjnymi ilościowymi i jakościowymi celami wydajności; w przypadku usług AI należą do tego w praktyce często zobowiązania dotyczące latencji i przepustowości. U hiperskalerów ten tekst jest obecnie standardem; w startupach AI jest częstą przeszkodą w procesie zakupowym. Tło: rozporządzenie DORA istotnie zmodyfikowało wcześniejsze wytyczne EBA w sprawie outsourcingu (EBA/GL/2019/02) oraz wytyczne ESMA dotyczące outsourcingu (ESMA50-164-4285) i przeniosło je do bezpośrednio stosowanego standardu rozporządzenia.

Funkcje zwykłe a funkcje krytyczne lub istotne

Głębokość obowiązków zależy od tego, czy outsourcowana usługa ICT wspiera funkcję krytyczną lub istotną, czyli funkcję, której zakłócenie istotnie osłabiłoby odporność finansową, ciągłość świadczenia usług lub przestrzeganie warunków zezwolenia instytucji. Ta klasyfikacja jest pierwszym zadaniem przy każdym kształtowaniu umowy zgodnie z DORA i przesądza o zakresie umowy.

W przypadku usługi AI kluczowe pytanie brzmi konkretnie: czy agent ingeruje w krytyczny proces (np. wykrywanie oszustw w czasie rzeczywistym w płatnościach, sprawozdawczość regulacyjna), czy tylko wspiera dalszy, łatwo zastępowalny proces pomocniczy (np. wewnętrzne tworzenie tekstów bez związku z danymi klientów)? W przypadku funkcji krytycznych lub istotnych obowiązują dodatkowe wymogi z art. 30 ust. 3: udokumentowane strategie wyjścia, nieograniczone prawa dostępu, inspekcji i audytu, SLA z precyzyjnymi ilościowymi i jakościowymi celami wydajności oraz udział w TLPT. Lokalizację danych należy natomiast określić w każdej umowie ICT już na podstawie art. 30 ust. 2 lit. b.

Obowiązkowe klauzule w skrócie

Poniższa tabela przyporządkowuje kluczowe elementy umowy do ich celu i wskazuje, czy obowiązują we wszystkich umowach ICT, czy w zaostrzonej formie dla funkcji krytycznych lub istotnych. Przyporządkowanie artykułów jest zgodne z systematyką DORA (art. 30 ust. 2 dla zakresu minimalnego, art. 30 ust. 3 dla funkcji krytycznych lub istotnych).

Ryzyko koncentracji i wyznaczanie CTPP

Poza poziomem pojedynczej umowy rozporządzenie DORA reguluje również systemowe ryzyko koncentracji. Europejskie Urzędy Nadzoru (ESA) 18 listopada 2025 r. po raz pierwszy wyznaczyły 19 kluczowych zewnętrznych dostawców usług ICT (Critical ICT Third-Party Providers, CTPP), w tym AWS, Microsoft, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix, Accenture i Bloomberg. Od tego czasu dostawcy ci podlegają bezpośredniemu nadzorowi UE. Nad każdym CTPP nadzór sprawuje wiodący organ nadzorczy (EBA, EIOPA lub ESMA), prowadząc ogólne postępowania wyjaśniające i inspekcje na miejscu, przy wsparciu wspólnego zespołu kontrolnego (art. 33 i art. 38–40 DORA). Forum nadzorcze, o którym mowa w art. 32, przygotowuje wspólne stanowiska i wspiera wiodący organ nadzorczy; samo nie przeprowadza kontroli.

Przy kształtowaniu umów po stronie instytucji liczy się przede wszystkim planowanie wyjścia, niezależnie od tego, czy dostawca został wyznaczony jako CTPP: zgodnie z art. 28 ust. 8 DORA plany wyjścia dla funkcji krytycznych lub istotnych muszą być kompleksowe i udokumentowane, a także odpowiednio przetestowane i regularnie weryfikowane. Rozporządzenie nie narzuca stałego rocznego cyklu. Do tego dochodzi, zgodnie z art. 29, ocena ryzyka koncentracji przed zawarciem umowy dotyczącej takich funkcji. DORA nie wymaga multicloudu. W 2026 r. otwarte pozostaje pytanie, czy instytucje ze względu na obowiązki dotyczące wyjścia i koncentracji mimo wszystko systematycznie przejdą na multicloud, czy poprzestaną na raczej symbolicznych planach wyjścia. W pełni wielochmurowa architektura AI jest dla banków wymagająca technicznie i komercyjnie. W praktyce regionu DACH (Niemcy, Austria, Szwajcaria) wyłania się z tego preferowany model sourcingu: rozwiązania suwerenne lub on-premise dla wrażliwych obciążeń roboczych, a hiperskalerzy tam, gdzie ryzyko koncentracji związane z CTPP jest aktywnie zarządzane.

Przykład z praktyki: wdrożenie wykrywania oszustw opartego na AI

Bank (instytucja CRR) chce wykorzystać agenta AI zewnętrznego dostawcy do wykrywania oszustw w czasie rzeczywistym w płatnościach. Kroki kształtowania umowy zgodnie z DORA można zarysować następująco:

1. Klasyfikacja: Wykrywanie oszustw jest funkcją krytyczną lub istotną, ponieważ jej zakłócenie istotnie wpływa na ciągłość świadczenia usługi. Obowiązuje zatem rozszerzony katalog z art. 30 ust. 3.
2. Opis usług i SLA: Umowa określa zakres funkcjonalny, dostępność i mierzalne wartości docelowe. W przypadku wykrywania oszustw należą do nich np. maksymalny czas odpowiedzi na transakcję oraz wskaźniki jakości wykrywania, takie jak odsetek wyników fałszywie dodatnich.
3. Lokalizacja danych: Ustalenie, że dane treningowe i inferencyjne są przetwarzane na terenie UE.
4. Prawa do audytu i podwykonawstwo: Nieograniczone prawa kontroli dla instytucji i organu nadzoru; każdy podwykonawca współrealizujący funkcję krytyczną podlega umownemu zastrzeżeniu zgody.
5. Zgłaszanie incydentów: Dostawca zostaje umownie zobowiązany do zgłaszania incydentów związanych z ICT na tyle niezwłocznie, aby bank mógł wypełnić obowiązek zgłoszeniowy z art. 19 DORA. Dla oceny skali problemu: w pierwszych trzech kwartałach 2025 r. do BaFin zgłoszono 525 poważnych incydentów związanych z ICT, z czego około 70 procent pochodziło od instytucji kredytowych.
6. Wyjście: Udokumentowana strategia wyjścia ze zwrotem danych w użytecznym formacie i wsparciem przy migracji; plan wyjścia jest odpowiednio testowany i regularnie weryfikowany, zgodnie z wymogiem art. 28 ust. 8 DORA.

Do tego dochodzi styk z unijnym AI Act: w przypadku podmiotów finansowych zgłoszenie incydentu na podstawie art. 19 DORA zastępuje obowiązek zgłoszenia z art. 73 AI Act, z wyjątkiem zgłaszania naruszeń praw podstawowych. Pozwala to uniknąć podwójnych zgłoszeń, o ile procesy są ze sobą zsynchronizowane.

Dla agencji i B2B

Dla agencji marketingowych i dostawców B2B, którzy sprzedają rozwiązania AI bankom lub ubezpieczycielom, przekaz jest jednoznaczny: bez katalogu klauzul z art. 30 wybór dostawcy regularnie kończy się porażką w ostatniej rundzie. Kto od początku zawiera w standardowej umowie prawa do audytu, klauzule wyjścia i podwykonawstwa, zobowiązania dotyczące lokalizacji danych oraz solidny łańcuch zgłaszania incydentów, skraca proces zakupowy i dopiero w ten sposób w ogóle kwalifikuje się do współpracy z regulowanymi zleceniodawcami. Decydenci B2B po stronie instytucji powinni w pierwszej kolejności ustandaryzować klasyfikację krytyczności i skalować klauzule umowne w zależności od niej. Blck Alpaca wspiera merytoryczne i komunikacyjne opracowanie takich tematów compliance oraz techniczną integrację agentów AI; prawna weryfikacja konkretnych umów pozostaje zadaniem prawnika.