DORA and AI: what Article 28 actually requires of your LLM vendor

The Digital Operational Resilience Act (DORA) has been binding on EU financial entities since 17 January 2025. If your organisation uses an LLM — whether via API or self-hosted — the model and its infrastructure fall under DORA's ICT risk management framework.

Most conversations about "AI compliance" jump to the EU AI Act. But for financial institutions, DORA is the regulation that's already binding, and its requirements for AI systems are specific, practical, and largely unmet by current private-AI vendors.

What Article 28 requires

Article 28 of DORA mandates that financial entities maintain a register of information on all contractual arrangements with ICT third-party service providers. This includes AI vendors and, critically, applies regardless of whether the AI is cloud-hosted or on-premise.

The register must document:

• Services provided — what the AI system does, which business functions it supports
• Data processing locations — where inference runs, where data is stored, where logs are kept
• Subcontracting chains — every entity in the delivery chain, not just your direct vendor
• Exit strategies — how you would migrate away, with what data portability guarantees

The gap generic AI vendors leave

Most private-AI vendors focus on deployment: spinning up a model, providing an API, maybe hosting it in an EU data centre. That's necessary but not sufficient.

DORA doesn't ask "is the model running?" It asks:

• Where is the register entry?
• Show me the incident response log
• Prove the resilience test
• Document the exit strategy

These are evidence requirements, not feature requirements. And they're the gap that matters for regulated financial institutions.

What self-hosted AI changes

Self-hosting your LLM on your own infrastructure — or on sovereign compute under your jurisdiction — simplifies the DORA compliance picture in several ways:

1. Data processing location: your premises, your jurisdiction, documented by default
2. Subcontracting chains: dramatically shorter — open-source model, your hardware, your network
3. Exit strategy: open-source models on standard hardware — no proprietary lock-in to document
4. Concentration risk: no dependency on a single cloud hyperscaler

But self-hosting doesn't eliminate the evidence requirement. You still need the register entries, the audit trails, and the resilience test documentation.

Evidence as infrastructure

The right approach treats compliance evidence as infrastructure — generated automatically as part of normal AI operations, not as a separate compliance project run quarterly by a different team.

This means:

• DORA register entries auto-populated from deployment configuration
• Immutable audit trails of inference operations, model versions, and configuration changes
• Automated resilience reports from regular testing
• Exit strategy documentation maintained as part of the deployment specification

When evidence generation is built into the infrastructure, the cost of compliance drops to near zero — and the evidence is always current, not months stale.

What to do next

If your organisation is evaluating AI deployment under DORA, the questions to ask your vendor are not about model benchmarks. They're about evidence:

1. Will you generate my Art. 28 register entries automatically?
2. Can you produce an immutable audit trail of all inference operations?
3. Do you run automated resilience tests, and can I get the reports?
4. What's the exit strategy, and is it documented?

If the answer to any of these is "we can help you fill in a template," that's a compliance project, not a compliance feature. The evidence should be automatic.

---

Svalv generates DORA compliance evidence as part of normal AI operations — not as a separate project. Book a readiness assessment to map your infrastructure to DORA requirements.