The default setting that let your vendor learn from your data

A product manager at a B2B company told me about an assumption that went unexamined until a customer asked about it directly. The customer wanted to know whether the data they put into the product could end up training someone’s model. The team’s honest first answer was that of course it could not. Then they actually read their provider’s terms and checked their account settings, and the picture was less certain than they had assumed. The default behavior, the tier they were on, the specific endpoints they used, all of it mattered, and the setting that guaranteed their data would not be used for training was one nobody had turned on because nobody had known to look.

Whether a model provider uses your prompts to improve its models is a real, consequential difference between vendors, and the default is not always the one you would guess. Some providers do not train on business API traffic. Some do unless you opt out. Some draw the line differently for different products or tiers. The only way to know is to read the specific terms for the specific way you are using them.

The default is a decision someone else made for you

When you sign up for a model provider and start sending prompts, you inherit whatever their default handling is. That default was chosen to suit them, not you. It might be fine. It might mean your prompt data, which for many teams contains customer information, is eligible to be used in ways your own customers never agreed to.

The gap between assumption and reality is the danger. Teams assume the enterprise-sounding product they are paying for keeps their data private, and often it does, but often the privacy depends on a setting, a tier, or an agreement that has to be actively in place. Assuming it is handled, without checking, is how you end up telling a customer something that turns out not to be true.

And this is exactly the kind of thing customers ask about now. Whether their data trains a third party’s model is a standard question in security reviews and procurement. Answering it confidently requires that you have actually read the terms, not that you assumed the reasonable thing.

Read the terms for your specific use

The fix is unglamorous and it is the whole job. Know, in writing, what your provider does with the data you send.

What to confirm:

Whether prompts are used for training. For your exact product, tier, and endpoints, not the general marketing claim.
How to opt out, and whether you have. If data is used by default, find the setting or agreement that changes it, and confirm it is actually in place.
How long data is retained. Even without training, retention matters, because it determines how long your prompts live in someone else’s systems.
What the data processing agreement says. The signed agreement, not the website copy, is what governs the relationship, and it should match what you tell your customers.

The teams that get this right treat the provider’s data handling as a fact to verify, not a comfort to assume. It takes an afternoon to read the terms and check the settings. It takes far longer to walk back a promise you made to a customer on an assumption that was wrong.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week, $2,500 engagement, we check what your provider actually does with your data, for the specific way you use them. Whether they train on it, how to prevent that, how long they keep it, and whether your settings match your assumptions. When a team tells us their prompts are private, we ask them to show us where the terms say so.

Whether your vendor learns from your data is often a setting, not a given. Read the terms for your exact use, and make sure the default is the one you thought it was.