- AI written policies fail in a specific way. The prose is competent and the legal defaults underneath it are wrong for your jurisdiction.
- A term that takes away a statutory right is not merely unwise, it is void. Section 62 of the Consumer Rights Act 2015 says so directly.
- The single most common error is a returns window that starts at the order date instead of the delivery date.
- Subscription cancellation wording is the fastest moving area in the United States, and the safest draft is the one that assumes the strict version returns.
- Your privacy notice is the page a model is least able to write, because the facts it needs are about your systems, not about law.
- Use a model to structure and to plain language the text. Use a checklist to decide what the text must contain.
Ask a model for a returns policy for an online shop and it will produce something that reads better than most of what is live on the web. Clean headings, no legalese, a friendly sentence about wanting you to love your purchase. It will take about nine seconds and it will look done.
The trouble is that a policy page is not a piece of writing with legal flavour. It is a set of factual claims about what you will do, sitting on top of a set of rights the customer already has whether you mention them or not. The model is fluent about the first and guesses at the second, and the guess is usually an average of American, British and European practice that matches none of them.
This piece is about the parts that break, and how to get a genuinely useful draft out of a model without shipping something unenforceable.
What does a model actually get wrong?
Not the tone and not the structure. It gets the defaults wrong, and it states them with total confidence because a confident policy page is what its training data looks like. Four failures show up again and again.
The first is the clock. Under the Consumer Rights Directive, a distance selling customer in the European Union has fourteen days to withdraw without giving a reason, and Article 9 counts that period from the day the consumer takes physical possession of the goods, not from the day they clicked buy. For services and for digital content not supplied on a physical medium, it runs from conclusion of the contract instead. A drafted policy that says "fourteen days from purchase" has quietly shortened the window by however long your courier takes, and the shortening is unenforceable.
The second is scope creep in the exceptions. Made to order goods, sealed items unsealed after delivery, perishables: real exceptions exist and the directive lists them. A model asked to write a returns policy for a candle maker will often produce a blanket "all items are final sale" because candle shops on the web say that. Most of them are wrong too.
The third is the refund mechanics. Who pays return postage, how quickly the money goes back, whether you may hold the refund until the goods arrive: these have specific answers, and the drafted version tends to pick the merchant friendly option in each case without flagging that it did.
The fourth is jurisdiction blending. The output will cheerfully cite a thirty day return window, a fourteen day cooling off period and a reference to a right of rescission in the same document, because all three phrases appear in policies it has seen.
Why is a wrong clause worse than no clause?
Because an unfair term does not simply fail, it can make the rest of your position weaker. Part 2 of the Consumer Rights Act 2015 sets out the fairness test, and section 62(4) treats a term as unfair where, contrary to the requirement of good faith, it causes a significant imbalance in the parties' rights to the detriment of the consumer. Section 68 adds a separate obligation that written consumer terms be transparent, and section 64 defines that as plain, intelligible language that is legible.
Read those together and the picture is uncomfortable for generated text. A clause can be void because of what it says. It can also be challenged because of how it says it, and dense generated boilerplate is exactly the sort of thing a regulator describes as failing the transparency limb. The fluency that makes a model's output look professional does not help here; what helps is brevity and specificity, which is the one thing a model avoids when it is unsure.
There is a practical consequence that owners underrate. If your written policy is worse than the law, customers who know their rights get them anyway and customers who do not get less. That asymmetry is precisely what consumer protection enforcement looks for, and it is also a slow leak of trust. We made a related argument about the claims you are allowed to make in AI assisted marketing copy, and the underlying discipline is the same: the model writes the sentence, you own the assertion.
The mapping table: what the draft says and what it should say
Below is the comparison I would run over any generated policy before it goes live. The left column is what generated drafts typically contain, taken from the recurring patterns above. The right column is what the underlying rules actually require for a shop selling to consumers in the United Kingdom or the European Union.
| Clause | Typical generated wording | What the rules require | Why the gap matters |
|---|---|---|---|
| Returns window | Fourteen or thirty days from purchase | Fourteen days minimum, counted from possession of the goods | Shortens the window by the delivery time and is unenforceable |
| Reason for return | Returns accepted for defects only | No reason needed for a distance sale within the withdrawal period | Removes the core statutory right, so the clause is void |
| Refund timing | Refunds processed within thirty business days | Without undue delay once withdrawal is communicated | Invites complaints and chargebacks you would lose |
| Exclusions | All sale items are final | Only the listed statutory exceptions apply | A blanket exclusion fails the fairness test |
| Privacy recipients | We take your privacy seriously | Named categories of recipient, purposes, retention period | Says nothing that Article 13 asks for |
| Subscription cancellation | Contact support to cancel | A route no harder than the one used to sign up | The area under active United States rulemaking |
What about subscriptions?
Subscriptions deserve their own paragraph because the ground is moving. The Federal Trade Commission finalised a rule in October 2024 requiring, among other things, that cancelling be at least as easy as signing up. The Eighth Circuit vacated it in July 2025 on procedural grounds. The FTC's own rule page records that the agency opened a fresh advance notice of proposed rulemaking on 13 March 2026, seeking comment on amendments to the Negative Option Rule.
A model trained across that whole period will confidently tell you one of three incompatible things depending on how you phrase the question. The useful posture for a small seller is not to track the litigation. It is to write the strict version now, because the strict version is cheap, it is what the pending rulemaking is pointed at, and enforcement against deceptive cancellation flows continued under general unfair practices powers throughout the period when no specific rule was in force.
Concretely: if a customer signed up with two clicks in the browser, they can cancel with two clicks in the browser. No phone call, no retention interview they cannot skip, no email address that goes unanswered for four days. Write it that way and no future rule change costs you anything.
If you sell across borders, the governing rules follow the consumer, not your registered address. A shop in Manchester selling to Lisbon is subject to consumer protection in the buyer's country for most purposes. Generated text almost never reflects this and will instead assert that the policy is governed by the law of wherever you asked it to assume.
Why is the privacy notice the hardest page for a model?
Because unlike a returns policy, almost nothing in it is a legal question. It is an inventory question about your own systems, and the model has no access to that inventory. Article 12 of the GDPR requires the information to be concise, transparent, intelligible and easily accessible, in clear and plain language, and the substance it must contain is a list of facts only you can supply: which processors you use, what each one receives, how long each keeps it, where they sit.
A generated privacy notice fills those slots with plausible placeholders. It will mention analytics providers you do not use and omit the shipping platform that holds every customer address you have ever taken. It will assert a retention period chosen for rhythm rather than truth. Every one of those is a false statement about your data handling, which is a materially worse position than a short honest notice with gaps.
The workable method inverts the usual order. Build the inventory first: open your billing page and list every service that touches customer data, then write one line per service saying what it gets and why. That list is the hard part and it takes an afternoon. Only then hand the list to a model and ask it to turn the inventory into a readable notice under the required headings. Now the model is doing what it is good at, which is prose, and the facts came from you. A similar inversion is at the heart of writing an internal AI policy with data classes, where the classification work is yours and the wording is the easy half.
The terms page that nobody reads and everybody needs
Terms of sale are the least glamorous of the three and the one that quietly decides disputes. Generated versions run long, which is the wrong instinct. Length is not protection; a court will not enforce a term buried at clause 41 that an average consumer would not have been aware of, which is the prominence requirement in section 64(4).
Five things earn their place for a small shop. What you are actually selling and when the contract forms, which is usually at dispatch rather than at checkout. Pricing errors and what happens when one occurs. Delivery estimates stated as estimates with what you do when you miss them. The complaints route and how long you take to respond. And the governing law, written honestly given the cross border point above.
Everything else is usually either restating a statutory right, which is fine but wastes attention, or attempting to remove one, which is void. Generated drafts pad heavily with the second category because that is what the corpus of terms pages contains.
The cookie banner is a policy page too
Owners treat the consent banner as a widget rather than as a legal text, and generated copy encourages that by producing something breezy. The banner makes two claims at once: that you have described the categories of cookie honestly, and that refusal is as available as acceptance. Generated banner copy routinely fails the second by offering accept and settings without offering reject, which is the pattern European regulators have penalised most consistently.
The wording is the small part. The configuration is the real work, because the banner has to actually block the scripts it says it blocks before consent is given. A model cannot verify that and will not mention it. If your analytics fires on page load regardless of what the visitor clicks, the finest banner text on the web is a misstatement, and it is one that anybody can check from outside your business in under a minute.
A method that actually works
None of this argues for paying a solicitor to draft three pages for a business turning over forty thousand a year. It argues for changing the order of operations.
Start from a primary source rather than from the model. For returns, that means the European Commission's own page on the Consumer Rights Directive, which sets out the pre contractual information duties and notes the standard withdrawal form in Annex I(B) that traders must provide. For a United Kingdom seller, the Consumer Contracts Regulations and the Consumer Rights Act play the same role. Read one of them once, take twenty minutes, and you will catch every error in the table above by eye afterwards.
Then give the model the constraints instead of the question. A prompt that says "write a returns policy" produces the average of the internet. A prompt that says "here are the six facts that must appear, here is the window and how it is counted, here are my three exceptions and why each qualifies, now write this as six short paragraphs a customer can understand" produces something you can ship.
Then check the numbers, every one of them, against the source rather than against a second model. Numbers are where generated policy text fails most reliably and they are also the fastest thing to verify.
Finally, date the page and put a reminder in the calendar. Policy pages rot. The subscription example above went from proposed to final to vacated to reopened inside thirty months, and a page written at any point in that sequence was wrong by the end of it. If you are building or rebuilding the storefront around these pages, it is worth doing at the same time as the rest of the structure rather than as an afterthought, which is one of the reasons our AI store builder treats them as part of the site rather than as a template to bolt on.
What a model is genuinely good at here
It is worth ending on the positive case, because the argument above is not that these tools are useless for legal pages. They are very good at three jobs.
Reading your existing policy and telling you what a customer might misunderstand. This works well because it is a comprehension task, not a knowledge task. Ask it to read your returns page as a confused buyer and list every ambiguity, and the list will be useful.
Converting a correct but dense clause into plain English while preserving meaning, which you then verify by reading both versions side by side. That is the transparency requirement in section 68 doing real work for you.
Producing the awkward supporting artefacts nobody wants to write: the withdrawal form, the complaint acknowledgement email, the internal note explaining to a part time assistant how to process a return. These carry no hidden legal defaults and generated versions are usually fine after a read through.
What none of those have in common with drafting from scratch is that in each case you supplied the substance. The model handled the sentences. That split is the whole of the method, and it is the same split that makes AI useful for reviewing supplier contract terms rather than writing them.
A policy page is a promise about behaviour, checked against rights the customer already had. Only one of those two things is inside the model.