9 min read Data governance

What leaves your perimeter is not your data, it is what the classifier inferred from it

What leaves your perimeter is not your data, it is what the classifier inferred from it

On August 19, 2026, OpenAI reaffirmed Zero Data Retention for its frontier models and previewed a system called Private Safety Processing, designed to spot patterns across related interactions without giving its personnel access to the content. Two and a half months earlier, on June 9, Anthropic had moved the other way: mandatory 30-day retention of prompts and outputs on its Covered Models, on every platform where they are offered, including through AWS Bedrock, Google Cloud Agent Platform and Microsoft Foundry. On August 20, Bloomberg reported that Anthropic would let those 30 days sit in the customer's own cloud, a plan publicly confirmed by one of its developers and expected this fall.

Reading that sequence, the reflex is to see a divergence followed by a rally, and to conclude that the no-storage camp won. The opposite happened. Both labs reached the same technical diagnosis, that some risks are visible only when several requests are viewed together, and neither gave it up. What moved in three months is where the data sits. What never moved is the computation running across it and the signal coming out of it. An enterprise that negotiated over storage location negotiated over the one variable its providers were willing to concede.

The August 20 article on the control that exists on paper but never runs covered the classifiers you operate yourself. The July 15 article on audits and the AI Act delay covered what an auditor comes to verify. This subject is the blind spot between them: what your provider's classifiers produce from your data, where those derivatives go, and what you can demonstrate about them.

Two nested perimeters holding blue data blocks, crossed by a single orange line that exits
The data can stay with you while what is inferred from it leaves.

What Zero Data Retention actually covers

OpenAI's data controls page is more instructive than the announcement, because it describes a mechanism rather than an intention.

Two kinds of data coexist on the platform. Abuse monitoring logs, generated by default for all API usage and retained for up to 30 days. Application state, persisted by some features in order to fulfill the requested task. ZDR acts on the first by excluding customer content from those logs, and changes the behavior of two endpoints by forcing the store parameter to false on /v1/responses and /v1/chat/completions, even when the request tries to set it to true.

The point procurement grids miss is scope. Of the twenty-four endpoints listed in the documentation, eleven are ZDR eligible and thirteen are not. Among the ineligible ones are /v1/conversations, /v1/assistants and the whole /v1/threads family, vector stores, files, fine-tuning, evals, batches and video generation, the last one explicitly blocked for ZDR requests. The documentation states that these endpoints may still store application state even when ZDR is enabled for the organization. An enterprise that obtained ZDR and built its agent on the Conversations API or on a managed vector store does not have the regime it believes it has.

The two natures of data

Abuse monitoring logs: the traces a provider keeps in order to enforce its usage policies. They may contain customer content, but also metadata derived from that content.

Application state: the data a feature has to persist in order to work, for instance a conversation thread or the indexed contents of a vector store. It follows product logic, not compliance logic.

Derived signal: what a classifier produces from your content without being your content, typically an activity category and a severity level. It is neither a prompt nor a response, and that is precisely why it escapes clauses written about prompts and responses.

ZDR is not a switch either. The documentation describes it as subject to prior approval and to acceptance of additional requirements, then configurable at the organization or project level. And it shifts a responsibility: customers who enable it remain accountable for ensuring their users abide by the provider's usage policies and for meeting applicable moderation and reporting obligations. In obtaining non-storage, you take on the monitoring burden.

The derived signal, and the clauses that let it through

The decisive sentence in OpenAI's documentation runs to one line and is not about prompts. Abuse monitoring logs may contain customer content, it says, as well as metadata derived from that customer content, such as classifier outputs. That second category survives ZDR by construction, since ZDR is written about the first.

Private Safety Processing formalizes that split. When a risk is identified, OpenAI receives a narrowly defined signal indicating the type of activity involved, and its personnel do not get access to customer content even when that content is flagged. The diagram published with the announcement is explicit about the division: the customer receives the full alert and may choose to share, while OpenAI otherwise sees only the alert category and severity. The system works regardless of storage location, whether the content sits on infrastructure the customer controls or on OpenAI infrastructure encrypted with keys the customer holds and of which OpenAI has no copy.

That architecture is coherent and the trade-off it proposes is defensible. It is not verifiable today. The central claim, tracing patterns across related interactions without any human at the provider reading the content, rests on a technical white paper announced for September and not published as of this article. The system is being tested with early customers, among them Glean, Databricks, Abridge and Microsoft. Until that document exists, a compliance team writing Private Safety Processing into a certification file is documenting a design intention, not an audited mechanism.

Two clauses on the same page deserve reading before signature, and they appear in no marketing material. Under the heading Eyes Off, OpenAI reserves the right to make specific models ineligible for ZDR for specific customers, with advance written notice; in that case customer content is retained in abuse monitoring logs, but excluded from human review unless legally required. Under the heading Safety Retention, the same right is reserved where reasonably necessary to investigate or prevent severe risk activity; in that case content may be retained and subject to human review.

Table of the five data flows with their contractual commitment and coverage level
Five distinct flows, five different commitments, and only one of them genuinely sits inside the model contract.

ZDR is therefore not a state of the account, it is a revocable regime, model by model and customer by customer, whose switching conditions are written by the provider alone. There is a third exception, older and different in nature: submitted images and files are scanned on receipt, and an image whose classifier detects potential child sexual abuse material is retained for manual review even if ZDR, Modified Abuse Monitoring or Eyes Off is enabled. That one follows a legal obligation nobody disputes. Its interest for a technology executive lies elsewhere: it proves the principle admits written exceptions, and therefore that it will admit others.

Anthropic's regime, in its published version, is more legible because it is more explicit. Thirty days of retention for prompts and outputs on Covered Models, automatic deletion afterward except when flagged or legally required, no personnel authorized to read by default, human access possible only through a controlled path when content is flagged, review limited to a small set of approved reviewers, and every access recorded in a tamper-proof log that reviewers can neither suppress nor modify. The technical justification is named and sourced: Best-of-N jailbreaking, which sends hundreds of slight variations of one prompt until one gets through, is visible only when the requests are viewed together. The corresponding technical white paper has been published on Anthropic's trust center since the policy took effect.

The irony of the sequence is worth noting. The provider that imposed retention has documented its mechanism since June; the one that maintained non-storage will document its own in September. The most favorable contractual position and the most verifiable one are not held by the same company.

A grid by flow, not by provider

In the field, the recurring mistake is treating retention as a checkbox at the provider level, when commitments are made flow by flow and the flows do not share an owner. Five of them have to be qualified separately, each crossed with a written commitment, an obtainable proof and a consequence if the commitment fails.

Submitted data, meaning prompts, attachments and injected context. The commitment exists, it is written, and it is the best covered of the five. The obtainable proof is the named list of endpoints covered for your organization, not the public page.

Model outputs. Same regime as inputs at both providers, with the same endpoint limit. The question that settles it is application state: an output passing through a feature that is not ZDR eligible is persisted by that feature, whatever clause was signed about outputs.

Request metadata. Identifiers, timestamps, volumes, structured output schemas. At OpenAI, the data residency documentation classifies these as system data and explicitly excludes them from the regional perimeter, naming structured output schemas among them. An enterprise that paid the residency premium, billed at ten percent on eligible models released after March 5, 2026, has not regionalized those elements.

Derived security signals. This is the least covered flow and the hardest to get written down. The right question to put to your provider in writing is not what data do you retain, but what information derived from our data leaves our perimeter, in what form, how often, and for how long do you keep it.

Your orchestrator and tool logs. They fall outside the model contract and entirely under your responsibility. OpenAI's documentation makes the point for two concrete cases: data sent to a third-party MCP server is governed by that third party's retention policy, and hosted containers used by the code interpreter write temporary state to their filesystem while active. An agent calling three external tools has three additional retention policies nobody has read.

The retention regime therefore behaves as a selection criterion rather than as an end-of-contract clause, and the argument is not theoretical. During the litigation between OpenAI and The New York Times, the preservation order covering consumer ChatGPT exchanges explicitly excluded API customers under a non-retention agreement. The difference in regime produced an observable legal difference, and it remains the only full-scale test this market has.

What to start this week

Inventory the endpoints actually called in production and check them against your provider's eligibility list. The useful number is not how many of your projects are covered by an agreement, it is how many daily calls go to an ineligible endpoint. It is in your gateway logs, not in the contract.

Ask in writing for the list of derived signals that leave your perimeter, not the list of data that gets stored. The two questions have different answers and only one of them appears spontaneously in commercial replies.

Have legal read the unilateral reversibility clauses, naming the mechanisms that let the provider withdraw the non-retention regime for a model or for your organization. The question to settle is whether advance written notice leaves you a workable window to migrate, and what you do during that window.

Put the September white paper into your compliance register as a dated review point, with an owner and a date. A documentation promise accepted without a deadline becomes a permanent assumption.

Classify your use cases by data sensitivity rather than by owning team. That is the only split that then lets you align an eligible endpoint, a model and a jurisdiction onto each flow, instead of applying the strictest regime to everyone and watching teams route around it.

Conclusion

The question that structures an AI compliance file is no longer whether the provider retains your data, because the two main ones are converging on the same answer and it will soon be handed to you without negotiation. It is what information derived from your data leaves your perimeter, in what form, with what proof, and what happens the day the provider exercises a clause it wrote alone. An enterprise with no written position on this is not without one: it has its provider's.

Sources: As of August 2026

Godwin AVODAGBE