Zero Data Retention for Your App's AI Features: What Each Model Vendor Offers

Zero data retention, in the sense a paying customer means it, is an arrangement with the company whose model your live app calls when one of your users presses a button. It is not the privacy switch inside the coding tool you write the app in, and it is not a setting in somebody’s personal chat account. Those two wear the same three words and answer a different question about different software.

The question usually arrives in one line, inside an email or a form, and it is rarely technical. A customer wants to know whether the company behind your AI feature keeps what your product sends it, and they want that in writing, this week, before a contract moves.

Zero data retention on a model API is an arrangement rather than a switch waiting in your account. OpenAI approves it per organisation or project, Anthropic reviews and applies it per organisation, and Google’s own page names six areas where a customer has to act before retention reaches zero. All three publish exactly what they mean.

The three vendor sections below come from pages each company publishes about its own products, opened on 3 September 2026 and dated wherever a statement is used. AxonBuild holds no enterprise agreement with any of them, has requested no retention control on anyone’s behalf, has switched nothing on and has verified nothing inside anybody’s account. This is not legal advice, and it settles nothing about whether your own app meets a rule.

What zero data retention means on a model API, and what it does not cover

Each vendor writes the phrase differently, and the differences are the whole answer.

OpenAI’s announcement about zero data retention for frontier models, dated 19 August 2026 on the page, describes it as a promise to eligible API customers that the company “does not retain their prompts or model responses after a request is processed” and that customer content “is not available to OpenAI personnel for review”.

Anthropic’s article on which products a zero data retention agreement covers, dated 9 June 2026 on the page, describes approved arrangements in which the company keeps neither what a customer sends nor what the model returns, apart from what law and misuse work require. It then adds a carve-out in its own words: under those arrangements “Anthropic still retains User Safety classifier results in order to enforce our Usage Policy”.

Google’s own page for this carries no definition of the phrase, on a whole-page read in both request shapes on 3 September 2026. The page on zero data retention for the Gemini Enterprise Agent Platform treats it as an outcome a customer reaches instead, stating that customer data is kept for limited periods in named scenarios and adding: “To achieve zero data retention, customers must take specific actions within each of these areas”. The address cloud.google.com/vertex-ai/generative-ai/docs/data-governance, published under Vertex AI’s generative-AI data-governance path, resolved to that page, under that product name, on 3 September 2026.

Three things the phrase does not cover, each kept on a separate line of the vendors’ own pages.

It is not a promise not to train on your data. OpenAI’s data controls guide states that, as of 1 March 2023, data sent to its API is not used to train or improve its models unless a customer explicitly opts in, and states that separately from anything about retention. Google cites its Training Restriction term in one section and its retention list in another.

Encryption is a separate mechanism, not this one under another name. OpenAI’s August announcement describes an option it is developing in which content sits on OpenAI infrastructure “encrypted with keys controlled by the customer”, and keeps that apart from anything it says about retention.

And it says nothing about what your own product stores. What your app writes to its own database, logs and analytics is a separate answer in your own words, and the closing section deals with it. Nor is it a pricing question: what those model calls cost per customer is worked out on its own terms.

What OpenAI’s own pages ask you to do

OpenAI publishes the mechanism in its data controls guide for the platform, read on 3 September 2026. Two kinds of stored data are named there: abuse monitoring logs, which the guide describes as necessary for enforcing usage policies, and application state, which is data some API features keep in order to do their job.

The default is stated plainly: API features produce abuse monitoring logs, kept for up to thirty days, with a few endpoints such as transcriptions and moderations listed as keeping none (the table further down shows which), “unless longer retention is required by law, or is reasonably necessary to protect our services or any third party from harm”. That is what a new account gets.

Two named controls change it: Modified Abuse Monitoring and Zero Data Retention. The guide states that both are currently subject to OpenAI’s approval in advance and to “acceptance of additional requirements”, and that approved customers “may select between Modified Abuse Monitoring or Zero Data Retention for their API Organization or project”. It adds that customers who enable either one stay responsible for ensuring their users abide by OpenAI’s policies and for complying with moderation and reporting requirements under applicable law, which is worth reading twice if you assumed the control moved an obligation off your side.

Zero Data Retention keeps customer content out of the abuse monitoring logs the same way the other control does. On top of that, the guide states, it changes endpoint behaviour: the store parameter on two endpoint families “will always be treated as false, even if the request attempts to set the value to true”. Code that asks for a stored response gets an unstored one, silently, and any feature you built on stored responses stops working the way you wrote it.

Two more names sit under the same heading, and they are the ones likeliest to surprise a founder who thought approval was the end of it. Under Eyes Off, OpenAI reserves the right to make models ineligible for either control for specific customers, “as notified in advance to the impacted customers in writing”; content is then retained in the logs but excluded from human review unless law requires it. Under Safety Retention, the same reservation applies where it is reasonably necessary to investigate or prevent severe risk activity, and there the guide states the company may retain and human review content its classifiers detect as potentially violating its policies or your agreement.

Configuration, as the guide names it, is a Data Retention tab under Settings, then Organization, then Data controls, visible once an organisation has been approved. The choice is made for the whole organisation, and each project can inherit it, pick a control explicitly, or select None and turn the controls off for that project alone. So the answer you give a customer is only true of the projects actually set that way.

OpenAI’s enterprise privacy page, which carries its own update date of 8 January 2026, puts the same shape more briefly: except for certain endpoints and features listed in the platform documentation, the company “may securely retain API inputs and outputs for up to 30 days”, and a customer “can also request zero data retention (ZDR) for eligible endpoints if you have a qualifying use-case”.

Which OpenAI endpoints the control actually covers

The guide carries a table of every endpoint, and the honest reading of it is that the control is not uniform across the API. Zero Data Retention eligible endpoints, it states, do not retain customer content for application state, subject to the limitations it lists, while ineligible endpoints and capabilities “may still store application state, even if Zero Data Retention is enabled”.

The pattern underneath is simple once you see it: the endpoints that hold something in order to work sit outside the control, and the endpoints that answer and forget sit inside it.

Values read from OpenAI’s own table on 3 September 2026; its footnotes qualify several rows.

Three footnotes matter for a written answer. The video endpoint is described as currently blocked for requests under either control, with the guide telling customers who need it to configure a project whose retention setting is None. Image and file inputs are scanned on submission, and where the classifier detects what the guide calls potential CSAM content, the guide states the image is retained for manual review even with any of these controls enabled. And background mode on the responses endpoint stores response data to disk for roughly ten minutes so the caller can poll for it.

None of that makes the control worthless. It does mean a sentence like “our AI provider retains nothing” is wrong for most real apps, and that the accurate sentence names the endpoints your product calls.

What Anthropic’s own pages say, and where the consumer plans sit

Anthropic splits its answer across two articles, and reading the wrong one is the commonest way to get this wrong. The zero data retention article states in its first line that it covers certain commercial products, including the Messages API and Claude Code on Enterprise plans, and points consumer accounts elsewhere.

Inside the commercial article, the arrangement is described as something some Claude Platform and Claude Code for Enterprise customers may have, subject to the company’s approval, and set apart from the default retention approach the vendor documents elsewhere. Three product surfaces are named as the ones it applies to: eligible Anthropic APIs, anything using a Commercial organization API key with Claude Code reached that way included, and Claude Code on Enterprise plans. Nothing outside those three is inside the agreement, whatever else your team happens to use.

Two limits sit in the same article. The first is the classifier carve-out quoted above. The second is that, for what Anthropic calls Covered Models, the article states the company requires limited data retention and review as part of its safety work. That one turns into a real conflict two sections down.

Getting the arrangement is a conversation rather than a form. The article directs current and prospective customers to the sales team, and adds that requests are reviewed and applied per organisation, so a company running several has to say so. It then names the place to check the result: Claude Platform users can confirm the arrangement is applied under Settings, then Privacy Controls, then Data retention period. That path is the one thing here a founder can verify themselves in an afternoon.

The consumer side is a different document with different numbers. Anthropic’s article on how long it stores consumer data, dated 1 July 2026 on the page, states that a deleted conversation leaves chat history immediately and is deleted from back-end storage systems within thirty days. That is a deletion timetable for a personal account, not a retention arrangement for an API, and a customer who read the consumer page before asking about your API is comparing two unlike things.

Why Google’s version is a list of things to switch off rather than a switch

Google’s is the odd one out, and a founder who goes looking for the setting will not find it. Its own page sets zero data retention out as the result of six named areas, plus further conditions for agent products and for Google’s trained models, with an action required in each. Two cannot be acted on at all.

Read on 3 September 2026, the six run like this. Prompt logging for abuse monitoring on Google models applies, the page states, only to customers whose use of Google Cloud falls under the Google Cloud Platform Terms of Service, and a customer in that position who wants zero retention “can request an exception for abuse monitoring”. Advanced AI models may carry additional prompt and response logging under a named safety addendum, and here the page is candid rather than reassuring: “Zero data retention may not be possible when using some Advanced AI features.” It refers the reader to their account team.

Grounding with Google Search stores logs containing queries derived from end-user prompts, with contextual information sent alongside them, for up to three days for debugging, and the page then states flatly that there is no way to disable that storage if you use the feature. It recommends a different grounding product for customers who require zero retention. Grounding with Google Maps stores prompts, contextual information and generated output for thirty days to create grounded results, with the same conclusion in the page’s own words.

Request and response logging is disabled by default, can be enabled per model and per project, and writes the traffic to a designated table in Google’s data warehouse; the instruction is not to enable it. The Interactions API is the trap. The page states that when a store field is set to true, Google keeps user data such as prompts, responses and conversation state to support multi-turn conversations and later retrieval, and that if no value is specified it defaults to true for all models. A team that never touched the field has the storing behaviour switched on, and the page’s instruction is to set it explicitly to false.

Two further items sit under Google’s trained models. Session resumption for the live API is off by default and, when a caller enables it, stores cached text, video and audio prompt data along with model outputs for up to twenty-four hours. In-memory caching of inputs, outputs and derived data is on by default, isolated at project level, expires after twenty-four hours and can be turned off per project, but the page states in its own voice that this one does not violate zero data retention. That is the single default Google exempts, and knowing which defaults a vendor already counts as inside the term is worth more than a general promise about defaults.

On Google, then, the answer to “do we have zero data retention” changes the moment somebody adds a grounding tool to a prompt.

Where zero retention and a health-data agreement pull against each other

Two vendors document these as separate routes that can exclude each other. On OpenAI, the health route runs through modified retention rather than zero retention. On Anthropic, one class of model requires retention and is unavailable with the arrangement enabled. A founder asked for both, by two different customers, is reading pages that point opposite ways.

Take OpenAI first. Its help centre article on HIPAA eligible products and functionality carried a freshness stamp of “Updated: yesterday” when it was read on 3 September 2026, which is a warning in itself about how fast this ground moves. The products it names as eligible with a Business Associate Agreement include an entry written as “API with Modified Retention”. Not zero retention. The article goes on to state that eligibility for the API is contingent on the customer’s account being provisioned with modified retention unless OpenAI specifies otherwise, and that once an organisation ID is provisioned that way, the endpoints it lists can be used for processing protected health information “even if data is retained”.

The data controls guide says the same from the other side: under both Eyes Off and Safety Retention, it states that for customers who have executed OpenAI’s Business Associate and Healthcare Addendum, once an organisation ID is provisioned with that setting, the eligible endpoints can be used for health data even where data is retained. The agreement is written to survive retention rather than to require its absence.

The route to it sits in a separate help centre article on getting a Business Associate Agreement for the API services, read on 3 September 2026. Two answers there are useful to a small company: an enterprise agreement is not required to sign one for the API services, and most API services are covered with a few exceptions the page links out to. A third is useful to anyone confusing the products, since the agreement for ChatGPT is limited to sales-managed Enterprise or Edu accounts and the article states the company does not offer one for ChatGPT Business.

Anthropic’s article on business associate agreements for commercial customers, stamped “Updated over 2 weeks ago” on 3 September 2026, states the collision outright: “Covered Models require 30-day data retention and aren’t available with zero data retention (ZDR) enabled. Some services, like Claude Code, are only covered under the BAA when ZDR is enabled, which means those services can’t use Covered Models under the BAA.”

That runs in both directions. One class of model needs retention on, one class of service is only covered when retention is off, and they cannot both be true of the same call. The same article adds that the agreement is not automatic on any plan: the organisation’s primary owner activates HIPAA compliance in the settings under Data and privacy and accepts it there, standard Enterprise plans do not include coverage without that action, and the agreement then covers only the single organisation that accepted it.

None of that says whether your app needs such an agreement at all. That is a question about which of the services behind your product touch the data: which of the services behind your app need an agreement, and which do not works through the model provider, the logger and the email sender together. What has to change inside an app that already shipped on an AI builder and holds health records is a longer piece of work with its own order of operations, and which builders and hosting platforms will sign that letter, on which plan, is a map worth keeping in one place, because every vendor answers it differently.

Is ChatGPT SOC 2 compliant, and can you hand your customer the report?

The report a customer asks a software vendor for is a SOC 2 report, and the answer for OpenAI depends entirely on which product you mean. The company’s own pages give three different statements for the consumer service, the business and enterprise workspaces, and the API platform your app actually calls.

On the enterprise privacy page, the API platform is described in one sentence as having been audited and certified for SOC 2 Type 2 compliance. The same page states that ChatGPT Enterprise, ChatGPT Edu and ChatGPT for Healthcare have each successfully completed a SOC 2 Type 2 audit, and that ChatGPT Business has too. Three separate sentences for three separate things, which is the useful part: a customer who writes “is ChatGPT SOC 2 compliant” on a form is usually asking about a product your app does not use.

The report itself lives behind a request. OpenAI’s trust portal carried a banner on 3 September 2026 saying that its 2026 SOC 2 Type 2 report can be obtained by customers at that address, and its overview describes the portal as covering OpenAI’s ChatGPT services, including ChatGPT Enterprise and ChatGPT Edu, with products covered in a report evaluated by an independent third-party auditor. The document list separates public documents from private ones, and the private ones open through an access request rather than a download. A source note belongs here, because that host behaves unusually: on 3 September 2026 trust.openai.com returned a readable page to a plain automated request and refused a browser-shaped one, the reverse of the other openai.com and help.openai.com addresses read for this page, and the portal facts rest on the plain read.

Two things follow. The wording is not consistent even inside one company: one OpenAI page calls the API platform certified for SOC 2 Type 2, while the portal describes the same class of thing as a report an independent auditor evaluated, and the portal’s coverage sentence names the ChatGPT services rather than the API. And whichever wording you quote, the document belongs to the vendor. What an audit report covers, and what it leaves sitting with your own app is the part customers most often skip past. Whether your own company is expected to produce a report of its own is a separate decision, worth settling before you promise anything on a form.

Anthropic’s SOC 2 report, and how you get a copy

Anthropic publishes a short list rather than a page of detail. Its article on the certifications it has obtained, dated 16 March 2026 on the page, states that the company maintains these compliance credentials: a “HIPAA-ready configuration (BAA available)”, ISO 27001:2022 for information security management, ISO/IEC 42001:2023 for AI management systems, and “SOC 2 Type I & Type II”. The same article states that copies of the compliance documentation are requested through the company’s trust portal.

That route is where an automated reading stops. As of 3 September 2026, Anthropic’s trust portal at trust.anthropic.com does not render readable text to an automated read (a plain request and a browser-shaped request both returned a page with no readable body beyond its title). The scope of that observation is one address, read whole in both request shapes on one date; a person opening it in a browser may well see a working portal, and the certifications article is unambiguous that the documents are there.

Which leaves a small practical point. Neither vendor’s report arrives from your own account settings; both come through a request to the vendor, on the vendor’s timetable. A customer who gave you a Friday deadline gave it to the wrong company.

What to write down, and what the setting still does not cover

A written answer that survives a second reading names four things: the vendor, the exact product surface your app calls, the control’s own name as that vendor writes it, and the date somebody approved or accepted it. A fifth is worth adding for your own sake, which is who inside the account can change the setting.

That specificity is not pedantry. Every vendor page above scopes its answer to something narrower than the company: an organisation, a project, an endpoint list, a plan, a named feature. An answer written at company level stops being true the moment somebody adds a project, calls a different endpoint or turns on a grounding tool.

The bigger limit is the one no vendor page will tell you, because it is not their side of the line. A retention control at the model vendor says nothing about your own database, your application logs, your error tracker, your product analytics, your email sender, or the editor you write the code in. The prompt your app sent may leave no trace at OpenAI and still sit in three of your own systems, in plain text, indefinitely.

Four of those threads have their own answers. The supply-chain entry that asks the same questions of every dependency covers what to record about each provider your app leans on. How long you keep your own users’ data is the matching question about your own storage. What one builder’s own pages document about retention covers the layer above the model. And when the request escalates from changing a setting to moving the software, the ask that moving the app does not actually answer is the honest starting point.

Four more threads have no live page to point at yet, and they are worth naming because they tend to arrive together. If this line came in on a spreadsheet with forty other rows, the form itself is a subject with its own rhythm, and answering the whole thing is a different job from answering one line. If it came in as a list of conditions attached to a deal, that list usually holds several unrelated asks wearing one heading, and sorting them by who actually settles each one saves a week. If a customer has also asked you to sign an agreement about data handling, the vendors you have just enumerated are the list that agreement will ask you to name. And if the ask turns out to be that the whole product runs on the customer’s own infrastructure rather than yours, no vendor setting reaches it.

One loose end stays loose. OpenAI’s August announcement names the safety mechanism it built to work alongside zero retention, Private Safety Processing, and says the company planned to start rolling it out and to share a technical white paper in September 2026. Whether that changed anything above is not answerable from the pages as they stood on 3 September 2026, which is the reason to date every sentence you send a customer and re-read the pages before the next one.

Common questions about zero data retention on AI features

Is zero data retention the same as a vendor promising not to train on my data?

No, and the vendors keep the two on separate lines. OpenAI’s data controls guide states the no-training position as a standing fact dated 1 March 2023, subject to an explicit opt-in, and describes the retention controls separately as something a customer applies for. Google cites a Training Restriction term in one section and its retention conditions in another. A vendor can hold the training position while still keeping abuse monitoring logs for thirty days.

How does a small company apply for zero data retention on the OpenAI API?

Through OpenAI’s sales team, not through a setting. The data controls guide states that the retention controls currently need approval in advance and acceptance of additional requirements, and points readers to sales to ask about eligibility. Once approved, the choice appears as a Data Retention tab in the organisation settings.

Does zero data retention apply to Claude Code and to the consumer Claude plans?

Claude Code yes, in two specific forms; consumer plans no. Anthropic’s article names the covered surfaces as eligible APIs, anything using a Commercial organization API key with Claude Code reached that way included, and Claude Code on Enterprise plans. The free, Pro and Max plans are handled by a separate article about consumer data.

Can an app have zero data retention and a health-data agreement at the same time?

On both vendors’ own documentation, not straightforwardly. OpenAI’s HIPAA eligible products article names the API route as one with modified retention, and states that eligible endpoints can process health data even where data is retained. Anthropic’s agreement article states that its Covered Models require thirty-day retention and are not available with zero data retention enabled, while some services are only covered when it is enabled.

That describes what two vendor pages said on 3 September 2026, not your app. Which of the services behind your product need such an agreement at all is worked through on the page about model providers, loggers and email services.

Does zero data retention cover the data my own app stores about my users?

No. Every statement above is about what a model vendor does with a request after your app sends it. Your own database, application logs, error tracker, analytics and email sender sit outside all of it.

How long you keep your own users’ data is the matching question on your side of the line.

Which parts of an AI feature stay outside a zero-retention arrangement?

The parts that hold something in order to work. On OpenAI’s own endpoint table, the assistants, threads, vector store, files, fine-tuning, batches and conversations rows are all marked as not eligible, and the guide states that ineligible endpoints may still store application state even when the control is on. On Google’s page, two grounding features are stated to have no way to disable their storage at all.

Can I give a customer the model vendor’s audit report as proof?

Only of the vendor. Both companies route report copies through a trust portal request rather than a download, and both scope the report to their own products. A vendor’s report says nothing about the code your app runs.

What an audit report covers, and what it leaves sitting with your own app sets out the difference in the terms a customer’s form usually uses.

Does the AI builder I made the app with offer zero data retention?

That is a different vendor from the model provider, and a separate answer. The company whose editor you built in has its own terms about what it keeps, distinct from whatever OpenAI, Anthropic or Google does with your app’s runtime calls.

The two get merged constantly on forms. What one builder’s own pages document about retention works through the builder half on a dated read.