The EU AI Act and What It Means for IS Practitioners

The EU AI Act passed the European Parliament in March 2024 and entered into force in August 2024. When I first read coverage of it, my instinct was to file it mentally with GDPR: another EU regulatory initiative that would eventually matter but felt distant from day-to-day IS practice. I think that was the wrong instinct, and I want to explain why.

The Act establishes a risk-based classification system for AI applications. That structure is publicly documented and worth understanding in outline, because the category your AI system falls into determines what compliance obligations apply to you. The highest category, unacceptable risk, covers AI applications that are banned outright. Publicly documented examples include AI systems that use subliminal techniques to manipulate behavior in ways that bypass a person's conscious awareness, systems that exploit specific vulnerabilities of groups such as children or people with disabilities, government-operated social scoring systems, and certain forms of real-time biometric identification of individuals in public spaces. These are prohibited, not regulated. You cannot build and deploy them with extra documentation. They are off the table.

The high-risk category is where most of the compliance weight sits. High-risk AI includes systems deployed in critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control management, and the administration of justice. High-risk systems require conformity assessments, substantial technical documentation, human oversight mechanisms, and registration in an EU database. The specific documentation and oversight requirements are still being operationalized, and I hedge any characterization of specific timelines as ongoing implementation detail that may shift. But the general direction is clear: if your AI system makes or significantly influences decisions in those domains and EU users are affected, you are in a compliance regime that looks more like a regulated industry than a software product business.

This is the part that I think many IS practitioners have not fully processed yet. If you build an AI-based hiring tool, you are almost certainly in the high-risk category under employment and worker management. If you build a credit scoring model, you are likely in the high-risk category under access to essential services. If your medical device includes an AI component that assists diagnosis, you are dealing with overlapping high-risk classification under the AI Act and existing medical device regulation. The compliance demands are real and they are not hypothetical.

Gartner published a press release in April 2024 noting that organizations should evaluate four AI deployment classes in preparing for the EU AI Act, and stated that Gartner analyst Gabriele Rigon described the Act as "the constraint CIOs and IT leaders need to boost their AI ambitions." I read this as accurate industry framing: the regulation is a governance forcing function. You can read that press release at the Gartner newsroom. In February 2026, Gartner projected that global AI regulations would fuel a billion-dollar market for AI governance platforms, with spending expected to surpass a billion dollars by 2030. Those numbers are forecasts, not measured outcomes, and I cite them as directional signals.

The extraterritorial reach is the part I want to emphasize most, because it is where I see the most underestimation. Like GDPR, the EU AI Act applies based on where the AI system's outputs are used, not where the developer is located. A company incorporated in California that deploys an AI-powered recruitment tool used by EU employers to screen EU job applicants is operating within the scope of the Act. The location of the servers is not what determines jurisdiction. The location of the impact is what determines jurisdiction. This means the Act affects US-headquartered companies, Asian technology providers, and any other organization whose AI systems produce outputs consumed by EU persons in regulated domains. The compliance obligation travels with the use, not the developer.

I have been thinking about this through the lens of the post I wrote on how AI policy tends to be compliance theater built on institutional isomorphism, and the EU AI Act is interesting precisely because it creates pressure that is harder to fake than a policy document. The high-risk conformity assessment requirements and registration obligations generate audit trails. A policy document saying "we take AI ethics seriously" does not satisfy the conformity assessment requirement. The coercive pressure here is more legible than GDPR's, partly because the risk categories give organizations clearer signals about which systems need which compliance work, and partly because the enforcement mechanism is more specified.

The practical challenge for IS practitioners right now is that the implementation details are still being developed. Technical standards, conformity assessment procedures, and enforcement protocols are being operationalized across EU member states. What the Act says at the legislative level and what an organization needs to do operationally are not fully mapped yet. Gartner's guidance suggests organizations should start with an AI inventory, cataloging what AI systems they have, what domains they operate in, and what outputs they produce, and then risk-classify each against the Act's categories. That seems right to me as a starting point, but I would add that the inventory itself is harder than it sounds for organizations that have been deploying AI features rapidly across many products without centralized tracking.

What I think IS practitioners should take away is that the EU AI Act is not primarily a legal team problem. The conformity assessments, technical documentation, and human oversight requirements require input from data scientists, system architects, product managers, and operations teams. It is an organizational governance challenge that happens to have a legal compliance dimension. Organizations that treat it as something for the legal department to handle are going to find that the legal department cannot answer questions about how a model produces its outputs, how training data was selected, or what monitoring is in place for model drift. Those are IS and data science questions, and the compliance regime requires answers to them.