DORA riziko tretích strán v oblasti IKT: Kedy sa poskytovatelia AI považujú za kritických poskytovateľov IKT služieb

Riziko tretích strán v oblasti IKT podľa DORA označuje povinnosť finančných subjektov aktívne riadiť riziká vyplývajúce z externe zabezpečovaných IKT služieb. Podľa nariadenia (EÚ) 2022/2554 (DORA, uplatňuje sa od 17. januára 2025) môžu byť poskytovatelia AI a LLM považovaní za externých poskytovateľov IKT služieb. Finančný subjekt, ktorý ich využíva, ich potom musí riadiť podľa článkov 28 až 30: register informácií, zmluvné požiadavky, riadenie koncentračného rizika. Ak európske orgány dohľadu (ESA: EBA, EIOPA, ESMA) zaradia poskytovateľa medzi kritických, podlieha sám rámcu dozoru podľa čl. 31 a nasl.

• Koho sa to týka? DORA sa zameriava na finančné subjekty (okrem iného inštitúcie podľa CRR, poisťovne podľa Solventnosti II), nie priamo na poskytovateľov AI. Na AI službu sa DORA vzťahuje prostredníctvom finančného subjektu.
• Prečo AI? Orientačná pomôcka BaFin z 18. decembra 2025 zaraďuje systémy AI ako podprípad „sieťových a informačných systémov“ podľa čl. 3 bodu 2 DORA, a tým vťahuje celý súbor povinností DORA do riadenia AI (AI governance).
• Najprv kľúčová povinnosť: Každá zmluvná IKT služba, aj LLM služba v produkčnej prevádzke, patrí do registra informácií, ktorý sa sprístupňuje orgánom dohľadu.

Prečo sa poskytovatelia AI/LLM stávajú poskytovateľmi IKT služieb

DORA nereguluje AI ako technológiu, ale digitálnu prevádzkovú odolnosť finančných subjektov. Rozhodujúcou pákou je široká definícia IKT služieb a sieťových a informačných systémov. Keď finančný subjekt nasadí do produkčnej prevádzky AI službu, napríklad hostovaný jazykový model, API na skórovanie podvodov alebo cloudového asistenta pre dokumenty, stáva sa táto služba súčasťou jeho rizika tretích strán v oblasti IKT.

Orientačná pomôcka BaFin k IKT rizikám pri nasadení AI vo finančných subjektoch z 18. decembra 2025 túto súvislosť v nemeckej praxi dohľadu výslovne pomenúva: systémy AI sú podprípadom „sieťových a informačných systémov“ podľa čl. 3 bodu 2 DORA. Na AI aplikácie (workloads) sa tým vzťahujú povinnosti DORA v oblasti riadenia IKT rizík (čl. 5 až 15), testovania odolnosti vrátane penetračného testovania na základe hrozieb (Threat-Led Penetration Testing, čl. 24 až 27) a rizika tretích strán v oblasti IKT (čl. 28 až 30). Orientačná pomôcka sa podľa vlastného vyjadrenia chápe ako nezáväzná pomoc a nestanovuje žiadne očakávania dohľadu. Má finančným subjektom pomôcť splniť požiadavky DORA pri nasadení AI. Adresátmi sú primárne inštitúcie podľa CRR a poisťovne podľa Solventnosti II.

Praktický dôsledok: poskytovateľ AI nepodlieha DORA „automaticky“. DORA sa na službu vzťahuje prostredníctvom finančného subjektu, ktorý ju využíva, a ten musí svojho poskytovateľa riadiť, zmluvne zaviazať a dokumentovať tak, aby sa požiadavky DORA dali splniť.

Register informácií (Register of Information)

Ústredným nástrojom riadenia rizika tretích strán v oblasti IKT je register informácií. Finančné subjekty musia viesť úplný zoznam všetkých zmluvných dojednaní o IKT službách a sprístupniť ho príslušným orgánom dohľadu. Register eviduje, akú funkciu služba podporuje, či ide o kritickú alebo dôležitú funkciu, kto je poskytovateľom a ktorí subdodávatelia sú zapojení.

Pre AI to znamená: LLM alebo ML služba v produkčnej prevádzke nie je „nástroj z marketingového rozpočtu“, ale IKT služba, ktorá patrí do registra, len čo zodpovedá zmluvnému outsourcingu. Register je zároveň dátovým základom, z ktorého ESA rozpoznávajú, ktorí poskytovatelia sú v sektore natoľko rozšírení, že ich treba zaradiť medzi kritických.

Kritickí externí poskytovatelia IKT služieb (CTPP) a rámec dozoru

DORA zriaďuje vlastný rámec dozoru (Oversight Framework) pre kritických externých poskytovateľov IKT služieb (Critical ICT Third-Party Providers, CTPP). Upravuje ho čl. 31 a nasl., a je teda oddelený od súboru povinností finančných subjektov v čl. 28 až 30. Dňa 18. novembra 2025 ESA po prvýkrát určili 19 CTPP, medzi nimi AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, Deutsche Telekom, Equinix a Bloomberg (zoznam ESA).

Po určení podliehajú títo poskytovatelia priamemu dohľadu na úrovni EÚ. Pre každého CTPP je podľa čl. 31 ods. 1 písm. b) príslušný jeden z troch ESA (EBA, EIOPA alebo ESMA) ako hlavný orgán dozoru (Lead Overseer). Pri práci mu pomáha spoločný prieskumný tím (Joint Examination Team, čl. 40). Hlavný orgán dozoru môže vydávať odporúčania (čl. 35). Tieto odporúčania nie sú právne záväzné. Poskytovateľ však musí do 60 kalendárnych dní oznámiť, či ich bude dodržiavať, alebo zdôvodniť, prečo nie. Ak odpoveď nepríde alebo zdôvodnenie nestačí, hlavný orgán dozoru to zverejní. Ako krajné opatrenie môžu vnútroštátne orgány dohľadu uložiť finančným subjektom povinnosť pozastaviť využívanie služby (čl. 42).

Dôležité pre diskusiu o AI: väčšina produkčných AI/LLM aplikácií dnes beží na určených hyperscaleroch, ako sú AWS, Microsoft Azure alebo Google Cloud. Aj keď AI startup sám (zatiaľ) nie je určený ako CTPP, technicky často stavia na určenom poskytovateľovi. Dohľad nad hyperscalerom pod ním však nič nemení na vlastnej zodpovednosti finančného subjektu za outsourcing, schopnosť exitu a koncentračné riziko.

Kedy sa poskytovateľ považuje za kritického

ESA určujú poskytovateľov podľa štyroch kritérií z čl. 31 ods. 2 DORA: systémový dosah rozsiahleho výpadku na poskytovanie finančných služieb, systémová významnosť závislých finančných subjektov (napríklad globálne systémovo významné a iné systémovo významné inštitúcie, G-SII a O-SII), závislosť kritických alebo dôležitých funkcií od poskytovateľa a nahraditeľnosť. Delegované nariadenie (EÚ) 2024/1502 z toho robí dvojstupňový postup. V stupni 1 musí poskytovateľ dosiahnuť všetky kvantitatívne prahy. Jeden z nich: podporuje kritické alebo dôležité funkcie najmenej 10 % finančných subjektov určitej kategórie a tie spolu držia najmenej 10 % aktív tejto kategórie. Kvalitatívne sa v stupni 2 posudzuje len ten, kto dosiahne všetky prahy. Dátovým základom sú registre informácií finančných subjektov.

Na prvom zozname nie je žiadny poskytovateľ, ktorého hlavnou činnosťou sú AI modely, napríklad OpenAI, Anthropic alebo Mistral. Naše hodnotenie: poskytovatelia zameraní výlučne na AI a LLM tieto prahy v súčasnosti dosahujú zriedka, pretože ich služby v bankách a poisťovniach zatiaľ podporujú málo kritických alebo dôležitých funkcií a často sa odoberajú cez platformy hyperscalerov. Poskytovateľ, ktorý na zozname nie je, môže podľa čl. 31 ods. 11 sám požiadať o určenie za kritického. Vnútroskupinoví poskytovatelia IKT služieb a poskytovatelia, ktorí pôsobia len v jednom členskom štáte pre finančné subjekty činné výlučne v tomto štáte, sa neurčujú (čl. 31 ods. 8).

Koncentračné riziko a exitová stratégia

Koncentračné riziko je v kontexte AI obzvlášť výrazné. Ak je takmer každá banka v EÚ pri AI aplikáciách odkázaná na jedného z mála určených hyperscalerov alebo na centrálne riešenia bankových združení, vzniká systémová koncentrácia rizika. DORA preto vyžaduje, aby finančné subjekty aktívne riadili svoju závislosť. Pred uzavretím zmluvy o IKT službách pre kritické alebo dôležité funkcie posudzujú, či je poskytovateľ ťažko nahraditeľný alebo či sa zmluvy hromadia u toho istého poskytovateľa (čl. 29). Pre takéto služby potrebujú exitové stratégie. Exitové plány musia byť komplexné a zdokumentované a musia sa dostatočne testovať a pravidelne preskúmavať (čl. 28 ods. 8). Pevný interval na to DORA nestanovuje, na rozdiel od plánov kontinuity činností v oblasti IKT, ktoré sa musia testovať najmenej raz ročne (čl. 11 ods. 6).

V praxi zostáva systematická multi-cloud AI architektúra v roku 2026 technicky aj komerčne náročná. Medzi exitovým plánom na papieri a skutočne uskutočniteľnou zmenou poskytovateľa preto často zíva medzera.

Požiadavky na outsourcing a zmluvy (čl. 30)

DORA čl. 30 stanovuje povinný súbor zmluvných ustanovení pre IKT služby. Pre tieto služby tak čl. 28 až 30 DORA majú prednosť pred usmerneniami EBA k outsourcingu (EBA/GL/2019/02) a príslušnými usmerneniami ESMA. Kľúčové prvky ustanovení:

• Opis služieb vrátane podmienok, za ktorých možno služby zadať subdodávateľom (sub-processorom) (ods. 2 písm. a))
• Miesta poskytovania služieb a spracúvania údajov vrátane miesta uloženia údajov a predchádzajúceho oznámenia plánovaných zmien (ods. 2 písm. b))
• Opisy úrovne služieb (ods. 2 písm. e)), pri kritických alebo dôležitých funkciách s presnými kvantitatívnymi a kvalitatívnymi výkonnostnými cieľmi (ods. 3 písm. a))
• Práva na ukončenie zmluvy (ods. 2 písm. h)), pri kritických alebo dôležitých funkciách navyše exitové stratégie s povinným prechodným obdobím (ods. 3 písm. f))
• Pri kritických alebo dôležitých funkciách neobmedzené práva na prístup, kontrolu a audit pre finančné subjekty a orgány dohľadu (ods. 3 písm. e))

Záväzky týkajúce sa latencie alebo výpočtovej kapacity DORA výslovne nepredpisuje. Či ich potrebuješ, vyplýva z výkonnostných cieľov danej funkcie.

Podľa nášho hodnotenia sú tieto ustanovenia pri hyperscaleroch prevažne štandardným textom, pri AI startupoch naopak častou prekážkou v obstarávaní (procurement blocker). Pre AI dodávateľov bez spoľahlivých práv na audit, bez transparentnosti subdodávateľov a bez zdokumentovaných miest spracúvania sa výberový proces vo finančných subjektoch v EÚ často končí pred finálnym kolom.

Prehľad: povinnosť, koho sa týka, právny základ

Praktický príklad: LLM asistent v regionálnej banke

Stredne veľká banka zavádza interného znalostného asistenta založeného na LLM. Beží cez API poskytovateľa AI, ktorý sám hostuje na Microsoft Azure. Kroky relevantné z hľadiska DORA:

1. Klasifikovať: Podporuje asistent kritickú alebo dôležitú funkciu? Ak áno, požiadavky sa sprísňujú.
2. Zaregistrovať: Zmluva a služba sa zapíšu do registra informácií vrátane subdodávateľa Azure (určený CTPP).
3. Zmluvne zabezpečiť (čl. 30): práva na audit, exitová stratégia s prechodným obdobím, podmienky pre subdodávateľov, stanovené miesta poskytovania služieb a spracúvania údajov (banka tu volí EÚ) a SLA s kvantitatívnymi výkonnostnými cieľmi.
4. Posúdiť koncentračné riziko: Leží kritická funkcia na jedinom hyperscaleri? Exitový plán zdokumentovať a pravidelne testovať.
5. Proces incidentov: Závažné IKT incidenty služby, napríklad halucinované regulačné citácie ako významná udalosť prevádzkového rizika (operational risk), podliehajú podľa DORA ohlasovacej povinnosti.

Pseudokód riadiacej logiky (governance):

```
ak AI_sluzba.je_zmluvny_outsourcing:
Register.zapisat(AI_sluzba, sub_processory=[Hyperscaler])
ak AI_sluzba.podporuje_kriticku_funkciu:
Zmluva.preverit(Cl30_ustanovenia) # audit, exit, SLA, sub-processor
ExitPlan.test(interval="pravidelne")
Koncentracne_riziko.posudit(poskytovatel, funkcia)
Incident.aktivovat_cestu_hlasenia(zavaznost="major")
```

Údaje o článkoch vychádzajú z textu nariadenia DORA, status CTPP zo zoznamu ESA z 18. novembra 2025. Tento príspevok nie je právnym poradenstvom; či a ako sa DORA vzťahuje na konkrétnu AI službu, si vyžaduje posúdenie v jednotlivom prípade prostredníctvom odborného právneho a regulačného poradenstva.

Pre agentúry a B2B rozhodovateľov

Pre marketingové agentúry a poskytovateľov služieb, ktorí dodávajú AI funkcie bankám, poisťovniam alebo iným finančným subjektom, je DORA tvrdým predajným kritériom, nie doplnkom. Kto chce predávať riešenia založené na LLM do regulovaného finančného sektora, mal by od začiatku myslieť na schopnosť auditu, transparentnosť subdodávateľov, rezidenciu dát v EÚ a spoľahlivú cestu exitu. Inak projekt nestroskotá na kvalite modelu, ale na obstarávaní. Blck Alpaca pomáha s koncepciou AI workflowov v súlade s DORA a s ich ukotvením v procesoch outsourcingu a riadenia dodávateľov, aby sa tvoja AI iniciatíva vo finančnom sektore vôbec dostala do finálneho výberového kola. Právne posúdenie v jednotlivom prípade si doplnkovo zabezpeč u odborného poradcu.