A privacy policy has one job: to tell people, truthfully, what your site does with their information. The rules on what it must cover are fairly settled. The hard part for AI-built apps is the “truthfully” bit.
When an app is generated in an afternoon, the policy often is too. It might come from the same AI tool, a template site or another app’s footer. It reads well. It just doesn’t describe your app. Patch has read a lot of privacy policies. Most of them were about a different website.
Why AI-built apps have a particular problem
A typical Lovable, Bolt or Cursor project talks to more services than its owner remembers. There’s a database and auth provider, a payment processor, an email sender, an analytics tool, maybe an AI model, maybe a chat widget. Each new prompt can add another.
A generic policy says “we may share data with trusted third parties”. Your app actually sends email addresses to Resend, card details to Stripe and support messages to OpenAI. The gap between what the policy says and what the site does is what this checklist is about.
Step 1: list what your site actually talks to
Do this before writing a word. Check four places:
- The browser. Open your site in a private window, open developer tools and watch the Network tab while you click through sign-up, checkout and any AI features.
- Your code. Look at
package.jsonfor SDKs (@supabase/supabase-js,stripe,resend,openaiand so on). - Your secrets. Environment variables and edge function secrets list every API key, and every key is a service.
- Your backend. Edge functions and webhooks often call services the browser never sees.
Then write it down:
| Service type | Example | What it might receive | What to check |
|---|---|---|---|
| Database and auth | Supabase, Lovable Cloud, Bolt Cloud | Accounts, emails, everything users save | Data region, data processing terms |
| Payments | Stripe | Names, emails, payment details | Its role. Stripe’s privacy policy says it acts as a controller and/or processor depending on the activity |
| Resend, Postmark, SendGrid | Email addresses, message content | Data processing terms, region | |
| Analytics | Platform analytics, Google Analytics, Plausible | Page views, device details, possibly identifiers | Whether it needs consent |
| AI APIs | OpenAI, Anthropic, Google | Whatever users type into AI features | Retention, training use, region |
| Hosting | Lovable, Bolt, Vercel, Netlify | Request logs, IP addresses | Where logs are kept |
Check each provider’s own terms rather than guessing. For example, Supabase’s Data Processing Addendum says Supabase acts as a processor and the customer as controller. OpenAI’s API data controls say API data isn’t used to train its models by default, and that abuse monitoring logs are kept for up to 30 days. Those are exactly the details your policy should reflect.
Step 2: the UK GDPR and GDPR checklist
When you collect personal data directly from people, Article 13 sets out what to tell them. The EU GDPR has the same structure. The ICO’s guide to what privacy information to provide turns it into a list. Your policy should cover:
- Who you are. Your legal name (the company, not the app’s nickname) and contact details.
- Your representative and data protection officer, if you have them.
- Purposes. What you use each kind of data for: running accounts, taking payment, sending email, improving the product.
- Lawful basis for each purpose. Contract, consent, legitimate interests, legal obligation. If you rely on legitimate interests, say what they are.
- Recipients. The ICO says you can name the organisations or give categories, and if you only give categories, be as specific as possible. For a small app, naming them is usually clearer.
- International transfers. If data leaves the UK or EU, which it usually does with US-based services, say so and say what safeguards apply. The ICO’s international transfers guidance explains the options.
- Retention. How long you keep each kind of data, or the criteria you use to decide.
- Rights. Access, correction, erasure, restriction, objection and portability, and how to use them.
- Withdrawing consent, where you rely on consent.
- Complaints to you. Since 19 June 2026, UK organisations must give people a clear way to raise a data protection complaint and acknowledge it within 30 days. UK GDPR Article 13 now lists the right to complain to the controller. Say how.
- Complaints to the regulator. In the UK that’s the ICO. Since 30 September 2026 the legal body has been the Information Commission, and it still goes by ICO. If you serve EU visitors, mention their right to complain to an EU data protection authority too.
- Whether people have to give the data, and what happens if they don’t.
- Automated decision-making and profiling, with meaningful information about the logic. Worth thinking about if an AI model makes decisions about users.
If you get personal data from somewhere other than the person, such as an enrichment API or a CSV import, Article 14 also asks for the categories of data and where they came from.
And write it plainly. Article 12 asks for a “concise, transparent, intelligible and easily accessible form, using clear and plain language”. The EDPB’s transparency guidelines go into more detail.
Step 3: cookies and similar technologies
Explain what your site stores on visitors’ devices and why: login sessions, analytics, anything from embeds. If some of it needs consent, the policy should match what your banner offers, and the banner should actually hold those scripts back. ShipPatrol’s trackers before consent check tests that. Our guide to whether a vibe-coded site needs a cookie banner covers the rules.
Step 4: California basics
The CCPA applies to for-profit businesses that do business in California and cross revenue or data-volume thresholds. According to the California Attorney General, covered businesses need:
- A notice at collection. The categories of personal information you collect and the purposes, given at or before the point of collection.
- Rights in the privacy policy. The rights to know, delete, correct, opt out and limit, and how to use them.
- A “Do Not Sell or Share My Personal Information” link, if you sell or share personal information.
- Respect for Global Privacy Control signals as a valid opt-out.
The detailed rules are in the CPPA regulations. Many small apps fall below the thresholds, but check.
Step 5: the AI features
If your app sends user content to a model, the policy should say:
- which provider receives it
- what is sent (the prompt, uploaded files, chat history)
- whether the provider keeps it, for how long, and whether it’s used for training, according to the provider’s terms
- whether any decision about the user is made automatically
Don’t copy-paste a generated policy
A generated or borrowed policy is a fine starting draft. It’s a poor final one. Look for:
- Services you don’t use, and missing ones you do.
- “We do not use cookies” on a site running analytics.
- “We never share your data” on a site that takes payments.
- A company name, address or regulator that isn’t yours.
- Placeholders like
[Company Name]still in the text. They happen more often than you’d think. - Retention described only as “as long as necessary”, with no period or criteria.
ShipPatrol’s policy mismatch check compares the services your site loads with the ones your policy names.
Keep it true after launch
A privacy policy goes out of date the moment you add a service and don’t update it. Make “update the policy” part of adding any new SDK, script or API key. Change the “last updated” date when you do.
This isn’t legal advice
This checklist reflects the official guidance linked above as of 21 October 2026. It isn’t legal advice and it isn’t a policy template. If you handle sensitive data, serve children or make automated decisions about people, get a qualified adviser to look at it.
Check yours
A free scan checks whether your site has a privacy policy and lists the services it actually talks to, so you can compare the two.