Vibe coding and the GDPR: your obligations if your app processes personal data
By Kike Gandia · Co-Founder & CEO, OSCP
The GDPR does not ask how you built the application. If it processes personal data of EU residents — a name, an email, an IP address — the obligations are exactly the same as if you had developed it with a team of twenty. And there is a detail that surprises people building with AI: the regulation requires security by design and by default, which means the permissive configuration a builder ships is not an excuse. It is precisely what the rules ask you to close.
When it applies to you: almost always
It is enough for your application to process one piece of data that identifies a person, directly or indirectly. That covers the obvious — name, email, phone — and also what many people do not consider personal data: an IP address, a device identifier, or content a user uploads if it makes them identifiable.
It does not matter whether you are a sole trader, whether the app is free, whether you have ten users or whether you still call it an MVP. The regulation exemptions are narrow, and the household activity exemption does not cover a product you offer to third parties.
Using third-party services does not release you either. If your application stores data with a cloud provider, you remain the data controller and that provider is your processor, under a contract that must exist in writing.
The four obligations most often missed
Lawful basis. You need a legal reason to process each piece of data: consent, contract performance, legitimate interest or another. "I asked for it in the form because the builder put it there" is not a lawful basis.
Minimisation. You may only process data necessary for the purpose. Generated applications tend the other way: the model creates tables with extra fields because they looked useful. Every field you do not use is risk with no upside.
Informing the user. A privacy policy that genuinely states what you collect, why, where it is hosted and who it is shared with. Copying a template that does not describe your application is itself a breach of the rules.
Security of processing. Article 32 requires technical measures appropriate to the risk. A database reachable without authentication does not meet that, and it is the most common flaw in generated applications.
What happens exactly if data leaks
If there is a breach posing a risk to the rights of the people affected, you have 72 hours from becoming aware of it to notify the supervisory authority — the AEPD in Spain. Not from resolving it: from becoming aware.
Where the risk is high, you must also communicate it to the affected individuals, without undue delay and in plain language.
One detail works against you in this specific scenario: when the leak happens because the database was publicly reachable, you will not be able to establish that nobody accessed it. Access through the public path does not leave the same trace as an intrusion, and the burden of diligence sits with you.
It is worth documenting the assessment even when you conclude notification is not required. That documentation is exactly what gets requested afterwards if anyone asks.
How this relates to the AI Act, which is a different thing
The two are often confused and regulate different things. The GDPR governs the processing of personal data, whatever the technology. The AI Act governs artificial intelligence systems according to the use they are put to.
If you only used AI to write the code, the AI Act probably does not apply to you: the tool was a development instrument, not an AI system you place on the market. If your application incorporates AI — a chatbot, automated classification, a recommendation — then it does, with obligations depending on the risk level of the use.
The GDPR, by contrast, applies in both cases from the first piece of personal data you store.
What to do, in order
1. Inventory what you actually store. Open the tables and look. There are almost always fields nobody uses.
2. Delete what you do not need. The cheapest measure and the one that removes the most risk.
3. Verify the data layer is closed. Without that, Article 32 is not met and everything else is paperwork.
4. Write a privacy policy that describes your application, not a generic template.
5. Sign processor agreements with your providers. Most offer them pre-signed from their console.
6. Decide what you would do in a breach before having one: who you notify and within what deadline. Improvising inside the 72 hours is expensive.
FAQ
My app is free and I do not sell data, does the GDPR still apply?
Yes. The regulation does not distinguish by business model or by whether there is profit: it is triggered by the processing of personal data, whether you charge for it or not. What the regulation does modulate is the proportionality of the measures, not whether they are required: you will be asked for measures appropriate to the risk of your processing, not those of a multinational.
I use a cloud provider, is the responsibility not theirs?
No. You decide what data is processed and why, so you are the controller; the provider is a processor and answers for what you instruct, under contract. If you left the database reachable, the responsibility is yours even though the infrastructure belongs to a third party: the access configuration is your decision, not theirs.
Do I need to register the application with the AEPD?
There has been no prior registration of files since 2018. What you do have is the obligation to keep an internal record of processing activities, with exemptions for organisations under 250 employees that in practice rarely apply, because they lapse where processing is not occasional or involves special categories of data.
Related service
Related content
- AI Act compliance consulting
- Is an app built with AI secure?
- Check in 15 minutes whether your app leaks data
- What are the security risks of vibe coding