How to Add GDPR Data Deletion to an AI-Built App
A practical, engineering-first walkthrough of how to implement GDPR's right to erasure in a real app, covering hard delete versus anonymization, the systems where user data hides, a compliant request workflow, and a working prompt for an AI coding agent.
If even one person in the European Union has an account in your app, GDPR's right to erasure, defined in Article 17, applies to you. It is not a compliance nice-to-have you can push to the backlog. Regulators can fine companies up to 4 percent of global annual revenue or 20 million euros, whichever is higher, and being a small startup has not held up as a defense. And "deleting a user" is far more complicated than running one query against your users table.
That gap between what people assume deletion means and what it actually requires gets worse when an app was built fast with an AI coding tool. Speed is the point of that workflow, and compliance plumbing like this is exactly the kind of thing that gets skipped when a feature ships in an afternoon. If you have not looked closely at how your app's foundation was assembled, it is worth revisiting the general approach to building an app with AI before bolting a deletion system on top of it.
None of this is legal advice, it is an engineering breakdown of what the regulation requires you to build. For a broader look at where AI tools fall short on legal judgment calls, see this breakdown of using AI for legal advice.
What deletion actually has to mean
Deletion is not one operation, it is three different ones, and using the wrong one for the wrong kind of data creates its own liability. Teams that treat every delete request the same way tend to either destroy records they were legally required to keep, or quietly keep records they were legally required to destroy.
Hard delete: the row, file, or object is permanently destroyed and unrecoverable. This is the right outcome for most personal data once a request is confirmed and the grace period has passed.
Anonymization: identifying fields, name, email, IP address, any free-text field that might contain a name, are stripped or replaced, but the underlying record stays for aggregate use, an order total in revenue reporting, a support ticket count, a churn cohort. Once a record can no longer be tied back to a specific person, it stops being personal data under GDPR, and the erasure obligation is satisfied without you losing the data point itself.
Scheduled purge: the record is flagged for deletion now but actually removed later, on a timer. This is how you handle a recovery window for accidental account deletions, and how you handle systems that cannot be edited on demand, like backups, queues, or read replicas.
Immediate hard delete everywhere sounds like the safest default, and for most tables it is. It is the wrong move for financial records. Invoices, receipts, and transaction records are usually subject to separate tax and accounting retention laws, six to ten years in most EU member states, seven years in the US. GDPR itself accounts for this conflict: Article 17(3) states the right to erasure does not apply where processing is necessary to comply with a legal obligation. In practice that means you keep the invoice, but you scrub the fields that identify the person, replacing name and email with something like deleted-user-4821, while the amount, date, and tax details stay intact.
Where user data actually hides
Founders usually design the deletion flow around their main database and forget everything downstream of it. A real deletion request has to reach all of the following:
Related tables an ORM migration added later and nobody remembers: comments, uploaded files, saved drafts, notification preferences, referral codes, anything carrying a foreign key back to the user's id.
Email tools: Mailchimp, Customer.io, Postmark, or SendGrid keep their own contact and suppression lists that do not sync automatically with a database delete.
Product analytics: Mixpanel, Amplitude, PostHog, and Google Analytics store event history tied to a user or device ID indefinitely by default.
Support tools: Intercom, Zendesk, or Crisp conversation history, often searchable by the same email address you just removed from your own system.
Error tracking and application logs: Sentry captures full request payloads by default, and log lines frequently print emails, names, or IP addresses into stack traces that sit around for months.
Third-party AI or LLM logs: if user data ever went into a prompt sent to an LLM provider, or through a logging or observability layer sitting in front of it, that provider may be retaining the full prompt text, including whatever personal details you passed in.
Payment processors: Stripe or Paddle keep their own copies of billing data, in part because they carry their own regulatory retention obligations that are independent of yours.
Backups: your nightly or point-in-time backups still contain the record until the backup itself rolls off retention. This is worth planning for at the same time you design your backup strategy, not as an afterthought once a deletion request comes in.
CDN and edge caches, staging or development database copies, and the CSV export a teammate downloaded into a spreadsheet six months ago.
Building the deletion request flow
A compliant flow needs a paper trail and a time limit, not a support ticket handled ad hoc whenever someone remembers to look at the inbox.
The user requests deletion from account settings itself, not by emailing support, so there is a timestamped, authenticated record of the request. Require re-entering a password or a confirmation code first, so a compromised session cannot delete an account someone else owns.
The system shows a clear summary before confirming anything: what gets deleted, what gets retained and why (invoices, tax records), and the exact date deletion will complete.
The account enters a grace period, typically 14 to 30 days, during which it is disabled or read-only but recoverable. Logging back in during this window cancels the request automatically.
A scheduled job executes the actual deletion once the grace period ends: hard-deleting rows across every table and third-party system on the checklist, anonymizing anything under a retention obligation, and recording exactly what happened.
A final confirmation email goes out once deletion completes, sent to the address on file before it is removed, along with a short record of what was deleted and what was retained and why.
Right to erasure and the right to data portability are separate obligations under GDPR, but most products handle them together in practice: prompt the user to export their data before they finalize a deletion request, since once it is gone, it is gone.
Every step above should write to the same place you keep records of who did what and when. If a regulator ever asks you to prove a deletion request was honored inside the required window, an audit trail is the only evidence that holds up.
Prompting an AI coding agent to build this correctly
An AI coding agent can scaffold most of this in one pass, but only if the prompt specifies the grace period, the exact tables involved, and what gets anonymized instead of deleted. A vague request like "add account deletion" will get you a hard delete on one table and nothing else.
"Build a GDPR account deletion endpoint. When a user requests deletion, do not delete immediately: set their status to pending_deletion and store a deletion_requested_at timestamp. Send a confirmation email describing a 30-day grace period with a cancel link. Create a scheduled daily job that finds accounts where deletion_requested_at is more than 30 days old and status is still pending_deletion, then: hard-delete their rows in comments, uploads, sessions, and notifications; anonymize their name and email on any invoice or order records instead of deleting them, replacing both with deleted-user-{id}; call the Stripe API to remove stored payment methods but leave the customer record intact per Stripe's own retention rules; write an entry to the audit_log table recording the deletion with a timestamp; and send a final confirmation email to the address on file before it is removed. Do not touch rows referenced by financial or tax reporting tables. Add a test confirming a pending_deletion account can still log in and cancel during the grace period."
Review whatever comes back line by line before it ships. The agent has no idea which analytics tool, email provider, or logging service you actually use, so it will only handle what is in your own database unless you name the other systems explicitly, and in most cases you will still need to wire up their APIs yourself.
FAQ
How long do I have to delete a user's data under GDPR?
Without undue delay, and within one month of receiving the request. That window can be extended by up to two more months for complex requests, but you have to tell the user within the first month that you are doing so and explain why. In practice, that means your grace period plus your purge job should finish comfortably inside 30 days, not push right up against the deadline.
Can I keep anonymized data after a deletion request?
Yes. Once data is genuinely anonymized, meaning it can no longer be linked back to a specific person by you or anyone else, it stops being personal data and the erasure obligation no longer applies to it. Aggregated revenue totals, anonymized usage counts, and stripped support tickets are fine to keep. Pseudonymized data, where a reversible key or ID still connects the record to the person, does not qualify as anonymized and still has to be deleted.
Do I have to delete data from my backups too?
Eventually, yes, but regulators generally accept that backups cannot be edited on demand the way a live database can. The accepted approach is a documented, bounded backup retention window, for example 30 or 90 days, so the data disappears automatically once old backups roll off and get overwritten. What does not hold up is keeping backups indefinitely with no rotation policy and calling that compliant.
Does GDPR apply if my app has no EU-based company but has EU users?
Yes. GDPR's territorial scope, under Article 3, covers any company that offers goods or services to people in the EU or monitors their behavior, regardless of where the company is incorporated or where its servers are located. Having no EU employees or legal entity does not exempt you if EU residents are signing up and using the product.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
