Legislation · 11 Oct 2024 · Rob Nidschelm

The AI Act Does Not Replace GDPR: How Europe’s Digital Rules Fit Together

The EU AI Act has changed the governance of artificial intelligence, but it has not created a self-contained rulebook. When an AI system uses personal data, supports a critical service or operates inside a financial entity, several European laws can apply at once.

This is one of the easiest things to misunderstand about AI regulation.

An organisation identifies an AI use case, determines its category under the AI Act and assumes the legal analysis is largely complete. In reality, the AI Act sits beside existing rules. GDPR continues to govern personal-data processing. NIS2 addresses the resilience of essential and important entities. DORA creates specific operational-resilience requirements for the financial sector.

The same system may therefore need to satisfy several obligations for different reasons.

Consider an AI tool used by a bank to support credit decisions. The AI Act may classify the use as high risk. GDPR may apply because personal data is processed and people are affected by automated analysis. DORA may apply because the system supports a financial service and depends on ICT infrastructure or providers. Security, privacy, model governance and operational resilience are all part of the same service, even if the organisation assigns them to different teams.

The challenge is not choosing which law applies. It is designing one governance model that can show how all of them are addressed.

What the AI Act adds

The AI Act uses a risk-based structure. Some practices are prohibited. Certain systems are treated as high risk and face extensive requirements. Other AI systems carry transparency obligations, while many lower-risk uses remain subject mainly to existing law and voluntary practices.

The categories are helpful, but classification is only the beginning.

An organisation also needs to understand its role. A company developing and placing an AI system or general-purpose AI model on the European market may be a provider. An organisation using an AI system under its authority may be a deployer. Importers, distributors, authorised representatives and product manufacturers can have additional responsibilities.

The role can change the obligation more than the technology does. Two organisations may use the same model through different arrangements and have different duties.

The AI Act also introduces governance requirements that were often missing from informal AI projects: documented risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity and post-market monitoring for relevant systems.

Most of these are not entirely new security or quality concepts. What is new is that they must be applied consistently to AI and, in many cases, demonstrated.

GDPR remains fully applicable

The AI Act does not weaken or displace GDPR. European data-protection law remains applicable whenever personal data is processed during the lifecycle of an AI system.

That lifecycle can include data collection, preparation, training, fine-tuning, testing, prompting, retrieval, output generation, monitoring and retention. Personal data may appear in more places than the final user interface suggests.

GDPR asks questions that an AI Act classification does not answer:

• What is the purpose of the processing?
• What is the lawful basis?
• Is all of the personal data necessary?
• Were individuals given clear information?
• How long will input, output and logging data be retained?
• Can people exercise access, correction, deletion or objection rights?
• Is a data-protection impact assessment required?
• Are personal data transferred outside the European Economic Area?
• Does automated decision-making significantly affect a person?

An AI system can be compliant with one aspect of the AI Act and still violate GDPR because it collected unnecessary data, used it for an incompatible purpose or failed to protect an individual’s rights.

Where the rules reinforce each other

The overlap is not always duplication. Many controls can support several legal requirements at the same time.

Data inventories

GDPR requires organisations to understand personal-data processing. AI governance requires knowledge of the data used to develop and operate systems. A shared inventory can record datasets, sources, purposes, legal bases, retention, quality, sensitivity and access.

The inventory should also capture prompts, retrieval sources and generated outputs. In generative AI, these can be as important as the original training data.

Transparency

GDPR requires clear information about personal-data processing and certain automated decisions. The AI Act creates additional transparency requirements, including informing people in specific circumstances when they interact with AI or encounter AI-generated or manipulated content.

One notice may need to answer both questions: what is the AI doing, and what happens to the person’s data?

Security by design

GDPR requires appropriate technical and organisational measures to protect personal data. The AI Act addresses robustness and cybersecurity for relevant AI systems. NIS2 and DORA add resilience and risk-management requirements in their respective scopes.

Shared measures may include controlled access, secure development, data separation, model evaluation, vulnerability management, supplier assurance, monitoring and incident response.

Accountability and evidence

All of these frameworks reward the same discipline: important decisions should be traceable. An organisation should be able to show who approved a use case, how it was classified, which risks were accepted, which tests were performed and what changed after deployment.

NIS2 changes the infrastructure conversation

The AI Act can make teams focus on the model. NIS2 forces a wider view of the service.

If an organisation in a critical sector depends on AI, it must consider the network and information systems, suppliers and operational processes around that AI. The model may be hosted by a cloud provider, accessed through an API, connected to internal data and embedded in a workflow that supports essential services.

Security questions then include:

• Can the service continue if the model provider is unavailable?
• How are compromised credentials or API keys detected?
• Can a malicious input influence connected tools or data sources?
• Which supplier must report an incident, and how quickly?
• Is there a tested fallback that does not depend on the same provider?
• Can the organisation reconstruct what the system did during an incident?

NIS2 also brings management accountability and supply-chain risk into the discussion. An AI pilot can stop being a local innovation experiment once it becomes part of an important operational process.

DORA adds financial operational resilience

For financial entities, DORA goes further into ICT risk, incident management, resilience testing and third-party oversight.

An AI service used in fraud detection, customer authentication, trading support, credit assessment or service operations may support a critical or important function. The organisation then needs to understand not only whether the model performs well, but how the service fails.

This includes conventional outages and cyberattacks, but also AI-specific failure modes: model drift, corrupted retrieval data, unexpected provider changes, unsafe automation, prompt injection, inaccurate outputs and loss of traceability.

A system can remain online and still be operationally unsafe. Availability alone is not resilience.

Build one control map instead of four programmes

The worst response to overlapping laws is to create a separate governance process for each one. That produces repeated questionnaires, inconsistent inventories and multiple risk assessments for the same system.

A better approach begins with the AI use case and maps obligations around it.

Step 1: Describe the real service

Record what the system does, who uses it, which decisions it influences, what data it processes, which systems it can access and what happens when it is wrong or unavailable.

Step 2: Determine legal and operational roles

Identify provider, deployer and other AI Act roles. Separately identify GDPR controller and processor roles, the entity’s NIS2 or DORA status, and relevant suppliers.

Step 3: Classify impact

Assess the AI Act category, privacy risk, critical-service impact, security exposure and potential harm to individuals or society. Do not allow a low AI Act category to hide high privacy or operational risk.

Step 4: Map shared controls

Connect each risk to controls that can satisfy multiple requirements. A well-designed logging control may support security monitoring, human oversight, incident investigation and accountability. Supplier due diligence may support AI governance, GDPR processor oversight, NIS2 supply-chain security and DORA third-party risk.

Step 5: Assign evidence owners

Every important control should have an owner and a source of evidence. If an organisation says human oversight exists, it should be able to show where a person can intervene, what information they receive and whether intervention has been tested.

Step 6: Monitor change

AI systems change through new models, prompts, datasets, integrations and user behaviour. A use case that was low risk during a pilot may become materially different after it is connected to production systems or allowed to act automatically.

Governance must follow the deployed system, not the original presentation.

The useful question is not “Are we AI Act compliant?”

That question is too narrow.

The better question is: Can we explain and demonstrate how this AI-enabled service remains lawful, secure, resilient and accountable throughout its lifecycle?

Answering it requires privacy, security, legal, risk, technology and business teams to work from the same description of the system. It also requires the organisation to recognise that compliance is not a property of the model alone.

AI operates inside an environment of data, infrastructure, people, suppliers and decisions. European regulation increasingly reflects that reality.

The organisations that handle the overlap well will not be those with the most separate committees. They will be those that turn several legal requirements into one coherent way of designing and operating technology.

Sources and further reading

• Original Getronics article: Navigating the EU’s AI Legislation
• European Commission: AI Act
• European Commission: Principles of personal-data processing under GDPR
• EDPB: Statement on data-protection authorities and the AI Act
• European Commission: NIS2 Directive
• ESMA: Digital Operational Resilience Act

This article provides general technical and operational context, not legal advice.