Blog · 2026-08-06
Writing a privacy policy for an AI-built app — what Art. 13 GDPR requires
By the howsafeismyapp team
Somewhere between "the app works" and "people are signing up," most AI-built apps cross a legal line without noticing: the moment you collect personal data, Art. 13 GDPR obliges you to tell people — at that moment, not later — what you do with it. That is what a privacy policy is: not a ritual page, but the delivery mechanism for a specific list of information the law spells out.
The good news: for a typical Lovable, Bolt or v0 app, that list is shorter and more concrete than the 4,000-word walls of text suggest. The work is not writing — it is knowing your own stack. (Practical guidance, not legal advice.)
When the duty starts
Earlier than most builders think. Art. 13 applies when you collect personal data from a person — and personal data is any information relating to an identifiable person:
- A signup or waitlist form collects email addresses. That's personal data.
- A contact form — same.
- Server logs with IP addresses, session handling, error tracking with user context — all processing.
If your app has a public URL and any of the above, the duty is live now. Our scanner checks the visible symptom — whether a recognizable policy is linked at all: no privacy policy found.
What Art. 13 actually requires you to say
Condensed to what matters for a small app, your policy must state:
- Who is responsible — your name (or company) and contact details, matching your imprint. For the German market that page is its own duty under § 5 DDG: no imprint found.
- What you process and why — each purpose in plain terms: operating accounts, sending the newsletter, payment processing, analytics.
- The legal basis for each purpose (Art. 6) — typically contract performance for accounts and payments, consent for marketing and tracking, legitimate interest for basics like security logging (named as such).
- Who receives the data — your processors. This is the part generic templates always get wrong, because it is specific to *your* stack.
- Third-country transfers — if a provider processes data outside the EU (many US services), say so and on what safeguard the transfer rests.
- How long you keep it — or the criteria (e.g. "until account deletion").
- The person's rights — access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and the right to complain to a supervisory authority.
- If applicable: automated decision-making, and whether providing data is required.
That is the whole skeleton. Everything else in bloated policies is padding.
The real work: an honest inventory of your stack
An AI-built app's privacy policy fails in a characteristic way: the *text* was generated from a template while the *stack* was generated from prompts, and the two never met. The fix is a fifteen-minute inventory. Open your app and note:
- Hosting — Vercel? Netlify? A Cloud Run service? Region?
- Database and auth — Supabase? Firebase? Clerk? These process every user's core data.
- Email — Resend, Postmark, Mailchimp?
- Payments — Stripe?
- Analytics and embeds — anything third-party loading in the browser. Open DevTools → Network in a private window; every third-party domain you see either belongs in the policy or shouldn't be loading: third-party tracking service embedded. Anything that tracks needs consent *before* it runs — a policy paragraph does not substitute for that: tracking loads before anyone could consent.
- AI APIs — if user input is sent to OpenAI, Anthropic or similar, that is a disclosure-worthy processing step with its own third-country questions.
Each entry becomes one honest paragraph: what, why, which provider, where. A short policy that matches reality beats a long one that doesn't — a policy describing trackers you removed, or missing the ones you have, is evidence against you rather than for you.
Generators, templates, and AI-written policies
Can you generate the policy the way you generated the app? A generator or model produces usable scaffolding *if* you feed it your real inventory and read the output critically. The failure mode is unchanged from copy-pasted templates: text describing a fictional app. Two rules keep you safe:
- Never let the text claim more or less than the Network tab shows. The DevTools view is the ground truth the policy must describe.
- Update the policy when the stack changes. Added analytics? New AI feature? The policy changes the same day.
For the German market, note that supervisory authorities expect the information to be easily understood by your users — for a German-targeted app, that generally means a German-language policy.
Where it lives
Its own page — /privacy or /datenschutz — linked from the footer of every page, app screens included, plus directly at the point of collection (a line under the signup form). Not behind a login: Art. 13 information is due before or at collection, so a policy only visible to registered users has failed its one job.
Related but distinct: a cookie banner is a *consent* mechanism, not an *information* page — whether you need one at all is its own question, covered in do you need a cookie banner for your Lovable app?
Common questions
My app has three users. Do I really need this already?
The duty attaches to processing personal data, not to scale. Three real users' email addresses are personal data. The effort is one honest page — proportionate even for tiny projects.
Is an English-only policy enough for German users?
If you address the German market — German UI, German marketing — regulators expect information users can actually understand, which points to German. An English-only product not targeted at Germany can generally stay English.
Can I just write "we don't collect any data"?
Only if it's true, and it almost never is — server logs, signup forms and any third-party embed already contradict it. A false "no data" claim is worse than no policy, because it is demonstrably wrong from the outside.
Do I need a cookie banner too?
Separate question. The policy informs; a banner collects consent for non-essential storage/tracking. No trackers, no banner needed — but the policy is required regardless. See the cookie banner guide.
Check the visible part in a minute
Whether a policy is linked where it should be — and whether trackers, fonts or an open database contradict what it claims — is all visible from outside. Our free passive scan loads your app like any anonymous visitor and reports the gaps in about a minute. No login, nothing installed, nothing stored.