"We don't train on your data" has become the standard reassurance every AI vendor offers a nervous enterprise buyer. It's also, on its own, close to meaningless. Not training a shared model on client data is table stakes — it says nothing about where the data physically sits while a model processes it, who else's infrastructure it passes through, or what gets logged and retained along the way.
For an insurer, that distinction isn't academic. Policy data, claims narratives, and underwriting submissions carry PII, and in many lines, protected health information. A vendor's privacy answer needs to hold up to a regulator's question, not just a sales conversation.
Two architectures that get described the same way
Most enterprise AI vendors fall into one of two patterns, and the marketing language often doesn't make clear which one you're buying.
The four questions that actually reveal the architecture
Marketing language rarely distinguishes these two patterns, so the useful move is to ask questions that force a specific, technical answer rather than a reassuring one.
- Where does inference happen? "In our cloud" is not an answer. Which cloud, whose account, and is it a resource dedicated to you or shared across customers?
- What gets logged, and where? Prompts, documents, and outputs are often logged for debugging or monitoring — sometimes outside the boundary the vendor describes as private.
- Can another customer's usage ever influence your model's behavior? Fine-tuning on aggregate usage, even anonymized, is a form of cross-tenant influence worth naming explicitly.
- What happens to data after the contract ends? Deletion timelines and whether backups are included are usually where the real answer lives.
What the boundary looks like end to end
For an insurance AI application specifically — underwriting triage, claims intake, document processing — the privacy question isn't just about the model. It's about everything the data touches on the way in and out.
Privacy that depends on a vendor's internal policy is a promise. Privacy that depends on architecture is a fact.
Why this gets harder to verify as AI vendors scale
The pressure on any AI vendor is to serve more customers off shared infrastructure, because that's what makes the unit economics work. That pressure is completely reasonable for a vendor selling generic productivity tools. It's a poor fit for a vendor handling regulated insurance data, where the cost of getting isolation wrong isn't a support ticket — it's a breach disclosure.
This is also why "SOC 2 compliant" and "enterprise-grade security" are necessary but not sufficient answers. Those certifications typically describe operational controls — access management, incident response, audit logging. They don't, by themselves, tell you whether your data physically shares infrastructure with another company's.
The practical takeaway for any enterprise evaluating AI vendors, insurance or otherwise: ask for the architecture diagram before you ask for the privacy policy. The diagram tells you what's structurally possible. The policy only tells you what someone has promised not to do.