
An AI-generated privacy policy can be perfectly valid or completely worthless, and the thing that decides which has nothing to do with the fact that an AI wrote it. What matters is whether the document accurately describes what your company does with personal data and contains what the law requires it to contain. A regulator judges the text, not the tool that produced it.

## The law does not care who drafted it

Nothing in GDPR requires a lawyer to write your privacy notice. Articles 13 and 14 set out what the notice must contain, and Article 5(1)(a) requires that you handle personal data lawfully, fairly, and transparently. A supervisory authority reading your policy holds it up against your actual processing, not against your drafting method. So "we used ChatGPT" is neither a defence nor, by itself, a problem.

## Where generic AI output actually fails

The failure is almost always the same shape: the generated text describes a generic company rather than yours. It names a lawful basis that does not match what you really do, lists data categories you never collect while missing ones you do, or drops mandatory Article 13 items altogether. That mandatory content includes the purpose and lawful basis for each use, retention periods, the recipients of the data, any transfers outside the EU, the rights available to the user, and the right to lodge a complaint with a supervisory authority. A general-purpose chatbot has no access to your systems, so it fills those slots with plausible defaults. Plausible and accurate are not the same thing, and only one of them is a defence.

## The real risk is a mismatch, not a "fake document"

There is no GDPR penalty for using AI. The exposure is the gap between what your policy claims and what your systems do. If your notice says you delete data after twelve months and you keep it for three years, or states you share nothing with third parties while your analytics vendor quietly receives everything, that is a transparency failure under Articles 5 and 13. The gap also undermines whatever sits on top of it: consent collected against an inaccurate notice is fragile, and the discrepancy tends to surface at the worst moment, when a user files an access request or complains to a regulator. The inaccuracy is what creates the risk. Whether a human or a model typed the words does not enter into it.

## Where the AI Act actually comes in

Because this sits under the AI Act, the honest position is worth stating directly: the EU AI Act does not regulate the act of using an AI tool to draft a document. Its obligations arrive in stages — prohibited practices applied from February 2025, rules for general-purpose AI models from August 2025, broader transparency duties from August 2026, and high-risk system obligations now pushed back to December 2027 under the Digital Omnibus agreement reached in 2026 — and they fall mainly on AI providers and on deployers of high-risk systems, not on a founder writing a policy.

Where the AI Act does touch your privacy notice is indirect but real. If your own product uses AI on personal data, Article 50 can require you to tell users they are interacting with an AI system, and the privacy notice is often where that disclosure lands. So the AI Act is more likely to mean your policy needs to say more about the AI you deploy than that an AI-drafted policy is somehow void.

## What makes a generated policy sound

A generated privacy policy holds up when it is generated from accurate facts about your business and checked against the Article 13 list, not when it is produced from a one-line prompt. The input is the whole difference. A document built by answering structured questions about your real data, purposes, vendors, and retention periods will map onto your systems. A paragraph requested from a general chatbot maps onto an average of every company in its training data. Generation is not the problem; ungrounded generation is.

If you have already drafted something with an AI tool, the fix is not to throw it out. Read it line by line against what your company actually does and against the Article 13 checklist, correct every claim that does not match, and add every required item it left out. A generated draft that has been grounded in reality is a legitimate privacy policy. One that has never been checked against your systems is a liability wearing the shape of one.

---

**Wondering whether your current privacy policy matches what your site actually does?**

Run a free scan at [/scan](/scan) — it detects the tracking and data flows on your live site, so you can compare them against what your policy claims.

Need a policy built from your real processing instead of a generic prompt? Generate a GDPR-compliant Privacy Policy for €19 at [/generate/privacy_policy](/generate/privacy_policy).


AI privacy-policy generators describe a generic company, not yours — wrong lawful bases, missing Article 13 disclosures, claims your systems don't match.

Is Your AI-Generated Privacy Policy Actually Legal?


If your website loads Google Analytics, you almost certainly need a consent banner, and you need it to appear before Analytics runs, not after. Google Analytics sets cookies on your visitor's browser, and under EU law that action requires prior consent unless the cookie is strictly necessary. Analytics is not strictly necessary. That is the whole case, and it did not change with GA4.

The confusion usually comes from treating this as a GDPR question. It is really a cookie-law question, and the two work differently.

## The requirement comes from the cookie law, not GDPR alone

The rule that forces the banner is Article 5(3) of the ePrivacy Directive (2002/58/EC), often called the "cookie law." In plain terms: you may not store information on a user's device, or read information already stored there, unless the user has consented after being clearly informed. There is one carve-out, for cookies that are strictly necessary to deliver a service the user actually asked for, such as keeping items in a shopping cart or remembering a login.

GDPR enters at a second stage. It defines what valid consent means. Under Article 4(11), consent has to be freely given, specific, informed, and unambiguous: a clear affirmative action, not a pre-ticked box or silence. Article 7 adds that withdrawing consent must be as easy as giving it. So the ePrivacy Directive decides *when* you need consent; GDPR decides *what counts* as consent.

Google Analytics trips the first rule. It reads and writes cookies. That alone requires consent, regardless of what you later do with the data.

## Google Analytics cookies are not "strictly necessary"

GA4 sets cookies such as `_ga` and `_ga_<container-id>` to tell visitors and sessions apart. Their purpose is measurement: understanding how people use your site. Useful, but not necessary to deliver the page the visitor requested. Every major EU regulator treats analytics as non-exempt by default.

A few authorities have carved out narrow exemptions for privacy-preserving, first-party audience measurement. France's CNIL, Italy's Garante, and Spain's AEPD allow certain analytics cookies without consent, but only where the tool is strictly limited: first-party only, aggregate figures, no cross-site tracking, and data kept under the site operator's control. Google Analytics does not qualify for any of them. The CNIL has said plainly that neither Universal Analytics nor GA4 meets its exemption criteria, because the data leaves your control and enters Google's ecosystem. The tool the CNIL actually points to for exempt analytics is a self-hosted, EU-hosted Matomo setup.

So if you are running standard Google Analytics and hoping the analytics exemption covers you, it does not.

## "But we use Consent Mode" isn't a defence

This is the mistake we see constantly. Google Consent Mode v2, which Google has required since March 2024 for anyone using its tags to measure or advertise to EEA users, is not a consent banner and does not collect consent. It is a signal-passing mechanism. Your banner or consent management platform collects the user's choice; Consent Mode relays that choice to Google's tags so they behave accordingly, firing normally when consent is granted and sending cookieless pings when it is not.

Consent Mode assumes a banner exists upstream to tell it what the user decided. Installing Consent Mode without a working banner means you have wired up the plumbing with nothing feeding it. You still have no lawful basis to set the cookie in the first place.

## The "anonymised IP" and "we don't run ads" arguments

Two objections come up often, and neither survives contact with Article 5(3). Anonymising IP addresses reduces the personal data GA collects, but the consent trigger is the act of storing and reading the cookie, not the sensitivity of what sits inside it. Anonymisation does not remove the cookie. And "we only use Analytics, no advertising" misses that the cookie law draws no line between analytics cookies and advertising cookies. Both are non-essential. Both need consent.

There is a separate, older dispute about Google Analytics and EU–US data transfers, which produced enforcement decisions from the Austrian, French, and Italian authorities in 2022. The EU–US Data Privacy Framework adequacy decision from July 2023 addresses the transfer question when Google is certified under it. But transfers and cookie consent are two different problems. Even with the transfer issue settled, the requirement to obtain consent before setting the cookie is untouched.

## What a compliant setup looks like

A lawful Google Analytics deployment needs a banner that holds GA back until the user acts, offers a real choice where refusing is as easy as accepting, and records the decision. Behind it, your cookie policy should name the Google Analytics cookies, state their purpose and lifespan, and your Consent Mode configuration should read from the banner. Pre-ticked boxes, "by continuing to browse you accept" notices, and cookie walls that load GA before any click are the exact setups regulators have been fining.

The ePrivacy Regulation meant to replace all this was formally withdrawn by the European Commission in February 2025 — this isn't consolidating into one clean EU rule any time soon. The Directive stays in force, each member state keeps transposing it slightly differently, and the banner requirement isn't going anywhere.

---

**Not sure whether your site fires Google Analytics before your visitors consent?**

Run a free scan at [/scan](/scan) — it detects the tracking tools and cookies your site loads and flags what needs consent.

Need the document itself? Generate a GDPR-compliant Cookie Policy for €19 at [/generate/cookie_policy](/generate/cookie_policy).


Using only Google Analytics on your site? You still need a cookie consent banner. Here's why GA cookies require prior consent under the EU ePrivacy Directive.

Do You Need a Cookie Banner If You Only Use Google Analytics?


If your SaaS has a single user in the EU, GDPR already applies to you. Being incorporated in Delaware or London does not change that. Below is the actual work, in roughly the order a founder should do it, with the GDPR article behind each step so you can see why it is on the list rather than just that it is.

## First, confirm GDPR applies to you

Article 3 sets the territorial scope. In plain terms: if you offer your service to people in the EU, or you monitor their behaviour (analytics, tracking, and profiling all count), the regulation applies even when your company and your servers sit outside the EU. Most SaaS products with any EU signups are in scope. If you are established outside the EU and clearly caught by this, Article 27 can also require you to appoint an EU representative, a contactable person or firm inside the EU who acts as a local point of contact. Sort that out early, because it changes what your privacy notice has to say.

## Map the personal data you actually hold

You cannot protect or disclose what you have never written down. Article 30 requires a record of processing activities, usually called a ROPA: what data you hold, why, who it goes to, and how long you keep it. There is a narrow exemption for organisations under 250 staff, but it evaporates the moment your processing is regular or includes special-category data, which covers essentially every SaaS running customer accounts day to day. Treat the ROPA as mandatory. It is also the document that makes every later step faster, because your privacy notice, your vendor list, and your breach plan all read from it.

## Pin a lawful basis to each purpose

Article 6 says every use of personal data needs one of six lawful bases, picked before you process rather than justified afterwards. For a typical SaaS: performance of a contract (Article 6(1)(b)) covers running the core service your customer signed up for; legitimate interests (Article 6(1)(f)) can cover security, fraud prevention, and basic product analytics, as long as you can show you weighed your interest against the user's; consent (Article 6(1)(a)) is what you need for marketing email and non-essential cookies. Resist the urge to label everything "consent." It is the hardest basis to obtain properly and the easiest to invalidate.

## Write a privacy notice that matches what you do

Articles 13 and 14 list what a privacy notice must contain: your identity and contact details, the purposes and lawful basis for each use, who receives the data, any transfers outside the EU, retention periods, the rights available to users, and the right to complain to a supervisory authority. The error we see constantly is a notice copied from another company that describes processing the startup does not do and omits processing it does. A regulator reads your notice against your real systems, not against how polished it sounds.

## Put a DPA in place with every processor

Article 28 requires a written data processing agreement with every vendor that handles personal data on your behalf: your cloud host, your email provider, your analytics tool, your payment processor, your support desk. Most large vendors publish a standard DPA you can accept in a few clicks. The obligation is on you to have actually accepted it and to keep the list of who is on it current. Each of those vendors is a processor, and their own subprocessors sit under the same contractual chain.

## Handle transfers outside the EU

If any of those processors store or access data in the US or another non-EU country, Chapter V applies. For US vendors the two main routes are the EU–US Data Privacy Framework, if the vendor is certified under it, or Standard Contractual Clauses if it is not. The Framework is currently valid: the EU General Court upheld it in September 2025 in the Latombe case, though an appeal to the Court of Justice is pending, so this is an area to keep an eye on rather than treat as permanently closed. Note which of your subprocessors depend on it.

## Secure the data and plan for a breach

Article 32 requires security measures appropriate to the risk: encryption, access controls, backups, and a tested way to restore. Articles 33 and 34 set the breach rules. You have 72 hours from becoming aware of a breach that risks people's rights to notify your supervisory authority, and you must tell affected users directly when the risk to them is high. Write the procedure before you need it. Who phones the regulator at 2am is not a question to answer for the first time at 2am.

## Build the data subject rights process

Articles 15 to 22 give individuals rights over their data: access, correction, erasure, portability, and objection. You have one month to respond to a request. For a small SaaS this rarely needs dedicated software. It needs a named owner, a written process, and the practical ability to find, export, or delete one person's data across all your systems. That last part is where teams discover their data map had holes in it.

---

**Want to see which of these you are missing before you start?**

Run a free scan at [/scan](/scan) — it checks your live site for the tracking, cookies, and disclosures GDPR expects and flags the gaps.

Ready to fix the first one? Generate a GDPR-compliant Privacy Policy for €19 at [/generate/privacy_policy](/generate/privacy_policy).


A practical, ordered GDPR checklist for SaaS founders: territorial scope, ROPA, lawful bases, privacy notice, processor DPAs, transfers, security, and DSARs.

GDPR, explained for founders

Is Your AI-Generated Privacy Policy Actually Legal?

Do You Need a Cookie Banner If You Only Use Google Analytics?

A GDPR Compliance Checklist for SaaS Startups