AI-Built Apps and GDPR: Who Owns an Exposed Record?

If your AI-built app exposes customer data, the model provider does not become the company that has to explain it. You decided what to collect, what to store, and what the app would do with it. Under the GDPR that usually makes you the controller. The people in the tables are data subjects. The clock starts when you become aware, not when you finish blaming the agent that wrote the query.

This is not legal advice, and it is not a substitute for reading the regulation or asking counsel if you have EU or UK users. It is the operational picture founders miss because the app was generated quickly: a leak is still a personal-data breach, a builder is often a processor, and "the AI wrote it" is not a role the regulation recognizes. The technical holes that cause the leak are in vibe coding security vulnerabilities and in MCP servers the agent can call. This note is who has to act after the hole is real.

The roles do not move because an agent wrote the code

Article 4 of Regulation (EU) 2016/679 defines the controller as the body that decides the purposes and means of the processing. The processor processes personal data on behalf of the controller. Processing is broad. Article 4(2) includes collection, storage, alteration, retrieval, disclosure, and erasure. A generated app that stores accounts is processing. A supplier who migrates or debugs that data on your instructions is processing too.

Article 24 says the controller implements measures to show that processing complies. Article 28(1) says that where processing is done by a processor, the controller uses only processors that provide sufficient guarantees, and Article 28(3) requires a contract that states the subject matter, duration, nature and purpose, the type of data, and the categories of people. The contract binds the processor to process only on documented instructions, to keep people who handle the data confidential, to help you with security and with requests from individuals, to delete or return the data at the end, and to allow audits. Article 28(9) says the contract is in writing, including electronic form. Article 28(10) says a processor that starts determining purposes and means on its own is a controller for that processing.

That last sentence is the one to apply to AI tools. A host that stores your database on your instructions, under a contract, is a processor. A model tool you paste customer rows into, with no contract and no instruction not to train on them, is a problem you created as controller. A coding agent with your production connection string is processing personal data if it reads the tables, whether or not you thought of it as a developer convenience.

Article 5 still applies to the app the agent built. You need a lawful basis, you collect what you need for the purpose, you keep it accurate and no longer than necessary, and you protect it. A generated schema that stores a copy of an identity document "in case" fails minimization even if the upload feature works. A log line the agent added, with the full request body, fails the security principle and creates a second breach waiting in the log vendor.

What a breach requires you to do

Article 4(12) defines a personal-data breach as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or unauthorized access. A bucket left public, a row-level policy that returns every customer, an agent that emailed a CSV to the wrong place, a laptop backup of production: those are breaches if personal data was involved. You do not get to wait for a ransom note.

Article 33 requires the controller to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If you notify later, you state the reasons for the delay. The notification describes the nature of the breach, the categories and approximate numbers of people and records where possible, the name and contact of your data protection officer or other contact, the likely consequences, and the measures you have taken or propose. You may provide that in phases. You also document every breach, the facts, the effects, and the remedial action, so the authority can check. "We think the agent might have" is not that document. A factual timeline is.

The processor's duty in Article 33 is to notify the controller without undue delay after the processor becomes aware. Your contract should say how, and to which address. A status page you do not read is not the processor telling you.

Article 34 requires you to communicate the breach to the person when it is likely to result in a high risk to them, in clear language, without undue delay. The message covers the nature of the breach and the contact, consequences, and measures from Article 33. You do not have to contact each person if appropriate protection rendered the data unintelligible, such as encryption, and that protection was applied to the data affected; or if you took later measures that mean the high risk is no longer likely; or if individual contact would involve disproportionate effort, in which case you use a public communication that is as effective. If you have not told people and the authority considers the risk high, it can require you to.

Encryption helps with Article 34 only if the attacker did not also get the key. A database the agent could read with a token is not "encrypted in a way that makes the data unintelligible" to that token. Do not write the user email as if it were.

Article 32 requires security appropriate to the risk, including, as appropriate, encryption and pseudonymisation, confidentiality, availability, and restoration of access after an incident, and a process for testing those measures. A backup you have never restored does not meet the restoration part. An access-control bug in generated code does not meet the confidentiality part. The regulation does not excuse either because a model wrote the migration.

Article 35 requires a data-protection impact assessment before processing that is likely to result in a high risk, in particular when using new technologies. An agent that acts on customer data, makes decisions about people, or sends data to a new model provider is a candidate. The assessment is how you notice the transfer and the access path before the 72-hour clock exists. Doing it after the leak is a different document.

Where AI-built apps actually leak

The client bundle. A service-role key or a database URL in the frontend is unauthorized access waiting for a viewer. Anyone who loads the page has the means. If that key reads personal data, you are in Article 33 territory once you know. Rotate the key, assume it was used, and build the timeline from the provider's logs if you have them.

The missing authorization check. One user fetches another's row by changing an id. That is unauthorized disclosure. The number of people affected is a query you should be able to run. If you cannot, your logs are part of the problem.

The agent and the prompt. A support bot that receives a customer's message and sends the conversation to a model is disclosing data to that provider. Whether that is lawful depends on the basis, the contract, and where the provider sits. The European Data Protection Board's report on privacy risks in LLMs discusses how retrieved context and prompts can lead to disclosure and to indirect prompt injection. A system prompt is not a legal basis. A data-processing agreement and a decision about what is allowed to be in the prompt are.

The debug copy. A founder exports production so the coding agent can "see the bug." That export is processing, often in a new country, on a laptop, with no retention date. The Spanish data protection authority's guide to agentic AI is aimed at controllers deciding whether to use agents on personal data at all. The practical test is smaller: can you list every place a customer row was copied in the last month, including agent transcripts? If you cannot, you are not in a position to notify accurately.

The processor you never contracted. The builder, the host, the model API, the error tracker, the email tool. Article 28 applies to each that processes personal data for you. A terms-of-service click is sometimes a contract and sometimes not the contract Article 28 describes. Read it for instructions, subprocessors, deletion, and breach notice. If the tool has no such terms and you are sending EU personal data, stop sending it until you have an answer you can defend.

What to have before you need the 72 hours

1. A one-page record of what personal data you hold, why, where it is stored, and who you send it to. Article 30's record is the heavier version. A list you can open at midnight is the useful version.
2. A named person who can decide that you are "aware" of a breach, and a mailbox that processors can use. Awareness is what starts the clock. A ticket nobody owns delays the clock in a way you will have to explain.
3. Contracts or a documented reason for each processor, including the model provider and the coding tool if it receives customer data. Subprocessors included, because Article 28(2) limits adding them without authorization.
4. A way to know what was accessed: database audit logs, storage access logs, agent traces that do not themselves become an unbounded copy of the data. See agent observability for how to trace a run without logging everything forever.
5. A tested restore, because Article 32 treats availability and restoration as security, not as a nice-to-have. The steps after a bad deploy are in disaster recovery for an AI-built app.
6. A short notice draft: what happened, what data, what you are doing, how to reach you. You will edit it with facts. You do not want to invent the structure at hour 70.
7. A rule that production data does not go into an agent prompt or a laptop export without a reason, a scrub, and a deletion date.

If you have users in the EU or UK and you have never done items 1 through 3, do them before you add the next AI feature. The feature is optional. The duties attach to the data you already have.

What to stop doing

Do not announce "no breach" because the agent said the policy looked fine. Run the two-account test. Do not put real customer rows in a prompt to save time. Do not assume the builder's privacy policy covers your customers' rights requests. Those requests come to the controller. You need a way to find, correct, export, and delete a person's data. An agent-built admin page that cannot find the person is an operational gap you will feel on the first request.

Do not copy a 72-hour timer onto a breach that is unlikely to risk anyone, and do not skip the timer because you hope it is unlikely. Write down why you believe the risk is low, using Article 33's exception, or notify. The document is the part the authority can ask for later.

Requests from the people in the database

Articles 15 through 17 and 20 give people rights to access, correct, delete, and in many cases receive their data. A generated app that has no way to find a person by the email they will write to you will fail the first request, and the deadline on that request will not care that the admin screen was never in the prompt. Before you need it, confirm you can: locate a person's rows across the tables that hold them, export those rows, correct a field, and delete or anonymize them without breaking the accounting record you are required to keep.

Deletion is where generated schemas hurt. The same person is in users, orders, events, a log table, an agent transcript, and a file bucket. A button that deletes the user row and leaves the rest is not a deletion. Write the list of stores once, including the model provider if prompts contain personal data, and test the list on a fake person. If a store cannot delete, that is a reason to stop sending data there, not a footnote.

Keep the request and your response. The same habit as the breach file applies: what they asked, what you found, what you changed, when. An agent can help you draft the reply. It should not be the only system that knows where the data was, because the agent session will be gone and the obligation will not.

How Techtribe helps when customer data is in an AI-built app

We find the paths that disclose data: keys in the client, missing authorization, exports, prompts, and processors you did not list. You get that list in writing, with what to rotate and what to close, so your own counsel and your own notification decision have facts instead of a vibe. We do not replace a lawyer, and we do not send the regulatory notice for you.

If the product needs a real access model, a record of processing you can stand behind, and an architecture that does not copy production into the editor, that scope is a Production MVP or, for a product already live and growing, a Dedicated Team. SaaS products with accounts and customer data are the work described on SaaS development. Bring what you store and whether you already know of an exposure. If you know, say it first so the call starts with containment.

The fixed scope for taking a generated app to production is a page per tool: Lovable, Bolt, v0, and Replit.