A clinical AI exit plan should explain how the organisation will continue its work when a contract ends, a supplier fails or a service changes materially. Exporting a file is only one part of that plan. The organisation also needs usable records, clear responsibilities, appropriate retention and a way to operate without the departing product.
Rehearse the end before signing the beginning
Imagine a hypothetical university using a learning platform and a hospital using a clinical assistant. Both are told that their data can be exported. Neither has checked whether the export can support the work that must continue after access ends.
The university may need learning records and evidence that learners can understand. The hospital may need approved clinical records, relevant audit information and a safe replacement workflow. The same export promise does not answer both needs.
This article provides an original exit-planning framework. It is not a statement that any named supplier is at risk of failure or that all organisations have identical retention obligations.
Inventory the things that matter
List the information and configuration that the service holds or creates. Depending on the actual product, this might include learning records, transcripts, feedback, source references, templates, permissions and audit events.
Then distinguish what belongs in the organisation's authoritative system from material held only in the supplier's environment. A draft, an approved record and a generated explanation may have different roles and retention needs.
Do not assume that everything should be exported indefinitely. The inventory should identify what is necessary, who is responsible for it and which legal, contractual or professional requirements apply. Unnecessary retention can create its own risk.
A useful question is: "Which task would fail tomorrow if this item disappeared?" The answer helps prioritise continuity rather than treating every database field as equally important.
Test whether the export is usable
A machine-readable file may be useful for migration but difficult for a clinician or learner to inspect. A PDF may be readable but unsuitable for structured transfer. Some situations need both.
Test a representative export before the end of the contract. Can the receiving system identify the person, date, activity and status correctly? Are source references and attachments preserved where needed? Does the export distinguish a draft from a reviewed record?
Do not wait until the supplier has disabled access to discover that an important field is missing. A contractual promise should be translated into an observable test, with the outcome recorded.
The test should use appropriately governed sample material, not an uncontrolled download of all patient or learner information merely for convenience.
Preserve meaning, not only rows
In the hypothetical university, a record says that a learner completed a simulation and received feedback. If the export omits the case version or scoring context, a later reviewer may misunderstand what the result represents.
In the hypothetical hospital, a generated draft may have been amended before approval. If the export preserves only the original draft, it does not represent the final clinical record. If it preserves only the final text, other required audit information may still need a separate route.
These examples show why a row count is insufficient. Check whether the exported information still answers the questions for which it is being retained. The necessary detail depends on the actual workflow and obligations.
Include content rights and subcontractors
A service may display licensed reference material that cannot simply be carried into a replacement product. Establish which outputs and records can be retained and which source content remains subject to separate rights.
Also identify dependencies on model providers, hosting services and other subcontractors. The organisation may not contract with each one directly, but their role can affect continuity, deletion and access.
The NCSC cloud-security principles, checked on 19 September 2026, provide a foundation for examining operational assurance, supply-chain responsibilities and service use. The exit checklist here is an additional practical framework, not an official NCSC certification process.
Ask what happens if a dependency changes before the main contract ends. A supplier may remain in business while losing an important capability or content source.
Separate termination from deletion
Account closure, withdrawal of access and deletion are not necessarily the same event. Clarify what remains, for how long, in which systems and for what reason. Include backups and records that may need to be retained under applicable obligations.
The ICO's current anonymisation guidance, checked on 19 September 2026, also matters where a supplier proposes retaining "de-identified" material. That label alone does not establish that the information is anonymous.
Do not promise immediate deletion of every copy if the actual arrangements are different. Conversely, do not accept indefinite retention justified only by a vague wish to improve the product. The contract and operational process should be specific enough for the organisation to understand and oversee.
Rehearse a short interruption and a permanent exit
A short outage may require a temporary fallback. A permanent exit requires a replacement process, communication and transfer of responsibilities. Test both rather than assuming one continuity document covers everything.
For a clinical service, identify how staff will complete the intended task without the AI function and where approved information remains available. For an educational programme, establish how learners access necessary records and continue required activities.
Assign an owner for the exit decision and the rehearsal. Record unresolved dependencies before they become urgent. An exit plan that nobody can execute is only a contract appendix.
What iatroX documents, and what it does not establish
This article is published by iatroX and applies the same transparency standard to its own service. The CPD page checked on 19 September 2026 describes PDF export, direct export to linked FourteenFish accounts and continued access to completed learning evidence after a subscription ends.
Those statements concern the documented CPD workflow. They should not be extended into a guarantee about every transcript, configuration, institutional migration or supplier-failure scenario. Organisational buyers should request the arrangements relevant to their proposed use.
For an individual learner, retained completed evidence can be useful. For a university or hospital, the decision requires a broader account of data, rights, continuity and responsibilities. The sensible time to establish that account is while both parties still expect the relationship to continue.
Frequently asked questions
Is a data-export clause enough for an exit plan?
No: test whether the export preserves the information and meaning needed for ongoing work. Continuity, rights, retention and responsibilities also matter.
Does ending a subscription mean every record is immediately deleted?
Not necessarily: access and retention arrangements differ. Check the specific contract, policy and applicable obligations rather than assuming they are identical.
Does iatroX's CPD export promise cover every type of platform data?
The published statement concerns its CPD evidence workflow. Wider migration or organisational requirements need separate confirmation.
Review a clinical AI continuity or exit question with iatroX Insights →