GDPR and the Cyber Resilience Act are asking for the same thing

Here is a question most regulated companies cannot answer quickly: how much of your compliance work are you doing twice?

Not because anyone is careless. Because regulations arrive one at a time, each as its own document, each with its own vocabulary, each landing on a different desk. GDPR is the privacy team's problem. The Cyber Resilience Act is the product security team's problem. NIS2 belongs to someone else again. So you build three programmes, three sets of controls, three audits — and nobody notices that large parts of them are the same work wearing different words.

The same duty, three disguises

Take logging. Keeping a trustworthy record of security-relevant events.

GDPR asks for it, in the language of "security of processing" and accountability — you must be able to demonstrate what happened to personal data. The Cyber Resilience Act asks for it, in the language of secure-by-design products and vulnerability handling — you must be able to detect and record security-relevant events in the things you ship. NIS2 asks for it again, in the language of incident detection and reporting.

Three regulations. Three teams. Three audits. One underlying capability: you can produce a reliable, tamper-evident log of security-relevant events, and prove it.

If your compliance lives in documents, those three duties never meet. They sit in separate PDFs, separate spreadsheets, separate heads. You implement logging three times, or — worse — you implement it twice and assume the third is covered.

Why a graph sees what a document can't

This is the bet behind the compliance system I've been building: compliance is not a document problem, it is a graph problem.

When you model it properly, a regulation isn't a PDF. It's a set of obligations — who must do what. Each obligation points at the capability it requires. And different obligations, from different regulations, written in different decades, point at the same capability node.

So "security of processing" from one regulation and "security logging" from another stop being two unrelated paragraphs in two unrelated files. They become two edges arriving at one node. And the instant you can see that, two questions become answerable that were previously guesswork:

Where am I doing the same work twice? (The capabilities with many obligations converging on them — build once, satisfy several.)
Where is there an obligation with no capability behind it? (The gaps. The things you are legally required to do that nothing in your organisation actually does.)

That second question is the one that keeps compliance officers up at night, and it is almost impossible to answer from a stack of documents. It is a single query against a graph.

The part I refuse to compromise on

There is an obvious failure mode here: I could let an AI "read" the regulations and cheerfully tell you GDPR and the CRA are the same, and it might be confidently wrong.

So the system doesn't work that way. The regulations are ingested from the EU's own authoritative source, not scraped from PDFs. Every claim the system makes — this obligation maps to that capability, this capability has no control behind it — traces back to the specific article that backs it. An assertion with no traceable source is treated as what it is: an unverifiable assertion, which is to say, not an answer.

The AI's job is to help you ask the question and read back what the graph returned. The graph is the source of truth. That distinction is the whole ballgame in a regulated world.

The takeaway

If you are standing up compliance for the AI Act on top of what you already did for GDPR, CRA and NIS2, the worst thing you can do is start a fourth programme from a blank page. Most of the duty is already somewhere in your organisation, under a different name. The work is not to do it again — it's to see where it already converges, and where it genuinely doesn't exist yet.

You can't see that in a document. You can see it in a graph.

I'm Tete Mensa-Annan. I ran the software engineering platform at a regulated pharma and now help engineering and compliance leaders adopt AI without losing control of it. If "are we covered, and can we prove it?" is a question you can't answer quickly, that's usually a modelling problem, not an effort problem — and I'm happy to talk about where yours lives.