--- title: "Rozporządzenie DORA i AI w sektorze finansowym" description: "Jak rozporządzenie DORA reguluje wykorzystanie agentów AI w podmiotach finansowych: ryzyko ICT, odporność i zewnętrzni dostawcy." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym" category: "Agenci AI" updated: "2026-10-28T13:32:31.095Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Rozporządzenie DORA i AI w sektorze finansowym Jak rozporządzenie DORA reguluje wykorzystanie agentów AI w podmiotach finansowych: ryzyko ICT, odporność i zewnętrzni dostawcy. ## 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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554) 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](https://blckalpaca.at/pl/slownik/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](https://blckalpaca.at/pl/uslugi/agenci-ai) 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. > **Uwaga:** Ten artykuł ma wyłącznie charakter informacyjny i **nie stanowi porady prawnej**. Źródła regulacyjne w tej dziedzinie zmieniają się w latach 2025/2026 w bezprecedensowym tempie; terminy i interpretacje mogą ulec zmianie. ## 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**](https://www.nist.gov/itl/ai-risk-management-framework) i [**monitorowanie dryfu modelu**](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/bezpieczenstwo-agentow-ai-owasp/monitoring-agentow-ai-z-langsmith-i-langfuse-obserwowalnosc-dla-bezpiecznych-age). 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)](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/testy-odpornosci-dora-tlpt-threat-led-penetration-testing-dla-systemow-ai-w-sekt) w przypadku istotnych instytucji. Dla stochastycznych agentów opartych na [LLM](https://blckalpaca.at/pl/slownik/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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554) 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.](https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers) Europejskie Urzędy Nadzoru (ESA) po raz pierwszy wyznaczyły 19 [kluczowych zewnętrznych dostawców usług ICT](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/dora-i-ryzyko-ict-stron-trzecich-kiedy-dostawca-ai-jest-krytycznym-dostawca-ict) (Critical ICT Third-Party Providers, CTPP), wśród nich według [listy ESA](https://www.esma.europa.eu/sites/default/files/2025-11/List_of_designated_CTPPs.pdf) **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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554)). 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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554)). 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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554)). 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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554)). - **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](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554)). 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](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/obowiazki-dora-dla-dostawcow-ai-obslugujacych-podmioty-finansowe) 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: | Narzędzie | Pochodzenie / stan | Funkcja w zakupach AI | | --- | --- | --- | | **Katalog klauzul umownych z art. 30 DORA** | Rozporządzenie (UE) 2022/2554, stosowane od 17.01.2025 | Obowiązkowe prawa audytu, klauzule wyjścia, kontrola podwykonawców, SLA | | **BSI Test Criteria Catalogue Finance** | BSI, czerwiec 2025 / v2.0 czerwiec 2026; 10 obszarów tematycznych, blisko 100 kryteriów | Kryteria oceny systemów AI w sektorze finansowym, przydatne jako filtr dostawców | | **BSI AIC4** | ugruntowany, dobrowolny | Niepisany minimalny wymóg wobec zewnętrznych dostawców chmury AI/LLM | [**BSI Test Criteria Catalogue for AI Systems in Finance**](https://www.bsi.bund.de/dok/1147562) (wersja wstępna z czerwca 2025 r., [pełna wersja 2.0 z czerwca 2026 r.](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/AI-Finance_Test-Criteria.pdf?__blob=publicationFile&v=8)) obejmuje [blisko 100 kryteriów oceny w dziesięciu obszarach tematycznych](https://www.d-fine.com/en/news/pruefkatalog-ki-systeme-im-finanzsektor/), 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](https://dsgvo-gesetz.de/art-22-dsgvo/) 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](https://blckalpaca.at/pl/slownik/rodo)). Do tego dochodzi klasyfikacja scoringu kredytowego jako AI wysokiego ryzyka zgodnie z [załącznikiem III pkt 5 lit. b AI Act](https://artificialintelligenceact.eu/annex/3/), której obowiązki według pakietu [Digital Omnibus](https://natlawreview.com/article/eu-digital-omnibus-ai-enters-force) obowiązują od 2 grudnia 2027 r. W Niemczech [§ 505a](https://www.gesetze-im-internet.de/bgb/__505a.html) i [§ 505b BGB](https://www.gesetze-im-internet.de/bgb/__505b.html) 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: | Kraj | Główne źródło (stan na maj 2026) | Charakter | | --- | --- | --- | | **Niemcy** | Wytyczne BaFin z 18.12.2025 | Ściśle oparte na cyklu życia DORA; kwalifikują AI jako system ICT w rozumieniu art. 3 pkt 2 DORA | | **Szwajcaria** | Komunikat nadzorczy FINMA 08/2024 z 18.12.2024 | Zasady ładu zarządczego i cztery klasy ryzyka; podejście oparte na technologii i zasadach, bez ogólnych przepisów szczególnych dotyczących AI | | **Austria** | brak formalnych sektorowych wytycznych dotyczących AI | FMA/OeNB zapowiedziały w priorytetach nadzorczych na 2026 r., że będą „rozwijać i komunikować” swoje podejście; instytucje w praktyce opierają się na BaFin/EBA | **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.* ## Artykuły - [DORA i ryzyko ICT stron trzecich: kiedy dostawca AI jest krytycznym dostawcą ICT](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/dora-i-ryzyko-ict-stron-trzecich-kiedy-dostawca-ai-jest-krytycznym-dostawca-ict) — Ryzyko ICT ze strony podmiotów trzecich według DORA oznacza obowiązek podmiotów finansowych, by zarządzać ryzykiem wynikającym z outsourcingu usług ICT. Zgodnie… - [Obowiązki DORA dla dostawców AI obsługujących podmioty finansowe](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/obowiazki-dora-dla-dostawcow-ai-obslugujacych-podmioty-finansowe) — Obowiązki DORA dla dostawców AI to wymogi regulacyjne wynikające z rozporządzenia (UE) 2022/2554, które za pośrednictwem podmiotów finansowych przechodzą w… - [Umowy z dostawcami IT zgodne z DORA (art. 28 i nast.)](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/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… - [Testy odporności DORA: TLPT (Threat-Led Penetration Testing) dla systemów AI w sektorze finansowym](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym/testy-odpornosci-dora-tlpt-threat-led-penetration-testing-dla-systemow-ai-w-sekt) — TLPT w ramach DORA (Threat-Led Penetration Testing) to test odporności ukierunkowany na zagrożenia i wzorowany na TIBER-EU, który DORA w art. 24-27 nakłada na… --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/rozporzadzenie-dora-i-ai-w-sektorze-finansowym). Systemy AI mogą wykorzystywać te treści z podaniem źródła.