DORA + EU AI Act: What CSSF Firms Owe, and When

Quick answer: DORA has been fully applicable to Luxembourg financial firms since 17 January 2025. The EU AI Act's Article 50 transparency duties have applied since 2 August 2026, and its high-risk obligations now land on 2 December 2027 — moved from 2 August 2026 by Regulation (EU) 2026/1744. The two regimes genuinely overlap in four areas — third-party risk management, incident reporting, resilience testing, and human oversight — and Article 9(10) of the AI Act explicitly permits integrating AI risk management into the ICT risk management procedures you already run under DORA. Build one system of record and evidence it under both, rather than funding two parallel projects.

Last verified 7 August 2026.

Two regulations sit on top of every AI initiative in a Luxembourg financial firm: the Digital Operational Resilience Act (DORA), fully applicable since 17 January 2025, and the EU AI Act. Most CSSF-supervised entities and CAA-regulated insurers — including those deploying AI in claims, underwriting and fraud detection — treat these as two separate compliance projects with two budgets and two timelines. That is the expensive way to do it.

The AI Act dates changed in July 2026

If your programme is planned against 2 August 2026, replan it. The Digital Omnibus on AI — Regulation (EU) 2026/1744, in force since 27 July 2026 — rewrote the application dates:

AI Act obligation	Applies
Article 5 prohibited practices; Article 4 AI literacy	Since 2 Feb 2025 (two new prohibitions from 2 Dec 2026)
GPAI obligations; Article 99 penalty regime	Since 2 Aug 2025 (Commission GPAI fining powers since 2 Aug 2026)
Article 50 transparency	Since 2 Aug 2026 — machine-readable marking of pre-existing generative systems by 2 Dec 2026
Stand-alone Annex III high-risk systems	2 Dec 2027 (was 2 Aug 2026)
AI embedded in Annex I Section A products	2 Aug 2028 (was 2 Aug 2027)

For a Luxembourg bank or insurer this changes the sequencing but not the destination. The live obligation today is Article 50 — your customer chatbot, your voice channel, any AI-generated client communication. The heavy work — the credit-scoring model, the life and health underwriting engine — is on the December 2027 clock, and it needs most of that time.

This guide explains where DORA and the AI Act overlap, where they don't, and how to sequence the work so you pay for the underlying controls once.

If a combined DORA / AI Act control set is keeping your compliance file open, book a free 30-minute call and we'll walk your specific case through the rules.

Why these two regulations belong in the same conversation

DORA and the EU AI Act were drafted by different teams in Brussels for different reasons. DORA is a financial-sector ICT resilience regulation: keep the digital plumbing running, contain incidents, manage third-party dependencies. The EU AI Act is a horizontal product-safety regulation: classify the risk of AI systems and constrain the high-risk ones with documentation, testing, and human oversight.

But for a Luxembourg bank, fund administrator, insurer, or PFS, both regimes converge on the same artefacts:

• An inventory of every AI system in production
• A risk classification per system
• A description of every third-party vendor providing AI components
• An incident-response plan that covers AI failures
• An audit trail of model decisions and human overrides
• A monitoring and reporting process to the relevant authority (CSSF for DORA, market surveillance for the AI Act, the CNPD when personal data is involved)

You can build these artefacts twice — once in your DORA register and again in your AI Act technical file — and watch your compliance bill double. Or you can build a single system of record that satisfies both.

The four areas of genuine overlap

1. Third-party risk management. Under DORA, every "ICT third-party service provider" must be inventoried, contractually bound to specific resilience standards, and exit-tested. Every external AI vendor — your model provider, your orchestration platform, your hosting environment — fits that definition. Under the AI Act, the same vendors are part of your provider/deployer supply chain, and you owe documentation on each. Build one vendor register, tag it with both regulatory views, and you have done the work once.

In Luxembourg this file also has to satisfy Circular CSSF 22/806 on outsourcing arrangements, as amended by Circular CSSF 25/883. The CSSF realigned its rulebook around DORA during 2025 (Circulars 25/880 and 25/882) specifically to separate DORA obligations from non-DORA ones — establish which side your arrangement sits on before you build the file, because the requirements differ.

2. Incident reporting. DORA requires major ICT incident reporting to the CSSF within strict timelines. The AI Act adds a duty to report serious AI incidents (malfunctions, biased outputs causing harm). For a Luxembourg bank, both reports cover the same underlying event in many cases. A single incident-classification taxonomy that maps to both regimes is far cleaner than two parallel processes.

3. Continuity and resilience testing. DORA mandates Threat-Led Penetration Testing (TLPT) and digital operational resilience testing. The AI Act mandates testing of high-risk AI systems for accuracy, robustness, and cybersecurity. The methodologies overlap meaningfully: red-team an AI system for adversarial inputs and you've satisfied parts of both regimes — and much of the NIS2 / AI Act overlap as well, if NIS2 also applies to you.

4. Human oversight and accountability. Both regimes ultimately require a named human accountable for the system. DORA wants an ICT senior management owner; Article 26 of the AI Act wants a deployer-side person with the competence, training and authority to exercise oversight. In a Luxembourg SME or mid-sized firm these are usually the same person. Document them as one role with two regulatory hats.

The consolidation is explicitly permitted. Article 9(10) of the AI Act allows the AI risk management system required for high-risk AI to be integrated into, or form part of, the risk management procedures a financial entity already maintains under Union financial services law — including the ICT risk management framework it runs under DORA. This is not a grey-area interpretation; it is drafted into the regulation. Firms that build a separate AI risk register from scratch are choosing to do the work twice.

Where DORA and the AI Act diverge

It's just as important to be clear on where the two do not overlap, so you don't try to force-fit:

• Risk classification logic differs. DORA risk-tiers your services by criticality. The AI Act risk-tiers your AI systems by use case. A "non-critical service" under DORA can still contain a "high-risk AI system" under the Act (e.g. an HR screening tool used internally).
• DORA covers all ICT, not just AI. Most of your DORA work is about your core banking system, your trading platform, your custody system. AI is a small slice.
• The AI Act covers all AI, not just financial. A chatbot on your public website triggers AI Act transparency obligations regardless of DORA.
• Reporting authorities differ. DORA reporting goes to the CSSF (or the CAA for insurers). AI Act reporting goes to the national market surveillance authority — which under bill of law n°8476 would be the CNPD by default, with the CSSF retaining AI systems inside its existing financial-sector remit and the CAA insurance. The bill was still in the parliamentary process at the time of writing, so for now expect questions to arrive through your existing supervisory relationship first.

Rather resolve this in one conversation? Book a free 30-minute call — bring your use case and we'll walk it through together, in plain language.

Classification precision, before anything else

For a Luxembourg financial firm, more money is lost to mis-scoping than to under-scoping. Four determinations decide the size of the programme:

• Credit scoring of natural persons — Annex III point 5(b). High-risk from 2 December 2027. And an Article 27 Fundamental Rights Impact Assessment applies to you as deployer, private or not — 5(b) and 5(c) deployers are named in Article 27(1) alongside public bodies.
• Life and health insurance risk assessment and pricing — Annex III point 5(c). High-risk, FRIA applies. Motor, property and liability pricing are outside this heading. Do not scope the whole book in.
• Fraud detection — expressly excluded from Annex III 5(b). Not high-risk on that ground. Internal AML and capital-adequacy models are governed by sectoral law, not Annex III. The trap is the hybrid pipeline where credit-scoring logic and anomaly detection are architecturally inseparable — assume in scope.
• Client-facing chatbots and voice channels — not high-risk, but squarely inside Article 50, which is due now. This is the most likely first enforcement contact, because an undisclosed chatbot is visible from outside the firm.

The Article 6(3) filter can take a listed system out of scope where it poses no significant risk of harm — but never where it profiles natural persons, which rules out most credit and underwriting applications. Where you rely on it, the assessment must be documented and registered.

The sequencing that saves you money

Step 1 — Close Article 50 now. It is live. Walk every client-facing AI surface, confirm the disclosure exists at first interaction in FR / DE / EN, and document who signed off editorial responsibility on AI-generated client communications. Half a day to a week, and it closes the only exposure that is currently enforceable.

Step 2 — Build the unified inventory. Every AI system in the firm, from the production fraud-detection model to the marketing team's ChatGPT subscription. For each: business owner, vendor, data inputs, decision impact, provider-or-deployer role, and AI Act class (prohibited / high-risk / Article 6(3) filtered / limited / minimal). This single inventory feeds your DORA ICT register, your Circular 22/806 outsourcing file and your AI Act records.

Step 3 — Classify and prioritise against December 2027. The high-risk systems are the constraint. For each you owe a risk management process (integrated into your DORA framework under Article 9(10)), data governance, technical documentation to Annex IV, logging, transparency, human oversight design, accuracy and robustness testing, post-market monitoring, and — for 5(b) and 5(c) deployers — a FRIA. That is twelve to eighteen months of real work per complex system, not a checklist.

Step 4 — Templatise once, reuse everywhere. One set of templates — risk assessment, model card, DPIA, incident playbook, monitoring runbook, vendor due-diligence questionnaire — satisfying DORA, the AI Act, Circular 22/806 and GDPR simultaneously. Most Luxembourg firms we work with end up with about a dozen reusable documents covering 80% of the recurring obligations.

Step 5 — Operationalise monitoring. Compliance becomes an ongoing operating discipline, not a project: quarterly model performance review, annual DORA testing cycle, ongoing vendor reassessment, and override-rate reporting that proves your human oversight is real rather than decorative.

For more depth on the AI Act side, see our guide to what actually applies now.

What the CSSF has actually said about AI

There is no dedicated CSSF circular on artificial intelligence. Supervisory expectations come through two joint CSSF / BCL thematic reviews on AI use in the Luxembourg financial sector: the first published in May 2023, covering credit institutions, e-money institutions and payment institutions; the second in May 2025, substantially broader, adding investment firms and authorised alternative investment fund managers — more than a threefold increase in participation.

The consistent message across both editions: governance, human oversight and explainability must be demonstrable for any AI solution a supervised entity relies on. That is the same triad the AI Act codifies, which is convenient — the evidence you build for one serves the other. Read both reports; they are the closest thing to a CSSF AI rulebook that exists, and they tell you what your supervisor has already been asking your peers.

Three failure modes to avoid

We see the same three mistakes repeatedly in Luxembourg financial firms:

Treating DORA as "done" because the January 2025 deadline passed. DORA is a continuous-operation regime, not a one-time certification. Your AI deployments since January 2025 should already be in your DORA ICT register; if they're not, fix that before adding AI Act work on top.

Outsourcing the AI Act work to legal alone. The AI Act is a technical regulation as much as a legal one. Lawyers cannot write a meaningful technical file without engineering input. A joint legal + engineering + risk working group is the only structure that ships compliant systems on time.

Underestimating the third-party scope. Every AI vendor in your stack triggers DORA contractual amendments, Circular 22/806 outsourcing documentation and AI Act supply-chain evidence. If you have five or more AI vendors, plan 4–8 weeks for contractual remediation alone.

Reading the deferral as a reprieve. This is the new one, and it will cost several Luxembourg firms their December 2027 date. High-risk obligations moved sixteen months; a first high-risk file takes twelve to eighteen. The deferral bought you the time the job needs, not time off.

---

Find out where your AI footprint actually stands — against the real dates

The 20 More AI Act Readiness Assessment, sized for CSSF-supervised entities and CAA-regulated insurers. Ten working days, fixed scope:

1. The unified AI inventory — every AI system and AI feature in the firm, structured so the same rows serve your DORA ICT register, your Circular 22/806 outsourcing file and your AI Act records. One system of record, three regulatory views.
2. The classification determination — provider or deployer per system; Annex III 5(b) / 5(c) in scope or out; fraud-detection and AML models correctly excluded; Article 6(3) filter assessed and documented where it applies; Article 27 FRIA flagged where it is yours.
3. The Article 50 gap report — the disclosures legally due on your client-facing channels today, mapped to the specific chatbot flows, voice scripts and client communications missing them.
4. A costed plan to 2 December 2027 — mapped against your existing DORA control set, showing explicitly which AI Act obligations you can discharge through Article 9(10) integration and which need net-new work, in a one-page memo for your risk committee.

We also deploy AI systems for Luxembourg financial firms on EU-hosted infrastructure with the DORA, AI Act and GDPR documentation produced in parallel with the build, not bolted on afterwards.

→ See the AI Act readiness service, or book a free 30-minute consultation. We will do a quick inventory call and tell you honestly whether you are on track or behind — no sales theatre.

Related reading:

• EU AI Act August 2026 deadline: Luxembourg compliance checklist
• AI for financial services in Luxembourg: CSSF use cases
• Private AI deployment for Luxembourg's regulated industries
• GDPR-compliant AI for Luxembourg SMEs
• AI Knowledge Hub — 20 More Resources