What does a credible exit plan from a cloud AI vendor look like under DORA?

A credible exit plan under DORA names the replacement arrangement, proves that data, prompts, embeddings and audit logs can be extracted in usable form, sets a realistic transition timetable, and has actually been rehearsed. DORA requires financial entities to maintain documented exit strategies for ICT services supporting critical or important functions, and supervisors can be expected to ask for them for AI services on the same basis as any other ICT service. A plan that cannot demonstrate extraction and a tested destination is a statement of intent, not a strategy.

The question matters in 2026 because AI services have embedded themselves in critical workflows faster than exit planning has matured, and the proprietary formats behind embeddings, fine-tuning artefacts and audit logs make AI exit far harder to evidence than conventional ICT exit.

What does DORA actually require in an exit strategy?

DORA, in force since 17 January 2025, requires financial entities to put exit strategies in place for ICT services supporting critical or important functions. The strategy must anticipate failure or deterioration of the provider, allow the entity to exit without disrupting the function or breaching regulatory obligations, and be documented and sufficiently tested. Contracts must include termination rights and transition assistance provisions. The regulation treats concentration risk and lock-in as supervisory concerns rather than commercial preferences, which is why an untested exit plan for an AI service inside a critical function is a finding waiting to be written.

Why do most AI exit plans fail inspection?

Because the valuable state is stranded. A conventional software exit moves databases and configuration. An AI exit must also move the artefacts that make the deployment useful: embeddings built over years of documents, fine-tuning artefacts, retrieval indexes, prompt libraries, evaluation baselines and the audit logs regulators expect. Many of these exist only in a provider's proprietary formats, and some cannot be exported at all. The plan then reduces to starting again elsewhere, which is a rebuild, not a transition, and a rebuild timed by an emergency is the most expensive kind there is.

What exactly must be extractable?

We suggest listing every artefact class and testing each one for export:

• Prompts, outputs and conversation history in an open, documented format.
• Embeddings and retrieval indexes, or the source corpus and a repeatable pipeline to rebuild them.
• Fine-tuning artefacts and evaluation baselines, or evidence they can be reproduced.
• Audit and access logs, complete and verifiable, not summaries.
• Configuration, guardrails and routing rules in exportable form.

If any class cannot be extracted in usable form, the exit plan must say so plainly and cost the gap honestly, because a supervisor will find the omission faster than an incident will.

What does a rehearsed exit actually mean?

A rehearsed exit is one you have partially performed. We call it the extraction drill: export a representative slice of every artefact class, load it into the named replacement, and run the critical function against it for a defined period. Record the elapsed time, the failures and the manual effort required. A drill of this kind converts an exit strategy from a document into evidence, and it is the difference between an exit plan a supervisor accepts and one a supervisor tests for you.

Is operator-owned AI the strongest exit plan?

Largely, yes. When the AI layer runs on operator-owned hardware there is no vendor runtime to leave: the models, indexes, prompts and logs already sit on infrastructure the entity controls. Mickai is built as a Sovereign Intelligence Operating System, a SIOS, that runs offline on the operator's own machines, with every action sealed in a post-quantum signed audit ledger under FIPS 204 (ML-DSA). Exit risk does not vanish, but it changes shape. It becomes a question of licence terms and hardware, which are tractable, rather than of stranded state inside another company's cloud, which often is not.

“The strongest exit plan is an AI layer with no vendor runtime to leave.”

What exit questions still apply to on-premise vendors?

Fairness requires saying that exit planning applies to on-premise deployments too. Buyers should ask for source code or artefact escrow, licence terms that survive vendor failure, data and log formats that are documented and open, hardware independence so the system is not bound to one supplier's machines, and the ability to operate the deployment for a defined period without vendor involvement. An on-premise arrangement that fails these tests has moved the lock-in inside the building rather than removed it. The test is always the same: could the entity keep the function running, and prove its history, if the vendor disappeared tomorrow?

How the whole architecture holds together is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

What does DORA say about exit strategies for AI services?

DORA requires documented, tested exit strategies for ICT services supporting critical or important functions, and an AI service inside such a function is covered on the same basis as any other ICT service. The strategy must allow exit without disrupting the function and be supported by contractual termination and transition assistance provisions.

Why can I not just export my data from an AI vendor?

Raw data export is usually possible, but the artefacts that make an AI deployment work, such as embeddings, fine-tuning artefacts, retrieval indexes and full audit logs, are often held in proprietary formats or excluded from export tooling. An exit plan that only covers raw data leaves the expensive state behind and understates the true cost of leaving.

Does an exit plan need to be tested or just documented?

Tested. DORA expects exit strategies for critical or important functions to be sufficiently tested, and supervisors increasingly ask for evidence of rehearsal. A partial extraction drill, exporting each artefact class and running the function on the replacement, is the practical way to generate that evidence before a regulator or an outage demands it.

If I run AI on my own hardware, do I still need an exit plan?

Yes, but it is a smaller and more tractable plan. The questions become licence survivability, escrow, documented formats and hardware independence rather than extraction from a remote runtime. An operator-owned deployment holds its own state, so the hardest part of a cloud exit, recovering stranded artefacts, does not arise.

What should I ask an AI vendor before signing under DORA?

Ask which artefact classes are exportable, in what formats, at what completeness, and within what timescale; whether transition assistance is contractual; and whether the audit logs are verifiable outside the vendor's own systems. Written answers to those questions become the skeleton of the exit strategy DORA requires.