GDPR & the EU AI Act: digital compliance in 2026

GDPR has governed personal data since 2018. The EU AI Act, phased in since 2024, now governs AI systems according to their risk level. The two texts overlap substantially — an AI system that processes personal data is subject to both — and many organizations discover this double constraint only when industrializing their first AI use cases, rather than anticipating it at design time.

What GDPR requires, concretely

GDPR rests on principles that AI hasn't changed, but has made mechanically harder to respect: data minimization, explicit purpose of processing, limited retention period, and rights of access, rectification and erasure enforceable by the person concerned. A language model trained on or fed with personal data complicates each of these principles — erasing a piece of data from a vector index is technically different from erasing it from a relational database, and this needs to be planned at design time rather than discovered when an erasure request arrives.

What the AI Act adds

The AI Act classifies AI systems into risk levels — unacceptable, high, limited, minimal — with obligations proportionate to each level. A high-risk system, for example a tool that influences a hiring or credit decision, requires complete technical documentation, effective human oversight and traceability of decisions. Most internal assistance or productivity uses fall under more limited risk, but the classification itself must be documented and justified — the absence of analysis is itself a compliance gap.

Where these obligations translate into architecture

Three design choices concentrate most of the compliance risk. Decision traceability: a system that influences a decision must be able to explain, after the fact, which data and which logic it relied on. Governance of training and context data: knowing precisely which data feeds a model, under what legal basis, is a prerequisite, not an option. And human oversight: high-risk cases require a real human checkpoint, not a checkbox in an interface.

These three choices are made at architecture time, not at audit time. A system designed without traceability costs significantly more to bring into compliance after the fact than one that builds it in from the start.

Continuous governance, not a one-off audit

The temptation is to treat compliance as a project, with a beginning and an end. Both GDPR and the AI Act keep evolving — new guidelines, new case law, new use cases that change an existing system's risk classification. Durable compliance looks more like continuous governance, built into the architecture's lifecycle, than an annual audit that starts from zero every time.

• GDPR and the AI Act overlap as soon as an AI system processes personal data.
• The AI Act's risk classification must be documented, even for limited-risk uses.
• Decision traceability, data governance and human oversight are the three key workstreams.
• These choices are made in the architecture, not as a patch after an audit.