GDPR for AI-Built Apps That Collect Data

Lovable, Bolt, Cursor, Replit and v0 will ship you working software in an afternoon. They will wire up a signup form, a user table and an email field without ever saying the words “data protection.” That is the trap. The app is collecting personal data from day one, and nothing about how it was generated makes it compliant. GDPR judges the app by what it does with that data, so the obligations land on you the second a real EU user signs up. Here is when GDPR applies, what every app needs, and the spots where AI-built apps quietly fall over.

Does GDPR apply to my AI-built app?

If your app reaches EU users and collects data about them, you are almost certainly in scope. GDPR covers the processing of personal data of people in the EU and EEA, full stop, no matter where your company or your servers sit. The code coming out of an AI tool changes nothing. The size of the project changes nothing.

• It is about the data, not the tech. Names, emails, IP addresses, location, device identifiers, account details: all of it is personal data. Collect any of it from EU users and GDPR is in play.
• Location of the user matters, not the company. You can be a one-person studio anywhere on earth. Offer your app to people in the EU and you can fall under GDPR.
• “Just a prototype” is not an exemption. The moment real people type real data, the obligations are live. There is no grace period for unfinished software.
• Free does not mean exempt. A free product collecting EU user data is treated exactly like a paid one.

If you are not sure your build is ready for any of this, start with our guide on whether your AI app is production ready.

The GDPR basics every app needs

GDPR is broad, but a short list of requirements hits almost any app that touches personal data. These are the foundations. Miss one and you have exactly the kind of gap AI-built apps ship with by default.

• A lawful basis for processing. Every use of personal data needs a valid legal ground: consent, performance of a contract, a legitimate interest. You have to be able to name which one applies to each kind of processing.
• Consent where it is required. When you lean on consent (marketing, non-essential cookies and trackers), it has to be freely given, specific, informed, and as easy to withdraw as it was to give. Pre-ticked boxes do not count.
• Data-subject rights. Users can ask for their data, get it corrected, get it deleted, get a portable copy, and object to certain processing. Your app needs a real way to honour those requests inside the timeframes GDPR sets.
• Transparency. A clear, accessible privacy notice has to spell out what you collect, why, the lawful basis, who you share it with, and how long you keep it.
• Data-protection by design and by default. Privacy, data minimisation and security get built in from the start, not bolted on after launch.
• Breach duties. When a personal-data breach happens, GDPR makes you notify the relevant supervisory authority, and in higher-risk cases the affected people, without undue delay.

Where AI-built apps fall short

AI tools optimise for an app that runs, not an app that is compliant. The gaps show up in the same predictable places every time, and those are exactly the places regulators and users care about.

• No real consent flow. Generated signup forms and cookie banners tend to collect data first and ask later, or never ask at all. Usually there is no record of what a user agreed to and no way to take it back.
• Data sent to LLMs and third-party subprocessors. AI-built apps love to pipe user input straight to an LLM API or some other external service. Every one of those is a subprocessor handling personal data. They have to be disclosed, covered by proper data-processing terms, and named in your privacy notice. The AI tool does not set any of that up for you.
• No deletion or export path. The scaffolded data model often has no way to fully delete a user or export their data. That makes honouring data-subject rights a nightmare.
• Secrets and data exposure. Keys shipped to the browser, wide-open database defaults, missing access controls: any of these can expose personal data, which is both a security and a GDPR problem. We cover the key side of this in our guide on exposed API keys in AI-built apps.
• No records or retention limits. Data just piles up forever, with no retention policy and no record of processing activities. GDPR expects you to keep both.

A GDPR readiness checklist for AI-built apps

Run through these before you put an AI-built app in front of EU users. They map straight onto the basics above.

1. Map your data. List every piece of personal data you collect, where it lives, and where it flows, including any LLM or third-party API.
2. Assign a lawful basis. For each kind of processing, write down which lawful basis you are relying on.
3. Build a real consent mechanism. Where consent is required, capture it explicitly, record it, and make withdrawal easy.
4. Implement data-subject rights. Make sure you can find, export, correct and fully delete a user’s data on request.
5. Document subprocessors. List every third party that touches personal data, confirm proper data-processing terms are in place, and disclose them.
6. Publish a clear privacy notice. Say what you collect, why, the basis, who you share it with, and how long you keep it. In plain language.
7. Set retention limits. Decide how long each data type sticks around and delete it when that period is up.
8. Lock down security. Pull client-side secrets, enforce access controls, and close the data-exposure gaps.
9. Have a breach plan. Know how you would detect, contain, and report a personal-data breach inside GDPR timeframes.

For broader compliance once you are processing customer data at scale, see our guide on SOC 2 for AI-built apps.

Want us to run this audit for you?

We do a free 15-minute build audit: you show us your AI-built app, we tell you the specific security and production gaps and what it takes to fix them. No obligation.

Book your free build audit