AI-Assisted Development under GDPR, NIS2 and DORA

The moment you attach a coding agent to your codebase, you touch three regulatory regimes at once.

Not because AI is separately regulated — the AI Act is its own story — but because AI tooling touches existing rules in places your delivery pipeline never had to think about. You send code to a third party. You pull in dependencies nobody chose by hand. You change what proposes a production change.

This article covers the engineering side. It is not legal advice — for the precise scope in your situation you need your own counsel or compliance officer.

There is immediate confusion here, and it is sharper at ZEN because we use both meanings daily.

• GDPR (AVG in Dutch) — covers personal data: what you process, why, and where it ends up.
• NIS2 — the EU directive on cybersecurity for essential and important entities. Emphasises risk management, supply-chain responsibility and incident reporting. National transposition has run late in several member states, the Netherlands included, so check the current status before planning against a date.
• DORA — two different things. The Digital Operational Resilience Act applies to the financial sector and covers ICT risk and your reliance on third-party ICT providers. DORA metrics are the four delivery measures from DevOps research. They are unrelated, and in any meeting with both compliance and engineering in the room, that is five minutes well spent.

The rules are not new. What changes is where they land.

Previously your code went from repository to pipeline to production, entirely inside boundaries you drew. With a coding agent, part of that code — and sometimes the context around it — goes to a service you do not operate. That is not a catastrophe, but it is a processing activity and a dependency, and you need to be able to name both.

The core question is not "do we use AI" but "what are we sending".

Code itself is usually not personal data. The context around it can be: a test fixture with real customer names, a stack trace containing email addresses, a database dump somebody pasted in to look something up, a log file attached to explain a bug.

What you practically want to know:

• Which tooling sends what outside? IDE plugins, CI integrations and agents differ substantially in what they transmit.
• Where does processing happen? Region and sub-processors matter, exactly as with any other cloud service.
• Is your input used for training? Usually switchable on business plans, but it is a deliberate decision somebody has to make and record.
• Are those tools in your processing register? If AI tooling is widely used but recorded nowhere, that is the first gap anyone will notice.

NIS2 puts significant weight on supply-chain security. An AI coding assistant with write access to your repositories, or one running inside your pipeline, is part of that chain.

So the questions you already ask other vendors apply here: what access does this have, what happens if it fails or is compromised at their end, and how would we find out?

One thing is specific to AI tooling: dependencies nobody chose. If an agent proposes a package and it passes review, a supplier has been added to your chain by a model. That is exactly the kind of decision NIS2 wants visible — so do not leave your dependency scanning and your approval route for new packages untouched as volume rises.

If you fall under the Digital Operational Resilience Act, the bar moves from "we have a policy" to "show me".

You need to be able to show which third-party ICT services you rely on, what risks attach to them, and how your system behaves when something fails. An AI coding service involved in producing your production code belongs in that register.

The practical consequence is documentation that is not separate from your system: which tooling was involved in a change, who approved it, and evidence that your controls actually ran. Pulled out of your pipeline, that is not extra admin. Reconstructed by hand afterwards, it is a great deal of work.

Four things that serve all three regimes at once, none of them expensive:

1. Record which AI tooling runs where, and what it may do. One register, with access and processing location. This is the first document anyone asks for.
2. Flag AI-assisted changes. A PR-level marker is enough. It makes both your risk conversation and your impact measurement possible — without it, both are guesswork.
3. Automate your controls in the pipeline. Dependency scanning, secret detection, infrastructure policy checks. As code volume rises this is the only thing that scales; manual review does not.
4. Keep the evidence that those controls ran. Not because a regulator enjoys it, but because "we always scan" is not an answer and a pipeline log is.

AI tooling rarely introduces a new regime. It relocates existing obligations into your delivery pipeline, where they were not before.

GDPR is about what you send. NIS2 is about who is in your chain, including the dependencies a model proposed. DORA is about whether you can evidence it.

All three converge on the same point: knowing what happens in your pipeline, and being able to show it. Which is precisely why measurement is not a compliance exercise but ordinary good engineering — and why, now that code is cheap, it is the part that matters.