What the EU AI Act is mapped to,
and why it differs from GDPR.
AI Act requirements are mapped across 8 frameworks. Only 2 of them are shared with GDPR — the rest exist because the Act regulates failure modes that no general-purpose security framework describes.
Not GDPR plus extras — a different application-security set.
It would be reasonable to assume the AI Act inherits everything GDPR maps to and adds AI frameworks on top. It does not. The two share exactly 2 frameworks — the cloud foundation and the security programme — and then diverge. The classic web OWASP Top 10 is not in the AI Act set; AI-specific families take its place, because the application-layer risks of an AI system are not the application-layer risks of a web app.
Put in layers, the overlap is exact: the two regulations share the foundational layer and nothing above it. A team already implementing GDPR has the foundation — not the work.
The Act blends three kinds of obligation, so the mapping spans three layers.
The AI Act asks three different things at once: how you govern an AI system, how you defend the AI itself, and whether the systems underneath are secure at all. No single framework covers all three — which is why the set looks long, and why there are four separate OWASP lists rather than one.
AI governance & risk management
How you run an AI system responsiblyNIST AI RMF
Risk management, in the AI Act’s own shapeArticle 9 requires a risk management system across the lifecycle — not a one-off assessment. NIST AI RMF is the framework built for exactly that: govern, map, measure, manage. It is the closest structural match to what the Act actually asks for.
AI-specific security
What goes wrong with this AI system specificallyOWASP GenAI / LLM Top 10
Generative and LLM-specific failure modesPrompt injection and insecure output handling have no analogue in the classic web Top 10. For any system with a generative component, this is where transparency and robustness obligations actually land.
OWASP Agentic Top 10
Systems that act, not just answerHuman oversight under Article 14 is materially harder when the system takes actions. The agentic risks — excessive autonomy, unsafe tool use — are the concrete form that oversight obligation takes.
OWASP MCP Top 10
The tool and context layerWhere an AI system reaches external tools and data through a protocol layer, that boundary is its own attack surface. It carries the provenance and access questions the Act asks about data governance.
OWASP ML Top 10
Classical ML, not just generativeMuch of what the Act regulates is not generative at all — scoring, classification, biometric systems. This covers the traditional ML failure modes those systems carry.
MITRE ATLAS
Adversarial threats specific to MLAccuracy, robustness and cybersecurity under Article 15 include attacks that classic security frameworks do not describe: data poisoning, model evasion, extraction. ATLAS is the adversarial-ML taxonomy, so those obligations map to named techniques rather than generic hardening advice.
Foundational security
The AI still runs on infrastructureCloud Security (AWS, Azure, GCP)
The system still runs somewherealso GDPRAn AI system is a deployed system first. Logging, access control, and data residency obligations resolve to the same cloud primitives as any other workload, so the foundation carries over unchanged.
NIST CSF
The security programme underneathalso GDPRThe AI Act assumes a functioning security posture and builds on top of it. NIST CSF covers that base layer, so AI-specific controls sit on something an auditor already recognises rather than starting from nothing.
Choosing these is the regulatory-engineering work, not a default. The AI Act ships no control catalogue of its own, so we mirrored the structure of the Act itself rather than force-fitting one infosec framework that was never built for AI risk.
These frameworks are young, and we would rather say so.
GDPR’s control landscape has had decades to settle. The AI-specific frameworks above have not. OWASP’s GenAI, Agentic and MCP lists emerged between 2023 and 2025 and are still being revised; NIST AI RMF is 2023; MITRE ATLAS updates continuously. The industry has not converged on stable AI control catalogues — because everyone, including the framework authors, is still building them.
So we are straight about our own work: an AI Act mapping today is a well-reasoned starting point against a moving target, not a settled control set. That is the honest state of AI governance in 2026, and a buyer who knows the field already knows it. Our answer is the thing we sell anyway — we map to the current framework versions, record when we did it, and update as they mature, so you work from the latest reasoned mapping rather than a snapshot that quietly went stale.
Which obligations apply depends on your role.
The AI Act assigns obligations by actor — provider, deployer, importer, distributor — and the mapped work differs sharply between them. The AI Act hub breaks the obligations out by role before any of this becomes implementation work.
In scope for both regulations?
The GDPR mappings page covers the shared foundation. Reading the two together shows which work is common and which is genuinely new.