Most companies assume their AI coding tool is GDPR-compliant because it has a privacy policy. But the questions that actually matter are: Where does my code go? Does it train AI models? And do you have a Data Processing Agreement?
When the DPO Calls
Every CTO who takes AI-assisted development seriously eventually gets a visit from the Data Protection Officer. The conversation usually starts innocuously enough: Which tools are your developers using? Copilot? Cursor? Claude? Then comes the question almost nobody is prepared for: Where is your code being processed — and who can see it?
This isn't theoretical. Germany's Data Protection Conference (DSK) — the consortium of German supervisory authorities that issues guidance under EU GDPR — published concrete guidelines on AI deployment in 2024. They explicitly favor closed systems that don't share data with third parties, and require a documented legal basis for every data processing activity. Answering "we have a privacy policy" won't cut it. Neither will it for UK companies post-Brexit or for US businesses with EU customers subject to GDPR.
Three questions separate teams that have actually thought this through from everyone else.
Klingt interessant?
Question 1: Where Does My Code Go?
For GitHub Copilot Business and Enterprise, the answer is clearly documented: Microsoft processes requests on global Azure infrastructure — without specific EU data residency guarantees for Copilot. If you're on the Free or Pro tier, you don't even get a Data Processing Agreement (DPA); the GitHub privacy policy applies, and prompts may be used for training improvements unless you actively opt out.
Cursor's situation is less well-known but at least as significant. Even if you plug in your own API key, requests still route through Cursor's own backend — this is explicitly documented in their privacy documentation. Inference providers like Baseten, Together AI, and Fireworks (all US-based) can temporarily store model inputs. EU data residency isn't an option at all.
Anthropic processes Claude requests on US infrastructure by default. An EU data residency option exists for Enterprise customers, but it's not the default and must be explicitly negotiated.
This matters for a concrete reason: if your code lands in a US data center, US law applies — including FISA Section 702, the US intelligence statute that compels American cloud providers to grant government agencies access to data on request. Standard Contractual Clauses (SCCs) can't fully eliminate this risk, as the European Court of Justice made clear in its Schrems II ruling. For EU-based companies, this creates real legal exposure. For US companies with EU customers, it's a compliance gap worth closing before regulators notice it.
Question 2: Does My Code Train AI Models?
This is the question most CTOs never think to ask — and for companies with proprietary code, it's existential.
With GitHub Copilot Free and Pro, the default answer is yes: prompts and suggestions can be used for model improvement. There's an opt-out buried in account settings, but an opt-out is not the same as a contractual exclusion, and it has to be set actively. Business and Enterprise customers are in better shape: GitHub explicitly excludes training on customer data at those tiers and offers a downloadable DPA.
With Cursor, everything hinges on "Privacy Mode." If it's disabled — which, reportedly, may be the default state for accounts created after October 15, 2025 — code data, prompts, and editor actions can be used for AI training. Enable Privacy Mode and you get zero data retention. If your developers don't know to check this, they may be contributing your production code to Cursor's next model release right now.
This isn't a minor concern. Proprietary code that flows into a training set could — in fragments — resurface for other users. Whether that's realistically likely is a separate debate. Whether you've contractually excluded it is a compliance question with a clear answer: you haven't, unless the DPA says so explicitly.
Question 3: Do You Have a DPA — and Does It Cover What It Needs To?
A Data Processing Agreement under Art. 28 GDPR is mandatory the moment a service provider processes personal data on your behalf. Code itself is rarely personal data — but test fixtures with real customer records, inline comments, commit messages, and configuration files can all qualify.
GitHub offers a freely downloadable DPA for Business and Enterprise customers that explicitly covers Copilot. That's genuinely good practice by market standards. Cursor has a DPA, but no publicly accessible, immediately usable version in the same vein. Many smaller tools have nothing at all.
A solid DPA must cover: the purpose and duration of processing; a list of sub-processors with their locations; technical and organizational measures (TOMs); and — this is the core requirement — an unambiguous statement that data will not be used to train third-party models. A DPA that glosses over that last point, or phrases it vaguely, doesn't protect you.
What GDPR-Compliant Actually Means
GDPR compliance in AI development isn't a checkbox. It's an architecture question: Where does the model run? Who can access the prompts? Does code leave your own infrastructure at all?
That's the starting point for nopex. The platform wasn't retrofitted for compliance after the fact — EU infrastructure, no training on customer data, and an available DPA are part of the architectural design. Code doesn't leave your infrastructure without a clear reason; data processing happens within the EU. That's not a claim you have to take on faith from a privacy page — it's documented and contractually binding.
For companies adopting AI-assisted software development without wanting to spend three hours with a lawyer discussing FISA 702 and sub-processor chains, that's the practical difference.
Want to see how nopex implements GDPR compliance in practice? Get in touch
