Anthropic logs 30 days on its top models, OpenAI no longer does

Anyone building AI features into a product used to settle the data retention question once, clarify it with the provider and then tick it off. That approach stopped working this summer. Within a few weeks the two largest providers moved their rules in opposite directions, and not at provider level but per model.

That is the actual news. Retention policy no longer attaches to the contract, it attaches to whichever model sits in your code.

What Anthropic has required since June

With Claude Fable 5 and Mythos 5, Anthropic introduced a category it calls covered models. For these models a retention requirement has applied since 9 June 2026: every prompt and every output is stored for 30 days.

Two details matter. First, there is no opt-out, not even for enterprise customers who had previously agreed zero data retention contractually. Second, the logs explicitly serve misuse detection rather than model training. That is a meaningful distinction, but it does not change the fact that content sits with the provider for a defined period.

For teams in regulated environments that is precisely the sticking point. Anyone who built a data protection impact assessment on the assumption that nothing remains with the processor has to strike that assumption for these two models.

What matters most, though, is the scope of the rule, and most coverage leaves it out: it applies to these two frontier models only. Opus 5, Sonnet 5 and Haiku 4.5, the models that actually run practically every production workload, are not covered. Anyone who does not specifically need the most capable model available is simply unaffected.

Photo: Cytonn Photography / Pexels

What OpenAI committed to on 19 August

OpenAI moved in the other direction and confirmed zero data retention for eligible API customers on its frontier models. Requests and outputs are not retained after processing, staff have no access to customer content, and enterprise data is not used for training unless the customer explicitly opts in.

More interesting than the commitment is the technical route to it. Both providers face the same problem: misuse is most reliably detected by looking at patterns across multiple sessions, and that normally requires stored content. Anthropic solves this through retention. For the same purpose OpenAI has announced a mechanism called Private Safety Processing, in which automated systems are meant to spot cross-session patterns without staff gaining access to the underlying content. A technical paper on it is announced for September 2026.

Whether it delivers what it promises cannot be judged before that paper is published. Until then there is a documented retention requirement on one side and a commitment whose technical implementation is still pending on the other. Both belong side by side, fairly stated.

Photo: cottonbro studio / Pexels

Why this is more than a footnote

The real break lies not in either rule but in where responsibility now sits. Data retention used to be a matter between company and provider, settled in a contract, valid for everything running through the interface. Now the same provider, under the same contract, can apply two different rules to two different models.

That has practical consequences for how AI features get built. Changing a model in a configuration file used to be purely a performance and cost decision. Now the same edit can change the data protection assessment of the entire application without anything else in the code moving. And because such model swaps often happen casually whenever a newer model ships, this is a change that slips through easily.

There is a second point: with models under forced logging, it does not help that the data is deleted afterwards. For the duration of the retention period it sits with the provider, and if that provider is based in the US, that is a third-country transfer with everything that entails.

Photo: Luis F Rodríguez Jiménez / Pexels

What I take from this for projects

Three things have proven workable, and none of them is laborious.

Model choice belongs documented, not assumed. Every project with AI features should record somewhere which model is called at which step. That sounds trivial but often is not the case in practice, because model IDs sit scattered across configuration files and environment variables. Gathering that once gives you the basis for every further assessment.

Not every step sees personal data. In most applications I build, only a small share of calls processes real personal data at all. Summarising internal documentation, classifying by topic, drafting a text block, none of that needs it. Separating those steps cleanly from the ones touching customer data shrinks the set of genuinely critical calls considerably. And only for those does the model need to be chosen on data protection grounds rather than capability.

Zero data retention is a building block, not a solution. Even with zero retention you still need a data processing agreement under Art. 28 GDPR, a legal basis for the processing, and with providers outside the EU an assessment of the third-country transfer. The retention rule answers one of several questions. Which is exactly why it is no disaster when a single model answers it differently, as long as you know which one.

On balance the development is less dramatic than the headlines suggest, but it does require a shift in thinking. The question is no longer which provider you trust, but which specific model runs where, and what data it gets to see in the process.

If you have AI features in production and are unsure which models your workflows actually call and what data arrives there, I am happy to take a look. The answer is usually less alarming than feared, and the few critical spots can be reworked deliberately.