Acceptable Use Policy for an AI Product: What to Put In
Most AI startups copy a SaaS acceptable use policy and find, on the day they need it, that nothing in the document lets them suspend an account before Monday.
An acceptable use policy for an AI product is the document that lets you cut someone off. That is its whole job. Everything else in it is either legally required or decoration, and the difference between a policy you can act on and a policy you cannot is about six sentences.
Most AI startups copy a general SaaS acceptable use policy, add a paragraph about not generating harmful content, and discover on the day they need it that nothing in the document lets them suspend an account before Monday.
The three clauses that actually get enforced
In practice, AI products suspend accounts for three reasons. Everything else is theoretical.
Automation and volume abuse. Someone is running your product as an unattended pipeline at a rate your pricing did not anticipate. This is the most common enforcement action by a wide margin, and it is usually not malicious. It is a customer who found your product useful and pointed a script at it.
Prohibited content generation. Someone is using your product to produce something you do not want associated with your name, or that your model provider's terms forbid. Note the second half: you inherit your provider's restrictions whether or not you restate them.
Resale and output laundering. Someone is wrapping your product and reselling it, or harvesting output at scale to train a competing model. Both are real, both are commercially serious, and generic SaaS policies rarely cover the second.
Write these three properly and the rest of the document is background.
What each clause needs to contain
Automation limits, stated as numbers or as behaviour
Vague fails. "Excessive use" is not enforceable because the customer's definition of excessive is different from yours and both are defensible.
State either a number or an observable behaviour:
You may not: exceed 1,000 requests per hour on any plan without
written agreement; operate the Service through an automated
process that does not have a human reviewing outputs; or run
the Service continuously for more than 6 hours without an
interactive session.The middle clause is the useful one. It catches the pipeline case without committing you to a specific number that will look wrong in six months, and it draws a line most legitimate customers are nowhere near.
Prohibited uses, inherited and restated
Your model provider has a usage policy. Your customers have never read it and are bound by it through you. Two sentences fix this:
Your use of the Service is additionally subject to the usage
policies of our underlying model providers, which we may update
by notice. Where those policies and this one differ, the more
restrictive applies.Then list your own prohibitions in specific terms rather than categories. "No illegal content" is a category. "No generating identity documents, no impersonating a real person without their consent, no automated content targeting a named individual" are things a support agent can check against a screenshot.
The suspension clause you can act on same day
This is the one people get wrong, and getting it wrong is expensive precisely when it matters. A policy that requires notice and a cure period before suspension means you watch the abuse continue for the length of the cure period.
The structure that works: immediate suspension for a defined short list, notice-and-cure for everything else.
We may suspend access immediately and without prior notice
where we reasonably believe use of the Service: creates a
security risk to the Service or other customers; violates
applicable law; or breaches the prohibited uses above. For any
other breach of this Policy, we will give notice and 7 days to
remedy before suspending."Reasonably believe" is doing important work. Requiring certainty before acting means acting late. And distinguishing immediate from notice-and-cure is what makes the whole document usable, because it means the common commercial disputes get a fair process and the genuine emergencies do not.
Where the AUP sits among your other documents
An acceptable use policy is not a privacy policy and not a service level agreement. Stuffing them together produces a document nobody can navigate.
Document | Answers | Binds |
|---|---|---|
Acceptable use policy | What the customer may not do | The customer |
What you do with their data | You | |
What uptime you promise | You | |
Terms of service | The commercial relationship | Both |
Keep the AUP as a separate, short, linked document. Short matters: it should be readable in three minutes, because the only time anyone reads it is when they are annoyed.
An internal AI usage policy for your own staff is a fourth, different document with a different audience, and mixing the two is a common and confusing mistake.
Enterprise customers who ask for this kind of document are frequently the same ones asking about a compliance certification a step up from it. Do you need SOC 2 to sell an AI product covers when that becomes worth pursuing.
Two things to leave out
Do not promise to review every output. A clause saying you monitor use for compliance creates an expectation you cannot meet at scale and may create liability when you miss something. Say you may monitor, not that you do.
Do not enumerate every possible misuse. A long list reads as exhaustive, and anything absent from an exhaustive list looks permitted. A short list plus a general clause is stronger than a long list alone.
The enforcement side nobody writes down
A policy is only as good as the process behind it. Three practical things worth having in place before you need them:
A way to see what an account is doing. If a customer is flagged and you cannot inspect their usage pattern within an hour, the policy is decorative. This is the same visibility that keeping an audit trail of AI use gives you internally.
A named person who can suspend. Not a committee. Abuse tends to arrive at inconvenient hours.
A written reinstatement path. Most suspensions are misunderstandings, and a customer who gets suspended with no route back becomes a public complaint rather than a renewal.
If your product includes a customer-facing chatbot, the AUP is the contractual layer and guardrails on the chatbot itself are the technical one. You want both, and neither substitutes for the other. Decide the refund position for a suspended account at the same time, because that question always arrives attached to the first suspension. The broader risk picture sits in AI risks.
FAQ
Do I need an acceptable use policy if I have terms of service?
You need the clauses. Whether they live in a separate document or a section of your terms matters less than whether they are specific enough to enforce. A separate document is easier to update, since you can usually change an AUP by notice where terms need re-acceptance.
Can I suspend a customer without warning?
If your policy says so for defined categories, generally yes, subject to your jurisdiction and any negotiated enterprise agreement. Enterprise contracts frequently override the standard AUP, so check what you signed before acting on a large account.
What if my model provider changes their usage policy?
You inherit it. This is why the incorporation clause matters: without it, you are contractually unable to enforce a restriction you are contractually required to enforce.
How long should it be?
One page. If it runs longer, the enforcement-relevant parts are buried, and the people who need to apply it under time pressure will not find them.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
