DORA en AI: hoe financiële instellingen AI compliant inzetten
Op 17 januari 2025 werd de Digital Operational Resilience Act (DORA, Verordening 2022/2554) van kracht voor alle EU-financiële instellingen. Banken, verzekeraars, pensioenfondsen, beleggingsondernemingen én hun ICT-leveranciers moeten sindsdien aantonen dat hun digitale operaties bestand zijn tegen verstoringen. AI-systemen vallen nadrukkelijk binnen de scope — als verwerker van klantdata, als beslisondersteuning of als interne kennistool. Dit artikel legt uit wat DORA vraagt van AI en hoe je dat compliant inricht.
DORA in vijf zinnen
DORA harmoniseert digitale weerbaarheid voor de hele EU-financiële sector. De verordening rust op vijf pijlers:
1. ICT-risicobeheer — een gedocumenteerd en getest beheerssysteem
2. Incidentrapportage — ernstige ICT-incidenten binnen wettelijke termijnen aan DNB of AFM melden
3. Operational resilience testing — periodieke (TLPT) penetratietests
4. ICT-derde-partij-risicobeheer — een volledig register van alle ICT-leveranciers, inclusief AI
5. Informatie-uitwisseling — vrijwillige threat intelligence sharing tussen sectorgenoten
Voor AI zijn vooral pijlers 1 en 4 doorslaggevend.
Waarom AI onder DORA valt
AI-systemen zijn ICT-diensten in de zin van DORA, ongeacht of ze worden ingezet voor klantcommunicatie, kredietbeoordeling, fraudedetectie of interne kennisontsluiting. Drie consequenties:
1. Elk AI-systeem moet in het ICT-derde-partij-register (Artikel 28 DORA), met details over leverancier, locatie van verwerking, criticaliteit en uitwijkscenario.
2. AI die kritieke functies ondersteunt (bijvoorbeeld kredietbesluiten of fraude-monitoring) valt onder de zwaardere eisen voor "critical ICT services".
3. De verantwoordelijkheid blijft bij de financiële instelling. "Onze AI-leverancier zegt dat het goed zit" is geen verweer bij DNB.
De vijf DORA-eisen die AI direct raken
1. ICT-derde-partij-register (Art. 28)
Voor elk AI-systeem moet je vastleggen: leverancier, modelhost, jurisdictie van verwerking, datacategorieën, criticaliteit, exit-strategie, en of er sprake is van subcontracting. Bij SaaS-AI als ChatGPT Enterprise of Copilot betekent dat: het register van OpenAI/Microsoft's subverwerkers volledig in kaart, telkens bijgewerkt.
2. Contractuele waarborgen (Art. 30)
Het contract met de AI-leverancier moet expliciet bepalingen bevatten over: dataveiligheid, audit-rechten van de instelling én van de toezichthouder, beëindiging zonder onevenredige kosten, en gegevenslokatie. Veel standaard-SaaS-contracten voldoen hier niet zonder maatwerk.
3. Audit-rechten en monitoring (Art. 5, 28)
De financiële instelling moet onafhankelijk kunnen controleren of de leverancier zijn beveiligingsverplichtingen nakomt. Bij externe SaaS-AI gebeurt dit vaak via SOC 2- of ISO 27001-rapportages, maar voor kritieke functies kan DNB extra waarborgen eisen.
4. Operational resilience testing (Art. 24-26)
Periodieke tests of het AI-systeem operationeel weerbaar is: kan het overschakelen naar een backup, hoe gedraagt het zich bij een DDoS, wat gebeurt er als de modelprovider uitvalt? Bij externe modellen ben je afhankelijk van wat de leverancier test en rapporteert.
5. Concentratierisico (Art. 29)
Als je AI sterk afhankelijk is van één hyperscaler (Azure, AWS, GCP), telt dat mee in je concentratierisico. DORA stuurt op diversificatie. Een soevereine AI-stack helpt om concentratie-risico aantoonbaar te beperken.
Waar publieke AI worstelt met DORA
Publieke AI-platforms zoals ChatGPT Enterprise, Microsoft Copilot of Google Gemini zijn binnen DORA niet onmogelijk, maar de compliance-last is hoog. Drie veelvoorkomende uitdagingen:
Hoe een private LLM DORA-compliance vereenvoudigt
Een private LLM zoals Amaii lost de meeste DORA-uitdagingen op architectuurniveau op:
| DORA-eis | Hoe private AI dit vereenvoudigt |
|---|---|
| Derde-partij-register | Geen externe modelverwerker; alleen het platform Amaii in het register, niet OpenAI/Microsoft eronder |
| Contractuele waarborgen | Eén partij, één DPA, één jurisdictie (Nederland/EU) |
| Audit-rechten | Volledige auditlogging in eigen log-store; geen afhankelijkheid van externe rapportages |
| Operational resilience | Eigen infrastructuur betekent eigen testbaarheid; geen afhankelijkheid van OpenAI-uptime |
| Concentratierisico | Model-agnostische opzet (Llama, Mistral) plus EU-cloudkeuze (Hetzner, OVH) verlaagt afhankelijkheid van één hyperscaler |
Stappenplan: DORA-conforme AI invoeren
Voor financiële instellingen die AI willen schalen onder DORA:
1. Scope-bepaling — inventariseer welke AI-toepassingen "critical ICT services" raken
2. Register-update — voeg elke bestaande AI-tool toe aan het ICT-derde-partij-register
3. Gap-analyse — toets of huidige contracten voldoen aan Art. 30 (audit-rechten, exit, locatie)
4. Architectuurkeuze — bepaal welke AI in private deployment moet en wat in SaaS kan blijven
5. Testplan — neem AI op in het jaarlijkse resilience-testprogramma
6. Incidentprocedure — koppel AI-incidenten aan het DORA-incidentmeldproces (DNB-portaal)
Conclusie
DORA maakt AI niet onmogelijk in finance — maar het maakt transparante, controleerbare en aantoonbaar weerbare AI verplicht. Voor algemene productiviteit kan een SaaS-AI met de juiste contractuele waarborgen voldoen. Voor kritieke functies (kredietbeoordeling, fraudedetectie, klantcommunicatie met persoonsgegevens) is een private LLM binnen de eigen omgeving de schoonste route: minder subverwerkers, kortere keten, volledige audit-baarheid.
Wil je verkennen hoe DORA-conforme AI er voor jouw instelling uitziet? Bekijk de pagina AI voor finance of plan een demo.
Begrippen in dit artikel
De achtergrond bij deze termen vind je in de begrippenlijst private AI: DORA (Digital Operational Resilience Act), Private AI, Private LLM, RBAC en vendor lock-in voorkomen.
