Whose Model Trains on Your Prompts? AI Free-Tier Data Terms

The price of a free tier is rarely the money. It is the data. Every major free tier answers the question "what happens to my prompts?" differently, and in most cases the answer changes between the free tier and the paid tier of the same product. Two tiers with identical token allowances can be opposite privacy events, and the only difference is which one you are billed on.

Here is what six widely used free tiers actually state, verified against their official pages this month.

The spectrum, side by side

Three patterns emerge from that table, and each one has a practical consequence.

Pattern 1: the tier switch is the privacy switch

Google is the clearest example. Its pricing documentation says it directly: free-tier content is used to improve Google's products, and the paid tier is where that stops. Same API, same key format, different data policy. The switch is a billing change, not a contract negotiation.

Anthropic runs the same mechanism at plan level: consumer free usage trains by default with an opt-out available, while Team and Enterprise default to no training. The privacy posture is not a hidden setting; it is a property of which plan you pay for.

The implication is that "does this provider train on my data?" is the wrong question. The useful question is: does this provider train on my data on the tier I am actually on? The honest answer often changes when the billing does, and it can change again when a promotional tier ends.

The workflow consequence is unglamorous but effective: bookmark both the terms page and the pricing page's data-use line for every provider you use, and note the tier each statement applies to. They are frequently different documents, and the pricing page is often the one that carries the tier distinction.

Pattern 2: the commercial-use ban on trial keys

Cohere handles risk differently. Its trial API key is free and usable — but its pricing page states that trial keys are rate limited and are not permitted for production or commercial use. Note what that restriction touches: it governs what you may do with the output, not what the provider does with the input.

That is a clause people discover at the worst possible moment, when a side project acquires paying users. The fix is procedural rather than technical: start the production-key application, or the sales conversation for current-generation models, well before you ship. Lead time is the real cost, and it is the kind of cost a launch plan can absorb if it is on the plan.

A second, related trap exists on platforms with trial credits rather than trial keys: the account itself has an expiry. Bedrock's free-plan account for new AWS customers runs for a limited window and then closes unless you convert to paid. Azure's trial credits expire on their own clock. In both cases the data terms were clean throughout — the thing that ran out was the money.

Pattern 3: the enterprise wrapper inherits the enterprise terms

Bedrock and Azure sit at the opposite pole from consumer free tiers. The "free" element is a credit attached to a normal cloud account, and the data terms are the standard cloud terms that apply to every dollar you spend there: you retain your data, and the provider does not train on your content.

The catch is structural, not textual. First, the credits expire. Second, and more subtly, the account you built during the trial is the production account — there is no later migration to a cleaner tier, because you were already on the clean terms. What changes when the credit runs out is the bill, not the policy.

For teams with existing cloud commitments, that makes these the least surprising free tiers to evaluate on. For individual developers, it makes them the least accessible, since the entry point is a cloud account rather than a signup form.

The four clauses people confuse

Data-use terms are shorthand for four separable commitments. Providers state them in different places, and a strong answer on one does not imply a strong answer on the others.

Two of these are routinely conflated. "We do not train on your data" is not the same as "we do not keep your data." A provider can decline training while retaining inputs for a defined period for abuse monitoring. Similarly, a no-training commitment on the API can coexist with human review of flagged conversations for consumer interfaces. Read the retention and review clauses separately; they are where the operative detail lives.

The fourth clause, routing, deserves attention specifically for gateway users. When you call a model through an aggregator, the sub-processor may not be the brand on the dashboard. A routed request can be served by a different upstream provider than the one you assumed, and their retention rules apply to that request. If your compliance position depends on who processes the data, verify the routing disclosure rather than assuming a single upstream.

What to send, in what order

Three rules do most of the work.

1. Synthetic first. During any free-tier evaluation, send data you could publish. This is not paranoia; it is calibration. A free tier is the cheapest place to learn a provider's quality and the worst place to test its confidentiality, and an evaluation dataset of synthetic documents answers the quality question just as well.
2. Read the clause for the tier you are on, not the tier you intend to buy. Free-to-paid data-policy changes are routine. The statement that matters today is the one that names today's tier.
3. Treat commercial-use bans as launch blockers. If the terms say "no commercial use", that is a milestone with lead time attached, not a footnote. Put it on the release checklist the same way you would put a domain purchase.

A compact evaluation protocol that encodes the above:

[object Object]

A synthetic first-pass harness

The point of the synthetic step is to make "send something harmless" the default rather than a discipline you have to remember. A small generator is enough:

[object Object]

Every record is explicitly labelled as synthetic, which matters if you later need to demonstrate what you sent during an evaluation. Keep the corpus and the provider's data-use URL together in your notes.

Compliance questions worth taking to counsel

We are publishers, not lawyers, and none of the above is legal advice. What we can do is narrow the list of questions a technical team should put in front of counsel, because a reviewer with a legal background will ask for exactly these:

• Which tier are we on, and what does the provider's own documentation say about training for that tier?
• Does any clause require us to obtain consent from the end users whose data we submit?
• Are we subject to a residency requirement, and does the provider offer a region that satisfies it?
• Which sub-processors handle our requests when we route through a gateway, and are they disclosed?
• What is the retention period, and is deletion available on request?
• If a trial key bans commercial use, what is the migration path and how long does it take?

Prepare those answers in writing before a launch review. Teams that can answer them quickly tend to be teams that picked their free tiers deliberately rather than by convenience.

Do API terms and chat-product terms differ at the same provider?

They routinely do, and using the wrong document is one of the most common mistakes we see in free-tier due diligence. A provider can operate three or four surfaces at once, each with its own default posture.

Anthropic illustrates the split cleanly: the consumer free plan trains by default with an opt-out, while Team and Enterprise default to no training — same company, same models, different defaults by surface and plan. Google illustrates a second axis: the improvement statement attaches to the free tier of the developer API itself, and the paid tier is where it stops.

The practical rule: read the document that governs the surface you actually call. A note in a chat product's help centre does not govern your API key, and a pricing page's data-use line does not govern a consumer application you shipped.

What changes when a trial becomes production?

Migrating off a trial tier changes more than the invoice, and the changes arrive on different schedules.

• Google. Moving to the paid tier is the moment the "used to improve Google's products" statement stops applying to your content — a billing change that silently improves your data position.
• Cohere. A trial key is barred from production or commercial use, and current-generation production keys route through an application. The constraint is lead time, so the migration belongs on the release plan.
• AWS Bedrock. A new-account free-plan arrangement has a limited window, after which the account closes unless you convert to a paid account. The data terms never changed; only the credit did.
• Azure OpenAI. Trial credits expire on their own clock while the standard cloud data terms continue. There is no policy to renegotiate at the end of the trial, only a bill.

Two lessons follow. The moment that changes your data posture is usually a billing event, not a contract event. And if a production path requires an application, treat it as a dated milestone.

A clause log worth keeping

Because these statements move, the deliverable is a record rather than a conclusion: a single table, kept with your API keys and updated on every pricing email.

Add a row per surface you actually call, including the gateway in front of it, and date every row — the date column tells you which rows need re-reading.

How we verified this

How we verified this (2026-09-17): each row of the comparison table comes from the provider's own documentation — the Gemini API pricing documentation for the free-tier improvement statement, Anthropic's pricing page for the plan-level training defaults, Cohere's pricing page for the trial-key production and commercial restriction, AWS's Bedrock pricing and free-tier pages for the credit structure and account behaviour, Azure's OpenAI pricing page for the trial credit, and Mistral's pricing documentation for plan-level terms and residency options. We re-read these pages on the date shown. Where a clause is described qualitatively, that is because the provider states the behaviour in prose rather than as a number; we do not convert prose into invented figures.

Where this breaks: limitations to keep in mind

• Pages change quietly. A data-use line can be edited without an announcement. Date your notes, and re-check after any pricing email.
• Consumer and API terms differ. A provider's chat product and its API can carry different defaults. Confirm which document governs your integration.
• Gateways add a layer. If you call through an aggregator, the upstream provider processes the request. Your data-use position is the intersection of both policies, not just the one you read first.
• Residency is not the same as privacy. A regional endpoint can satisfy where data is processed while saying nothing about whether it is used for training. Ask both questions.
• Regulated data needs a different process. If you handle health, financial, or children's data, assume a free tier is the wrong venue until counsel says otherwise.

The one-line rule

A free-tier comparison that stops at "how many tokens" is comparing the wrong thing. The allowance tells you what the tier is worth; the data-use clause tells you what your prompts are worth to the provider — and the tier boundary is usually where that answer changes. Read the clause for the tier you are on, send synthetic data until you have, and treat a commercial-use ban as a release dependency rather than fine print.