Clicksov
Book a call

Buying AI under DORA: the exit strategy belongs in the contract

Published · 6 min read

If you are a bank, insurer or other financial entity in the EU, DORA applies to the AI workflows you buy. Once such a workflow supports a critical or important function, you need an exit strategy for it. Most AI vendors do not offer one. This article explains what DORA asks, why AI contracts rarely meet it, and what to put in the contract instead.

What DORA asks of exit strategies

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. Chapter V covers ICT third-party risk. Article 28 sets the general principles, and paragraph 8 is the one that matters here. In plain terms:

  • For ICT services that support critical or important functions, the financial entity must have exit strategies.
  • Those strategies must consider the risks that may arise at the provider, including failure, deterioration of service quality, business disruption and termination.
  • The entity must be able to exit without disrupting its business, without breaching regulatory requirements and without harm to the continuity and quality of its services.
  • Exit plans must be comprehensive, documented, tested where appropriate and reviewed periodically.
  • The entity must identify alternative solutions and develop transition plans so that it can remove the contracted services and data from the provider and transfer them to another provider or bring them in-house.

Note the words: documented, tested, periodically reviewed. A paragraph in a contract that says "the provider will cooperate on termination" does not meet this.

Whether an AI workflow supports a critical or important function is your own assessment. A claims intake workflow that prepares files for handlers may not be critical on day one. A workflow that sits in the path of every payout probably is. The assessment should be written down either way.

Why AI vendors rarely deliver it

Three reasons, none of them malicious.

The product is a service, not an artefact. Many AI vendors sell access to a hosted application or API. There is nothing to hand over; the value sits in their platform. An exit means you start again.

The model and the prompts are the product. Vendors that fine-tune on your data often keep the resulting weights. Prompts and evaluation logic live in their system. When you leave, you leave with your raw data and little else.

Nobody tested the exit. Even where a contract mentions one, it is rarely rehearsed. The first time anyone tries is the day the relationship ends, which is the worst possible day to find out it does not work.

What an exit package should contain

Clicksov writes the exit package into the contract and keeps it current with every release. On leaving, the customer receives:

  • The workflow repository. One versioned repository with the specification and prompts, the domain model and your customer-specific mapping, the model manifest, the evaluation set (golden examples and thresholds), the deployment (Helm charts and an infrastructure module per certified partner), the policy (data residency, retention, guardrails, AI Act documentation) and the day-2 runbook. Signed, with a software bill of materials (SBOM).
  • Container images. The images that run the workflow, so a new team can deploy the same thing.
  • Model references, including any fine-tunes on your data. If a model was adapted using your data, the result is yours.
  • A data export in open formats.

The point is that an exit is a handover, not a rebuild. Another team, your own or a different vendor's, can take the repository and run it.

How to test it: switch drill and portability test

A documented exit that has never run is a hope, not a strategy. Two tests make it real.

Portability test, every release. Every release of a Clicksov workflow is deployed to at least two cloud partners and one on-premise reference, and must pass the same evaluation set on each. Every model swap starts with the evaluation set. Infrastructure partners enter the catalogue only after passing the reference test. This is possible because the workflow is built on open interfaces: Kubernetes, OCI images, Helm, GitOps, an OpenAI-compatible API behind an AI gateway, open data formats, OpenTelemetry tracing and OIDC single sign-on. The CNCF's Kubernetes AI Conformance programme, launched in November 2025, points the same way: AI workloads that run the same across environments.

Switch drill, once a year per customer. Once a year, the workflow is moved to another certified partner or to the on-premise reference, and the evaluation set is run again. The result is written down. That record is what you show a supervisor who asks whether your exit plan has been tested.

The Data Act angle: switching fees

DORA tells you to be able to leave. The EU Data Act makes leaving cheaper. Its switching rules for cloud and other data processing services have applied since 12 September 2025. From 12 January 2027, providers may no longer charge switching fees, including egress fees, for a one-off switch to another provider or to on-premise. Until then, fees are capped at the provider's direct costs. Some charges remain allowed, such as egress for ongoing multi-cloud use and extra switching support you agreed to in advance.

For AI workflows this matters twice: for the infrastructure partner that hosts the workflow, and for any AI vendor whose service falls under the definition of a data processing service. In both cases the contract should state that a one-off switch carries no egress charge.

A five-point contract checklist

  1. Classification. Write down whether the workflow supports a critical or important function, and who decided.
  2. Exit package, itemised. Repository, images, model references including fine-tunes, data export. Named in the contract, with formats.
  3. Currency. The package is updated with every release, not assembled on termination.
  4. Test. A yearly switch drill with a written result, plus a portability test on every release.
  5. Fees. No egress or switching charge for a one-off switch, in line with the Data Act from 12 January 2027.

How Clicksov handles it

Clicksov takes one workflow at a time into production for regulated organisations and runs it on European partner infrastructure or on your premises. The exit package, the portability test and the yearly switch drill are part of the standard offer and are written into the contract. Data and models stay in the EU, keys stay in your own KMS or HSM, and no training happens on your data. Sovereign, in the sense that you can leave.

Want to see what an exit package looks like for your workflow? Book a conversation.

Sources

Which process do you want to take live?

Book a call