AI cloud exit contracts under the EU Data Act

The legal and engineering teams should record what the customer buys and how the supplier delivers it. The statutory definition requires ubiquitous, on-demand network access to shared, configurable, scalable and elastic computing resources. Those resources must support rapid provisioning and release with minimal management effort or provider interaction. Software and platforms can qualify alongside infrastructure. A consultancy delivering occasional analyses needs a different assessment from an on-demand AI application. Obtain the service description, architecture, provisioning process and accepted terms before deciding. (Data Act, art 2(8), recitals 80–81.)

An EU customer's covered service remains within scope when the supplier is established elsewhere. A supplier without an EU establishment must also designate the required EU legal representative. Record that representative's details in the contract file. The switching provisions have applied since 12 September 2025; Article 50's separate contract-age rules for unfair data terms do not postpone Chapter VI generally. (Data Act, arts 1(3)(f), 37(11)–(13), 50.)

Check the source and destination's primary objective, service model and main functionalities. These determine whether they provide the same service type, a distinction relevant to the technical switching duties. The contract should name each affected service and any retained services. A supplier using another cloud provider remains responsible for its own covered offering. (Data Act, arts 2(9), 23–24, 30, recital 91.)

Two special regimes require evidence:

• A service qualifies for the bespoke regime where most main features were custom-built for one customer's needs, or all components were developed for that customer, and the service is not offered broadly through the supplier's catalogue. Article 31(1) disapplies specified duties, including Article 29's switching-charge rules and specified equivalence and interoperability duties. Written exit terms, reasonable assistance and other applicable obligations remain. A customer-specific configuration or fine-tune does not by itself establish this test.
• Chapter VI does not apply to a non-production version supplied for testing and evaluation for a limited period. Free access alone does not establish that exclusion. Customers using free-tier offerings otherwise retain the relevant switching protection. (Data Act, arts 23(c), 25, 31.)

The provider must disclose the applicable Article 31 exclusions before contracting. Procurement should require a written explanation identifying the service and facts relied on. If an exclusion applies, negotiate the missing protection expressly, including a fee ceiling where Article 29 does not apply. (Data Act, art 31(3).)

The inventory should record each item's location, format, rights, personal-data content and destination dependency. Exportable data includes inputs, outputs and metadata generated directly or indirectly through the customer's service use. The definition excludes provider or third-party material protected by intellectual property rights or trade secrets. Digital assets require a right of use independent of the departing service contract. (Data Act, arts 2(32), 2(38).)

Use the following categories when negotiating the schedule:

• Prompts and customer content: stored instructions, uploaded files, conversation records, retrieval documents and customer-supplied training or evaluation data. Identify the retained versions and any rights restricting reuse.
• Outputs and service records: generated responses, customer feedback, job results, timestamps, usage records and relevant metadata. Specify schemas, identifiers and relationships needed to interpret the export.
• Configuration and customer applications: prompt templates, tool definitions, workflows, retrieval mappings, deployment manifests and access settings. Check independent use rights and identify dependencies. Replace credentials through a controlled process instead of copying shared supplier secrets.
• Fine-tuned components: training datasets, adapters, checkpoints, weights and evaluation records, item by item. Record whether each exists, can be separated, and can lawfully operate with the proposed base model and runtime.
• Provider and third-party technology: foundation models, proprietary orchestration, service software and internal security material. Identify what stays with its owner and what additional permission or replacement is needed.

These categories guide classification; they do not make every listed item exportable. The provider's contract must exhaustively identify portable categories and specified internal-functioning categories withheld because of trade-secret risk. Those internal exclusions must not impede or delay switching. Ask for a category-specific explanation and a separable export where protected material is mixed with customer records. A blanket reference to proprietary technology does not complete the statutory exercise. (Data Act, art 25(2)(e)–(f).)

Fine-tuning requires particular care. A customer may hold an independently usable adapter while the base model remains licensed only through the supplier's API. Another service may hold a checkpoint that contains inseparable provider material. The legal team should trace the relevant rights and obtain any necessary licence covering the replacement operator, locations and permitted uses. If the required permission is unavailable, the engineering team must plan replacement or retraining using lawfully usable material. The Data Act does not require disclosure or transfer of protected digital assets, development of new technology, or compromise of service security. (Data Act, arts 1(8), 2(32), 2(38), 30(6).)

Where software or technology leaves the UK, including by electronic transmission, the supplier should classify it and check recipients, end users and end use. Obtain any required export licence before controlled delivery or overseas access. Hosting location alone does not resolve that assessment. (Export Control Joint Unit, UK strategic export controls, sections "Control lists" and "End-use controls"; Exporting military or dual-use technology: definitions and scope, section "Technology transfer: scope".)

Require a sample export and documentation before approving the exit schedule. For non-infrastructure services, Article 30(2) requires open interfaces free of charge. Article 30(5) requires a structured, commonly used, machine-readable export on request for same-type switching where the specified standards or common specifications have not been published. Where relevant specifications have been published, check their application timetable under Article 30(3). The supplier must also provide switching information and an up-to-date register of formats and structures. Agree exact formats and conversion work against that evidence. (Data Act, arts 26, 30(2)–(5).)

The customer should appoint an exit owner and obtain the destination provider's migration plan before serving notice. Record the affected subscriptions, destination details, export categories and authorised migration contractors. Article 25 requires written switching terms that the customer can store and reproduce before signing. Those terms must support the customer's exit strategy. (Data Act, art 25(1)–(3).)

The schedule should distinguish four stages:

1. Notice. The period before switching begins cannot exceed two months. Record receipt and the resulting start date. The customer can choose another provider, its own infrastructure, or erasure on termination.
2. Transition. Switching must occur without undue delay and ordinarily within 30 calendar days after the notice period. The source contract remains applicable during this period.
3. Retrieval. After the agreed transition ends, the customer must have at least 30 calendar days to retrieve data. Retrieval access is a separate obligation from continued production service.
4. Erasure. Following a successful switch, the contract must guarantee erasure of the specified customer-related exportable data and digital assets after retrieval expires, or after a later period agreed by the parties. Personal-data duties must be reconciled with this timetable. (Data Act, art 25(2)(a), (d), (g)–(h), (3).)

If the ordinary transition is technically unfeasible, the provider must notify the customer within 14 working days of the switching request. It must justify that conclusion and specify an alternative transition no longer than seven months. The customer separately has a right to extend the transition once for a period appropriate to its purposes. The provider's seven-month ceiling does not define that customer-selected extension. Put the justification, dates and continued service obligations in writing. (Data Act, art 25(4)–(5), recital 87.)

During transition, the provider must give reasonable assistance to the customer and authorised third parties. It must exercise due care to maintain continuity, continue contracted functions, identify known continuity risks and maintain security through switching and retrieval. All participants, including the destination provider, must cooperate in good faith. The schedule should allocate extraction, transformation, import, testing, incident response and the final synchronisation of changed records to named owners. (Data Act, arts 25(2)(a)–(b), 27.)

Agree a test export, a rehearsal, the final update method and a rollback decision before cutover. Any restriction on service changes during migration should be negotiated expressly. Define emergency exceptions, notification and recovery responsibilities. These operational commitments make the assistance obligation measurable; their exact technical content depends on the service and agreed terms.

For services governed by Article 29, the provider can currently charge only costs directly linked to the switching process. From 12 January 2027, switching charges are prohibited. The definition includes charges for mandated switching actions and data egress. The supplier should identify the legal category, calculation and evidence for every proposed exit charge. The contract should implement the date change expressly. (Data Act, arts 2(35)–(36), 29(1)–(4).)

Standard service fees and early-termination penalties are outside that definition. Their exclusion does not validate every amount demanded. The parties should assess the actual term, its proportionality and applicable contract law, alongside the duty to remove switching obstacles. A fixed-term subscription may therefore carry payment consequences even where the export itself must be free. Require a separate calculation for accrued fees, minimum commitments, any termination payment and switching work. (Data Act, arts 23, 29(4), recital 89.)

Additional migration services beyond statutory duties can be separately priced when the customer requests them and agrees the price in advance. Identify the additional deliverable. A mandatory export or assistance task cannot become an optional paid service merely through a different invoice description. The source provider's outsourcing arrangements should not introduce an unsupported charge for its own obligations. Qualifying bespoke services need their own negotiated cost protection because Article 29 is disapplied. (Data Act, arts 2(36), 29, 31(1), recital 89.)

Continuing to operate two providers can create genuine subscription costs at both. Ongoing parallel use also has a separate rule permitting egress charges limited to incurred egress costs. Distinguish that arrangement from the switching process and its applicable fee rules. (Data Act, art 34(2), recital 99.)

The business owner should approve a continuity budget tied to the timetable and the customer's extension decision. Negotiate support capacity, service levels, escalation contacts and responsibility for avoidable delay. Identify which promises bind the source provider and which need a direct commitment from the destination. The Act limits the source provider's relevant responsibilities to its own services, contracts and practices. (Data Act, arts 24–25.)

The acceptance process should distinguish delivery of the export from readiness of the replacement service. For the first, check completeness against the inventory, file integrity, schema usability, metadata and permitted access. For the second, test the agreed workload, integrations, output quality, latency and access controls in the destination environment. The contract should identify who accepts each deliverable, the evidence required, a defect process and the consequence of failure.

For infrastructure services within Article 30(1), the source provider must take all reasonable measures within its power to help the customer achieve functional equivalence. That standard concerns materially comparable outcomes for shared features of the same service type. It does not require rebuilding the destination service. The equivalent statutory obligation does not extend to AI SaaS merely because the customer expects the same answers. (Data Act, arts 2(37), 24, 30(1), (6), recitals 86, 92.)

If a migrated fine-tune fails, identify the cause. Missing exportable records or unperformed agreed assistance can support a demand for the omitted performance. A substitute model's different behaviour does not by itself establish a source-provider breach. For stronger protection, negotiate benchmark conditions, model and runtime versions, tolerances, retesting, further assistance and agreed remedies. Specify which party bears replacement or retraining costs. Do not accept an identical-output warranty without evidence that the provider can perform it.

Where Irish law governs a covered business service contract, the 1980 Act implies necessary skill and performance with due skill, care and diligence. Section 40 permits variation or exclusion of relevant terms in business contracts. Review the actual exclusions and agree express export, assistance and remedial commitments. Those statutory terms do not establish a promise of identical model performance. (Sale of Goods and Supply of Services Act 1980, ss 39(a)–(b), 40(1)–(2).)

Preserve notice records, export manifests, failures and correspondence. The customer's legal team can pursue a complaint under Article 38 for infringement of Data Act rights and assess contractual relief under the chosen law and dispute clause. Article 39 concerns review of competent-authority decisions or inaction; it does not itself supply a universal damages remedy against suppliers. (Data Act, arts 38–39.)

Personal data needs a coordinated instruction. The controller should approve the data categories, purposes, recipients and necessary processing terms before transfer. A processor needs authorisation for subprocessors and must impose the required obligations downstream. A replacement processor engaged directly by the customer is not automatically the departing supplier's subprocessor. Confidentiality duties should reach everyone handling prompts, logs, training files and transferred components. (GDPR, arts 4(7)–(8), 5–6, 9, 28(2)–(4), 32.)

Assess model files as well as datasets. The EDPB's Opinion calls for a case-specific assessment before treating an AI model as anonymous. Both direct extraction of training-related personal data and obtaining such data through queries must present insignificant risks, considering reasonably likely means. Removing the original training files does not establish those conditions. Record the assessment and any required controls before releasing adapters or weights. Licentium's data protection for AI service covers the related processing, transfer and retention work. (EDPB, Opinion 28/2024, paras 34, 43–48.)

For an England-based supplier moving personal data to an Irish replacement provider, UK law recognises EEA destinations for the relevant transfer route. Any continued EU-to-UK disclosure or remote access requires its own EU assessment. The EU's UK adequacy decision currently runs until 27 December 2031, within its scope. Map any further overseas support or subprocessor access separately. Adequacy does not replace lawful processing, security or the required processor agreement. (Data Protection Act 2018, sch 21, paras 4(1), 5(1)(a); Decision (EU) 2021/1772, arts 1, 4, as amended by Decision (EU) 2025/2574; GDPR, arts 28, 32, 44–46.)

At the end of processing services, Article 28(3)(g) requires the processor, at the controller's choice, to return or delete personal data and delete existing copies, unless Union or Member State law requires storage. The exit schedule should reconcile that choice with the retrieval period and identify any legally required retention by category, legal basis and duration. Do not permit indefinite retention through a general backup clause. Specify backup expiry, restricted access, restoration controls and renewed deletion after restoration. A technical difficulty does not create a general statutory exception. (GDPR, arts 5(1)(e), 28(3)(g); Data Act, arts 1(5), 25(2)(g)–(h).)

Close the exit with an accepted delivery record, termination notification, revoked access and documented deletion. Under Article 25, successful switching triggers contractual termination where applicable; the separate erasure-only route has its own trigger at the end of notice. Preserve the agreed remedies for unresolved defects without leaving completion dependent on undefined expectations about another model. (Data Act, art 25(2)(c), (3).)