Exit planning: what happens to your data and your agents if you leave OpenAI

Your procurement process has an exit question for everything else. Someone can tell you what happens to the records in the CRM if you switch, roughly what it would cost to move payroll, and what notice the ERP contract requires. That discipline exists because those systems arrived through a process that asked.

AI did not. It arrived on a card, in a browser tab, one team at a time, and reached production without anyone being asked. So the exit answer does not exist, and in most companies nobody has noticed that it does not exist.

The question is simple enough to write down. If we had to leave in two years, what comes with us, what does not, and what would it cost to rebuild the difference. None of what follows is an argument for leaving OpenAI. Some lock-in is a fair price for capability, and pretending otherwise is not useful. The point is that it should be a cost you priced, not a discovery you make in the third week of a migration.

What comes with you is the work that already lives in your own estate

Start with the reassuring half, because it is larger than most people expect.

Your source code is yours. Your data, in your own database, is yours. The integration layer you built (the queues, the schema mapping, the retry logic, the code that decides which record gets written and when) is the expensive part of most AI deployments, and it is entirely portable, because the model is one call inside it.

Your prompts are yours if you kept them in your repository. Your evaluation set is yours if you built it as files under version control. If you fine-tuned a model, the training data you assembled is yours and works with any vendor, which is usually worth more than the resulting model.

OpenAI is explicit about ownership. Its enterprise privacy page states that "you retain all rights to the inputs you provide to our services and you own any output you rightfully receive from our services to the extent permitted by law". That settles the question of rights.

It does not settle the question of possession. Owning something held in a system you are leaving is only useful if there is a mechanism to get it out, and that is where the rest of this piece lives.

What stays behind is anything held in a vendor-side object

The pattern is consistent across every vendor, and once you see it you can apply it to any tool your team adopts next. Whatever you configured inside the vendor's interface belongs to the vendor's interface.

None of that is unreasonable behaviour by a vendor. It is what a software-as-a-service product is. It only becomes a problem when a company assumes the opposite and finds out at the worst moment.

On ChatGPT Business, OpenAI's own help centre says export is not available

This is the finding most likely to surprise a buyer, and it is stated plainly in two current help centre articles rather than buried in a contract.

"Data export is not available in a ChatGPT Business workspace." The same article answers the direct question, "Can I export data before I leave or after I merge?", with "No."

Three related constraints sit alongside it. "ChatGPT Business does not support merging one Business workspace into another." "GPTs created in one Business workspace cannot be transferred to another Business workspace." And if a workspace is deactivated (a cancelled subscription or a failed payment will do it) you can start a new one, but "the old data cannot be merged into the new workspace. The new workspace starts as a blank slate."

Read together, those sentences describe something wider than leaving OpenAI. They describe what happens in a restructure, an acquisition, a domain change, or a lapsed card. Exit is not only the day you switch vendor.

One inconsistency worth flagging rather than papering over. OpenAI's enterprise privacy page describes ChatGPT Business admins as able to "view, access, export, and delete end user conversations in the workspace", which reads differently from the help centre articles above. Those articles are the more specific and the more recently updated, and one of them states that members cannot automatically view other members' private chat history, without addressing what an administrator can see. We cannot reconcile the two from published sources. If your plan depends on being able to export, put the question to OpenAI in writing before you sign rather than settling it by reading.

On Enterprise the export route exists, and it keeps thirty days

ChatGPT Enterprise and Edu have the Compliance Platform, which is the real answer for a business that needs its interaction record outside the vendor. It provides logs and metadata you can feed into eDiscovery, data loss prevention or security tooling, and it is sold through OpenAI's sales team rather than switched on in settings.

The line that matters for exit planning is this one: "The Compliance Platform retains data for 30 days. If longer retention is desired then consumers should implement a system to continuously download all logs and retain them according to their policies."

The export capability is a pipe, not an archive. Build the pipe on day one and you hold your own history, so exit is a non-event. Decide at exit that you would like the last two years of interactions and the decision has arrived about twenty-three months late.

Prompts in a dashboard are the whole problem in a single artefact

The cleanest example available is unusually concrete, because both halves come from OpenAI's own documentation.

The Assistants API retires on 26 Aug 2026. OpenAI's migration guide maps assistants onto prompt objects and tells you to "Find these in the dashboard and click Create prompt". Follow that instruction and your configuration moves from one vendor-side object into another one.

Separately, on its deprecations page, OpenAI announced on 03 Jun 2026 that reusable prompt objects are being deprecated, with the v1/prompts API and the objects themselves "scheduled to shut down" on 30 Nov 2026. OpenAI's own recommended migration is to move reusable prompt content into your application code.

Keeping prompt text in your repository is therefore the portability answer and the deprecation answer at once. It costs a developer nothing to paste a prompt into a file instead of a text box, and it saves the same developer a week of archaeology later.

The same logic applies to evaluation sets. AgentKit's Evals become read-only on 31 Oct 2026 and both Evals and Agent Builder are scheduled to shut down on 30 Nov 2026. An evaluation set built inside a vendor tool has a lifespan set by the vendor. One held as files in your repository runs against any model, and it is the most useful thing to own when you are assessing a replacement.

In fairness, the same wind-down shows what good looks like. Agent Builder lets you export a workflow as Agents SDK code in TypeScript or Python, with the honest caveat that the process "does not convert your workflow graph or guarantee that every behavior transfers unchanged". A vendor handing you working code is a portable artefact. Note how rare that is on the list above.

The workspace-agent question, asked honestly

A large amount of work that used to need engineering now runs on a subscription. Workspace agents, which OpenAI introduced on 22 Apr 2026 as an evolution of GPTs, cover schedules, automatic triggers, running while the user is offline, Slack, connected apps, write-action approvals, shared editing and version history. If a workspace agent does the job you are considering, use it. We would rather say that than sell you a build you do not need.

Price the exit alongside it. OpenAI's workspace agents documentation covers duplicating an agent, reviewing and republishing earlier versions, and permanent deletion ("this action cannot be undone"). It documents no way to export an agent's configuration. What you can hold outside the platform is the instruction text, if you wrote it somewhere else first, and any skill files you authored and uploaded.

There is also a hard boundary worth knowing before you design around API triggers. OpenAI's own documentation, checked 08 Aug 2026, states that "the agent's response cannot currently be retrieved through the API". You can start a run from another system, and a beta header lets you poll its status, but you cannot get the answer itself back into the system that started it. If the output has to land in a record, that part is still engineering. The full comparison sits in our piece on Custom GPTs versus AI agents.

Deletion on the way out is a right you exercise, not a process that happens

OpenAI's Data Processing Addendum is clear on the principle. "Following expiry or termination of the Agreement, OpenAI will, at Customer's instruction, return or delete Customer Data, and existing copies unless retention of Customer Data is required under applicable laws, in which case OpenAI will isolate and protect it from any further processing except to the extent required by applicable laws."

Note the three words doing the work: "at Customer's instruction". Somebody in your organisation has to give it. The clause does not state a deadline, and it does not describe what "return" looks like in practice or in what format. The DPA also puts configuration squarely on you, stating that the customer is responsible for design decisions "e.g., retention periods, deletion, etc.".

Nothing self-cleans in the meantime. Deleted ChatGPT conversations are removed within 30 days, but on the API side OpenAI's data guide states that "objects that are not deleted via the API or dashboard are retained indefinitely", which covers conversations, vector stores and the files behind them. And of a deactivated ChatGPT Business workspace: "data in the workspace remains intact".

So put four things in writing, at contract stage rather than at exit, and keep the answers with the contract:

1. Who is entitled to issue the return-or-delete instruction, and to which address.
2. What "return" means in practice, in what format, and covering which object types.
3. What timeframe applies, since the clause does not name one, and whether it covers backups and

sub-processors.

1. What confirmation you receive that it has been done.

Whether those answers are legally sufficient is a question for your own advisers, and UK law firms are better at it than any engineering firm. What we can tell you is that a supplier who cannot get you a straight answer to the second one has told you something useful.

Two contract facts to check before signing rather than at exit

For a UK customer, the counterparty under OpenAI's Data Processing Addendum is OpenAI OpCo, LLC, the US entity. Customers based in the European Economic Area or Switzerland contract with OpenAI Ireland Ltd instead, which catches out UK groups that assume the Irish entity applies to them. For UK data, the DPA relies on the EU Standard Contractual Clauses as amended by the UK Addendum, the ICO's addendum issued under section 119A(1) of the Data Protection Act 2018. Write "UK Addendum" in your assessment, because that is the instrument OpenAI's contract actually names.

One more clause is worth knowing you have. If OpenAI adds a sub-processor you object to, you have 30 days to object, and if the objection cannot be resolved within a further 30 days either party may terminate, with pre-paid fees refunded for the remaining period. That is a documented exit route, and most buyers do not know it is there.

Five decisions at the start that make exit cheap

Every one of these is close to free on day one and expensive to retrofit.

1. Keep prompts and business logic in your repository, not in dashboard objects. Version them

like code, because that is what they are.

1. Put the model behind an interface. One module should be the only place in your codebase that

knows which vendor you use. Changing vendor then means changing that module, not the system.

1. Own the contract in your company's name. If the API account, the billing and the workspace

belong to your supplier, your exit from OpenAI is entangled with your exit from them, and you will be negotiating both at once.

1. Hold your own evaluation set, as files, in your repository. It is how you prove a replacement

is as good as what you have, and it turns a vendor comparison into days rather than months.

1. Keep the integration layer and the logging yours. If your own system records what went in and

what came out, you keep the operational history no matter whose model produced it.

If you want the wider version of this exercise across every AI dependency in the business rather than one vendor, that is what our OpenAI dependency risk audit sets out.

The decision in front of you

You are not choosing between lock-in and no lock-in. Every capable platform involves some, and a company that refuses all of it ends up building things it should have bought.

You are choosing between lock-in you priced and lock-in you discovered. The five decisions above convert the second into the first for very little money, and they are only available while the system is being designed.

For the full range of options open to a UK business, see our overview of what OpenAI offers.

The same test applies to every vendor, including Anthropic, and including us. We are an OpenAI Select Partner and our deepest capability is Claude. We resell neither and take no margin on your usage, so we have no interest in which one you standardise on. We do have an interest in the answer to "what happens if we leave" existing before it is needed. That question is part of how we scope OpenAI implementation work, and it sits under AI implementation rather than under any one vendor, because the answer should not change depending on who you pick. To get your exit position documented before you commit to a build, request a quote.