The EU AI Act Explained: What It Means for Your AI

What the EU AI Act is

The EU AI Act is the European Union's comprehensive, risk-based regulation of artificial intelligence — the first law of its kind anywhere in the world. It entered into force in 2024 and applies in phases over the following years. Its central idea is simple to state and consequential to implement: the law does not regulate AI as a single monolithic thing, but classifies AI systems according to the risk they pose to people's health, safety, and fundamental rights, and then applies obligations proportionate to that risk.

For security, risk, and AI leaders, this framing is the most important thing to understand. Two organizations can both be "using AI" and yet face completely different obligations. A company that uses an AI model to recommend films to its customers sits at the opposite end of the spectrum from one that uses AI to screen job applicants or to help operate critical infrastructure. The EU AI Act is designed to leave the first case almost entirely alone while imposing detailed, auditable duties on the second. Your obligations follow your use case, not merely the fact that a model is involved.

The Act is often described as horizontal legislation, meaning it cuts across every sector rather than targeting a single industry. It sits alongside — and in some places interlocks with — existing EU frameworks such as product-safety law and data-protection law under the General Data Protection Regulation (GDPR). It is enforced through a combination of national authorities in each member state and an EU-level AI Office that oversees general-purpose AI models and coordinates consistent application across the Union.

This guide is written to give enterprise teams an accurate working model of the regulation. It is general guidance for planning purposes and not legal advice; the definitive text is the Regulation itself, along with the guidance issued by the European Commission and the AI Office. Where an exact date or figure is best confirmed against the primary sources, this article describes the requirement at an accurate high level rather than overstating precision. For a deeper look at how the Act fits into a broader governance program, see our companion guide to the NIST AI Risk Management Framework and our overview of compliance at Deflected.

The risk-based structure, in plain terms

Everything in the EU AI Act flows from a single organizing principle: classify by risk, then regulate in proportion. The Act defines four broad tiers. Understanding where a given system lands is the first, and often the hardest, step in any readiness effort — because classification determines the entire compliance burden that follows.

• Unacceptable risk — a small set of practices considered a clear threat to people's safety, livelihoods, and rights. These are prohibited outright.
• High risk — systems that can significantly affect health, safety, or fundamental rights. These are permitted but carry the Act's most extensive obligations and must pass a conformity assessment before reaching the market.
• Limited risk — systems where the main concern is that people should know they are interacting with, or seeing the output of, an AI. These carry targeted transparency obligations.
• Minimal risk — the large majority of AI applications, such as spam filters or AI in video games. These are largely unregulated by the Act, though voluntary codes of conduct are encouraged.

A separate and important set of rules applies to general-purpose AI (GPAI) models — the large foundation models that can be adapted to many downstream tasks. Because these models sit underneath a huge range of applications, the Act treats them on their own terms, with obligations that scale up further for the most capable models that could pose systemic risk. We cover GPAI in its own section below.

It is worth stressing that these tiers are not self-selected. The Act sets out criteria and, for high-risk systems, specific categories and use-case lists. An organization does not get to declare its system low-risk simply because that is convenient; it must assess honestly against the Act's definitions and, in the high-risk case, be prepared to demonstrate the classification with documentation.

Unacceptable-risk: the prohibited practices

At the top of the pyramid sits a narrow band of AI practices the EU has decided are simply incompatible with its values and are therefore banned. These prohibitions were among the earliest parts of the Act to take effect. While the precise legal wording is detailed and should be read in full before making decisions, the prohibited categories broadly include practices such as:

• Manipulative or deceptive techniques that operate below a person's consciousness or exploit vulnerabilities in order to materially distort behavior in a way likely to cause harm.
• Exploitation of vulnerabilities due to age, disability, or a specific social or economic situation, again where this materially distorts behavior and risks harm.
• Social scoring — evaluating or classifying people over time based on their behavior or characteristics in ways that lead to unjustified or disproportionate detrimental treatment.
• Certain uses of biometric and predictive systems — including specific applications of biometric categorization touching sensitive attributes, untargeted scraping of facial images to build recognition databases, and certain forms of individual predictive policing based solely on profiling.
• Emotion recognition in the workplace and in education, outside narrow safety or medical exceptions.
• Real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes, subject to tightly drawn exceptions.

For most commercial enterprises, the prohibited list will not describe anything they intend to build. Its practical importance is as a bright line: any project that drifts toward these practices should be stopped and reassessed, because the penalties for engaging in a prohibited practice are the most severe the Act provides. The exact scope of each prohibition, and its exceptions, should always be confirmed against the current legal text and official guidance.

High-risk AI systems: the heart of the Act

The high-risk tier is where the EU AI Act does most of its work, and where the vast majority of compliance effort will land for organizations that fall within it. High-risk systems are not banned — the Act fully expects them to be built and used — but they must be built and used responsibly, with a defined set of controls and the evidence to prove those controls exist.

What makes a system high-risk

The Act identifies high-risk systems through two main routes:

• AI as a safety component of regulated products. Where an AI system is a safety component of, or is itself, a product already covered by specific EU product-safety legislation (for example machinery, medical devices, or certain vehicles and equipment) and that product must undergo third-party conformity assessment, the AI is treated as high-risk.
• AI used in listed sensitive areas. The Act enumerates specific areas where AI use is considered high-risk. These broadly cover domains such as biometrics; critical infrastructure; education and vocational training; employment, worker management, and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum, and border control; and the administration of justice and democratic processes.

There is a limited mechanism by which a system in a listed area may not be considered high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights — but this is a narrow, documented exception, not a general escape hatch, and it must be justified and recorded.

The obligations that follow

Once a system is high-risk, the provider must implement a coherent set of requirements across the system's lifecycle. These are the obligations most teams will spend their time operationalizing:

• Risk management system. A continuous, iterative process to identify, evaluate, and mitigate the risks the system poses throughout its lifecycle — not a one-time exercise, but an ongoing discipline updated as the system and its context change.
• Data and data governance. Training, validation, and testing datasets must meet quality criteria appropriate to the intended purpose — relevant, sufficiently representative, and examined for possible biases that could lead to prohibited discrimination or harm.
• Technical documentation. Documentation drawn up before the system is placed on the market and kept up to date, detailed enough to allow authorities to assess the system's compliance.
• Record-keeping and logging. The system must technically allow for the automatic recording of events (logs) over its lifetime, supporting traceability and post-market monitoring.
• Transparency and information to deployers. Clear instructions for use so that the organizations deploying the system can understand its capabilities, limitations, and the human oversight it requires.
• Human oversight. The system must be designed so that people can effectively oversee it — able to understand its output, intervene, or stop it, and avoid over-relying on it (a phenomenon sometimes called automation bias).
• Accuracy, robustness, and cybersecurity. The system must achieve an appropriate level of accuracy and be resilient against errors, faults, and attempts by third parties to manipulate its behavior or exploit vulnerabilities.

The cybersecurity requirement deserves particular attention from security teams, because it is where the EU AI Act intersects most directly with day-to-day AI security practice. A high-risk system must be resilient against attempts to alter its use, behavior, or performance, or to compromise its security properties. In the era of large language models, that means defending against threats such as data poisoning, model evasion, adversarial inputs, and — critically — prompt injection, where crafted input hijacks a model's behavior. Robustness is not a paperwork exercise; it is an engineering and operational commitment that has to be tested and maintained.

Conformity assessment and the CE mark

Before a high-risk AI system is placed on the market or put into service, it must undergo a conformity assessment — a procedure to demonstrate that the requirements above have been met. For many high-risk systems this takes the form of an assessment based on internal control, where the provider verifies its own compliance against the requirements; for certain categories, third-party involvement is required. A system that passes bears the CE marking, and the provider draws up an EU declaration of conformity and, where applicable, registers the system in an EU database. Substantial modifications to the system can trigger the need for a fresh assessment.

Limited and minimal risk: transparency and freedom

Below the high-risk tier, the Act's demands lighten considerably. The limited-risk category is defined less by potential for physical or rights-based harm and more by the risk of people being misled about what they are dealing with. Here the obligations are about transparency. Broadly, these include duties such as:

• Disclosing AI interaction. Where people interact with an AI system such as a chatbot, they should be informed that they are dealing with a machine, unless it is obvious from the circumstances.
• Labeling synthetic content. Providers of systems that generate synthetic audio, image, video, or text must, in general, mark outputs in a machine-readable way as artificially generated or manipulated.
• Marking deepfakes and AI-generated public-interest text. Deployers who use AI to produce deepfakes, or to generate or manipulate text published to inform the public on matters of public interest, generally have to disclose that the content is artificially generated or manipulated, subject to certain exceptions.
• Notifying subjects of emotion recognition or biometric categorization where those systems are used (and permitted), so people know such processing is taking place.

These transparency duties are increasingly relevant to any organization deploying generative AI in customer-facing or public communications, even if the underlying system is not high-risk. Labeling synthetic media, in particular, connects to a broader societal push against deception and fraud — a theme we explore in our guide to deepfake and voice-clone fraud.

The minimal-risk tier covers the overwhelming majority of AI systems in everyday use — recommendation engines for low-stakes content, spam filtering, inventory optimization, AI features in games, and countless others. The Act imposes no mandatory obligations on these systems beyond the general transparency rules that may apply, and it encourages providers to adopt voluntary codes of conduct. This deliberate light touch is a feature, not an oversight: the EU's stated intent is to concentrate regulatory attention where the risk is real and to leave innovation in low-risk applications unencumbered.

General-purpose AI models and systemic risk

The rise of large foundation models prompted the Act to address a category that does not fit neatly into a single use-case risk tier: general-purpose AI (GPAI) models. These are models trained on broad data at scale, capable of performing a wide range of distinct tasks and of being integrated into many different downstream systems. Because a single such model can sit beneath thousands of applications, the Act places obligations on the model providers themselves, so that responsibility does not fall entirely on the many organizations building on top of them.

Baseline obligations for GPAI providers

Providers of general-purpose AI models are broadly expected to:

• Maintain up-to-date technical documentation of the model, including its training and testing process and evaluation results.
• Provide information and documentation to downstream providers who integrate the model, so those providers can understand its capabilities and limitations and meet their own obligations.
• Put in place a policy to respect EU copyright law, including in relation to text and data mining.
• Publish a sufficiently detailed summary of the content used to train the model, according to a template provided by the AI Office.

Some obligations are calibrated differently for models released under genuinely free and open-source licenses, reflecting a policy choice to support open research and development while still protecting the public interest.

Models with systemic risk

The Act singles out the most capable GPAI models — those considered to carry systemic risk because of their scale, reach, and potential impact. A model can be classified as posing systemic risk based on its capabilities, with the amount of compute used for training serving as one indicator, or by a designation from the AI Office. Providers of these models take on additional duties, broadly including:

• Performing model evaluations, including adversarial testing (red-teaming), to identify and mitigate systemic risks.
• Assessing and mitigating systemic risks at the EU level, including their sources.
• Tracking, documenting, and reporting serious incidents and possible corrective measures to the AI Office and relevant authorities.
• Ensuring an adequate level of cybersecurity protection for the model and its physical infrastructure.

Adherence to codes of practice, developed with the AI Office and industry, is one route through which GPAI providers can demonstrate compliance while more detailed harmonized standards mature. For enterprises that consume foundation models rather than build them, the practical takeaway is twofold: the models you build on carry their own obligations that should inform your vendor due diligence, and the documentation those providers supply is a valuable input to your own compliance and secure application design.

Who the Act applies to — and how far it reaches

The EU AI Act assigns obligations by role, and the two roles that matter most to enterprises are provider and deployer. Getting your role right for each system is essential, because the obligations differ substantially.

• Providers develop an AI system or a general-purpose AI model — or have one developed — and place it on the market or put it into service under their own name or trademark. Providers of high-risk systems carry the bulk of the Act's obligations: the risk management, documentation, conformity assessment, and post-market monitoring duties described above.
• Deployers use an AI system under their own authority in a professional capacity. Deployers of high-risk systems have their own, more limited set of duties — such as using the system in accordance with its instructions, ensuring appropriate human oversight, monitoring its operation, keeping logs where under their control, and, in some cases, conducting a fundamental-rights impact assessment.

The Act also recognizes other roles, including importers and distributors, and — importantly — provides that certain actors can become a provider by, for example, putting their name on a high-risk system, substantially modifying it, or changing a system's intended purpose in a way that makes it high-risk. An organization that fine-tunes or significantly adapts a third-party system should therefore check carefully whether it has stepped into provider obligations.

Extraterritorial reach

One of the most consequential features of the EU AI Act is that it does not stop at Europe's borders. Its scope is deliberately extraterritorial. In broad terms, it applies to:

• Providers that place AI systems on the market or put them into service in the EU, or place GPAI models on the EU market, regardless of where the provider is established.
• Deployers of AI systems that are located or established within the EU.
• Providers and deployers located outside the EU where the output produced by the AI system is used in the EU.

The practical consequence is that a company headquartered anywhere in the world can fall within the Act's scope without a single office in Europe, simply by serving EU users or by producing outputs consumed in the EU. Non-EU providers of high-risk systems are also generally required to designate an authorized representative in the Union. For global enterprises, this mirrors the reach many teams already grew familiar with under GDPR: if your AI touches the EU market, plan as though the Act applies until you have confirmed otherwise.

The phased timeline, at a high level

The EU AI Act did not switch on all at once. After entering into force in 2024, its provisions apply on a staggered schedule, giving organizations time to prepare for the more demanding obligations. The exact dates should be confirmed against the official text, but the sequence is clear and worth understanding because it tells you what to prioritize:

1. Prohibitions first. The bans on unacceptable-risk practices, together with certain general provisions such as requirements around AI literacy, applied earliest — within months of entry into force. If any part of your roadmap risks touching a prohibited practice, that is the most time-critical item.
2. General-purpose AI obligations next. The obligations on providers of general-purpose AI models, and the associated governance and enforcement machinery at the EU level, apply on a subsequent milestone, giving model providers a defined runway to comply.
3. High-risk and the remainder last. The bulk of the high-risk obligations apply after a longer transition, with an even longer period for high-risk systems tied to certain regulated products. This extended runway reflects how substantial the high-risk obligations are to implement well.

The strategic reading of this timeline is that the phasing rewards organizations that start early. High-risk obligations look distant on a calendar but are deep in practice — building a genuine risk management system, curating and documenting data, standing up logging and human oversight, and preparing for conformity assessment are multi-quarter efforts, not sprints. Treating the longest deadline as the time to begin is the most common and most avoidable planning mistake.

Penalties: fines scaled to global turnover

The EU AI Act backs its obligations with meaningful enforcement. Penalties are structured in tiers, and — as with GDPR — the fines are calculated as the higher of a fixed amount or a percentage of the offending company's total worldwide annual turnover. This turnover-based design is deliberate: it ensures that penalties are felt by the largest enterprises, not just small ones, and that non-compliance cannot simply be treated as a cost of doing business.

Without asserting the precise figures, which should be read from the Regulation, the tiering works broadly like this:

• The highest tier applies to violations of the prohibitions on unacceptable-risk practices. These carry the largest ceilings, reflecting how seriously the EU treats banned uses.
• A middle tier applies to breaches of other obligations under the Act, including many of the high-risk requirements and the duties on providers and deployers.
• A lower tier applies to supplying incorrect, incomplete, or misleading information to notified bodies or authorities.

Proportionate, dedicated provisions also apply to general-purpose AI model providers. National authorities administer most enforcement, with the AI Office playing the central role for GPAI, and member states are responsible for laying down the specific penalty regimes within the Act's framework. For a board or executive committee, the headline is straightforward: exposure scales with the size of the business, so the financial case for getting readiness right grows precisely as the organization grows.

How the Act relates to the NIST AI RMF and ISO/IEC 42001

The EU AI Act does not exist in isolation. Two other pillars of AI governance — one American and voluntary, one international and certifiable — fit around it, and understanding the relationship helps organizations avoid duplicating effort.

The NIST AI Risk Management Framework

The NIST AI Risk Management Framework is a voluntary framework published by the U.S. National Institute of Standards and Technology. It is not a law and imposes no legal obligations; instead it offers a structured way to identify, measure, and manage AI risk through its core functions of GOVERN, MAP, MEASURE, and MANAGE, oriented around characteristics of trustworthy AI such as validity, safety, security, accountability, transparency, fairness, and privacy. Those characteristics overlap heavily with what the EU AI Act requires of high-risk systems. An organization that has genuinely operationalized the NIST AI RMF will already be doing much of the substantive work — risk assessment, measurement, documentation, oversight — that EU AI Act readiness depends on, even though the framework is not itself a route to legal compliance.

ISO/IEC 42001

ISO/IEC 42001 is the international management-system standard for artificial intelligence — the AI equivalent of how ISO/IEC 27001 works for information security. It specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS), and it is certifiable, meaning an accredited body can audit an organization against it and issue a certificate. Because it is process-oriented and auditable, ISO/IEC 42001 is a natural backbone for demonstrating the kind of ongoing, governed, evidence-producing approach the EU AI Act expects. Harmonized European standards are also being developed specifically to support conformity with the Act; conforming to those, once available, will provide a presumption of conformity with the corresponding legal requirements.

The practical synthesis for enterprise teams is this: use the NIST AI RMF to shape how you think about and measure AI risk, use ISO/IEC 42001 to give your program a governed, certifiable management structure, and treat the EU AI Act as the binding legal target those two help you hit. None of the three replaces the others, and building on the voluntary frameworks makes demonstrating legal readiness dramatically more tractable. Our AI Governance & Compliance engagement is built precisely around aligning these regimes rather than treating each as a separate project.

A practical readiness checklist

Turning the EU AI Act from a legal abstraction into an operational program is mostly about doing a sequence of concrete, unglamorous things well. The following checklist is a general, non-exhaustive starting point for enterprise teams. It is not a substitute for legal advice, but it reflects the shape of what a sound readiness effort looks like.

1. Build an AI inventory. You cannot regulate what you cannot see. Catalog every AI system your organization provides or deploys, including systems embedded in third-party products and the quiet, unsanctioned tools employees adopt on their own — the problem of shadow AI. The inventory is the foundation everything else rests on.
2. Classify each system by risk tier. For every system, determine whether it is prohibited, high-risk, limited-risk, or minimal-risk under the Act's criteria, and record the reasoning. Flag anything near the prohibited line for immediate review.
3. Confirm your role for each system. Decide whether you are the provider, the deployer, or both — and watch for situations, such as fine-tuning or rebranding, that could turn a deployer into a provider with far greater obligations.
4. Check extraterritorial scope. Determine which systems touch the EU market or produce outputs used in the EU, and therefore fall within the Act regardless of where your organization sits.
5. Stand up a risk management process. For high-risk systems, establish the continuous, documented risk management lifecycle the Act requires — not a one-off assessment.
6. Get your data governance in order. Document data sources, assess datasets for quality and representativeness, and examine them for bias that could cause discrimination or harm.
7. Create and maintain technical documentation. Assemble the documentation that would let an authority assess compliance, and keep it current as systems change.
8. Implement logging and traceability. Ensure high-risk systems record events over their lifetime, and that those logs are retained and usable for monitoring and investigation.
9. Design in human oversight. Make sure people can understand, supervise, intervene in, and stop high-risk systems, and guard against over-reliance on automated output.
10. Harden accuracy, robustness, and cybersecurity. Test and maintain the system's resilience against errors and against adversarial threats such as data poisoning, evasion, and prompt injection — and treat this as an ongoing engineering commitment.
11. Prepare for conformity assessment. Understand which assessment route applies to each high-risk system, and assemble the declaration of conformity and any registration obligations.
12. Meet transparency duties. Where systems interact with people or generate synthetic content, implement disclosure and labeling so users know what they are dealing with.
13. Address GPAI in your supply chain. Fold the documentation and obligations of the foundation-model providers you rely on into your vendor due diligence and your own compliance evidence.
14. Assign ownership and governance. Give the program a clear owner, connect it to your broader risk and compliance functions, and align it with the NIST AI RMF and ISO/IEC 42001 so you build one governed system rather than many disconnected efforts.
15. Invest in AI literacy. Ensure the people building, deploying, and overseeing AI have a sufficient understanding of it — a general expectation the Act reflects and a prerequisite for meaningful human oversight.

Worked through honestly, this list is less a compliance chore than a description of a mature AI program. That alignment is intentional on the EU's part: the Act is, in large measure, an attempt to require in law the practices a responsible organization would want to adopt regardless.

How Deflected helps

Deflected is not a law firm and not an accredited conformity-assessment or certification body, and nothing here should be read as legal advice or as a guarantee of compliance. What Deflected does is help organizations get ready — turning the EU AI Act's requirements into implemented controls and producible evidence, and mapping them alongside the frameworks that make the work coherent. The determination of legal compliance always rests with the organization, its counsel, and the competent authorities.

In practice, a readiness effort with Deflected tends to move along a few clear lines of work. We help you build and maintain the AI inventory and risk classification that everything depends on, including surfacing shadow AI. We help translate the high-risk obligations — risk management, data governance, documentation, logging, human oversight, and robustness — into concrete controls with owners and evidence, so the artifacts an assessor would want already exist. And because the Act's cybersecurity requirement is squarely in our domain, we help harden AI systems against the adversarial threats that robustness obligations demand attention to.

That security work connects to the rest of the Deflected platform. Defending a high-risk system against manipulation means defending against prompt injection, data exfiltration, and model abuse — exactly what tools like our inline AI gateway are built to do — and generating the immutable logs that both good security and the Act's traceability expectations rely on. Where systems handle information that must stay confidential for years, our encryption approach uses post-quantum standards — ML-KEM-1024 (FIPS 203) for key encapsulation, hybrid X25519 + ML-KEM key exchange, and AES-256 for data at rest and in transit — so that data protected today stays protected against tomorrow's threats. You can read more about how we approach evidence and framework mapping on our compliance overview.

The throughline is simple: the EU AI Act asks organizations to run their AI responsibly and to prove it. Deflected helps with both the running and the proving, while being clear about the line it does not cross — we support your readiness; we do not certify your compliance or provide legal counsel.

Frequently asked questions

The closing takeaway is a reassuring one. The EU AI Act can look daunting as a legal document, but its logic is coherent and its demands, for the systems that fall under them, largely describe how responsible AI should be built anyway: know what you have, classify it honestly, manage its risks continuously, govern its data, document and log what it does, keep humans meaningfully in control, and make it accurate and hard to attack — then be ready to show your work. Start with an inventory, prioritize by risk and by the phased timeline, align the effort with the NIST AI RMF and ISO/IEC 42001 so you build one governed program rather than many, and treat readiness as an ongoing discipline rather than a one-time deadline. Organizations that approach it that way will find the Act less a burden imposed from outside than a codification of the AI maturity they were right to pursue regardless.