DORA za AI sisteme: kontrolna lista za gradnju za inženjerske timove i timove za rizik

Kako se DORA primenjuje na AI sistem i šta morate da zabeležite?

Ako vodite — ili isporučujete IKT za — finansijski subjekt u EU, Akt o digitalnoj operativnoj otpornosti (Regulation (EU) 2022/2554, DORA, koja se primenjuje od 17. januara 2025.) tretira vaš AI sistem kao svaki drugi kritičan deo IKT-a. Mora biti identifikovan, procenjen po riziku, testiran, ugovorno fiksiran i zabeležen u registru koji možete predati nadzorniku. Krajnja tačka za LLM inferenciju je IKT; vektorska baza podataka je IKT; a oba obično isporučuje treća strana. AI nije izuzet.

DORA obuhvata širok skup finansijskih subjekata — banke, osiguravajuća društva, investiciona društva, institucije za plaćanje i institucije za elektronski novac, pružaoce usluga povezanih sa kripto-imovinom i druge — i doseže kroz njih do njihovih trećih strana pružalaca IKT usluga. Najkritičniji od tih pružalaca mogu biti određeni za direktan nadzor na nivou EU.

Ovo je inženjersko i praktičarsko uputstvo o tome kako se timovi pripremaju za DORA-u i ispunjavaju njene zahteve, utemeljeno u produkcijskoj isporuci sistema za pretragu (retrieval) i agentskih sistema. Ovo nije pravni savet i nije garancija usklađenosti. Odgovornost za DORA okvir, program testiranja i registar ostaje na finansijskom subjektu — ne prenosi se na vašeg cloud provajdera ili dobavljača modela. Dobavljač isporučuje činjenice; subjekt nosi obavezu. Potvrdite sopstvene obaveze i rokove u odnosu na zvaničan tekst i sopstvenog pravnog savetnika.

DORA je izgrađena na pet stubova. Ispod je svaki od njih pročitan kao inženjerski zadatak — šta zabeležiti i koje dokaze proizvesti — praćen unosom u Register of Information po pojedinačnim poljima koji zahteva četvrti stub.

Stub 1 — Upravljanje IKT rizikom: imenujte AI zavisnost

Prvi stub je dokumentovan okvir za upravljanje IKT rizikom u vlasništvu uprave. Za AI sistem, potez je da prestanete da tretirate „model" kao crnu kutiju i počnete da ga tretirate kao mapiranu zavisnost sa radijusom uticaja.

Zabeležite:

• Funkciju koju ovaj AI podržava i da li podupire kritičnu ili važnu funkciju. Model koji izrađuje interne sažetke nije isti rizik kao onaj koji ocenjuje kreditnu sposobnost ili trijažira upozorenja o prevari.
• Ceo lanac zavisnosti — pružalac inferencije, region hostinga, vektorsko skladište, model za ugrađivanje (embedding), sloj orkestracije — sa načinom otkaza ako se svaki od njih degradira ili nestane.
• Pojedinačne tačke otkaza. Čvrsta zavisnost od jednog američkog hyperscaler-a za inferenciju upravo je krhkost koju DORA traži da izneseš na videlo.

Dokazi koje treba proizvesti: dijagram arhitekture sa granicama toka podataka, inventar zavisnosti i dokumentovana procena rizika koju osoba koja je nije napisala može da isprati. Držite je pod verzionom kontrolom pored koda kako bi ostala aktuelna, umesto da truli na wiki-ju.

Stub 2 — Upravljanje incidentima: učinite AI otkaze klasifikovanim

Drugi stub je upravljanje incidentima povezanim sa IKT-om: otkriti, klasifikovati i — iznad praga — prijaviti veće incidente vašem nadležnom organu u definisanom roku. AI sistemi otkazuju na načine koje generički monitoring propušta, pa ih instrumentalizujte.

Zabeležite taksonomiju incidenata za otkaze specifične za AI: prekid inferencije, prekoračenje latencije, pretraga koja vraća pogrešan ili zastareo kontekst, pokušaj ubrizgavanja prompta (prompt-injection) ili eksfiltracije podataka, tiho pogoršanje kvaliteta nakon ažuriranja modela ili indeksa. Za svaki od njih definišite šta „veći" znači u vašoj šemi klasifikacije, kako dežurni tim ne bi improvizovao usred incidenta.

Dokazi koje treba proizvesti:

• Strukturirano logovanje ulaza, modela i verzije, izvora pretrage, ključnih odluka i izlaza — sa odbranjivim rokom čuvanja. Ovo je zapis iz kojeg rekonstruišete incident.
• Pragovi za upozoravanje vezani za gore navedenu taksonomiju, a ne samo za CPU i 500-ke.
• Priručnik za prijavljivanje (runbook) koji mapira klasifikovan incident na to ko obaveštava koji organ i do kada.

Incident koji ne možete rekonstruisati jeste onaj koji ne možete klasifikovati ili prijaviti. Log je dokaz.

Stub 3 — Testiranje otpornosti: testirajte putanju modela, a ne samo aplikaciju

Treći stub je program za testiranje digitalne operativne otpornosti — redovno testiranje i testiranje prodora vođeno pretnjama (TLPT) za značajne subjekte. Eksplicitno uvedite AI putanju u obim.

Zabeležite plan testiranja koji izvežbava načine otkaza AI-ja, a ne samo srećni scenario:

• Vežbe otkaza zavisnosti — isključite primarnu krajnju tačku inferencije i potvrdite da se sistem degradira bezbedno (rezervni put, red čekanja ili iskren prikaz greške), umesto da se zaglavi ili izmišlja.
• Testovi pretrage i utemeljenosti (grounding) — da li sistem odbija ili označava kada kontekst nedostaje, umesto da samouvereno odgovara ni iz čega?
• Testiranje protivničkih (adversarial) ulaza — ubrizgavanje prompta, pokušaji eksfiltracije podataka i granični slučajevi protiv razdvajanja zakupaca (tenant separation).
• Prebacivanje pri otkazu i oporavak — ako vodite hibridnu ili samostalno hostovanu putanju, dokažite da prebacivanje radi pod opterećenjem, a ne samo na dijagramu.

Dokazi koje treba proizvesti: rezultati testova sa datumima, tiketi za otklanjanje i kadenca ponovnog testiranja. Za obim TLPT-a, izloženost AI sistema i njegove granice podataka pripadaju brifu testera.

Stub 4 — Rizik trećih strana: Register of Information i rizik koncentracije

Ovo je stub gde odluke o nabavci AI-ja najjače ujedaju i gde je registar obavezan. Register of Information je inventar svih aranžmana sa trećim stranama u oblasti IKT-a — gde regulatori prvo gledaju i gde nedovoljno specifikovan AI sistem pokazuje svoje praznine. Za svaki aranžman povezan sa AI-jem, zabeležite bar:

Zatim se suočite sa rizikom koncentracije direktno. DORA tretira preteranu zavisnost od jednog pružaoca — ili od pružaoca kojeg je teško zameniti — kao nedostatak otpornosti koji morate izneti na videlo i njime upravljati. Zavisnost od LLM-a jednog dobavljača u jednom regionu je udžbenički slučaj: zatvoreni frontier modeli nisu međusobno zamenljivi po principu „ubaci i pokreni", pa je „prešli bismo na drugog pružaoca" stvaran plan izlaska samo ako ste testirali alternativu i možete se prebaciti unutar svojih ciljeva oporavka. Ako ne možete popuniti redove „stvarni region obrade", „podizvođači" i „zamenljivost" za svog AI pružaoca, to nije praznina u papirologiji — to je sam rizik koncentracije, učinjen vidljivim.

Dve strukturne mere ublažavanja, obe koje treba da dokumentujete:

• Zamenljivost — apstrahujte granicu inferencije tako da možete preusmeriti na alternativni model ili pružaoca bez ponovnog projektovanja arhitekture.
• Izloženost jurisdikciji i CLOUD Act-u — EU-suvereno ili samostalno hostovano postavljanje zadržava IKT lanac snabdevanja unutar jurisdikcije i uklanja zahtevani transfer podataka u SAD. Pokretanje inferencije na Mistral AI sa Qdrant za vektorsku pretragu, uz rezidentnost podataka u EU i mogućnost samostalnog hostovanja lokalno (on-prem) ili u izolovanom (air-gapped) okruženju, način je na koji tu zavisnost u praksi smanjujemo. Modeli hostovani u SAD ostaju validni za mnoge radne opterećenja; poenta je birati promišljeno i zabeležiti izbor.

Stub 5 — Razmena informacija

Operativno najlakši stub: DORA podstiče finansijske subjekte da razmenjuju obaveštajne podatke o sajber pretnjama unutar zajednica od poverenja. Za AI sistem koristan doprinos je konkretan — indikatori iz pokušaja ubrizgavanja prompta i eksfiltracije, i obrasci iz incidenata u lancu snabdevanja modela. Zabeležite da li učestvujete i kako sanitizovani indikatori napuštaju vaše okruženje bez curenja podataka o korisnicima.

Dokazi koje finansijski subjekt zaista može da podnese

DORA počiva na dokumentaciji. Suvereno ili samostalno hostovano postavljanje vredi svoje tvrdnje o otpornosti samo ako proizvodi artefakte koje vaš okvir, registar i testiranje zahtevaju:

1. Klasifikujte funkciju koju AI podržava i zabeležite obrazloženje.
2. Mapirajte ceo lanac zavisnosti i označite svaku pojedinačnu tačku otkaza.
3. Instrumentalizujte logovanje specifično za AI — ulazi, model/verzija, izvori pretrage, izlazi — sa odbranjivim rokom čuvanja.
4. Definišite taksonomiju AI incidenata i povežite je sa upozoravanjem i priručnikom za prijavljivanje.
5. Testirajte načine otkaza — vežbe zavisnosti, utemeljenost, protivnički ulaz, prebacivanje pri otkazu — po kadenci, sa datiranim dokazima.
6. Popunite unos u Register of Information za svakog AI pružaoca i pod-obrađivača.
7. Procenite rizik koncentracije i dokumentujte svoju poziciju zamenljivosti i izlaska — sa rezultatima testiranog prelaska, a ne dijagramom.
8. Fiksirajte ugovorne uslove — prava na reviziju, podizvođenje, pomoć pri raskidu/izlasku.
9. Smanjite izloženost jurisdikciji tamo gde podaci to nalažu, putem EU-suverene ili samostalno hostovane putanje inferencije.
10. Zakažite kadencu ponovnog pregleda kako bi registar i testovi držali korak sa promenama modela i indeksa.

Redovi koje ne možete popuniti su vaši DORA prioriteti. Uočite podelu rada koju DORA pretpostavlja: vaša firma poseduje okvir, testiranje i registar; dobavljač isporučuje činjenice — gde se pokreće, njegove zavisnosti, revizorski trag i priču o zamenljivosti.

Gde se TechRevati uklapa

Većina ovoga postaje lakša kada je postavljanje izgrađeno za to od prvog dana. Strukturirano logovanje, fiksirano poreklo (provenance) modela, apstrahovana granica inferencije i EU-rezidentna putanja pretvaraju unose u registar i dokaze o testiranju u svojstva sistema, a ne u grozničavo trčkaranje pred reviziju. To je pozicija oko koje je EinCoreRAG izgrađen: Mistral plus Qdrant, EU-rezidentan i sa mogućnošću samostalnog hostovanja, tako da „kuda idu naši podaci" ima odgovor koji se može revidirati, a plan izlaska je postavljanje koje već vodite.

Ako mapirate DORA-u u odnosu na živ ili planiran AI sistem — uz preklapanje sa GDPR i EU AI Act — naš pregled usklađenosti izlaže kako mu pristupamo, mapirajući svaku obavezu na dokaz koji isporučujemo, a ne na obećanje. A Sovereign RAG Pilot je definisan, jednozakupčev (single-tenant) način da testirate EU-rezidentan, samostalno hostiv sloj za pretragu (retrieval) u odnosu na sopstvene zahteve za rizik koncentracije i rezidentnost — sa revizorskim tragom kao nusproizvodom. Kontaktirajte nas na hello@techrevati.com.