Separate reports, announcements, and causes
On September 14, Reuters relayed a report from The Information: NVIDIA was limiting Anthropic models to less sensitive tasks, Palantir was seeking irrevocable zero-data-retention arrangements, and Booz Allen was restricting their use for proprietary cybersecurity work. The report covered enterprise concerns about data at Anthropic and OpenAI, but provided no formal notice of NVIDIA banning both companies’ models across the board. The parties did not immediately respond to requests for comment. Reuters report
A separate, publicly confirmed fact is that NVIDIA and Palantir announced a supply chain intelligence partnership on September 10. The deployment would begin with NVIDIA’s own operations, using Nemotron and emphasizing control of proprietary data. Joint announcement
These developments can be considered together, but they cannot be joined into an unproven causal claim: “NVIDIA switched to Nemotron because of Claude’s retention policy.” Deploying its own models could involve business customization, cost, data governance, and product strategy at the same time. The deployment announcement does not confirm every motive suggested by the reporting.
Nor has NVIDIA always rejected external models. In April, it described its internal use of GPT-5.5-powered Codex, saying that more than 10,000 employees were already using it. The deployment used approved cloud virtual machines, dedicated environments for individual employees, read-only access to production systems, and a ZDR policy. This is the company’s own disclosure, not an independent audit. It nevertheless shows that the question is which paths and data an external model may access. NVIDIA’s deployment account
Why 30 days can change a purchasing decision
On June 9, Anthropic released Fable 5 and Mythos 5, explaining that this class of model required 30-day retention of business traffic to detect complex abuse across interactions. The company said the purpose was safety defense rather than training new Claude models. Launch and retention announcement
For a vendor, an individual request may not reveal an attack assembled from multiple requests. For a customer, retaining the full content creates an additional storage location, access process, and exposure to incidents over the following month. Both sides may be pursuing security while reaching different conclusions about what security requires.
This does not overturn a promise not to use data for training. It shows that the promise never answered every question. Even if data does not change model weights, it may still enter logs, abuse investigations, troubleshooting, or other service state. Whether sensitive designs, unpublished financial information, or supply chain data enter a training set is only one measure of their exposure.
On September 1, Anthropic announced Enterprise Frontier Safeguards. The proposal would store safety signals in customer-controlled cloud storage, with customers managing keys, permissions, and audits. A phased rollout was planned for later that fall, with temporary ZDR arrangements for eligible customers in the meantime. Announcing a solution, establishing a customer’s eligibility, and completing a deployment are three different states. By mid-September, this could not be described as a guarantee already delivered to every customer. EFS announcement
ZDR is not an umbrella for four different promises
Zero data retention is first a service arrangement with a defined scope: which organization, which endpoint, which content, and which retention period. Reducing it to “the vendor never touches data” makes it harder to verify.
| Promise | What it actually answers | What still needs separate confirmation |
|---|---|---|
| No use for training | Whether inputs and outputs improve the model | Safety logs, fault records, and human investigations |
| Zero data retention | Whether the agreed content is stored persistently | Covered models, endpoints, data types, and exceptions |
| Restricted human access | Who can view raw content | Automated processing, approved exceptions, and access records |
| Customer-controlled storage | Who manages location, keys, and permissions | Runtime processing, subcontractors, and the customer’s own configuration risks |
OpenAI’s data controls documentation distinguishes training use, abuse monitoring logs, and application state. API data not being used for training by default does not make every feature stateless. Applying for ZDR also requires checking endpoint eligibility: files, conversations, and vector stores do not automatically inherit the same guarantees from the settings of an ordinary request. OpenAI data controls documentation
This distinction matters particularly for agents. An individual call might retain no content, while the agent’s file store, conversation history, tool logs, and third-party search services still hold information. Reviewing only the model endpoint does not cover the entire workflow.
What has counted as evidence that nothing was retained?
A customer cannot tell from a normal response whether the server also saved a log. Capturing network traffic can show what was sent, but cannot reveal everything that happened inside the vendor’s systems. Credible ZDR has therefore depended on mutually consistent evidence, rather than a dashboard displaying a zero.
The contract defines scope and responsibility first: retention periods, permitted uses, subcontractors, exceptions, change notices, and audit rights. Account settings apply these commitments to organizations, projects, models, and APIs. Architecture documentation explains which systems handle the data; operational records show whether access, deletion, and exception procedures followed the agreement. Independent audits provide assurance about particular controls over a specified period.
| Verification layer | Evidence to obtain | Limits of that evidence |
|---|---|---|
| Obligations | DPA, ZDR agreement, exceptions, and change clauses | A basis for accountability, not proof that every call complied |
| Configuration | Organization approval, endpoint eligibility, versions, and retention settings | Covers only the paths associated with that configuration |
| Data flow | Log locations, access controls, caching, and deletion mechanisms | Must also explain state outside the model and downstream services |
| Operations | Access and deletion records, exception handling, and audit reports | Audits have a scope and period; they are not permanent guarantees |
A SOC 2 report or ISO certification does not replace this work. An enterprise needs to check whether the report covers the purchased service and relevant controls, rather than merely finding a badge on the vendor’s website. Error logs, caches, and overlooked intermediate services are particularly easy to miss in the gap between a contractual commitment and its implementation.
A model upgrade can reopen the issue. A previously approved model might not require a particular kind of retention, while a new one requires safety review. Automatic switching could then carry the customer beyond its original boundary without a new decision. Irrevocable commitments become a negotiating point because customers want not only today’s configuration, but also the right to refuse when the rules change.
A strict mode should stop when conditions are not met
Zero retention cannot be engineered through a vague intention to log as little as possible. The failure behavior must be explicit: when a model or feature does not satisfy the constraint, is the call rejected, or does the system quietly switch to default retention?
AWS Bedrock’s retention documentation offers a useful implementation example. A strict no-retention mode can block models that require data to be stored; setting store=false in a request does not replace the platform’s retention policy. Supported modes may change, but the design principle is clear: if the constraint is not met, do not proceed with the call. Bedrock retention documentation
Enterprises can design access controls around this principle without depending on every vendor keeping the same rules forever. Public material can go to general services, while restricted data follows approved paths only. Files and tools can be reviewed separately, and model version changes can trigger a new review. The essential requirement is that the list governs real requests, rather than simply appearing in a procurement appendix.
Running one’s own models can shorten the path data takes across organizations, but does not automatically remove risk. Responsibility for keys, patches, permissions, backups, and security response returns to the enterprise. A self-hosted service that nobody maintains may be more vulnerable than a mature vendor’s controlled service.
Questions an enterprise should be able to answer
Instead of asking only whether ZDR is supported, ask the vendor and internal platform team to explain together:
- Which organization, region, model version, endpoint, and intermediate services handle this call.
- Where inputs, outputs, metadata, files, caches, and tool logs are stored, and for how long.
- Which automated systems and people can access them, who approves exceptions, and what evidence is recorded.
- Who notifies customers when model upgrades or safety policies change, and whether customers can continue to refuse retention.
- Whether the system rejects the request, alerts the customer, or switches modes when the conditions are no longer met.
This evidence cannot prove absolutely that no copy has ever existed anywhere. It can turn a vague promise into an arrangement that can be checked, declined, and enforced.
Frontier models intensify the conflict: safety systems want to observe usage for longer, while enterprises want raw data to disappear quickly. A purchasing decision therefore depends on more than model intelligence. When both requirements cannot be satisfied, can the enterprise still hold to the boundary it approved?
References
- Reuters: Report on Palantir, NVIDIA, and Booz Allen restricting model use over data concerns
- The Information: Anthropic data concerns prompt enterprise restrictions on model use
- Anthropic: Fable and Mythos access and data retention policy
- Anthropic: Data retention practices for Covered Models
- Anthropic: API and data retention
- Anthropic: Enterprise Frontier Safeguards
- OpenAI: Platform data controls
- OpenAI: Security and privacy
- NVIDIA: Internal deployment of GPT-5.5-powered Codex
- NVIDIA and Palantir: Sovereign intelligence for critical supply chains
- AWS Bedrock: Data retention modes
写作附记
Original Prompt
$blog-writer provides a detailed breakdown of the whole story. Reports indicate that Nvidia has internally restricted the use of frontier models from Anthropic and OpenAI, switching sensitive data to its own AI. How did various companies previously prove ZDR?
Rewrite the articles from these three months. If an article was not written by AI, do not rewrite it.
Comments
Comments will load when you scroll here.