The average website privacy policy reads at roughly a college level: one survey of the 300 most popular sites found 96.8% scored below the recommended Flesch Reading Ease of 60, and a study of mobile apps put the mean at grade 12.8 while the average US adult reads at grade 8. A policy nobody can parse on the first read is not transparent, it just looks thorough. These prompts rewrite the same legal content into something a real user understands without weakening a single claim, then hand the rewrite back to counsel for sign-off.
TL;DR
- Privacy policies are hard on purpose-by-accident: most score below the readability floor regulators expect, and reading every policy you encounter in a year would take an estimated 244 hours (McDonald & Cranor, 2008).
- GDPR Article 12 already requires “concise, transparent, intelligible and easily accessible” wording in “clear and plain language” — plain English is a compliance feature, not just a UX nicety.
- Use the 12 prompts below to draft layered notices, a top-of-page TL;DR, tables for data collection, and one-click consent copy. The model writes the draft; a lawyer checks the legal claim.
- Best results come from Claude Opus 4.7 or GPT-5.5 Thinking with a side-by-side
legal | plain-Englishoutput so meaning shifts are visible. Never publish AI policy text without counsel review.
Who this is for
Founders who want policies that feel less hostile, comms leads working alongside legal, and indie devs drafting a first-version privacy policy or terms of service before a lawyer reviews it.
When not to use these prompts
Do not treat the output as final legal copy: GDPR, CCPA/CPRA, and your jurisdiction’s rules carry real penalties, so counsel signs off before publishing. Do not use a “plain-English” rewrite to quietly weaken a protection users rely on — regulators read the friendly version too, and a banner that buries “Reject” is itself a violation.
Why plain English is now a legal requirement, not a nicety
| Requirement | What it means in practice | Source |
|---|---|---|
| GDPR Art. 12(1) | “Concise, transparent, intelligible and easily accessible form, using clear and plain language,” especially for content aimed at children | EDPB / GDPR text |
| Layered notice | A short first-layer summary in plain language, with the full legal text one click below | EDPB transparency guidelines |
| Equal-prominence consent | ”Reject all” must be as easy and visible as “Accept all,” on the same layer | EDPB Cookie Banner Task Force Report (Jan 2023) |
| Readability target | Aim for Flesch Reading Ease ≥ 60 / ~grade 8; most policies miss this | Readability studies, 300 top sites |
Enforcement is not theoretical. In September 2025 France’s CNIL fined Google €325M and Shein €150M over cookie-consent practices, and Denmark’s regulator named cookie consent a 2026 priority, testing whether users have a “real opportunity to say no.” Plain, symmetrical copy is the cheapest insurance you can write.
Which model to use
- Claude Opus 4.7 (Claude Pro $20/mo, June 2026) — strongest at preserving exact legal meaning while simplifying; 1M-token context fits a full policy plus prior versions for a clean redline.
- GPT-5.5 Thinking (ChatGPT Plus $20/mo) — reliable for the side-by-side
legal | plaintable and consent-copy variants; Plus holds roughly 320 pages of in-app context. - Gemini 3.1 Pro (Google AI Pro $19.99/mo) — useful when the policy already lives in Google Docs/Workspace.
Whichever you pick, always demand the side-by-side output so a human can spot any line where the meaning shifted. See our tone rewrite prompts for adjusting voice once the legal pass is clean.
Prompt anatomy / structure formula
Every policy rewrite prompt should carry six elements:
- Audience: one specific reader (a non-technical EU user, a parent, a developer reading your AUP).
- Goal: one outcome — understand / accept / reject / submit a request.
- Voice: 2-3 anchor adjectives (calm, direct, non-defensive).
- Constraints: word count, banned phrases, must-include facts, reading level.
- Format: paragraph, bulleted, headed, or side-by-side table.
- Examples: 1-2 tone samples — the strongest lever for matching voice.
12 copy-ready prompt templates
1. Plain-English rewrite preserving claims
Rewrite this section of our policy at a US grade-8 reading level (Flesch Reading Ease 60+).
Constraint: preserve every legal claim, do not weaken or expand any of them.
Output a two-column table: legal version | plain-English version.
In a third column, flag any plain-English line where the meaning may have shifted, for legal review.2. Top-of-page TL;DR (first layer)
Write a 3-bullet "what this policy says" summary for the top of the page (GDPR layered-notice first layer).
Each bullet <= 20 words, plain English, no jargon.
End with a "Read the full policy for detail" link to the legal text below.3. Privacy: what we collect
Rewrite the "data we collect" section as a table:
data type | why we collect it | how long we keep it | who we share it with.
Skip any category we don't actually collect. One row per real data type.4. Privacy: rights you have
Plain-English rewrite of user rights: access, correct, delete, export, restrict, object, withdraw consent.
For each: one sentence on what it lets you do + one sentence on how to use it.
No legal verbs ("hereinafter", "shall"). Name the email or form a user actually clicks.5. Cookie banner copy (equal prominence)
Write cookie banner copy that passes the EDPB equal-prominence test:
(1) a <= 40-word notice,
(2) two buttons of equal visual weight: Accept all / Reject all, both on the first layer,
(3) a "Manage preferences" link to category-by-category toggles.
No dark patterns: Reject must be one click and as visible as Accept.6. Terms: liability + indemnity in plain language
Rewrite our liability + indemnity section in plain English without weakening protections.
Goal: a user reads it and understands "what could happen if this product breaks, and who is responsible".
Keep the original legal version beside it for counsel to compare.7. Acceptable use policy
Write an Acceptable Use Policy as a list of "you may not" items: specific behaviours, not vague categories.
Examples: send spam, scrape our APIs without permission, harass other users, evade rate limits.
Each item: 1 line for the behaviour + 1 line for the consequence (warning, suspension, ban).8. Data subject request reply templates
Draft reply templates for: (1) access, (2) deletion, (3) correction, (4) export, (5) objection / withdrawal.
Each template: acknowledge within the legal window, state the action timeline (GDPR default: 1 month),
list what we need to verify identity, and what the user will receive.9. Children’s privacy
Write a plain-English children's privacy section.
Cover: minimum age, no targeted ads to minors, parental rights, and how to delete a child's data.
Say what we DO, not just "We do not knowingly collect..." Keep it readable for a parent in a hurry.10. International transfer plain-English
Rewrite the international data transfer section in plain English:
(1) where data goes, (2) the legal basis (Standard Contractual Clauses, adequacy decision),
(3) the protections in place, (4) how a user gets a copy of the safeguards.
Do not reduce it to "We comply with applicable laws."11. Plain-English consent UX
For our consent UI, write 3 variants of consent copy:
(a) base case, (b) re-confirmation after a policy change, (c) granular per-category toggles.
Each <= 60 words. "Reject all" must be one click and equal in prominence to "Accept all".12. Policy diff for users
Our policy changed. Write a user-facing summary:
(1) what changed, (2) why, (3) what you should do (if anything), (4) the effective date.
Plain English. Skip the full redline but link to it for anyone who wants the detail.A 5-step workflow that actually ships
- Paste the section, not the whole policy. Run prompt #1 on one section at a time so the model keeps full context on the legal claim.
- Force the side-by-side. The third “meaning may have shifted” column is the whole point — it turns the lawyer’s review from a full re-read into a 5-minute scan of flagged lines.
- Run a readability check. Paste the plain version into a Flesch-Kincaid checker (Hemingway, or
textstatif you script it) and aim for grade 8 or below. - Layer it. Use prompt #2 for the first-layer TL;DR and keep the legal text one click down — that two-stage structure is exactly what EU regulators recommend.
- Counsel signs the rewrite, not just the legal version. Because the friendly copy is what users act on, it is the version that gets enforced against you.
Common mistakes
- Vague audience, so the output reads generic.
- No tone anchor, so every variant comes back the same flavour.
- No constraints — skip word count, banned phrases, and reading level and you get mush.
- Skipping examples — 1-2 tone samples are the strongest signal for voice.
- Trusting the first draft — the model lands on a safe middle.
- Leaving AI clichés in (“In today’s fast-paced world…”).
- No fact-check pass — the model is sometimes confidently wrong about your retention periods.
- Reducing meaning while rewriting — every rewrite needs a legal re-check against the original.
FAQ
- Does plain English create legal risk?: Done right, no — you preserve the exact claim and keep the legal version beside it. The risk is the opposite: GDPR Article 12 requires “clear and plain language,” so dense, unreadable text is the non-compliant option.
- What reading level should I target?: Aim for US grade 8 (Flesch Reading Ease ~60+). Most policies sit at grade 12 or higher, so even moving down two grades is a real improvement.
- Can AI write the whole policy?: It can draft, but it should not be the final word. Use it for the rewrite and the layered summary, then have counsel confirm every legal claim survived intact.
- Which model is best for this?: Claude Opus 4.7 for preserving exact meaning across a long policy, GPT-5.5 Thinking for clean side-by-side tables and consent variants. Both are on $20/mo plans as of June 2026.
- Is a “Reject all” button really required?: Under the EDPB Cookie Banner Task Force position, refusing must be as easy as accepting — same layer, equal prominence. CNIL’s €325M Google fine in 2025 shows the cost of getting this wrong.
- How often should I refresh the rewrite?: Whenever the underlying legal text changes, and run prompt #12 to tell users what changed and why.