GDPR Data Mapping for Vibe-Coded Apps: Find Where Your Data Lives When an AI Wrote the Code

TL;DR: GDPR data mapping means writing down where personal data enters your app, where it sits, who touches it, why you hold it, and when you delete it. If an AI wrote your code, that record does not exist — because nobody made those choices. The AI did. This guide shows how to build the map from the outside in, without reading a line of code. Start with a free scan of your live URL.

Here is the strange truth about vibe-coded apps. You own a database you have never really looked at. The AI picked the tables. The AI picked the fields. The AI wired your signup form to a vendor you may not recall adding. The app runs. But ask where a user's email address goes after signup, and the honest answer is: you do not know.

GDPR calls that a problem. You cannot protect data you cannot find. You cannot delete data you cannot find. And you cannot answer a user's export request from a database you have never mapped. This page fixes that — this is the mapping piece. For the full legal picture (lawful basis, consent, user rights), read our GDPR guide for vibe-coded apps.

Why the map does not exist when an AI wrote the code

In a hand-built app, a developer decides which table stores what, which fields are private, and which vendor sees a copy. The decisions may be undocumented, but at least a human made them and can recall them.

In a vibe-coded app, there was no decision. You asked Lovable, Bolt, Cursor, or v0 for "user profiles" or "checkout." The AI wired it together. It did the job — and left no paper trail. No note on why chat logs are stored raw. No flag on which fields are sensitive. No list of the vendors it pulled in.

So the map is not lost. It was never made. That is why data mapping for an AI-built app starts from zero — and why it is the first thing we check on the compliance side.

The five questions a data map answers

A real map is not a form you fill once and forget. It is a living record that answers five questions for every type of personal data you touch:

• What do you collect? Names, emails, payment tokens, IP addresses, chat logs.
• Where does it live? Which table, which storage bucket, which vendor's servers.
• Who touches it? Your app, your vendors, and any AI model you call.
• Why do you hold it? The lawful basis: consent, contract, or legitimate interest.
• How long do you keep it? A set period with a deletion job behind it. Not "forever by default."

Most vibe-coded builds fail all five. None of these questions were ever part of the prompt.

A starter map you can copy

Here is what the first pass looks like for a typical AI-built SaaS. Copy the shape, swap in your own rows:

The "kept for" column is the one your AI builder never filled. Ask an AI for a signup flow and it stores the user forever. No expiry logic. No purge job. Retention is not a footnote — it is the data-minimization core of GDPR. Someone has to add the deletion clock. It will not add itself.

The vendor list: your sub-processors

Every SaaS app leans on a stack of third parties, and each one is a line in your map. Under GDPR they are your sub-processors, and each needs a name, a purpose, and a retention note:

• Your database host. It holds everything. And if Row Level Security is off, it also holds an open door. A policy of USING (true) counts as off. CVE-2025-48757 exposed 170+ AI-built apps this exact way.
• Your payment provider. Often acts as its own controller for the payment slice. Note that in your record.
• Your email and analytics tools. They collect usage data most founders never think to log.
• Any AI model you call. If user content goes into a prompt, that vendor is in your data flow. Map it.

Skipping one vendor is how a routine review turns into a finding. If you can see the vendor in your network tab, a regulator can too.

Article 30: turning the map into proof

Article 30 of GDPR asks most controllers for a written Record of Processing Activities — a ROPA. A regulator does not ask "did you think about privacy?" They ask for the document.

The ROPA lists your purposes, the types of people whose data you hold, the types of data, the recipients (your vendors), and your retention schedule. In other words: it is your data map, formatted. Build the map and the record falls out of it.

A missing record does not crash your app. The app keeps running. What you lose is the one document that proves you know where your users' data lives.

How to build the map without reading code

You do not need to read what the AI wrote. Work from the outside in:

1. Scan the live app. The free scan shows what your URL exposes to the public — including data doors you did not know were open.
2. Test your tables. The free RLS checker shows whether the public anon key can read your user data.
3. List your forms. Every input field on your site is a data entry point. Write each one down.
4. Open the network tab. Load your app, watch the calls. Every third-party domain is a vendor for your list.
5. Check your headers. The security headers checker shows what leaves your app with every response.

Two hours of this beats a week of code reading. And it matches how a regulator, or an attacker, will look at your app: from the outside.

The 2026 twist: map your AI flows too

From August 2, 2026, Article 50 of the EU AI Act requires apps to tell users when an AI talks to them. Fines for a breach run up to €15 million or 3% of global turnover. That makes AI flows part of your map: what user content goes to a model, which model, and where the output lands. Our EU AI Act guide for SaaS founders covers who is in scope.

What this costs

The $799 Compliance Score is credited toward the DFY setup. See a sample report before you spend anything.

FAQ

A data map is not paperwork for later. It is the answer to the first question anyone serious will ask you — a user, a buyer, a regulator: where does my data go? If an AI wrote your code, nobody has answered it yet. Two hours and the steps above change that.