Leaving an AI vendor? Secure your data and access before you terminate

Ending an AI supplier relationship can create a bigger operational problem than signing the replacement. If your team relies on the platform for customer interactions, internal workflows or stored prompts, a poorly timed exit can cut off records, settings and access your business still needs to keep operating.

Before you send notice, confirm what can be exported, how long access stays open, whether read-only use is available, what transition help will cost, and how deletion will be handled. That matters because a promise to return data does not always include prompts, logs, configurations or migration support in a format your next system can use.

In Australia, the answer usually sits across both contract and privacy issues. Your signed terms may deal with expiry, early termination, notice periods, retrieval windows and assistance fees. If personal information is involved, privacy obligations can also affect security, retention, destruction and verification steps with the supplier.

This article focuses on what to lock down before termination takes effect, what you can and cannot safely assume, and why testing the handover matters. This article is general information only and is not legal advice.

What to lock down before you send notice

Start with a practical exit inventory. In AI arrangements, that usually goes well beyond asking for a data dump.

Write down exactly what your business needs to get back, keep using for a short period, or verify as deleted. A useful checklist usually includes:

• customer or internal datasets uploaded into the platform
• prompts, prompt libraries, system instructions and templates
• outputs your team needs to retain for operations, customer support or compliance
• settings, rules, automations and workflow configurations
• integrations, API connections, webhooks and credentials that need replacement or rotation
• logs and audit material used for troubleshooting, accountability or internal review
• information handled by subprocessors or connected third parties
• customer-facing dependencies, such as chat assistants, triage flows or document generation, that cannot stop abruptly

This matters because export, usable format, workflow handover, ongoing access and deletion are different promises. The Australian Government Architecture exit-planning checklist, written for agencies rather than private businesses, asks directly about prompts, logs, configurations, model artefacts, portability, transition rights and continuity. Those are useful questions to put to your AI supplier, but the checklist does not itself give a private customer legal rights. A contract may deal with one, some or none of them. Even where the vendor agrees to provide data back, that does not always mean the export is complete, structured or useful in another system.

The first decision is how the contract is ending

Your rights and timing depend on the agreement you actually signed and the facts on the ground. Do not assume you can end the contract whenever you choose or retrieve every vendor-held asset without extra cost.

Before anyone sends a termination or non-renewal notice, identify the path you are using. In practice, AI contracts often end because the fixed term is expiring, because one side wants an early commercial exit, because there is an alleged breach, or because both sides are prepared to negotiate a managed handover.

Review whether the signed documents deal with notice, expiry or non-renewal, alleged breach, any fee for early exit, and post-termination access or assistance. The answers vary by contract and facts. The government guide to ending a contract explains common ways a contract can finish. Confirm your own signed terms and obligations before setting a cutover date.

That includes the main agreement, order form, service description, privacy schedule, any data processing terms and later variations. Do not focus only on the headline termination clause: check for a retrieval window, any assistance fee, and any limit on continued access after the account closes.

Also avoid treating non-payment, disabling user seats or engaging a replacement supplier as if those steps alone cleanly end the existing deal. They may not. Ongoing confidentiality, licence limits, accrued fees and return or deletion obligations may still need to be dealt with under the contract.

What you can ask for, and what you should not assume you own

A well-drafted AI supply contract can address data return or export, deletion, transition assistance and some level of post-termination access. But those rights are not automatic just because your business paid for the service.

An AI vendor environment can contain uploaded material, service outputs, configuration, logs and supplier-created tooling. Make a separate list of each item your business needs after exit, then check which export, access and transition promises the signed documents actually cover.

For that reason, separate the vendor environment into at least four categories:

• your source material, such as uploaded business data, customer records or documents
• business records produced through the service, such as reports, support transcripts or customer communications
• configurations and workflows that may sit between customer content and supplier tooling
• vendor-owned software, models, connectors and know-how that may not be transferable

That separation helps you ask better questions. Can your data be exported? In what format? Will prompts and configuration data be included? Is there read-only access after active use stops? Is migration help available? Can the vendor give a deletion confirmation, or only explain its standard process?

Ask for clear written answers to those access and export questions. The government exit-planning checklist prompts agencies to identify contractual constraints and export limitations; a private business can use those questions to review its own agreement, without treating the checklist as a source of contractual rights.

Test the handover before you commit to an exit date

The most expensive mistake is setting the end date first and discovering the handover problem later. A safer sequence is to map the contract, test an export, price transition help, set milestones, and then line up the formal notice.

Start by asking for a sample export while the relationship is still live. A test run may reveal missing fields, unreadable formats, incomplete conversation history or logs that are technically available but practically useless. If prompts or configurations matter to your workflow, verify that they can be extracted in a form your replacement system can actually use.

Next, check whether transition support is included or only available for an extra fee. Some vendors will provide technical assistance, staged account closure, limited continued API access or staff time for migration. Others will not. If customer operations depend on the tool, spell out who does what, by when, and what assumptions are being made about your internal team.

A concrete example helps. Imagine the AI service triages incoming customer requests and routes them to the right people inside your business. If that process stops overnight, requests may sit unassigned, response times may slip and customer commitments may be missed. Do not assume there is an overlap period simply because the service is business-critical. If you need one, the contract or a negotiated exit arrangement should say so.

That overlap could take different forms depending on the system. It might be a short read-only period, a limited retrieval window, staged user access changes, or continued access to a narrow set of functions while the replacement goes live. The point is to negotiate a safe landing, not to assume the law supplies one.

Privacy obligations matter, but they do not replace the contract

If personal information is involved, data privacy law can shape part of the exit process. But it does not turn privacy compliance into a full substitute for contract planning.

For APP entities, APP 11 requires reasonable steps to protect personal information. If the information is no longer needed for any purpose for which it may be used or disclosed under the APPs, the entity must take reasonable steps to destroy or de-identify it, unless it is a Commonwealth record or Australian law or a court or tribunal order requires retention. The OAIC guidance says that if an organisation instructs a third-party cloud provider to irretrievably destroy personal information on its hardware, reasonable steps include verifying that this has happened.

Where APP 11 applies, check the privacy duties separately from the commercial export and access arrangements. The practical exit plan needs to address both: protecting and appropriately disposing of personal information, and agreeing the records and settings to be retrieved before access closes.

For electronic personal information that cannot be irretrievably destroyed, the OAIC describes de-identification or putting information beyond use as possible reasonable steps. Ask the supplier to explain and document its proposed method, including how it will handle backups. The contract alone does not settle whether those steps meet the applicable privacy duties.

The OAIC's Guide to securing personal information is useful as risk-management guidance. It encourages organisations to understand what personal information they hold, where it sits, and how third-party providers affect security and continuity. That is valuable for planning an exit. But it is not a statutory AI-vendor exit checklist, and it does not by itself answer what export, access or migration support the supplier owes you.

Settle the handover before notice

Bring the contract, technical and operational owners together before notice is sent. Confirm the exit route, test what can actually be exported, price any transition help, and ask whether a short retrieval or read-only period is needed. Put the agreed format, milestones, assistance fees and deletion or retention confirmation in writing; none should be assumed merely because the service is ending.

Key Takeaways

• Work out how the contract is ending before you send notice, because timing, fees and post-termination rights depend on the signed terms and the facts.
• List the assets you actually need back, including prompts, outputs, logs, configurations, integrations and customer-facing workflows, not just core datasets.
• Check which written export, access and transition promises cover each item; do not assume a general data-return clause supplies a complete migration package.
• Test exports and confirm any read-only period, transition help, milestones and costs before locking in an exit date.
• If personal information is involved, privacy obligations may affect destruction, de-identification and verification steps, but they do not replace the contract.

If you are leaving an AI vendor, Sprintlaw can help with an AI vendor risk review, termination rights, transition assistance, data access and deletion terms, and the replacement supplier contract. Call 1800 730 617 or email team@sprintlaw.com.au.