Provably Private AI as Infrastructure
Why zero-retention AI, plus the ability to strip identifiers on the same private path, is becoming table stakes for anyone who handles sensitive text.
In 2025, a federal court told OpenAI to stop deleting things.
As part of the New York Times' copyright litigation, OpenAI was ordered to preserve all consumer and API ChatGPT logs, including conversations users had already deleted, so they could be examined. That obligation stood until it was lifted in late September 2025, and the court later directed the company to produce 20 million de-identified chat logs. (Sources: OpenAI's own statement; U.S. District Court filings; Business Insider; TechSpot.)
Sit with that for a second. A user hit "delete." The company's policy said the data was gone. And a court said: no, you will keep it, and you will hand it over.
That is the whole problem with trust-based privacy in one example. A deletion policy is only as durable as the next court order, the next bug, the next acquisition, the next misconfigured setting. The one thing that survives all of them is an architecture that never kept the data in the first place.
This keeps happening, and it's always the same root cause
The OpenAI retention order isn't an outlier. Look at the last two years:
- A routine bug became a breach because the data was there to leak. In March 2023, a bug in an open-source component let some ChatGPT users see other users' conversation titles and, for a slice of paying subscribers, payment details. (OpenAI post-mortem; The Hacker News.)
- "Share" quietly turned into "publish," across vendors. Through 2025 and into 2026, chat-sharing features exposed conversations to search engines and archives: roughly 100,000 ChatGPT chats scraped from Google, hundreds of thousands of Grok chats surfaced in search results, and shared Claude chats indexed by Google and Bing that reporters found contained medical reports, clinical-trial data with real names, internal documents, and API keys. Researchers later found around 143,000 conversations across six major chatbots sitting on the public Internet Archive. (404 Media; Oxford Internet Institute; Wired; TechRepublic; Obsidian Security; Forbes.)
- Employees leaked what the tool was willing to keep. In 2023, Samsung engineers pasted confidential source code and meeting notes into ChatGPT; the company banned public generative AI and only brought it back years later behind a control layer it built on purpose. (Fortune; Forbes.)
- Store documents on the client (in the browser, or in storage the customer already controls), not in a vendor content database.
- Process AI requests in memory and discard the input. No persistence, no training on it.
- Keep content out of the logs entirely.
Different companies, different features, different years. Same root cause every time: the content was being retained, and retention was the precondition for the failure.
Policy says "we won't." Architecture says "we can't."
Most AI vendors answer the privacy question with a promise and a settings page. Don't train on my data: there's a toggle. Keep my content private: there's a tier. Be HIPAA-ready: have an admin flip a switch and sign an agreement.
Every one of those is a thing that can be reset by an update, clicked through on a consent modal, undone by a downgrade, forgotten by an admin, or overridden by a court. A toggle means the capability to retain exists and you are trusting a boolean to hold it back.
There is a different way to build: don't have the data path at all.
Do that, and an entire category of failure simply cannot happen to you. There is no stored corpus to breach, no conversation store to accidentally index, no retained logs to subpoena. You can't flip a toggle that doesn't exist. And you can't be ordered to produce what you never kept.
This is the difference between a promise and a property. We build for the property.
But privacy alone isn't the point. Usefulness is.
Here's the catch that makes "just don't retain anything" too simple: the most valuable thing you can do with sensitive text is often to clean it: strip the names, dates, account numbers, and other identifiers so a document can be shared, analyzed, or reused without the risk.
And cleaning normally creates its own privacy problem. To find the sensitive data, something has to read it. If that something keeps a copy, you've just moved the exposure to a new tool.
Zero-retention architecture dissolves that. On a path that keeps nothing, you can point AI at your most sensitive document, have it detect and remove the identifiers, and get back a de-identified draft, without ever creating a second copy of the sensitive version anywhere.
That's the combination we think belongs in every modern stack:
- AI that provably doesn't retain your content.
- AI that, on that same private path, finds and strips the identifiers that make the content sensitive.
Separately, each is nice. Together, they change what you're allowed to do with AI on the work that matters.
What this looks like in practice
We built it into Elixir Muse. Point it at a document and it runs a hybrid pipeline: deterministic pattern-matching for the structured identifiers (Social Security numbers, dates, emails, account numbers), a model pass for the context-dependent ones (names in prose, places, a job title that quietly identifies someone), and a verification pass that re-scans the result and flags anything it couldn't confirm. You get a de-identified draft plus a coverage report of exactly what changed and what still needs your eyes, all over the same zero-retention path, with nothing stored on our servers.
The worked example we use is HIPAA Safe Harbor, because it comes with a clean checklist: remove these 18 kinds of identifiers and confirm nothing left behind can identify the person. But the method is universal. The same find-strip-verify-confirm shape serves GDPR's data-minimization principles, CCPA, financial-sector rules, and the de-identification exercises the EU AI Act will keep making relevant as its deadlines land through 2027 and 2028.
One thing we're deliberate about: the tool produces a reviewed draft, not a compliance certification. HIPAA Safe Harbor requires a human to make the final "no actual knowledge" judgment, and no model makes that call for you. What Muse does is make a knowledgeable person dramatically faster at reaching a defensible result, privately, with a documented trail, and without the sensitive original ever being stored.
The takeaway
Every leak of the last two years had the same precondition: the data was being kept. Deletion promises break. Toggles reset. Courts compel. The only guarantee that survives all of it is the one you build into the architecture (never hold the data at all), and then make that architecture useful by letting it clean your most sensitive documents without ever keeping them.
The safest data is the data you never kept. The best privacy architecture is the one that lets you keep using AI anyway.
This post summarizes a longer technical whitepaper. Incident references are drawn from third-party reporting and primary court filings, cited and dated in the full paper.
About the Author:
Hart Johnson is the Executive Managing Director of DevSecOps at Elixir Technologies, a visionary leader at the forefront of integrating development, operations, and security. With an MS in Cyber Security and Information Assurance (MSCSIA) and certifications as a Certified Ethical Hacker (CEH) and Computer Hacking Forensic Investigator (CHFI), Hart brings a wealth of expertise to his role. His extensive experience in both DevOps and Security and Compliance departments drives innovation and enhances infrastructure with a strategic focus in the SaaS industry. Hart’s background in teaching and his collaborative approach contribute to a culture of continuous improvement and shared success within Elixir Technologies.