GDPR Obligations Your AI-Built App Probably Missed
Written By
SprintX Team
AI & Product Engineering
August 02, 2026
7 min read
The GDPR requirements AI code generators never implement — real deletion, lawful basis, subprocessor disclosure, retention, and breach readiness — and how to close them.
Your app has European users. It may have had them from week one, because the internet does not check passports. Somewhere in the build, an AI assistant added a cookie banner and a privacy policy link, and that felt like the compliance box being ticked.
It was not. GDPR is mostly a set of engineering obligations, and the ones that matter are invisible in the UI. They live in your schema, your logs, your third-party calls, and your ability to answer a stranger's email within thirty days.
The pattern is consistent across the AI-built products we review: the visible compliance artifacts exist, and none of the underlying capability does.
Deletion is the obligation that breaks first
Article 17 gives users the right to have their personal data erased. In practice this means someone emails you asking to be deleted, and you have one month to actually do it — everywhere.
An AI-generated app almost never can. Here is what we find when we trace a delete request through one:
The user row gets removed or flagged inactive. Their records in eight other tables stay, because the schema has no cascading relationships and the generated delete handler only touched the one table the prompt mentioned. Their email is still in the messages table, the audit log, and three denormalized copies the model created to make a dashboard query simpler. It is in your transactional email provider, your analytics tool, your error tracker's user context, your CRM, and — if your product uses an LLM — in whatever prompt logs your model provider retains.
Deleting a user properly is a data engineering problem, and it has to be designed. That means knowing every place personal data lands, having foreign keys that model reality, deciding row by row between hard delete, anonymization, and retention under a legal basis, and having a documented way to propagate the request to each processor. If your schema was generated table by table without relationships, this is the moment that debt comes due — the sort of structural repair covered in fixing AI-generated code.
The obligations, and what each demands of the codebase
| Obligation | What it requires in practice | Common AI-built gap |
|---|---|---|
| Lawful basis (Art. 6) | A stated reason for each processing purpose | Never decided; consent assumed for everything |
| Access and portability (Art. 15, 20) | Export a user's data in a machine-readable format | No export path; manual database queries |
| Erasure (Art. 17) | Delete across all stores and processors within a month | Partial delete of one table |
| Consent for tracking | Prior, granular, revocable, with no pre-ticked boxes | Banner that loads analytics before the click |
| Records of processing (Art. 30) | A written inventory of what you process and why | Does not exist |
| Processor agreements (Art. 28) | A DPA with every vendor touching personal data | Vendors added by prompt, no DPAs |
| Breach notification (Art. 33) | Notify the regulator within 72 hours of awareness | No detection, so no awareness |
| Data protection by design (Art. 25) | Minimize collection, restrict access by default | Collects everything, roles are advisory |
None of these are exotic. All of them are work, and most of them are work in the database rather than the privacy policy.
Every AI API you call is a subprocessor
This is the obligation AI-built products miss most reliably, because dependencies on external services accumulate one prompt at a time.
If your app sends user content to a model provider, a transcription service, an embedding API, an enrichment tool, or a moderation endpoint, that vendor is processing personal data on your behalf. You need a data processing agreement with them, you need to list them in your privacy notice, and your customers need to be told before you add a new one.
Three specifics worth checking today. First, whether your provider's default terms allow your data to be used for model training, and whether you are on the tier that turns that off. Second, what the retention window is on the API side — many providers retain request payloads for abuse monitoring for a period, which is fine but must be disclosed. Third, where processing physically happens, which determines whether you have an international transfer to document.
Then there is the quieter version of the problem: personal data flowing into tools nobody thinks of as processors. Error trackers capturing request bodies. Analytics with user identifiers. Session replay recording form fields. Log aggregators holding email addresses forever. These are all subprocessors too, and log retention is one of the most common places we find personal data with no retention policy at all.
If you are building AI features specifically, the deeper treatment is in GDPR-compliant AI — the training, prompt-logging, and automated-decision questions have their own rules.
Consent that actually works
A cookie banner generated by an AI builder usually fails in the same way: the analytics script is already in the page head, firing before the user chooses anything. The banner is decoration.
Valid consent under GDPR and the ePrivacy rules has to be prior (nothing non-essential loads before the choice), granular (separate categories, not one accept-all), as easy to withdraw as to give, and recorded so you can demonstrate it later. A single "OK" button with no reject option is the configuration regulators have penalized most consistently.
The engineering implication is that your third-party scripts need to be gated behind the consent state, not merely accompanied by it. This usually means moving tag loading into a consent-aware wrapper, which is a half-day of work and is very often skipped.
Retention: pick numbers and enforce them
"We keep data as long as necessary" is not a retention policy. You need actual periods per data category, and something that enforces them.
Write down what you keep and for how long — account data while the account is active plus a defined tail, logs for a stated number of days, backups on a documented cycle, support tickets and analytics with their own windows. Then implement it: scheduled jobs that delete expired rows, retention configured in your log platform, backup rotation that eventually ages out. Unbounded storage is the default in every AI-generated app we have reviewed, because deleting things is never what anyone prompts for.
Backups deserve a note. You are not expected to surgically edit backup archives on every erasure request, but you are expected to have a defined backup lifecycle and to ensure deleted data does not get restored back into production. Document the approach.
Detection, because 72 hours is not long
Article 33 gives you 72 hours from becoming aware of a personal data breach to notify your supervisory authority. Most small teams have no mechanism for becoming aware. No alerting on unusual data access, no logs with meaningful retention, no owner.
The minimum viable version: authentication and privileged actions logged to a system with real retention, one alert on anomalous bulk reads, a written decision tree for who assesses an incident and who notifies, and the regulator's contact details found in advance rather than at hour 60. Anything more sophisticated can come later; what you cannot do is discover a breach from a customer tweet.
While you are in there, verify the boring stuff a scanner would catch — exposed storage, over-permissive access rules, endpoints returning more fields than the UI shows. A website security audit and an AI code audit both surface the data-exposure issues that turn a compliance gap into a notifiable incident.
A realistic order of work
If you are starting from zero, do it in this sequence. Map the data first — every table, every third party, every log destination — because you cannot fix what you cannot see. Then fix deletion and export, since those are the obligations a user can trigger unilaterally. Then subprocessor DPAs and privacy notice accuracy. Then consent gating. Then retention enforcement. Then breach detection and the written processes.
That is typically a few weeks of engineering for a small product, not a quarter. The expensive version is the one where you start after receiving your first deletion request from someone who knows their rights and intends to follow up.
Frequently asked questions
Does GDPR apply to my app if my company is not in Europe? It applies if you offer goods or services to people in the EU or UK, or monitor their behavior — regardless of where you are incorporated. Accepting signups from European users and running analytics on them is enough. Company location determines whether you also need an EU representative, not whether the rules apply.
How quickly do I have to delete a user's data? Without undue delay and within one month of the request, extendable by two months for genuinely complex cases if you tell the person why. The practical constraint is not the deadline but the plumbing: if your app cannot delete across every table, log store, and third-party service, you will miss it regardless of how fast you start.
Do I need a data processing agreement with an AI API provider? Yes, if any personal data reaches them, including user-authored text in prompts. Major providers publish a standard DPA you can accept, and you should also confirm their retention window and whether your plan excludes your data from model training. Then list them as a subprocessor in your privacy notice.
If your app collects European user data and nobody has traced where that data actually goes, the compliance gap is in the schema and the integrations, not the privacy policy. SprintX maps the data, builds real deletion and export, and closes the gaps in AI-built products. Send us your app and we will map what it stores.
