Your AI Vendor's Terms May Ban Your Users: Read the Population Restrictions Before You Pick a Model

Mostafa Dhouib·11 min read

Your AI Vendor's Terms May Ban Your Users: Read the Population Restrictions Before You Pick a Model

The short answer. Major generative AI providers' terms bar applications directed at, or likely to be used by, people under eighteen. That is not a clause about who holds the account. It is a clause about who uses the product. So the moment your role model includes a Student, a Child, a Patient under eighteen or a Junior Member, a whole class of model provider is off the table, and the viable set shrinks to providers who permit minors under conditions, providers with an enterprise agreement that carves it out, or weights you host yourself. Teams find this after the architecture is drawn, which turns a one-line procurement constraint into a re-architecture. The clause also changes, so it must be re-verified at build time rather than quoted from memory.

A brief arrives for an assistant over a school's records. The roles in the specification are Parent, Teacher, Administrator and Student.

The retrieval design gets drawn, the permission boundary gets argued about, a model is chosen on the usual grounds of capability and price, and somebody builds a prototype that works. Then, somewhere between the prototype and the contract, a procurement questionnaire asks who the end users are, and the answer includes thirteen-year-olds.

That one word, Student, was a constraint on the model provider all along. It was written in the specification on day one. Nobody read it as a procurement input.

The clause is about your users, not your account

There are two separate age provisions in a typical provider's paperwork and they get conflated constantly.

The first is an eligibility condition on the account holder. You must be of the age of majority in your jurisdiction, or have a parent or guardian's consent, to use the service yourself. This one is familiar and mostly irrelevant to a business buyer.

The second is a restriction on what you may build. Applications directed at children, or likely to be used by people under eighteen, are prohibited. Sometimes the wording is a flat prohibition. Sometimes it is conditional on age verification and verifiable parental consent, with the obligation sitting on you. Either way, the test is about the population your product serves, and the phrase that does the work is "likely to be used by". You cannot satisfy it by putting a tick box on a signup page when the entire product concept is a school portal.

This matters because the two provisions live in different documents. The account provision is in the terms of service, which everybody opens. The population restriction is usually in the usage policy or acceptable use policy, which is incorporated by reference and which nobody opens, and which the provider can revise without touching the contract.

How to read provider terms for user-population restrictions

Work through four documents, not one.

The service or business terms. Look for the definition of "End User" or "your users", and for whether restrictions are expressed as flowing down to them. If you are required to impose equivalent terms on your own users, that is a product requirement, because you now need those terms in your sign-up flow.

The usage or acceptable use policy. This is where population restrictions live. Read the whole list, not just the minors clause, because the same list usually restricts other populations and sectors you may be in without realising: medical advice, legal advice, employment or credit decisions, insurance eligibility, biometric identification, political targeting. Each one is a line item on your role model.

The data processing terms. Children's personal data is routinely a special category in a provider's own processing commitments, and the sub-processor list and residency terms will matter separately for a school or a health product.

Any model-specific or deployment-specific supplement. The same provider often has different terms for a hosted endpoint, a cloud-marketplace deployment and an enterprise agreement. The restriction that blocks you on one route may be absent or negotiable on another.

Then record what you found as a decision, not as a memory. Provider, document name, the date you read it, and the clause text you are relying on. That record is what you re-verify later, and without it you have nothing to re-verify against.

The viable set, once minors are in scope

Four shapes, in descending order of convenience and ascending order of work.

Providers who permit it conditionally. Allowed, with obligations transferred to you: age assurance, verifiable parental consent, sometimes content filtering requirements and a restriction on training. The obligations are real engineering, not paperwork, because age assurance has to happen before the first token goes out.

Providers with an enterprise agreement. The restriction is in a standard policy and a negotiated agreement can address it, with an education or health addendum. This is viable and slow. It also puts a contract negotiation on your critical path, which changes your schedule more than it changes your architecture.

Open weights you host yourself. No provider-side population restriction, because there is no provider in the request path. You acquire the rest of the problem instead: serving infrastructure, evaluation, safety filtering you now own, and a model licence that may have its own use restrictions you still have to read.

Keep minors off the model surface entirely. Students get the deterministic interface, adults get the assistant. This is the option teams skip because it feels like a retreat, and it is frequently the correct phase-one answer. It is also the only option where the compliance argument is short.

Note what is not on the list. There is no option where you choose on capability and price first and resolve the population question afterwards.

Why this is an architecture decision and not a legal footnote

The provider choice determines things that sit upstream of almost every other decision you make.

Context window size sets how much of a record you can put in front of the model, which sets whether you need retrieval at all. Tool-calling behaviour sets whether your permission boundary can be expressed as a set of parameterised queries the model calls, or has to be a fixed set of intents you route to. Latency and cost per token set whether a multi-step agent loop is affordable. Fine-tuning availability sets whether domain vocabulary is a training problem or a prompt problem. Hosting topology and data residency set where the whole system lives.

Change the provider and you change all of those. So a constraint that eliminates a class of provider is not a late-stage compliance check. It is one of the first three or four things that should be settled, alongside the system of record and the permission model.

There is a design consequence even when you resolve it cleanly, and it is worth building for before you need it. Make the provider a parameter of your model adapter from the first commit. One interface, provider behind it, model selection as configuration, and an evaluation suite that can be run against any provider you are allowed to use. This costs a day early. It costs a quarter late, because by then the provider's specific tool-calling format, token accounting and streaming semantics are spread through the application.

The mixed user base

Most real products are mixed. Parents, teachers and students. Clinicians, carers and patients. Adults and juniors in one membership.

If you route by role, the role has to be established before the request reaches a model, which puts role or age assurance on the hot path and makes it a security boundary rather than a preference. Everything the earlier work on permission boundaries says then applies: the routing decision has to be enforced server-side, derived from the authenticated session, and tested with a negative case that proves a minor's session cannot reach the restricted provider.

Routing also doubles your evaluation surface. Two providers means two prompt sets, two sets of refusal behaviours, two latency profiles and two sets of regression tests, run on every change. Teams consistently underestimate this, because the first version works and the drift arrives later.

And there is a case routing does not solve. A teacher is an adult, so a teacher's session may use the preferred provider, but the teacher is asking about a child's records and the child's data is going to that provider. The provider's population restriction may be satisfied. Your data-protection obligation to the child is not, and it is a separate analysis with separate answers. Do not let a resolved terms question stand in for an unresolved data question.

Terms change, so verify at build time

The population restriction you read today is not a fact about the world. It is the current text of a document the provider can revise unilaterally, and usage policies are revised more often than contracts.

So treat it the way you treat a dependency version. The decision record names the provider, the document, the date of verification and the clause. The release checklist includes re-verifying it, with the date recorded. A clause last verified a year ago is not evidence, it is a note. If you are about to ship a product whose legality rests on a sentence, read the sentence again on the day you ship.

This also means you should not trust any version of the clause quoted in an article, including this one. The facts here were accurate when written. Go and read the current text for the providers you are actually considering, for the deployment route you are actually using, in the region you are actually serving, and write down what you found.

The honest limit

I am an engineer, not a lawyer, and nothing here is legal advice. The point is narrower than legal analysis: the population your product serves is a procurement input to the model decision, and treating it as one prevents a predictable rebuild.

Terms differ by provider, by plan, by deployment route and by region, and enterprise agreements can change the answer entirely. "Likely to be used by" is a judgement rather than a test, and reasonable people land differently on a product that adults use about children versus one children use directly. That judgement needs a lawyer who has read your actual product, not a checklist.

And the restriction being satisfied does not make the design safe. A compliant provider still sends a child's records to a third party, and the questions about what is logged, what is retained, what is used for training and who can subpoena it are untouched by the clause this article is about.

FAQ

Can I use a major AI provider in a product that children will use? Often not on standard terms. Major generative AI providers' terms bar applications directed at, or likely to be used by, people under eighteen, and the test is about your user population rather than your account holder's age. Your routes are a provider that permits it under conditions, a negotiated enterprise agreement, open weights you host yourself, or keeping minors off the model surface.

Where is this restriction written? Usually in the usage policy or acceptable use policy rather than the terms of service, incorporated by reference, which is why it gets missed. Read four documents: service terms for the end-user definition and flow-down obligations, the usage policy for population and sector restrictions, the data processing terms, and any deployment-specific supplement, because routes differ.

Why does this change the architecture rather than just the contract? Because provider choice sets context window, tool-calling behaviour, latency, cost per token, fine-tuning availability and hosting topology, and those sit upstream of your retrieval design and your permission model. Eliminating a class of provider after those decisions are made invalidates them. Build the provider as a parameter of one model adapter so the choice stays cheap.

What do I do if my users are a mix of adults and minors? Decide between routing by role, excluding minors from the model surface, running one permitted provider for everyone, or self-hosting. If you route, the role must be derived from the authenticated session before any request is sent, enforced server-side, and covered by a negative test proving a minor's session cannot reach the restricted provider. Routing also doubles your evaluation surface.

Do these terms stay the same? No, which is why they must be re-verified at build time. A usage policy can be revised unilaterally and more often than a contract. Record the provider, document, clause and verification date in a decision record, re-check it on every release, and treat a clause verified long ago as unknown rather than as evidence.

Does self-hosting remove the problem? It removes the provider-side population restriction, since no provider is in the request path, and it leaves everything else. You take on serving, evaluation and safety filtering yourself, the model's own licence may carry use restrictions, and the statutory obligations around children's data apply regardless of where inference runs.