GDPR DPIA for AI-Built Apps: When You Need One and How to Do It

TL;DR: A DPIA is a written risk check that GDPR Article 35 asks for before you start high-risk processing of personal data. Most SaaS, websites and apps built with an AI coding tool will need one. That is true if they run an LLM feature, score or rank users, or handle health or money data. The hard part is not the form. It is the first section. You have to describe what the app does with personal data. If an AI tool wrote your code, you cannot answer that from memory. The code logs, stores, and sends data in ways you never asked for. So build the DPIA from the real codebase. This guide covers the Article 35 triggers and the nine EDPB criteria. It covers what Article 35(7) makes you write, and the Article 36 duty. It explains how the EU AI Act FRIA differs. And it ends with a step-by-step process.

Here is the usual story. A founder ships an app built with Lovable, Bolt, or Cursor. It has a chat feature that calls an LLM. It scores leads. A customer in Germany asks for the DPIA. The founder opens a template and starts filling in what they think the app does. Three weeks later a scan shows the app was logging full request bodies to a third-party tool. Chat included. The founder never chose that tool. The DPIA was fiction from page one.

A DPIA is a risk check, not a filing

Article 35(1) is short. If a type of processing is likely to be a high risk to people, you assess that risk before you start. New tech counts. So does the scope of the data and the purpose behind it.

Three things follow from that. First, the duty is on the controller. That is you, the founder, not your AI tool and not your LLM vendor. Second, it comes before processing, not after. Third, it is a living file. Article 35(11) says you review it when the risk changes. Adding a new AI feature is a change.

You do not send a DPIA to anyone. You keep it. A regulator asks for it after a complaint, a breach, or an audit. A larger customer asks for it during procurement. Both want the same thing: proof that you looked before you built.

When Article 35 says you must do one

Article 35(3) lists three cases where a DPIA is always needed:

• Profiling with real effects. Systematic, wide evaluation of people that leads to decisions with legal or similar effects on them. Think automated credit limits or job screening.
• Sensitive data at scale. Large-scale processing of special categories under Article 9, such as health, biometrics, or beliefs, or of criminal records under Article 10.
• Public monitoring at scale. Systematic monitoring of a public area on a large scale.

Those are the hard triggers. Most SaaS apps do not hit them cleanly. That is where the EDPB's nine criteria come in. They come from guidance the Article 29 Working Party wrote and the EDPB adopted. Meet two, and you should assume a DPIA is needed.

Notice the pattern. An LLM feature is one criterion on its own. Add scoring, tracking, or any sensitive field, and you are at two. That is why the honest answer for most AI-built apps is "yes, do one."

Each national regulator also publishes its own list under Article 35(4). Check the one for the country where your users are. Some lists name things like "processing with AI" outright.

When you do not need one

A DPIA is not needed for every bit of processing. If none of the nine signs apply and the data is plain, you can note that and move on. Write down why. A one-paragraph "no DPIA needed because" file is worth having.

Article 35(1) also says one assessment can cover a set of similar operations. So you do not need a fresh DPIA for every feature. You need one for each kind of high-risk processing, updated when the risk changes.

Regulators can publish lists of processing that never needs a DPIA under Article 35(5). Those lists are short. Do not count on being on one.

What Article 35(7) makes you write down

The law names four parts. Every DPIA needs all four.

1. A systematic description of the processing and its purposes. What data, from whom, why, stored where, sent to whom, kept how long. If you rely on legitimate interest, say what that interest is.
2. Necessity and proportionality. Why you need this data for this purpose. Why you could not do it with less.
3. The risks to people's rights and freedoms. Not risks to your business. Risks to your users. Leaks, wrong decisions, unfair scoring, loss of control over their data.
4. The measures that address those risks. The safeguards and controls. Access rules, encryption, retention limits, redaction, and human review.

Two more duties sit next to these. Article 35(2) says you seek your Data Protection Officer's advice if you have one. Most small startups do not need to appoint a DPO, so this often does not apply. Article 35(9) says you seek the views of the people affected, where that makes sense. A short user survey or a note on why you did not ask is enough.

The section founders get wrong

Part one is where AI-built apps fall over. The description of the processing has to be true. It has to match what the code does, not what you told the tool to build.

AI coding tools are good at the visible product. They are careless with the plumbing. In the apps we scan, the same patterns show up again and again. Each one changes what your DPIA has to say.

• User data inside LLM prompts. The chat feature sends the whole user record, or the full history, when it needed one field. That is a transfer to a processor, and the vendor needs a data processing agreement.
• Analytics and session replay added by default. The tool wired in a tracker to "help with debugging." Now you are systematically monitoring users and never wrote that down.
• Request bodies in the logs. Every form post, chat message, and upload lands in plain text in a log store with no retention limit. Your "where is the data stored" answer just doubled.
• Error tracking that captures everything. Stack traces with the user object attached. Another copy of personal data, in another vendor, that your description missed.
• Scoring and ranking features. A "smart" sort of users or leads is evaluation and scoring under the EDPB list. Founders rarely count it.
• Access rules that do not exist. The database has row-level security off, or a policy that reads USING (true). So the honest answer to "who can read this table" is "anyone with the public key." That is the single most common finding on the Supabase-backed apps we scan. Our RLS guide covers the fix.
• Secrets in the client bundle. A service key shipped to the browser means your "measures to address risk" section is describing a lock that is not there. See how to find exposed secrets in AI-built bundles.

None of this is a legal problem first. It is a knowledge problem. You cannot assess a data flow you do not know exists. So the DPIA starts with discovery, not with a template.

Article 36: when the risk stays high

Say you write the DPIA, list the measures, and the risk is still high. Article 36 then makes you consult the regulator before you start. Not after. Before.

The regulator has up to eight weeks to reply. They can add six more for a complex case. If they think the processing would break the law, they say so in writing. That is a long wait for a startup. It is a strong reason to bring the risk down with real controls first.

For most SaaS apps, the fix is technical. Turn on access rules. Cut the data in the prompt to what is needed. Redact logs. Set retention. Add human review to the automated decision. Do those, and the residual risk usually drops below the Article 36 line.

DPIA vs FRIA: two laws, two checks

This is where a lot of 2026 content gets it wrong. A DPIA is a GDPR duty. It is not an EU AI Act duty. The AI Act has its own check, and it is narrower than people think.

Article 27 of the AI Act creates the Fundamental Rights Impact Assessment, or FRIA. It applies to deployers of high-risk AI systems, but only some of them. Public bodies. Private firms that provide public services. And firms that use AI for credit scoring or for pricing life and health insurance. If you are a small SaaS selling to other businesses, you are most likely not on that list.

The two checks do overlap. Article 27(4) says that where a DPIA already covers part of the FRIA, the FRIA builds on it. It does not repeat it. And Article 26(9) tells deployers to use the provider's documentation to help with their GDPR DPIA. So you can combine them into one document. But the DPIA half is always GDPR, and it applies whether or not the AI Act ever touches you.

A few dates matter. The AI Act's duties for high-risk systems listed in Annex III apply from August 2, 2026. The transparency duty in Article 50, which covers telling people they are talking to an AI, applies from the same date. Our guide to AI Act risk tiers helps you work out which tier your product sits in. Our Article 50 disclosure guide covers the transparency side.

Practical rule: do the DPIA first. If you later find you are a high-risk deployer under Annex III, extend it into a FRIA. Do not start from the AI Act and back into GDPR.

How to do a DPIA for an AI-built app

Eight steps. The first three are technical. They are also the ones most guides skip.

1. Scan the live app. Start with what an outsider can reach. A free scan gives you the exposed paths, open tables, leaked keys, and missing monitoring in under two minutes. That is your first list of facts.
2. Read the code for data flows. Search the codebase for every outbound call, every logger, and every third-party SDK. Each one is a place personal data goes. Write them all down. Our data mapping guide walks through this step in detail.
3. Check what each vendor keeps. LLM provider, analytics, error tracking, email, payments. For each, note what you send, what they store, and for how long. Get the DPA for each one.
4. Write the description. Now fill in part one of Article 35(7) from the facts in steps one to three. Purpose, data, sources, storage, sharing, retention, legal basis.
5. Argue necessity. For every field you send to the LLM, every tracker, and every log line: do you need it? If not, cut it. Every cut lowers the risk score.
6. List the risks to people. Leak of chat history. Wrong automated decision. Bias in scoring. Data kept too long. Be plain and specific.
7. Fix, then list the measures. Turn on row-level security. Move secrets server-side. Redact logs. Set retention. Add rate limits. Add human review. Then write down what you did. Measures you have not shipped do not count.
8. Sign, date, store, and set a review date. Note who approved it. Check for Article 36. Put a reminder in the calendar for the next feature launch.

That whole process fits in a week for a small app. Most of the time goes into steps one to three. That is correct. The legal writing is the easy part once the facts are right.

Discovery is a scanning job

Steps one and two are the same work a security scanner does when it maps an attack surface. Every place data can leave the app is both a security finding and a line in your DPIA.

Founders comparing tools for this often start with the big names. We wrote plain comparisons for two of them. There is a Burp Suite alternative, for teams who want the scan run and explained rather than a pentest console to learn. And there is a Drata alternative, for teams who need the technical gaps found and fixed, not just a policy template to sign.

Both point at the same truth. A template gives you the four headings. It cannot tell you what your code does.

Where this sits in the wider picture

A DPIA is one GDPR duty among several. It sits next to data mapping, vendor contracts, access requests, and breach notification. The same code-level facts feed all of them. Do the discovery once, and each document gets easier.

If you are starting from zero, our GDPR compliance guide for AI-built apps is the better first read. Our compliance checklist covers the full sweep across frameworks.

We do not certify anyone for GDPR. We are not lawyers. What we do is find the technical facts a DPIA has to describe, and fix the gaps it has to admit. Our Compliance Wing runs automated checks and a human implementation pass. The plans are on our pricing page.

FAQ