Key Takeaways
- The greatest challenge for GDPR practitioners approaching the AI Act is often not learning a new set of rules, but recognising where familiar assumptions about compliance no longer apply.
- While GDPR focuses on the lawful and responsible processing of personal data, the AI Act focuses on the risks posed by AI systems themselves, leading to different compliance obligations and governance priorities.
- High-risk classification under the AI Act extends beyond questions of data processing and requires organisations to consider both the intended purpose of a system and, in some cases, the context in which it is deployed.
- Many AI Act obligations are ultimately obligations to produce evidence, requiring organisations to demonstrate that risks have been assessed, controls are operating effectively, and accountability has been clearly assigned.
- The AI Act treats compliance as an ongoing operational responsibility rather than a one-time assessment exercise, requiring continuous monitoring, documentation, and oversight throughout the lifetime of high-risk AI systems.
When the EU AI Act entered the picture, many organisations immediately started looking for parallels with GDPR because GDPR has been the benchmark for regulatory compliance across Europe for years. However, there are some important differences that can catch organisations off guard.
To begin with, GDPR fundamentally changed the way we thought about compliance by shifting the focus towards data flows and data governance. As a result, organisations have become accustomed to asking the same core questions whenever a new project is introduced: Where does the personal data come from? Who receives it? What is the lawful basis for processing it? Is it secure? Are people properly informed about how their data is being used?
In the AI era, this way of thinking still matters because GDPR applies in full whenever an AI system processes personal data. But while the AI Act builds on many of the instincts developed under GDPR, it adds a second layer of scrutiny by requiring organisations to look beyond the data itself and examine the systems that operate on that data. Therefore, the question is no longer limited to whether personal data is processed correctly but extends to how AI systems behave once the data is put to use.
This distinction is more significant than it first appears because an AI system may process personal data lawfully, securely, and transparently while still producing biased, misleading, unreliable, or harmful outcomes. Furthermore, the privacy documentation may be impeccable, yet the system itself may create risks that emerge only after deployment. In many ways, this possibility sits at the centre of the AI Act’s logic.
So, with the AI Act, we actually get to ask: Can we trust the system itself? Can we explain how it arrived at a particular outcome? Can we stop it from quietly drifting in a direction nobody intended?
Before going further, it’s worth calling out what may be the most dangerous assumption people bring to this framework after years of working with GDPR, namely that risk follows the data. Under GDPR, risk is often closely associated with the sensitivity of data being processed. Special category data triggers heightened obligations, which naturally encourages organisations to view data type as one of the primary indicators of regulatory risk. That means if you’re not processing special category data, your obligations are lighter; if you’re, they’re heavier.
The AI Act challenges that by taking a different approach to risk, though data governance still matters significantly, particularly when it comes to managing training and validation datasets for bias and representativeness. In practice, however, a system processing no personal data whatsoever can still be classified as high-risk under Annex III if it operates in a sensitive domain, such as employment, credit scoring, or law enforcement.
Conversely, a system processing substantial volumes of sensitive personal data may sit outside the high-risk categories entirely if its use case doesn’t fall within those domains. The implication? GDPR-trained instincts may point organisations towards the wrong classification outcome, and the organisations relying on them may either over-invest in systems that don’t require that level of scrutiny or, more dangerously, under-invest in systems that do. That’s not merely a knowledge gap but a consequence of relying on expertise developed for a different regulatory framework.
The GDPR Instincts We Still Need
If you already understand GDPR, the good news is that you’re not starting from scratch. Many of the habits developed under GDPR transfer remarkably well to AI governance. Accountability, documentation, risk assessments — all these still matter. Moreover, organisations still need clear ownership, clear responsibilities, and evidence that they’re complying with their obligations.
In fact, people with experience in privacy, governance, or risk management often have an advantage because they’re already used to asking difficult questions early. They know that compliance can’t simply be bolted onto a project at the end but needs to be built into it from the outset.
Those instincts remain valuable under the AI Act. The difference is that the questions become broader. In addition to asking where data comes from and how it’s processed, organisations need to understand how AI systems are trained, monitored, tested, supervised, and controlled throughout their lifecycle.
The First Mental Shift: From Data Flows to Decision Flows
One of the most useful ways to read the AI Act through a GDPR lens is to recognise that the focus begins to move from data flows towards decision flows.
Under GDPR, the key questions revolve around the collection, sharing, storage, security, transparency, and lawful processing of personal data. The AI Act doesn’t replace those concerns. Instead, it builds on top of them by asking what happens after information becomes part of a system that influences decisions, recommendations, opportunities, or outcomes.
That’s why two organisations with equally strong GDPR compliance programmes can face very different AI governance challenges. Both may handle personal data appropriately, yet one may deploy a system that introduces significant risks through the way it operates, while the other doesn’t.
This divergence shows up most clearly in how the AI Act classifies risk. If, under the GDPR, special category data triggers higher obligations and the lawful basis determines what processing is permitted, under the AI Act, the primary consideration is the use case and the domain in which the system is deployed rather than the data type alone.
According to the Act, there are eight categories of high-risk systems, covering areas such as employment, recruitment, healthcare, education, credit scoring, law enforcement, and border control. Systems operating in those domains face significant compliance obligations regardless of whether the underlying data would have triggered heightened scrutiny under GDPR.
In other words, an AI system used to screen job applicants is high-risk not because of the data it processes but because of the decisions it influences. This is a genuinely different way of thinking about risk, and it’s one that GDPR expertise alone won’t make obvious.
There’s a further wrinkle here that can be easy to overlook from a GDPR perspective. The AI Act classifies risk based on the intended purpose defined by the provider, but that’s only part of the picture. Deployers can also bring a system into high-risk territory through the context in which they use it, meaning responsibility for assessing classification doesn’t rest with providers alone. This is particularly relevant for general-purpose AI systems, where downstream deployment decisions can determine whether high-risk obligations apply at all. This is subtly but significantly different from GDPR’s approach, where purpose limitation governs what you can do with data you already hold.
As a result, organisations must look beyond the purpose for which data is processed and consider both the intended purpose of the AI system and the context in which it’s deployed. This may sound like a subtle distinction, but it requires a different mental model altogether and often demands that governance, risk, and compliance questions are raised much earlier in the development process.
The Second Mental Shift: Compliance Doesn’t End When the System Goes Live
Another assumption that often carries over from GDPR is the idea that organisations generally understand the systems they operate. Many GDPR obligations depend on that assumption, and organisations are expected to explain processing activities, define purposes, assign responsibility, and document how personal data is processed.
The AI Act is far less willing to take this for granted. Many AI systems, particularly those based on machine learning, don’t behave like traditional software. Their outputs are often probabilistic rather than deterministic. That means that an AI system may perform well during testing yet behave unexpectedly when exposed to real-world users, new data, and changing environments.
As a result, many AI Act obligations can be viewed as requests for proof. Organisations are expected to demonstrate that risks have been assessed, that appropriate oversight exists, that the system is being monitored throughout its lifecycle, and that responsibility has been clearly assigned. One mechanism that makes this especially concrete is the post-market monitoring obligation set out in Article 72 of the Act. This marks a subtle but important departure from how many organisations experience accountability under GDPR.
While GDPR accountability is ongoing in principle because DPIAs must be revisited when risk changes and security obligations under Article 32 are continuous, many organisations treat the initial assessment as the primary compliance event and return to it only when something material forces a review.
The AI Act takes a fundamentally different position here. Providers of high-risk AI systems are required to actively and systematically collect, document, and analyse performance data throughout the system’s lifetime, not just at the point of deployment.
Furthermore, the monitoring plan must be built into the technical documentation from the outset, and its outputs feed directly back into the risk management process. In practical terms, this means that compliance doesn’t end when a system goes live, but it’s a continuous obligation that requires ongoing governance, defined escalation procedures, and clear internal ownership. For organisations used to treating assessments as one-time exercises, this is a significant shift in how compliance work is structured. Ultimately, this raises a simple question: Do you genuinely understand the system well enough to trust it?
The Third Mental Shift: From Documenting Decisions to Demonstrating Control
GDPR accountability is largely concerned with demonstrating that personal data is processed lawfully, fairly, and transparently. The AI Act expands that idea significantly. A dataset may be collected lawfully, a model may be trained appropriately, and documentation may be complete, yet the resulting system can still produce unfair outcomes, misleading recommendations, or risks that weren’t obvious during development.
That is why the AI Act often feels closer to a safety framework than a traditional data protection law. It’s concerned not only with how information is handled but also with whether the system remains reliable, robust, explainable, and subject to meaningful human oversight.
Perhaps the most unfamiliar concept for those approaching the AI Act through a GDPR lens is the conformity assessment, set out in Article 43. If GDPR’s DPIA is designed to help organisations identify and document risks associated with processing activities, the AI Act’s conformity assessment serves a broader purpose by requiring organisations to demonstrate that a high-risk AI system complies with the AI Act’s requirements before it’s deployed. For organisations with a GDPR background, this represents a notable shift, as GDPR practitioners are used to internal accountability mechanisms, such as DPIAs, records of processing activities, and documented lawful bases. These are largely self-generated exercises in which the organisation assesses its own compliance.
While most high-risk AI systems can also undergo an internal conformity assessment, the scope of that assessment is considerably broader. The organisation isn’t simply examining how personal data is processed, but it must demonstrate that the system itself has been designed, tested, documented, and governed in accordance with the AI Act’s requirements, including obligations relating to risk management, data governance, technical documentation, human oversight, logging capabilities, accuracy, robustness, and cybersecurity.
Furthermore, for certain categories listed under Annex III point 1, such as biometric identification systems, third-party assessment by a notified body is required where the provider hasn’t fully applied harmonised standards, though for all other Annex III high-risk systems, internal self-assessment remains the default route. But even where self-assessment is permitted, the conformity assessment isn’t simply a documentation exercise in the GDPR sense. It’s actually closer to a product safety certification, sitting within a quality management system that must be maintained as a living structure rather than a completed record. For organisations accustomed to demonstrating accountability primarily through documentation, this represents a different order of obligation.
In other words, under the AI Act, accountability is no longer limited to what organisations do with information but increasingly extends to what their systems do with that information. What makes this framework unusual is that compliance is no longer treated as evidence that a review took place. Instead, it becomes evidence that ongoing control exists. A completed DPIA demonstrates that risks were assessed. A conformity assessment, combined with post-market monitoring, is intended to demonstrate that the organisation remains capable of identifying, understanding, and responding to risks as the system continues to operate.
The practical challenge, therefore, isn’t learning an entirely new compliance discipline but recognising where familiar GDPR instincts stop being reliable. Organisations that continue to follow the data alone may overlook the very risks the AI Act is designed to address. Those that learn to follow the system, its intended purpose, its behaviour, and its performance over time will be far better positioned to meet the Act’s requirements. Because, after all, GDPR taught us how to govern information, while the AI Act requires us to govern the increasingly autonomous systems that act upon it.
The practical stakes here are real. Organisations that read the AI Act through a GDPR lens alone risk misclassifying systems, building governance programmes around the wrong questions, and arriving at enforcement with a compliance posture that’s technically thorough but structurally misdirected. That’s an easy trap to fall into precisely because so much of the GDPR vocabulary carries over into the AI Act.
The more useful framing, perhaps, is that GDPR operates around one question: Can organisations prove they handle information responsibly? The AI Act introduces another: Can organisations prove they remain in control of the systems acting on that information? Both questions matter, but they’re not interchangeable, and answering the first well doesn’t mean an organisation has answered the second at all. To navigate this transition effectively, it’s not enough to know the GDPR and AI Act inside out. Organisations must also be able to recognise where familiar assumptions stop being reliable, where old instincts need to be adjusted, and where compliance requires a different way of thinking about risk.
Extra Sources and Further Reading
- Draft Commission guidelines on the classification of high-risk AI systems – European Commission
https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems/
These guidelines explain how providers and deployers should determine whether a system falls within the high-risk category, with practical examples. - AI Act Explorer – Article 43: Conformity Assessment – European Commission
https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-43
This article provides a practical explanation of one of the AI Act’s least familiar concepts for GDPR practitioners, including the different conformity assessment procedures. - AI Act Explorer – Article 72: Post-Market Monitoring by Providers and Post-Market Monitoring Plan for High-Risk AI Systems
https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-72
This article explains the obligation to establish and document a post-market monitoring system for high-risk AI systems, illustrating why AI Act compliance is an ongoing process rather than a one-off exercise. - A Five-Layer Framework for AI Governance: Integrating Regulation, Standards, and Certification – Cornell University
https://arxiv.org/abs/2509.11332
This paper explains how regulations, standards, conformity assessments, certification, and governance fit together into a single compliance ecosystem.
