Handling a data subject access request for an app nobody remembers building

An email lands in your shared inbox. Someone wants a copy of all the personal data your company holds about them, and they want it within a month. You start asking around, and it turns out one of the systems that has their data is a little app a marketing colleague built with Lovable last year. Nobody in IT set it up. Nobody is quite sure how to get data out of it.

That’s a data subject access request, or DSAR, and the clock is already running. This post walks through how to answer one when the app in question was AI-built and has no obvious owner.

What a DSAR actually requires

Under GDPR (Article 15) and the UK GDPR, any person can ask what personal data you hold about them and get a copy of it. You have to respond within one calendar month of receiving the request. For complex cases you can extend by two more months, but you must tell the person within the first month that you’re doing so and why.

The response has to cover more than just a data dump. The person can ask for:

Confirmation that you’re processing their data at all.
A copy of the actual data.
Why you’re processing it (the purpose).
Who you’ve shared it with, including any processors and third countries.
How long you plan to keep it.
Where the data came from, if you didn’t get it directly from them.

Here’s the part that trips up teams with AI-built tools: the request covers all systems, not just the ones IT knows about. If a colleague’s Lovable app has the person’s email, support notes, or order history, that data is in scope. “We forgot that app existed” is not a defense a regulator accepts. The obligation sits with your company as the data controller, no matter which team clicked the buttons.

Getting this wrong is not cheap. Ignoring or fumbling DSARs is one of the most common triggers for GDPR complaints, and regulators can fine up to 20 million euros or 4% of global annual turnover for serious breaches. Most cases don’t reach that, but even a warning plus a public complaint is a bad week.

The step-by-step checklist

Work through these in order. The first four are about the specific request in front of you. The last two stop it happening again.

Log the request and start the clock. Write down the date you received it. Your one-month deadline counts from that day, not from when you got around to reading it. Note it somewhere shared so a holiday or a sick day doesn’t blow the deadline.
Verify who’s asking. You’re allowed to confirm the person’s identity before handing over their data, and you should. Don’t demand a passport for a simple request, but do check the request comes from the actual data subject and not someone fishing. If verification is genuinely needed, the one-month clock can pause until you get it.
Find every system that might hold their data. This is where the AI-built app matters. List your CRM, your email tool, your support desk, your accounting system, and every internal tool built outside IT. If you don’t have that last list, you have a bigger problem than this one DSAR (more on that below). Search each system for the person’s identifiers: email, name, phone, customer ID.
Extract, review, and package the data. Pull the person’s records from each system, including the AI-built app. For a Lovable or similar app, that usually means querying the database behind it, not just reading the screen. Redact anything that would expose other people’s personal data. Then send the person a clear copy plus the context: purpose, recipients, retention period, source.
Write down where the app’s data lives and who owns it. After you’ve dug the data out once, capture it. Which database, which hosting provider, which country, who has access. Assign a named person as the owner. Next time, this becomes a ten-minute job instead of a two-week scramble.
Build a proper data inventory. The real fix is a living list of every tool that touches personal data, AI-built or not, with owner, data types, location, and retention. This is the single artifact that makes DSARs, audits, and breach response manageable. Without it, every request is a fresh archaeology dig.

A practical warning on the extraction step: many AI-built apps store data in a way that makes a clean export hard. There may be no admin screen, no export button, and no documentation. Budget more time than you think, and involve whoever can access the database directly.

A note on the redaction trap

Step 4 hides a mistake that’s easy to make under deadline pressure. When you pull one person’s records, you often pull rows that also mention other people: a support thread with two customers, a shared note, an email chain. The requester is entitled to their data, not everyone else’s. Handing over another person’s personal data inside a DSAR response is itself a data breach, so redact anything that identifies someone other than the requester before you send.

The AI-built app makes this harder, not easier. A normal support tool has a clean “this ticket belongs to this customer” structure. An app generated on the fly may mix data together in ways that make it hard to tell whose is whose. Slow down on the review, and if you’re unsure whether a field belongs to the requester, treat it as needing a closer look rather than shipping it blind.

Or, we do it for you

Digging personal data out of an undocumented AI-built app under a legal deadline is not a fun afternoon. We take over hosting for these apps, give you direct database access, tested backups, and a named human who can pull a clean export when a DSAR arrives. See how we handle it on our for-SME page.

FAQ

How long do we really have to respond to a DSAR?

One calendar month from the day you receive it. You can extend by up to two months for genuinely complex or high-volume requests, but you have to tell the person within the first month and explain why. Don’t treat the extension as a default; regulators expect you to meet the one-month deadline in normal cases.

Can we charge the person or refuse the request?

Usually no. The first copy is free. You can charge a reasonable admin fee or refuse only if a request is clearly excessive or repetitive, and you have to be able to justify that. “It’s hard for us to get the data out of our app” is not a valid reason to refuse.

What if the AI-built app has no way to export data?

That’s a compliance gap, not an excuse. You still have to produce the data, which may mean querying the underlying database directly or getting help from whoever hosts it. It’s also a strong sign the app needs to move to hosting where you actually control the data. See our GDPR hosting checklist for what to look for.

Does a DSAR cover internal-only tools?

Yes. If an internal tool holds data about an identifiable person, whether that’s a customer, a supplier contact, or an employee, that data is in scope. The tool being internal or “just for the team” doesn’t take it out of GDPR.