Exit strategies and portability when contracting AI in public administration

Why plan for the exit from the outset

AI projects for public bodies often involve sensitive data, technical dependencies and legal obligations (ENS, GDPR, Law 9/2017 and the EU AI Act requirements for high-risk systems). If an exit strategy is not built into the procurement and the architecture, vendor lock-in can lead to loss of control over data, service interruptions and high costs when changing providers.

Planning the exit is not optional: it's risk management. Below is a set of contractual, technical and operational measures that administrations can require and verify before and during procurement.

Essential contractual clauses

• Data delivery and portability: obligation for the provider to export data in open, documented formats (CSV/NDJSON for records, standardized formats for metadata and traces). Define timelines and export costs.
• Delivery of AI artifacts: specify what will be delivered on termination—model weights (ONNX, exported PyTorch/TF), inference code, Docker containers, retraining scripts and infrastructure specifications.
• Technical and code escrow: custody deposit of code, models and keys to be released under predefined conditions (bankruptcy, breach, end of contract).
• Transition SLA: hours of support, knowledge transfer and training for the administration during the handover period; prices and maximum timeframes.
• Periodic exit tests: right to audits and partial migration exercises (e.g., annual) at no additional cost.
• Intellectual property and licensing rights: clarify licenses for models and components; avoid clauses that prevent internal reproduction or deployment.
• Limited confidentiality: ensure NDAs do not block the administration's access to information needed for operational continuity.
• Penalties for lock-in: financial clauses if the provider impedes portability or technical transfer.

These clauses can be included in tender documents and contracts under Law 9/2017 of Public Sector Contracts; coordinate with the legal team from the specification phase.

Technical requirements to facilitate migration

• Open interfaces and versioned APIs: avoid proprietary protocols. Public documentation of the API and data schemas.
• Native exporters: the system must allow exporting datasets, logs, metrics and training metadata in standard formats.
• Containers and IaC: reproducible packaging (Docker/OCI) and infrastructure as code (Terraform, Ansible) to recreate environments.
• Model cards and data sheets: technical documentation for models (architecture, datasets, hyperparameters, performance) to ease retraining and evaluation.
• Reproducible pipelines: clear definition of ETL and ML pipelines (e.g., with MLflow, Airflow) and the ability to export pipeline definitions.
• Access to logs and traceability: inference logs and decision records, with retention policies that allow audits and continuity checks.
• Open or manageable dependencies: list of dependencies and versions; avoid components with restrictive licenses that block migration.

Testing and verification: don't assume, demonstrate

• Migration dry run: contractually include a full test migration to a staging environment, with defined acceptance criteria.
• Verification checklists: complete data, integrity checks, latencies, comparable inference outputs and deployment documentation.
• Functional and legal validation: tests for consent and data processing under the GDPR; verification of continuity against ENS requirements.
• Periodic external audits: include an annual third-party audit to verify that portability mechanisms are effective.

Governance and knowledge transfer

• Knowledge transfer (KT) plan: training for internal teams, runbooks, incident playbooks and escalation contacts.
• Mixed team during the exit phase: administration and provider technicians working together for the first operational cycles.
• Budget reserved for transition: include funds for temporary integrators or for post-termination support in the planning.

Quick "Exit plan" checklist (suggested timeline)

1. Before the contract: include portability, escrow and migration test clauses.
2. During the contract (every 12 months): export a complete copy and run a partial migration exercise.
3. 90 days before termination/resignation: execute a full migration to a staging environment and validate it.
4. 30 days: final data transfer, handover of models, training and orderly shutdown.
5. Post-migration (30–90 days): provider support according to the transition SLA and verification of KPIs.

Regulatory compliance to consider

• GDPR: guarantee rights of access and portability for personal data; procedures for orderly deletion where applicable.
• ENS (RD 311/2022): security requirements that must be maintained on the new platform; document equivalent measures.
• Law 9/2017: respect public procurement frameworks and justify technical and economic clauses in the procurement file.
• EU AI Act: for high-risk systems, retain the technical documentation and records needed for compliance after transition.

Conclusion and recommended next step

A planned exit combines three elements: concrete contractual clauses, verifiable technical requirements and periodic migration exercises. Immediate action: include a "migration dry run" clause in the next tender and schedule an annual export of data and artifacts. If desired, OptimTech can share a technical and contractual checklist adaptable to your procurement file and the ENS assessment of the project.

Takeaway: don't sign an AI contract without a tested exit plan — include technical portability, escrow and migration tests in the tender and verify them periodically.