I Read the Terms for 25 AI Tools. Three Say When They Will Delete Your Data.

TL;DR: I read the published export documentation and terms of service for 25 AI tools on 2026-08-15, and an explicit post-termination deletion or retrieval window appeared in only 3 of the 18 terms documents that returned readable text: OpenAI, Figma and Linear, all 30 days. Anthropic's consumer terms say the company "may at our option delete any Materials or other data associated with your Account," with no window at all. This is a documentation audit and not a functional test: I hold no paid accounts on these tools and I did not run a single export. The fix is a seven-step exit drill you can run this week, and the metric that tells you it worked is the age of your last verified restore.

Who is this for?

One person whose entire business lives in other people's databases. If a tool dies, gets acquired, or bans your account on a Saturday, there is nobody else to call. The receipts on solo AI companies keep landing on operations rather than tooling, and this is the most boring operational hole in the stack.

First, what the documents actually say, because the drill below is built on it. I fetched 32 policy and help pages across 25 tools with curl -L and a browser User-Agent, and looked for four things: a documented self-serve full export, the format it produces, a stated post-termination retention window, and a deletion deadline.

Finding	Document	How I read it
"OpenAI will delete all Customer Content from its systems within thirty days"	OpenAI Business Terms	Raw HTML, browser UA
Content available "for electronic retrieval for a period of 30 days, but thereafter Figma may delete any stored Customer Content"	Figma Terms of Service	Raw HTML
"Within thirty (30) days of termination... Linear will delete Customer's User Information"	Linear Terms	Raw HTML
"we may at our option delete any Materials or other data associated with your Account"	Anthropic Consumer Terms	Raw HTML
Return or "securely destroy" on customer request, no deadline given	Otter.ai Terms	Raw HTML, DPA section
Terms unreadable: 404 or client-side render	Cursor, Notion, Intercom, Clay, Granola, Fathom	Extraction returned under 250 characters

That last row is the one I want to be precise about. Six tools returned either a 404 or a rendered shell with almost no text in the raw HTML, and a grep finding nothing there is not evidence the clause is absent. I am reporting 3 of 18 readable documents, not 3 of 25. One note for anyone repeating this: openai.com/policies/business-terms/ refuses plain fetchers but serves fine to curl with a browser User-Agent, so a 403 there is a tooling artifact.

What are the steps?

1. List every tool that holds data you cannot rebuild from scratch. Not the tools you pay for. The ones holding state. Failure mode: people inventory their invoices, so the free-tier note-taker with two years of client calls in it never makes the list.

2. For each tool, find the export doc and write down what it actually produces. Notion documents export to PDF, CSV or HTML for a page, database or entire workspace. Slack documents a workspace export. Linear documents workspace CSV export, but the doc states that workspace admins do it and that on Enterprise plans only owners can. Failure mode: reading "export" as "full export." Notion's own doc notes you cannot export a Form view of a database. GitHub's migration tooling is Enterprise Importer, which is a migration path between GitHub tenants, not a self-serve archive.

3. Read the termination clause before you need it. Search the terms for "termination" and for a number of days. Failure mode: grepping raw HTML and concluding the clause does not exist. Six of my 25 rendered client-side. If the raw text is thin, open the page in a browser and read it, and record which method you used.

4. Run the export. Actually run it. I could not: no paid accounts, so every row above is what the vendor documents, not what the vendor does. Documented is not working. Failure mode: treating step 2 as step 4. A documented export that has never been executed is a promise, and the point of this drill is that you stop holding promises.

5. Open the file and look for your content, not your identifiers. Failure mode: the archive extracts cleanly and turns out to be proprietary JSON of internal IDs that only re-imports into the same vendor. Ask a narrow question: can I find the text of a specific client note from March in this file, by eye, without the vendor's software?

6. Restore one real artifact into something that is not the original vendor. One document, one table, one transcript, into a plain file or a different tool. Failure mode: an untested backup is not a backup, it is a folder. This is the step everyone skips and the only one that proves anything.

7. Put it on a schedule with a named trigger. Monthly, or on any vendor pricing change, acquisition announcement, or terms update. Failure mode: the heroic one-time export done the week you read an article like this, never repeated, silently stale by spring.

What goes wrong most often?

The exit is assumed to be somebody else's problem until the vendor is already gone. The ambient failure rate here is not theoretical: MCP Queen's 2026-07-28 sweep graded 9,326 remote MCP servers and found 1,603 of them, 17.2%, advertising an endpoint that does not answer. Roughly one in six things marked live is not. Integrations rot faster than the tools they connect.

The second failure is confusing an export with a right. Three vendors in my readable set commit to a number of days. Anthropic's consumer terms reserve the option to delete without one, which is entirely normal drafting and not a scandal; it just means the timeline is the vendor's, not yours. If your recovery plan depends on logging in after cancellation, your plan depends on a clause that mostly is not there.

The third is monitoring the wrong thing. Knowing a vendor is down right now is a different capability from being able to leave, and the second one is what survives an acquisition.

How do you know it is working?

One number: the age of your last verified restore. Not the age of your last export. The last time you took an exported file and reconstructed something usable from it somewhere else.

Mine is the metric I now track per tool, and the target is under 90 days for anything holding client work, under a year for everything else. It is deliberately harsh, because it is the only measure in this whole exercise that cannot be satisfied by reading a help page. An export you have never opened has an infinite restore age. So does a beautifully documented one. Run the drill on a schedule rather than on news, because the median warning before an AI tool stopped working was 15 days, and three of the twenty gave none.

If you run the drill and find a tool where step 5 fails, that is the finding, and it is worth more than the four hours it cost. You now know which vendor owns you, and the staleness signals that tell you which one is already coasting tell you which drill to run first.