DORA and AI
To DORA, your AI model is a supplier you have to be able to leave.
When a regulated firm sends work to a hosted model, it takes on an ICT third-party dependency. DORA does not ban that. It asks you to understand the dependency, size the concentration risk, and hold an exit plan you could actually run. A self-hosted, provider-agnostic gateway is how that exit plan stops being a paragraph in a policy.
Why a hosted LLM counts as ICT third-party risk
DORA (Regulation (EU) 2022/2554) has applied to in-scope financial entities since 17 January 2025. It governs how a firm manages ICT risk, including the ICT services it buys from third parties.
A frontier model reached over an API is one of those services. It is an ICT service supplied by an ICT third-party service provider, so the entity-level third-party rules in Articles 28 to 30 attach to it the same way they attach to a cloud host or any other SaaS vendor. AI tends to arrive informally, spreading across teams before anyone registers it, which is exactly how an un-assessed dependency forms.
One objective clarification up front: whether a given AI use supports a critical or important function is your own determination, and a sub-threshold, registered-only manager can sit outside DORA altogether. This page explains the architecture, not that classification.
What DORA actually asks for
The third-party regime is about governance and evidence, not banned suppliers. Four anchors matter for AI:
- Article 28. Sound management of ICT third-party risk across the lifecycle: due diligence, a register of information that flags which arrangements support critical or important functions, ongoing monitoring, and a documented exit strategy for those arrangements.
- Article 29. A preliminary concentration-risk assessment before you contract for a service supporting a critical or important function: is the provider not easily substitutable, and are you stacking several arrangements on the same or closely connected providers?
- Article 30(2). Baseline terms for every ICT contract, including access, recovery and return of your data in an easily accessible format on termination, insolvency or discontinuation.
- Article 30(3). Enhanced terms for critical or important functions: full service levels with performance targets, extended audit and inspection rights, and an exit strategy with an adequate transition period.
The exit plan is the part most AI stacks fail
Route every AI workload to one frontier API and you have concentrated a dependency on a single provider, which is the not-easily-substitutable pattern Article 29 tells you to check for. The Commission delegated regulation on the policy for ICT services supporting critical or important functions (Delegated Regulation (EU) 2024/1773) goes further: it expects a documented exit plan for each relevant arrangement, reviewed and tested. An aspiration on paper does not meet that.
The trap is that substitutability is behavioural, not just contractual. A clean termination clause is worth little if your prompts, your tool wiring and your outputs are all built against one vendor's proprietary interface, because you cannot re-point the work without rebuilding it.
A self-hosted, provider-agnostic gateway makes the exit real
GAIA-CORE puts one stable interface in front of several interchangeable model back-ends. Switching or adding a provider is a configuration change, not a rebuild, so the substitutability Article 29 asks about becomes a property you can demonstrate rather than assert.
The gateway runs on your own EU infrastructure, so the control plane, the routing and the audit layer are not themselves a foreign dependency. Several back-ends mean a single provider outage or withdrawal need not take the function down. The exit plan turns from a document into something you can exercise and evidence.
Your infrastructure
Your teams and workflows
Gateway
- One stable interface
- Policy enforcement
- Audit trail
Model provider A
Model provider B
Model provider C
Replaceable: a change of configuration, not a rebuild
Schematic of the implemented design.
The audit trail is where evidence lives
DORA's third-party regime runs on evidence: a register of information, ongoing monitoring, a demonstrable exit. GAIA-CORE produces a tamper-evident record of what was sent, to which back-end and under what controls, alongside live DPIA and RoPA endpoints.
In a witnessed protected-egress configuration, supported sensitive fields can be replaced with reversible tokens before external dispatch and the transaction can retain evidence of that control. The mechanism is currently default-off and residual context may still reach the provider. This supports DORA work; it does not discharge it.
The objective boundary
GAIA Brain is just short of MVP. As assessed on 10 October 2026, merged source contains 130,595 tracked TypeScript lines and the cumulative regression harness passed all 1,430 criteria. There is no official customer deployment or general-availability claim.
Protected-egress enforcement remains default-off and the final customer-hosted configuration requires witnessed gates and representative testing. No regulator has endorsed GAIA25 or GAIA Brain. If you are mapping DORA ICT risk onto your AI stack, talk to us about a bounded pilot.