How do EU AI Act obligations differ from GDPR in AI programmes?

Why EU AI Act and GDPR Controls Split Along Different Lines

The two regimes regulate different failure modes, so the control set should not be blended into one generic “AI compliance” checklist. The eu ai act is about how an AI system is designed, classified, deployed and monitored across its lifecycle, while GDPR is about whether personal data is processed lawfully, fairly and securely. That distinction matters even when the same model and the same dataset sit inside one programme.

EU AI Act regulatory framework is the best starting point when the programme question is risk classification, prohibited practices, high-risk duties or documentation obligations. GDPR becomes the governing lens as soon as the system ingests, infers from, stores or exposes personal data, especially where training data, prompts, logs or outputs can identify a person.

EU AI Act Compliance Guide is useful for turning that distinction into programme structure: one workstream for system obligations, another for data-protection obligations, with clear ownership instead of one team assuming the other has covered everything. The practical consequence is that a model can be compliant on AI governance and still fail privacy law, or be privacy-conscious and still miss AI Act duties.

What Each Regime Demands from an AI Programme

Under the AI Act, the programme has to ask what the system is for, who deploys it, what risk category it falls into, and what controls are needed around transparency, human oversight, technical documentation, logging, testing and post-market monitoring. Under GDPR, the programme has to ask what personal data is processed, on what legal basis, for which purpose, with what retention, access, minimisation, transfer and subject-rights controls. The same AI use case may therefore need two separate decision records.

ISO/IEC 42001:2023 AI Management System Standard fits here because it gives organisations a governance shell for the AI-side obligations: roles, accountability, risk treatment and continual improvement. For GDPR-specific programmes, EU General Data Protection Regulation (GDPR) remains the reference for processing principles, data protection by design and default, security of processing and DPIAs.

AI and Privacy Guide is the natural bridge when the practical problem is not abstract law but training data, model memorisation, automated decisions and the privacy effects of AI outputs. In real programmes, this is where teams discover that the AI Act may demand one kind of evidence, while GDPR demands a different kind of evidence about lawful processing and individual impact.

How to Run Both Regimes Without Collapsing Them into One Review

A workable approach is to separate the programme into two control maps that meet at defined handoffs. The AI Act map should cover system inventory, intended use, risk classification, oversight, transparency, logging and incident handling. The GDPR map should cover data mapping, lawful basis, notices, retention, DPIA, DSAR handling, vendor processing terms and security measures. Where the same control satisfies both regimes, document it once and reference it twice, rather than duplicating effort.

AI Governance Guide helps when teams need the operating model around those handoffs, especially committees, use case registers and decommissioning decisions. For privacy operating detail, NIST Privacy Framework adds a useful structure for privacy risk management, even though it does not replace GDPR obligations.

For programmes that process personal data at scale, the key discipline is evidence separation. Keep AI Act artefacts that show how the system was governed, tested and monitored, and keep GDPR artefacts that show why the processing was lawful, proportionate and protected. That separation shortens audits and prevents teams from mistaking an AI risk review for a privacy compliance assessment.

Risk and Threat Considerations

When AI programmes blur the two regimes, organisations usually fail in one of two ways: they over-focus on model governance and miss unlawful data use, or they over-focus on privacy paperwork and miss system-level risk, transparency and monitoring obligations. That creates exposure both to regulatory action and to operational failure if the AI is deployed before its data flows and lifecycle controls are settled.

Failure mechanism: The same use case is assessed only once, so personal data handling, automated decision impacts, logging, retention and third-party sharing are never tested against the correct legal standard.

Impact: The programme can ship with a false sense of compliance, leaving the organisation exposed to enforcement, rework, user complaints and a wider trust failure if the AI makes decisions faster than the governance model can correct them.

Practitioner Guidance

What to prioritise: Start by splitting each AI use case into two registers, one for AI Act obligations and one for GDPR processing activities. If you cannot show both, you do not yet have a complete compliance picture.

What to verify: Check whether the deployment decision, the data flow decision and the automated decision decision are being owned separately. If the same reviewer signs off all three without distinct evidence, the programme is probably under-controlled.

Practitioner takeaway: The strongest programmes do not try to force one regime to cover the other, they build a shared operating model with separate legal tests, separate evidence and one coordinated delivery process.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Compliance Guide
• Why do identity governance programmes need stronger controls when they intersect with EU data sovereignty and GDPR or AI Act compliance?
• How should organisations handle EU AI Act compliance when deadlines are split across different obligations?
• How should enterprises prepare for EU AI Act compliance in regulated AI programmes?
• How do EU AI Act requirements differ from traditional security controls in practice?