DORA za sisteme umetne inteligence: gradbeni kontrolni seznam za inženirske in tveganjske ekipe

Kako se DORA nanaša na sistem umetne inteligence in kaj morate zapisati?

Če upravljate — ali dobavljate IKT — finančnemu subjektu v EU, Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA, ki se uporablja od 17. januarja 2025) obravnava vaš sistem umetne inteligence kot vsak drug kritični del IKT. Treba ga je identificirati, oceniti tveganja, testirati, pogodbeno določiti in evidentirati v registru, ki ga lahko izročite nadzorniku. LLM inferenčna končna točka je IKT; vektorska baza podatkov je IKT; in oboje običajno dobavlja tretja oseba. Umetna inteligenca ni izvzeta.

DORA sega do širokega nabora finančnih subjektov — bank, zavarovalnic, investicijskih podjetij, plačilnih institucij in institucij za izdajo elektronskega denarja, ponudnikov storitev v zvezi s kriptosredstvi in drugih — in sega skozi nje do njihovih zunanjih ponudnikov storitev IKT. Najbolj kritični med temi ponudniki so lahko določeni za neposredni nadzor EU.

To je inženirsko in praktično vodilo o tem, kako se ekipe pripravljajo na DORA in jo izpolnjujejo, utemeljeno na produkcijski dostavi sistemov za pridobivanje (retrieval) in agentnih sistemov. Ni pravni nasvet in ni jamstvo skladnosti. Odgovornost za okvir DORA, program testiranja in register ostaja pri finančnem subjektu — ne prenaša se na vašega ponudnika oblaka ali dobavitelja modela. Dobavitelj priskrbi dejstva; subjekt nosi obveznost. Svoje lastne obveznosti in roke preverite ob uradnem besedilu in pri svojem lastnem pravnem svetovalcu.

DORA temelji na petih stebrih. Spodaj je vsak od njih prebran kot inženirska naloga — kaj zapisati in kakšne dokaze ustvariti — čemur sledi vnos v Register of Information po posameznih poljih, ki ga zahteva četrti steber.

Steber 1 — Obvladovanje tveganj IKT: poimenujte odvisnost od umetne inteligence

Prvi steber je dokumentiran okvir za obvladovanje tveganj IKT, ki je v lasti uprave. Za sistem umetne inteligence je poteza ta, da nehate obravnavati »model« kot črno škatlo in ga začnete obravnavati kot preslikano odvisnost z območjem vpliva (blast radius).

Zapišite:

• Funkcijo, ki jo ta umetna inteligenca podpira in ali podpira kritično ali pomembno funkcijo. Model, ki pripravlja osnutke internih povzetkov, ne predstavlja enakega tveganja kot tisti, ki ocenjuje kreditno sposobnost ali triažira opozorila o goljufijah.
• Celotno verigo odvisnosti — ponudnika inference, regijo gostovanja, vektorsko shrambo, model za vgraditve (embedding), orkestracijsko plast — z načinom odpovedi, če se vsaka od njih poslabša ali izgine.
• Enotne točke odpovedi. Trda odvisnost od enega samega ameriškega hiperskalarja za inferenco je natanko tista krhkost, ki jo DORA zahteva, da jo izpostavite.

Dokazi, ki jih je treba ustvariti: arhitekturni diagram z mejami pretoka podatkov, inventar odvisnosti in dokumentirana ocena tveganja, ki ji lahko sledi nekdo, ki je ni napisal. Hranite jo pod nadzorom različic ob kodi, da ostane aktualna, namesto da propada v wikiju.

Steber 2 — Obvladovanje incidentov: naredite odpovedi umetne inteligence klasificirljive

Drugi steber je obvladovanje incidentov, povezanih z IKT: odkrivanje, klasifikacija in — nad določenim pragom — poročanje o velikih incidentih vašemu pristojnemu organu v določenem časovnem okviru. Sistemi umetne inteligence odpovedo na načine, ki jih generično spremljanje spregleda, zato jih instrumentirajte.

Zapišite taksonomijo incidentov za odpovedi, specifične za umetno inteligenco: izpad inference, prekoračitev latence, pridobivanje, ki vrača napačen ali zastarel kontekst, poskus prompt-injection ali eksfiltracije podatkov, tiho poslabšanje kakovosti po posodobitvi modela ali indeksa. Za vsako opredelite, kaj v vaši shemi klasifikacije pomeni »velik«, da dežurna ekipa ne improvizira sredi incidenta.

Dokazi, ki jih je treba ustvariti:

• Strukturirano beleženje (logging) vhodnih podatkov, modela in različice, virov pridobivanja, ključnih odločitev in izhodnih podatkov — z zagovorljivo hrambo. To je zapis, iz katerega rekonstruirate incident.
• Pragovi za opozarjanje, vezani na zgornjo taksonomijo, ne le na CPU in napake 500.
• Priročnik za poročanje (runbook), ki klasificiran incident preslika v to, kdo obvesti kateri organ in do kdaj.

Incident, ki ga ne morete rekonstruirati, je incident, ki ga ne morete klasificirati ali o njem poročati. Dnevnik (log) je dokaz.

Steber 3 — Testiranje odpornosti: testirajte pot modela, ne le aplikacije

Tretji steber je program testiranja digitalne operativne odpornosti — redno testiranje in penetracijsko testiranje, vodeno z grožnjami (TLPT), za pomembne subjekte. Pot umetne inteligence izrecno vključite v obseg.

Zapišite testni načrt, ki preizkuša načine odpovedi umetne inteligence, ne le srečne poti:

• Vaje odpovedi odvisnosti — izklopite primarno inferenčno končno točko in potrdite, da se sistem varno poslabša (rezervni mehanizem, čakalna vrsta ali pošteno sporočilo o napaki) namesto da se zamrzne ali si izmišljuje.
• Testi pridobivanja in utemeljitve (grounding) — ali sistem zavrne ali označi odgovor, ko kontekst manjka, namesto da samozavestno odgovarja iz ničesar?
• Testiranje sovražnih vhodnih podatkov — prompt injection, poskusi eksfiltracije podatkov in robni primeri glede ločevanja najemnikov (tenant separation).
• Preklop ob odpovedi in obnovitev — če upravljate hibridno ali samostojno gostovano pot, dokažite, da preklop deluje pod obremenitvijo, ne le na diagramu.

Dokazi, ki jih je treba ustvariti: rezultati testov z datumi, sanacijske vstopnice (tickets) in ritem ponovnega testiranja. Za obseg TLPT sodita izpostavljenost sistema umetne inteligence in njegove podatkovne meje v izhodišče za testerja.

Steber 4 — Tveganje tretjih oseb: Register of Information in koncentracijsko tveganje

To je steber, kjer odločitve o nabavi umetne inteligence najbolj zagrizejo in kjer je register obvezen. Register of Information je inventar vseh dogovorov s tretjimi osebami na področju IKT — kamor regulatorji pogledajo najprej in kjer premalo natančno določen sistem umetne inteligence pokaže svoje vrzeli. Za vsak dogovor, povezan z umetno inteligenco, zajemite vsaj:

Nato se neposredno soočite s koncentracijskim tveganjem. DORA obravnava preveliko odvisnost od enega ponudnika — ali od ponudnika, ki ga je težko nadomestiti — kot pomanjkljivost odpornosti, ki jo morate izpostaviti in obvladovati. Odvisnost od LLM z enim samim dobaviteljem in eno samo regijo je učbeniški primer: zaprti frontier modeli niso neposredno zamenljivi, zato je »zamenjali bi ponudnika« resničen izstopni načrt le, če ste alternativo preizkusili in lahko preklopite znotraj svojih ciljev obnovitve. Če ne morete izpolniti vrstic »dejanska regija obdelave«, »podizvajalci« in »zamenljivost« za svojega ponudnika umetne inteligence, to ni vrzel v papirologiji — to je samo koncentracijsko tveganje, izpostavljeno na očeh.

Dva strukturna ukrepa za omilitev, oba pa morate dokumentirati:

• Zamenljivost — abstrahirajte inferenčno mejo, da lahko preusmerite na alternativni model ali ponudnika brez ponovne prearhitekture.
• Jurisdikcija in izpostavljenost CLOUD Act — EU-suverena ali samostojno gostovana namestitev ohranja dobavno verigo IKT znotraj jurisdikcije in odpravlja zahtevani prenos podatkov v ZDA. Izvajanje inference na Mistral AI z Qdrant za vektorsko iskanje, pod rezidenčnostjo podatkov v EU in z možnostjo samostojnega gostovanja lokalno ali v izoliranem (air-gapped) okolju, je način, kako v praksi zmanjšamo to odvisnost. Modeli, gostovani v ZDA, ostajajo veljavni za številna delovna bremena; bistvo je, da izberete premišljeno in izbiro zapišete.

Steber 5 — Izmenjava informacij

Operativno najlažji steber: DORA spodbuja finančne subjekte, naj si znotraj zaupanja vrednih skupnosti izmenjujejo obveščevalne podatke o kibernetskih grožnjah. Za sistem umetne inteligence je koristen prispevek konkreten — indikatorji iz poskusov prompt-injection in eksfiltracije ter vzorci iz incidentov v dobavni verigi modelov. Zapišite, ali sodelujete in kako sanirani indikatorji zapustijo vaše okolje, ne da bi razkrili podatke strank.

Dokazi, ki jih finančni subjekt dejansko lahko vloži

DORA teče na dokumentaciji. Suverena ali samostojno gostovana namestitev je vredna svoje trditve o odpornosti le, če ustvarja artefakte, ki jih potrebujejo vaš okvir, register in testiranje:

1. Klasificirajte funkcijo, ki jo umetna inteligenca podpira, in zapišite utemeljitev.
2. Preslikajte celotno verigo odvisnosti in označite vsako enotno točko odpovedi.
3. Instrumentirajte beleženje, specifično za umetno inteligenco — vhodne podatke, model/različico, vire pridobivanja, izhodne podatke — z zagovorljivo hrambo.
4. Opredelite taksonomijo incidentov umetne inteligence in nanjo povežite opozarjanje ter priročnik za poročanje.
5. Testirajte načine odpovedi — vaje odvisnosti, utemeljitev, sovražni vhod, preklop ob odpovedi — v določenem ritmu, z datiranimi dokazi.
6. Dokončajte vnos v Register of Information za vsakega ponudnika umetne inteligence in podobdelovalca.
7. Ocenite koncentracijsko tveganje in dokumentirajte svoj položaj glede zamenljivosti in izstopa — z rezultati testiranega preklopa, ne z diagramom.
8. Določite pogodbene pogoje — pravice do revizije, podizvajanje, prekinitev/pomoč pri izstopu.
9. Zmanjšajte izpostavljenost jurisdikciji, kjer to zahtevajo podatki, prek EU-suverene ali samostojno gostovane inferenčne poti.
10. Načrtujte ritem ponovnega pregleda, da register in testi sledijo spremembam modelov in indeksov.

Vrstice, ki jih ne morete dokončati, so vaše prioritete v okviru DORA. Upoštevajte delitev dela, ki jo DORA predpostavlja: vaše podjetje ima v lasti okvir, testiranje in register; dobavitelj priskrbi dejstva — kje teče, kakšne so njegove odvisnosti, revizijsko sled in zgodbo o zamenljivosti.

Kje se umešča TechRevati

Večina tega postane lažja, ko je namestitev za to zgrajena že od prvega dne. Strukturirano beleženje, določen izvor modela (provenance), abstrahirana inferenčna meja in EU-rezidenčna pot spremenijo vnose v register in dokaze testiranja iz naglice pred revizijo v lastnosti samega sistema. To je drža, okoli katere je zgrajen EinCoreRAG: Mistral in Qdrant, EU-rezidenčen in z možnostjo samostojnega gostovanja, tako da ima »kam gredo naši podatki« revizljiv odgovor, izstopni načrt pa je namestitev, ki jo že upravljate.

Če preslikavate DORA na živ ali načrtovan sistem umetne inteligence — skupaj s prekrivanjem GDPR in EU AI Act — naš pregled skladnosti predstavlja, kako pristopamo k temu, in vsako obveznost preslika v dokaze, ki jih dostavimo, namesto v obljubo. In Sovereign RAG Pilot je omejen, enonajemniški način za preizkus EU-rezidenčnega, samostojno gostljivega sklada za pridobivanje glede na vaše lastne zahteve po koncentracijskem tveganju in rezidenčnosti — z revizijsko sledjo kot stranskim produktom. Pišite nam na hello@techrevati.com.