GDPR DPAs for AI Coding Tools: What Article 28 Requires

TL;DR: Your AI coding tool can touch real user data. A prompt. A log. A debug session. An exported file. If it does, it may be processing personal data on your behalf. Under GDPR Article 28, that makes it a processor, and you need a Data Processing Agreement (DPA) with it. Most established tools (Lovable, Bolt, Cursor, Replit, v0.dev, Claude Code) now publish one. The DPA has to cover eight specific things. What's being processed. How long. Under what instructions. Who else touches it. And what happens when you stop using the tool. Check your vendor's DPA against that list. If it's missing pieces, or the vendor has none, that's a real gap, not paperwork you can skip.

A founder ships a working SaaS built with an AI coding tool. The signup flow works. The dashboard works. Then a customer's procurement team sends a security questionnaire. One line stops the deal: "Please provide your data processing agreements with all sub-processors." Nobody on the founding team has ever asked their AI coding tool for one. That's not a rare story. It's the default, because DPAs live in a vendor's legal page, not in the tool's UI.

GDPR Article 28, in plain terms

GDPR splits every organization handling personal data into two roles. You're the controller if you decide why the data is collected and what happens to it. A vendor is a processor if it handles that data only on your instructions, for your purposes. Article 28 sets the rules for that second relationship. It requires a written contract, the DPA, whenever a controller uses a processor.

The question that decides this isn't "did I use AI to write code." It's narrower. Does the tool ever receive personal data while it works? Does it process that data for you? If your prompts, logs, or debug sessions never include a real customer's information, the processor question may not apply to that tool. Most teams find at least one tool where it does — often without realizing it.

• Controller: you. You decide why and how personal data gets used in your product.
• Processor: a vendor that handles that data only on your documented instructions.
• DPA: the contract that binds the processor to those instructions and sets the ground rules.

Where AI coding tools quietly become processors

Founders underestimate this because the risk doesn't look like a data breach. It looks like ordinary work. A support engineer pastes a real customer's error log into an AI coding assistant to debug an issue. A founder exports a database snapshot to test a migration and runs it through an AI tool. A prompt includes a real user's name and email as a test case, because that was the fastest way to check the fix.

None of that is unusual. All of it can turn a coding assistant into a processor for that session. The tool doesn't have to be built for handling personal data. It just has to receive some, while working on your behalf. That's what triggers Article 28, regardless of which platform you're using: Lovable, Bolt, Cursor, Replit, v0.dev, and Claude Code all fall under the same test.

The processor test you can run yourself

You don't need a lawyer to do this first pass. Four questions, in order:

1. Does the tool ever receive personal data from you? Names, emails, account IDs, or anything in a log or prompt that could identify a real person counts.
2. Does it process that data on your behalf? If the tool is helping you build or run your product, this is usually yes.
3. Can you write down your instructions to it? If you can't explain what you've told the vendor to do with that data, you don't have a defensible Article 28 story yet.
4. Does the vendor use sub-processors? Cloud hosting, model providers, and analytics tools often sit behind the tool you signed up for. Your DPA needs to account for them too.

If the answer to the first two questions is yes, treat the vendor as a processor and go find their DPA. If you can't find one on their site, that's your answer on whether to ask for one directly.

What a compliant DPA actually has to include

This is the checklist to run against any vendor's DPA, including your AI coding tool's. GDPR Article 28(3) lists these requirements specifically:

A DPA missing several of these isn't a minor gap. It means you can't actually show a regulator, or a customer's security team, that the vendor relationship is under control.

How to request a DPA without losing a week to it

Check the vendor's site first. Search "[tool name] DPA," or look under their legal or trust page. Most established AI coding tools publish a standard one you can accept directly. Often with no back-and-forth needed. If you can't find one, send a specific written request rather than a vague one:

Request: "Please provide your Data Processing Agreement under GDPR Article 28, covering the personal data your tool may process while we use it for development. We need it to address processing instructions, security measures, sub-processor notice, deletion or return of data, and audit rights."

• Ask for the current version and its effective date, not an old PDF someone forwards you.
• Ask directly whether any data you share is used to train models, and how to opt out if so.
• Ask for their sub-processor list, and how you'll be notified if it changes.

If a vendor won't sign

Some vendors offer only their standard terms with no room to negotiate. That's not automatically a dealbreaker — it becomes one if those terms are missing the Article 28 essentials above. Here's the order to work through it:

1. Compare their terms to the checklist. If the gaps are small, that's a negotiation, not a blocker.
2. Push on the specific missing clauses, especially sub-processor notice and deletion timelines — these are the two most commonly weak spots.
3. Restrict what that tool ever sees, if you can't get better terms. Keep real user data out of prompts and logs sent to it.
4. Switch vendors, if the tool is central to how you handle personal data and the vendor won't move. It's disruptive, but shipping without an enforceable agreement is a standing compliance gap, not a one-time risk.

A signed DPA isn't the finish line

A DPA governs your vendor, not your product. It doesn't check whether your app actually deletes a user's data when asked. It doesn't check whether your database enforces the access limits your privacy policy claims. And it doesn't check whether an AI feature you shipped needs its own disclosure under the EU AI Act. Those are code and configuration problems, not contract problems. And an AI coding tool won't flag them for you, any more than it flagged the DPA question itself.

This is where the two sides of readiness meet. Our GDPR compliance guide for vibe-coded apps covers the product-side checklist — consent records, retention limits, and deletion flows. Our data mapping guide walks through tracing where personal data actually flows once it enters your system. That's the fastest way to spot an undisclosed processor. And if your app has an AI feature EU users interact with, our EU AI Act compliance guide covers when a separate disclosure applies.

If you're managing this across more than one vendor

Once you're tracking DPAs, sub-processors, and renewal dates across five or six vendors, a spreadsheet stops scaling. Compliance automation platforms exist to manage exactly this. If you're evaluating that category, see how we compare to Thoropass, which pairs automation with audit support. Or see our comparison with generic AI compliance tools that promise instant certification. Either can help you track vendor paperwork at scale. Neither one checks whether your own application code matches what that paperwork claims.

What to run next

Start by pulling the DPA for every AI coding tool your team actively uses, and run it against the eight-item checklist above. Then check that your app's own behavior matches your privacy policy: does deletion actually delete, does access actually stay scoped to the right user? A free scan against your live URL is the fastest way to see the technical side of that gap. If it turns up anything serious, our Launch Readiness Audit gets a security engineer to verify it. You get a fix list, not just another finding.

FAQ