AI Security
The model retention question that stalls your AI deal in security review
Big buyers are barring commercial AI models over 30-day data retention. Five questions to answer before your security review turns retention into a deal blocker.
September 18, 2026 · 5 min read

The clause that is killing AI deals right now is not about accuracy or price. It is about how long the model vendor keeps the data you send it, and who gets to turn that off.
Three large buyers made that concrete this quarter. Nvidia, Palantir, and Booz Allen Hamilton each restricted or reconsidered commercial Anthropic models over data retention (r/AIGuild summary). Palantir pushed for an irrevocable zero-data-retention guarantee. Booz Allen barred employees from using Anthropic commercial models for proprietary cybersecurity work. The reason is a default many teams never read: the commercial tier can require 30-day data retention for safety monitoring, and by default that retention is on.
If you sell a HealthTech or public safety product that embeds a commercial model, this is not someone else's news. It is the question your next regulated buyer asks in security review, and if you cannot answer it cleanly, your deal stops there.
Why retention is a deal question, not a marketing line
A regulated buyer does not evaluate your AI feature. They evaluate the data path behind it. When a hospital or an agency runs your product through review, they are asking a single question in five different ways: where does our data go, how long does it live there, and who can see it. Model retention sits at the center of every one of those.
The default retention window is the part that surprises people. Safety monitoring is a reasonable thing for a model provider to do. But a 30-day retention default means your customer's data is held by your sub-processor for a month, for a purpose your customer never agreed to, under a policy your customer cannot see. To a buyer bound by HIPAA or by criminal justice data rules, that is not a footnote. It is a finding. And it is your finding, because you chose the sub-processor, not them.
This is the trap for a vendor. You treated the model as a feature. Your buyer treats it as a sub-processor in their data chain, which is exactly what it is. The review does not care that the retention is for safety. It cares that data leaves the buyer's control for a window the buyer did not authorize.
The five-question retention rider
The way through is to answer the retention question before the buyer asks it, in writing, in language a security reviewer recognizes. I built this as a five-question rider that goes into the Buyer Risk Pack, the deal-review kit I use with vendors selling into regulated markets. Answer these five before your first serious security review and retention stops being the thing that stalls the deal.
- Default retention. What is the retention window on the tier you actually use, in days, from the provider's own documentation. Not the marketing tier. The one your product calls in production.
- Zero-retention option. Is a zero-data-retention path available, on what tier, and what does it cost or change. If it exists, say so and say how you turn it on. If it does not, say that too, because the buyer will find out.
- Training use. Is customer data used to train or improve the model on the tier you use. Yes or no, with the clause that says so. This is the question that ends fastest when you cannot answer it.
- Customer-held logs. Can the buyer keep their own record of what was sent and returned, independent of the provider. Regulated buyers need their own audit trail, not a promise that yours exists.
- Who can disable monitoring. If safety monitoring drives the retention, who has the authority to turn it off, and is that authority yours to give or the provider's. This is where the Palantir demand landed: an irrevocable guarantee, not a setting someone can quietly change.
Five questions. Each maps to a clause in the provider's terms, not to your opinion. A buyer's reviewer can check every answer against the source. That is the point. You are not asking them to trust you. You are handing them a document they can verify.
Answering without overclaiming
The discipline that matters here is the same one I hold on every risk claim: answer from the source, not from confidence. If your model tier retains data for 30 days by default and you have not enabled a zero-retention path, the honest rider says exactly that, and then says what you are doing about it. A reviewer will respect a clear no far more than a vague yes they later catch.
I do not sit on any information-sharing body, and I do not need to in order to write these questions. They come from reading the provider's own terms and from the pattern of what regulated buyers reject. That is the whole method. Read the contract your product depends on, translate it into the questions your buyer will ask, and answer them before the review instead of during it.
Where this fits
The vendors who lose deals to retention are not the ones with bad models. They are the ones who never read the retention default on the tier they shipped, and who meet the question for the first time in a buyer's security review with no answer ready. By then the deal has a hold on it and the reviewer has a reason to say no.
This is the work the AI Governance Toolkit and the Buyer Risk Pack are built to do: treat retention, training use, and sub-processors as deal questions with documented answers, not as things you hope no one asks. If you sell into hospitals or agencies and your product embeds a commercial model, write the five-question rider this week. Find your default retention window before your buyer does.