News analysis · 15 September 2026
Palantir and Nvidia Restrict Claude Use: Make Zero Retention Verifiable
By the ELYMENT AI editorial team · Free to read
Reuters reported on 14 September 2026 that Palantir, Nvidia and Booz Allen Hamilton were restricting or reconsidering advanced AI use because of proprietary-data concerns. The companies did not immediately comment, so their reported positions are not confirmed corporate policy. The business lesson is concrete: no-training promises differ from zero data retention. Buyers should verify the exact model, feature, organisation, integration and exception path covered before sensitive work reaches an AI system.
What the reported restrictions reveal
According to Reuters, citing The Information, Palantir pressed Anthropic for an irrevocable zero-data-retention commitment before making certain models available through its software. Nvidia reportedly limited Anthropic models to less-sensitive work and used its own Nemotron models internally, while Booz Allen reportedly barred Anthropic's commercial model from proprietary cybersecurity work.
The reported decisions are not proof that customer data was misused. They show that sophisticated buyers increasingly treat retention terms as an architecture and procurement decision, not a privacy-page footnote.
Zero retention has a technical boundary
Anthropic's current Claude Platform documentation says a zero-data-retention arrangement means customer prompts and responses are not stored at rest after the API response is returned. It also says ZDR is enabled per organisation, does not automatically extend to another organisation under the same account and covers only eligible endpoints, models and features.
The exclusions are material. Anthropic lists consumer products, Teams and Enterprise interfaces, Managed Agents, Claude for Excel and several stateful features as outside standard ZDR eligibility. Its Covered Models, including Claude Fable 5.1 and Claude Mythos 5.1, require 30-day retention unless Anthropic expressly authorises otherwise. Third-party integrations are not covered, and flagged content or legal holds can create separate retention paths.
This is why the question 'Do you train on our data?' is too narrow. A provider may answer no while prompts, outputs, files, session transcripts, telemetry or connector data are still retained for another documented purpose.
Require proof across six layers
Before approving sensitive AI work, require a retention evidence pack covering:
- Workload classification: define which data is public, internal, confidential, regulated or prohibited from external processing.
- Exact route: record the provider, model version, API organisation, workspace, cloud processor, region, endpoint, enabled features and connected tools.
- Contract scope: identify the binding retention term, its effective date, covered services, exceptions, change-notice requirement and remedy if terms change.
- Configuration proof: capture the organisation-level setting, workspace exceptions and a test showing that an ineligible feature is blocked or routed elsewhere.
- Secondary copies: map application logs, observability traces, prompt caches, files, vector stores, browser history, connector records, backups and support exports.
- Exit test: prove that the workload can move to an approved model, isolated environment or local system if retention terms become unacceptable.
Separate provider controls from your own copies
Even a valid provider ZDR arrangement cannot delete copies created by the buyer's application or another processor. An AI gateway may log prompts, a support platform may preserve transcripts, or a connector may retain source records under its own policy.
Security and legal teams should therefore approve the complete data path, not only the model vendor. Runtime controls should block prohibited routes, minimise payloads, redact unnecessary identifiers and alert when a model or feature falls outside the approved retention profile.
What business leaders should do next
Inventory sensitive AI workflows and label each with its current retention route. Where evidence is incomplete, restrict the task. Re-run the check whenever the model, workspace, feature, connector or provider term changes.
ELYMENT AI's earlier analysis of Anthropic's enterprise retention plan explains the provider-side options. Our AI services contracts guide covers contractual risk allocation, while the AI incident-metrics framework shows how to preserve useful evidence without uncontrolled logging. ELYMENT AI can help turn those requirements into an approval matrix that procurement, security and operators use together.
Sources
- Reuters: Palantir and Nvidia curb AI model use (14 September 2026) - Independent reporting, attributed to The Information, on reported restrictions by Palantir, Nvidia and Booz Allen and the companies' lack of immediate comment.
- Anthropic: API and data retention (Accessed 15 September 2026) - Primary documentation defining ZDR, organisation-level enablement, feature and product exclusions, Covered Model retention and exception paths.
- OpenAI: Enterprise privacy (Accessed 15 September 2026) - Primary provider statement used to distinguish no-training commitments from product-specific retention and control terms.
Continue learning
Frequently asked questions
Is zero data retention the same as no model training?
No. No-training terms address whether customer content is used to improve models. ZDR addresses whether covered prompts and responses are stored at rest after the API response. The scopes and exceptions must be checked separately.
Does Anthropic ZDR cover every Claude product and feature?
No. Anthropic documents ZDR by organisation, model, endpoint and feature. Consumer products, several stateful services, third-party integrations and Covered Models are among the exclusions or special cases.
What should a business record before sending confidential data to AI?
Record the data classification, exact provider route, contract version, retention configuration, exceptions, secondary logging systems and tested fallback path.