When you prompt an AI tool to “add user signup,” it builds a signup form. It does not ask where that data will live, who can see it, how long you will keep it, or what happens when a user asks you to delete it.
GDPR asks all of those questions. Your app has to answer them, whether or not the tool that built it was thinking about the law.
This is not legal advice, and we are engineers rather than solicitors. But we read a lot of AI-generated code, and the same data-protection gaps show up again and again. If you collect any personal data from people in the UK or EU, and almost every app does, these are the risks worth knowing about.
What GDPR actually expects from your app
Strip away the jargon and GDPR comes down to a few practical duties.
You should only collect data you genuinely need. You should keep it secure. You should be able to tell a user what you hold about them, and delete it if they ask. You should not quietly share it with third parties they never agreed to. And if something goes wrong, you may have to report it quickly.
None of that is exotic. The problem is that AI tools optimise for a working feature, not for these obligations. So the signup form works perfectly and still leaves you exposed.
The five violations we see most
1. Collecting more than you need
AI-generated forms love to ask for everything: full name, phone number, date of birth, address, all on a product that only needs an email.
GDPR calls this data minimisation, and it works against you here. Every extra field is data you now have to protect, justify, and delete on request. If you cannot say why you need a piece of information, you should not be collecting it.
2. Storing passwords and secrets in the open
This is the one that makes us wince most often. We regularly find user passwords stored as plain text, and API keys hardcoded straight into the code where anyone with access to the repository can read them.
Passwords should always be hashed, never stored in a form you could read back. Secrets belong in environment variables, not in the source. AI tools will happily write the insecure version because it works in a demo, and the demo never gets breached.
3. Leaking data to third parties by accident
Modern apps talk to a lot of outside services: analytics, error tracking, chat widgets, payment providers. Each one can receive personal data.
AI tools wire these up without considering consent. An analytics script that loads before the user agrees to cookies is a common and avoidable violation. So is sending a user’s email to a third-party service they were never told about. You are responsible for where the data goes, even when a library sends it for you.
4. No way to delete a user
GDPR gives people the right to have their data erased. Try this test on your own app: if a user emailed you today and asked you to delete everything you hold about them, could you actually do it?
For a lot of vibe-coded apps the honest answer is no, or only by hand, digging through a database you do not fully understand. The tool built the “create account” path because that was the feature you asked for. It never built the “forget me” path, because you never prompted for it.
5. Cookie consent that does not really work
A cookie banner that sets tracking cookies before the user clicks “accept” is worse than no banner at all, because it shows you knew the rule and broke it anyway.
AI tools often generate a banner that looks compliant but fires the tracking scripts on page load regardless of what the user chooses. The visible part is right. The behaviour underneath is wrong.
The quiet risk: data you did not know you were keeping
Beyond the obvious cases, AI-generated apps tend to accumulate personal data in places you never think about.
Logs are the usual culprit. To help with debugging, the tool writes code that records what happened, and those logs quietly capture email addresses, full form submissions, and sometimes passwords in plain sight. That log file is now personal data you are storing, probably with no retention limit and no protection.
Old database tables are another. You changed your signup flow three times, and each version left rows behind. You are still holding data from a feature you removed months ago.
A plain-English compliance checklist
You can check most of this without reading code:
- Do you know every place user data is stored? If not, that is the first gap to close.
- Can a user request their data and get it? There should be a clear process, even a manual one.
- Can you delete a user completely on request? Test it with a real account.
- Do tracking scripts wait for consent? Open your site, decline cookies, and check whether analytics still loads.
- Are passwords hashed and secrets kept out of the code? This one needs a developer to confirm, and it matters more than the rest.
- Do you have a privacy policy that matches what the app actually does? A generic template that describes data handling you do not do is its own problem.
If you cannot confidently tick most of these, you are not unusual. You are in the same position as most founders who shipped fast with AI tools.
Why this is worth taking seriously
The consequences are not just theoretical. The Information Commissioner’s Office can issue significant fines, and beyond the legal exposure, a data breach is often what ends the trust between a small product and its early users.
The reassuring part is that these problems are fixable, and they are cheaper to fix before a breach than after one. Hashing passwords, moving secrets out of the code, gating your tracking behind real consent, and building a proper deletion path are all well-understood jobs. They are invisible when they work, which is exactly why AI tools skip them.
Data protection is not the exciting part of building a product. It is the part that quietly protects everything else you have built.
Not sure whether your AI-built app handles personal data safely? Get a free code review. We check for exposed secrets, insecure storage, and consent gaps as standard, and tell you what needs fixing in plain English.