The vendor you vet is not the vendor you get

Ask a frontier model provider whether it trains on your data, and you will get a clear answer. Anthropic and OpenAI both state plainly that they do not train their models on enterprise customer data, and OpenAI has described internal practice in some detail: field teams who work with a customer’s deployment can share what they learned from doing the work, without that meaning the customer’s own data was used to train anything. It is a real distinction, and procurement teams are right to ask for it in writing.

It is also the wrong question to stop on, because it answers only one of the two ways a model provider can end up working against you.

Two different promises

A data-training assurance is a promise about your information: it will not become part of the model’s weights, available to be recalled for someone else. That promise says nothing about a second and separate risk, which is that the provider itself, quite legally and without touching your data at all, decides to build a product that competes with you.

The pattern is already visible. Anthropic partnered with Figma, building integrations and workflows around Figma’s design product, and later launched Claude Design, its own design tool that competes directly with Figma. No part of that sequence requires Anthropic to have trained on Figma’s customer data. It requires only that Anthropic learned, through the ordinary course of a technology partnership, where the valuable problems in that market were, and decided the capability it had built was worth productising on its own account. A vendor can keep every data-handling promise it made and still become a competitor, because the thing it learned from you was never the data. It was the shape of the opportunity.

Why this is easy to miss

Data-training questions get asked because they map cleanly onto existing procurement language: confidentiality clauses, data processing agreements, categories a legal team already has a checklist for. Competitive-entry risk does not map onto anything a standard vendor review was built to catch, because the harm does not arrive through a data breach or a contract violation. It arrives through a product announcement, and by the time it does, the commercial relationship is often too embedded to unwind quickly.

The risk is also uneven rather than universal. A provider is a plausible future competitor where the value it is helping you capture is a horizontal capability, adjacent to the provider’s own roadmap and cheap for it to build once it understands the market, rather than where the value sits in your domain expertise, your regulatory position or your operational data, none of which a model provider can simply decide to acquire. Distinguishing the two is a judgement about the specific product and the specific vendor, not a rule that frontier providers cannot be trusted.

What the question should actually be

A vendor review that stops at data handling has checked the box a legal team can see and left open the one that actually decides whether the relationship is safe to build a strategy on. The fuller version asks, in addition: what markets is this provider entering or plausibly entering, does what we are building depend on capability the provider could offer directly to our own customers or competitors, and how coupled would we be to this provider by the time that answer changed. None of those questions has a template answer, which is exactly why they are the ones worth asking before the relationship deepens rather than after a launch announcement makes the answer obvious.