OpenAI has committed to a Zero Data Retention architecture in which customer prompts and responses are not retained after processing, not available to OpenAI personnel for review, and not used for model training without explicit opt-in. Anthropic requires a 30-day retention window for all traffic on Mythos-class models , its most capable tier, for safety monitoring purposes. [1] [2]
These are not minor configuration differences. They reflect opposite answers to the same engineering question: how do you detect sophisticated misuse visible only across many interactions when your customer's data obligations say you cannot hold the content?
The Split Neither Vendor Can Hide
OpenAI's answer is to separate the signal from the substance. Under Zero Data Retention, safety systems evaluate each interaction individually. The company is previewing "Private Safety Processing," designed to identify patterns across interactions without giving personnel access to the underlying content. When a risk is identified, OpenAI describes receiving only a "narrowly defined signal" about the activity type. Personnel don't see the flagged content. Customers investigate alerts in their own systems and may choose to share information if they appeal or pursue an abuse investigation. Customer content stays on customer-controlled infrastructure; OpenAI is developing an option using OpenAI-held infrastructure encrypted with customer-controlled keys, with no copy held by OpenAI. [1]
One carve-out applies regardless of tier: images flagged for child sexual abuse material will be retained for manual review and legal reporting. [1]
Anthropic's answer starts from a frank concession: it has "less confidence" in its ability to flag certain serious misuse on zero-retention surfaces, and it knows of no mitigation strategy for the most dangerous actors other than refraining from deploying sufficiently capable models on those surfaces in at-risk settings. [3]
What Anthropic Requires, and Why
The company's August risk report frames the retention requirement as a decision it expects to be "unpopular with customers who have come to expect zero retention, and pose real risks to our business success (especially if competitors do not follow)." It describes the requirement as essential to detect attacks that span multiple requests, particularly attempts to develop offensive cyber capabilities or biological weapons. Retained data is not used to train new models or for non-safety purposes. Human access is logged. Deletion follows after thirty days in almost all cases. [2] [3]
This is a claim that the absence of retention makes certain categories of misuse harder to detect. The architecture accepts an expansion of the data a customer must trust Anthropic to hold in exchange for Anthropic's ability to monitor patterns across sessions.
What Each Vendor Concedes
OpenAI's Private Safety Processing is a preview, currently being tested with early customers. A full rollout and technical white paper are planned for September. OpenAI describes the safety architecture as "designed to" identify patterns without exposing content to personnel. That framing is honest about the status: the design goal is stated, not the demonstrated outcome. A customer adopting the preview accepts that the system has not yet been independently verified at scale. [1]
Anthropic's concession runs the other direction. Its own risk report acknowledges that mandatory retention poses real business risk and will be unwelcome to customers with strong data-handling obligations. For organizations in finance, health, legal services, or the public sector, those obligations often aren't preferences. They are regulatory requirements or contractual commitments to the people they serve. Anthropic's architecture asks those organizations to weigh reduced detection confidence under zero retention against the compliance cost of permitting a vendor to hold sensitive content for any period. [3]
Neither position is free. One trades some safety detection confidence for data custody. The other trades some data custody for safety detection coverage, while that coverage remains unverified in production.
What Belongs in a Model-Approval Record
For organizations with data-retention obligations, these architectural differences are now a procurement criterion, not an appendix to one. A model-approval record for any regulated workflow should document, at minimum: the retention period for prompts and responses; who can access retained content, under what conditions, and through what logged path; where encryption keys are held and whether the vendor holds a copy; any legal carve-outs that override the stated retention policy; and the eligibility terms under which the vendor's commitments apply to a specific deployment tier.
On the OpenAI side, Zero Data Retention is currently offered to eligible API customers, with the Private Safety Processing rollout and technical white paper planned for September. The carve-out for legally required reporting applies regardless of tier. The customer-controlled-key infrastructure option is still in development. Organizations evaluating the architecture should confirm eligibility, review the white paper when it publishes, and understand what the "narrowly defined signal" transmitted to OpenAI actually contains. [1]
On the Anthropic side, the thirty-day retention requirement applies to Mythos-class models and extends to future models of similar or greater capability. Organizations should confirm the data-access logging practices, what constitutes deletion under the policy, and whether their regulatory framework treats any vendor retention period as a compliance exposure. [2]
The practical consequence: route sensitive workflows only to model tiers whose data-handling architecture matches the organization's obligations, and document that routing decision. Where no available tier matches, that gap itself belongs in the record.
When the white paper arrives, it will either close some of the verification gap in OpenAI's approach or clarify what remains open. Either outcome is useful information for procurement.