EU AI regulation: What the EU AI Act means for your organization in 2026 and beyond

The EU AI regulation is no longer a draft on the horizon. The ban on unacceptable-risk systems has been live since 2 February 2025, while high-risk AI system obligations will roll out from 2 December 2027 for stand-alone high-risk AI systems.

The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) is the first comprehensive legal framework for AI. Walter Haydock, founder of StackAware, has observed that the EU is "probably the furthest ahead in terms of actually getting something enacted and enforced." That reach is not confined to Europe. Any organization placing AI systems on the EU market or serving EU users is in scope.

This guide breaks down who the EU AI Act applies to, how AI systems are classified by risk, what obligations apply to providers and deployers, key compliance deadlines, and the practical steps organizations can take to prepare.

What is the EU Artificial Intelligence (AI) Act?

The EU Artificial Intelligence Act, formally Regulation (EU) 2024/1689, is the European Union's first comprehensive legal framework for artificial intelligence. It sets harmonized rules for the development, market placement, and use of AI systems across the EU, with the aim of keeping AI safe, rights-respecting, and aligned with the Union's values.

A regulation is directly applicable across EU Member States once its provisions start applying. No member state needs to pass its own implementing law, and the rules create a common legal framework across the EU rather than requiring each country to transpose the Act into national law like a directive would.

Founders often assume there is a national law step still to come. There is not. The core obligations apply directly under the AI Act, although national authorities play a role in enforcement.

The AI Act has extraterritorial reach. Non-EU companies can fall within scope if they place AI systems or AI models on the EU market, or if the output produced by their AI systems is used in the EU.

Introduced by the European Commission in April 2021 and adopted by the European Parliament and the Council in 2024, the Act entered into force on 1 August 2024. Non-compliance can result in administrative fines of up to €35 million or 7% of global annual turnover for the most serious violations, such as deploying a prohibited AI system. The regulation specifies euros, not dollars.

Providers, deployers, importers, and distributors all carry compliance responsibilities under the Act. They are expected to meet obligations such as maintaining documentation, implementing required controls, and completing conformity assessments where applicable before certain AI systems reach the market.

On the enforcement side, national authorities handle market surveillance and enforcement, while the AI Office oversees GPAI models and supports implementation of the Act. The European Artificial Intelligence Board helps coordinate national authorities and promote consistent application of the rules across the Union.

Who does the EU AI Act apply to?

The Act applies to a wide range of actors across the AI lifecycle, whether or not they are based in the EU. It takes a lifecycle approach, assigning responsibilities to each actor according to their role, so that any AI system placed on the EU market is trustworthy and safe.

1. Providers

A provider is any natural or legal person, public authority, or body that develops an AI system or a general-purpose AI model and places it on the market or puts it into service under its own name or trademark. 

Providers sit at the core of the compliance structure. Before a system reaches the EU market, the system is subject to risk management procedures, technical documentation, conformity assessments for high-risk systems, and transparency requirements. 

As systems grow more complex and autonomous, the Act holds providers accountable for their design and training choices from the outset.

2. Deployers

A deployer is any entity or individual that uses an AI system in a professional capacity within the EU, excluding purely personal use. 

Deployers must use systems in line with their intended purpose and meet obligations around transparency, human oversight, and accuracy in their specific context. In sectors like healthcare, HR, and finance, deployers influence how AI affects people in practice, which is why the Act requires deployers of high-risk systems to apply safeguards and monitor real-world performance.

Sandip Wadje, managing director at BNP Paribas, described in an episode of the Risk Grustlers how this plays out in practice: “When a business team adopts an AI tool for productivity, legal, risk, and compliance teams need to understand what that tool means for their existing obligations.” For deployers in regulated industries, that coordination is a core part of governing AI responsibly.

3. Importers

An importer is an EU-based natural or legal person who places on the market an AI system developed by a provider established outside the EU. Importers are the bridge between non-EU developers and the European market. 

Before distribution, they must verify that conformity assessments have been completed, that technical documentation exists, and that instructions for use are available.

4. Distributors

The Act reaches further down the chain than most organizations expect. If you make an AI system available on the EU market without substantially modifying it, you are a distributor and you carry real obligations before you can pass it on. Verify that the provider and importer have met their own compliance duties first. That verification is the distributor's gate, not a formality.

5. The dual-role scenario

A company that develops its own AI system and also deploys it in the EU is simultaneously a provider and a deployer. Both sets of obligations apply at once. This is the most common position for SaaS companies building AI features into their own products, and it is easy to underestimate.

The Act also makes room for smaller organizations. Each member state must establish at least one AI regulatory sandbox by 2 August 2026, giving startups and SMEs a supervised environment to test AI systems against the rules before full market deployment.

Actor obligations at a glance

General-purpose AI (GPAI) models under the EU AI Act: Rules and obligations

General-purpose AI refers to a model that shows significant generality and can competently perform a wide range of tasks, regardless of how it is marketed or integrated downstream. 

GPAI models give industries a versatile, scalable foundation that gets embedded into many different AI systems. They are not inherently high-risk, but they can become part of a high-risk system, and providers are expected to cooperate to keep the whole chain compliant.

Rules for GPAI models under Regulation (EU) 2024/1689 include:

1. Technical documentation: Detailed documentation covering the model’s training, testing, and evaluation results.

2. Information for downstream providers: Enough detail for integrators to understand the model's capabilities and limits. This is what makes the compliance chain function. Without it, a downstream provider cannot assess their own high-risk obligations.

3. Copyright compliance: Providers must comply with the EU Copyright Directive. This matters in practice because generative models trained on web-scraped data are where most copyright exposure originates.

4. Training data transparency: A publicly available summary of training content, so rights holders and downstream users can see what went into the model.

Practitioners encounter this transparency exposure directly. As Walter Haydock discussed in our webinar, something unique to AI use cases is that models hosted by third parties might train on the data you provide to them, surfacing it later to other users. That risk of unintended exposure is precisely why the Act forces GPAI providers to document what their models learned from.

Not all GPAI providers face the same burden. GPAI models released under a free and open-source license have reduced obligations, copyright compliance, and the training data summary only, unless they are classified as posing systemic risk.

A model trained using more than 10²⁵ floating point operations (FLOPs) is presumed to present systemic risk, which triggers the heaviest obligations. 

Models above that line must also carry out:

• Model evaluations and adversarial testing

• Bias and security risk mitigation

• Serious incident reporting

• Cybersecurity protections covering the model itself, the APIs it exposes, and the infrastructure it runs on

Timing matters here. GPAI rules started applying to new models placed on the market from 2 August 2025. Models already on the market before that date have until 2 August 2027 to comply. 

To bridge the gap before harmonized standards are finalized, the GPAI Code of Practice was published in mid-2025, covering transparency, copyright, and safety. Participation is voluntary, but signing on is a recognized way to demonstrate compliance.

What are the AI Act risk levels?

The EU AI Act takes a risk-based approach, sorting AI systems into four categories by the level of risk they pose to fundamental rights, health, safety, and society. Compliance obligations scale with the category: stricter rules for higher-risk systems, near-total exemption for minimal-risk ones. Getting the classification right is the foundation of everything else.

This tiered logic mirrors how practitioners already calibrate risk. The first thing which a company should do is make sure that the context is defined before assessing any AI risk. Walter Haydock explained: “If you are making an AI-based meme generator, your risk appetite could conceivably be quite high. If you are deciding to put out social media posts from a generative AI-driven account, your risk tolerance might drop.” The Act’s four tiers are the regulatory expression of exactly that calibration.

1. High-risk AI systems

These systems can significantly affect people's lives, especially in safety-critical sectors or in contexts touching fundamental rights. They are permitted, but only under strict requirements: risk management, high-quality data governance, technical documentation, human oversight, and post-market monitoring.

High-risk systems fall into two sub-categories. The first covers AI used as a safety component in products already regulated under EU product safety law, such as toys, medical devices, lifts, and vehicles. The second covers AI in specified sensitive areas, which must be registered in an EU database before deployment.

Deployers in particular need to plan around two requirements that are easy to underestimate. Deployers of high-risk AI in certain contexts must complete a Fundamental Rights Impact Assessment (FRIA), an ex ante review that identifies and mitigates fundamental rights impacts before the system goes live. Separately, people affected by high-risk AI have the right to file complaints and to receive an explanation of decisions that affect them. For HR, credit, and law enforcement use cases, that right to an explanation is not optional.

One more thing to plan around: the list of high-risk applications can be expanded over time without amending the Act itself. A use case that is not high-risk today may be added later, so your classification process needs to be a living one.

2. Unacceptable-risk AI systems

These pose a clear threat to people's rights and freedoms and are banned outright, with only narrow law enforcement exceptions under strict safeguards. The prohibited practices are covered in detail in the next section.

3. Limited-risk AI systems

These carry some risk but not enough to trigger full regulation. The main obligation is transparency: users must know when they are interacting with an AI system or viewing AI-generated content. Clear interface design and accurate labeling usually satisfy the requirement. Even where the rules are lighter, documentation supports trust and accountability.

4. Minimal-risk AI systems

These are low-risk and largely exempt. Voluntary codes of conduct are encouraged, and upholding transparency and fairness here can future-proof your systems as expectations evolve.

EU AI Act risk tier summary

Which AI practices are prohibited?

Prohibited practices are simply the unacceptable-risk tier in operational form. The Act bans these uses outright because they threaten fundamental rights, safety, and democratic values to a degree no control can contain.

• AI that uses subliminal techniques to distort behavior in ways likely to cause physical or psychological harm

• AI that exploits vulnerabilities tied to age, disability, or socioeconomic situation to materially distort behavior

• Social scoring by public authorities that leads to unjustified or disproportionate detrimental treatment

• AI that classifies people based on behavior or characteristics with unjustified or disproportionate consequences

• Predictive policing based solely on profiling, location, or past criminal behavior

• Emotion recognition in workplaces and educational institutions, except in specific circumstances justified by law

• Untargeted scraping of facial images from the internet or CCTV to build or expand facial recognition databases

• Real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to narrow exceptions

‍

Those law enforcement exceptions are narrow and specific. Real-time remote biometric identification is permitted only to search for specific victims of crime, to prevent a specific and imminent threat, or to locate or identify suspects in serious cross-border crimes. 

The emotion recognition exception, "circumstances justified by law," refers to national law in the relevant member state, not just EU law, which means the permitted exceptions can vary by country.

No control architecture can adequately contain this category of harm. Do not deploy.

Practical AI risk categories organizations must address

Regulatory categories tell you what the law requires. The five failure modes below are what actually break things when AI hits a production environment.

Prompt injection

Attackers craft malicious inputs to make a model violate its own security policy. As Walter Haydock has explained, “Prompt injection is essentially a specific form of input injection that uses a system to essentially violate its own security policy.” It is harder to mitigate than SQL injection because, in his words, “with SQL injection there are a limited finite number of acceptable inputs, but that's not really the case with generative AI tools.” 

Direct prompt injection is the user tricking the model into producing forbidden output. Indirect prompt injection is subtler: a model scraping a malicious web page ingests hidden instructions and acts on them, even though the operator meant no harm.

Unintentional training and data leakage

Employees paste PII, PHI, or trade secrets into third-party LLMs, which may train on that data and resurface it to other users. As Haydock puts it, “Something that is unique to AI use cases is the fact that these models hosted by third parties might train on the data that you provide to them.” Samsung engineers reportedly submitted confidential code and meeting notes to ChatGPT, a widely cited example of how fast sensitive data can leave the building once an LLM is in the workflow.

Data or model poisoning

An attacker corrupts training data to alter how a model behaves. A poisoned model seeded into a supply chain will appear legitimate and produce wrong or malicious outputs on a specific trigger, all while behaving normally the rest of the time. 

Security researchers demonstrated this when they nearly uploaded a model to Hugging Face that would reliably misstate a historical fact on a specific trigger while producing correct outputs otherwise, a proof of concept for supply-chain poisoning.

Biased outputs

AI trained on historical human decisions inherits and amplifies human bias. As Kush Kaushik, Co-Founder of Scrut Automation, noted in a webinar, “What you feed to AI and what AI systems learn, they try to output the same. There might be a situation where the output is biased towards a particular community or a particular section of society.” 

This is the direct operational risk behind the Act's high-risk treatment of hiring, credit, and criminal justice systems.

Copyright and IP exposure

Generative outputs can incorporate copyrighted training data, creating liability for deployers. As Kush described it, “A lot of AI algorithms are being fed data so that they learn, and a lot of copyrighted information goes in, and then the output comes from the copyright material.”

These technical risks are exactly what the Act's high-risk category and GPAI systemic-risk provisions are designed to address. Documenting your controls against each of them is the foundation of your compliance evidence package.

EU AI Act compliance timeline: Key deadlines for 2026 and 2027

The Act is already in force, but its obligations land in stages. That staggering gives organizations time to adapt, but it also means several deadlines are already behind us, and the rest arrive on fixed dates.

One obligation is easy to miss because it has been live since day one. The AI literacy obligation under Article 4 applied from 1 August 2024, requiring providers and deployers to ensure their staff have an adequate level of AI literacy. It is active now, and most organizations have not formally addressed it.

EU AI Act compliance timeline

Rules apply to AI in products regulated under existing EU product safety law; existing GPAI models must comply

Providers of AI in regulated products; existing GPAI providers

For most organizations, 2 August 2026 is the operative planning horizon. High-risk obligations land then, and the work to get there, inventory, classification, documentation, oversight design, takes months, not weeks. 

If your AI is embedded in a product already regulated under EU product safety law, or if you provide a GPAI model that predates August 2025, your deadline is August 2027. The planning discipline is the same either way.

What related laws affect AI?

The EU AI Act is the cornerstone of AI regulation in the region, but it does not operate alone. Several other EU laws intersect with it, covering liability, privacy, product safety, and consumer protection.

1. AI Liability Directive (AILD)

The proposed AILD aimed to harmonize non-contractual civil liability for AI-related harm, introducing a rebuttable presumption of causality to ease the burden of proof on victims. As of March 2025, the European Commission withdrew the proposal. 

In practice, civil liability claims for AI-related harm currently fall back on national tort law across member states, which varies significantly from one country to the next.

2. General Data Protection Regulation (GDPR)

The GDPR (Regulation (EU) 2016/679) governs the processing of personal data in the EU. Where an AI system processes personal data, it must comply with both the GDPR and the AI Act at once. 

Treat them as parallel, simultaneous obligations rather than alternatives. The GDPR’s data minimization principle, in particular, sits in tension with GPAI training data transparency obligations, and controllers cannot rely on the AI Act’s compliance mechanisms to satisfy their GDPR duties.  

3. Product Liability Directive (PLD)

The revised PLD (Directive (EU) 2024/2853) modernizes liability rules to cover digital products, including AI. It expands the definition of "product" to software and AI, shifts the burden of proof to manufacturers in certain cases, and allows claims for psychological harm and data loss.

4. General Product Safety Regulation (GPSR)

The GPSR (Regulation (EU) 2023/988), effective from 13 December 2024, replaces the previous General Product Safety Directive. It ensures consumer products, including those incorporating AI, are safe, with stricter requirements, clearer product information, and enhanced market surveillance.

5. Digital Services Act (DSA)

Recommender systems covered under the DSA often fall within the AI Act's limited-risk transparency obligations as well. A platform running a recommender engine can find itself answering to both regimes simultaneously. GRC teams should map that overlap explicitly. Assuming the DSA covers the AI Act transparency obligation, or vice versa, is a gap that auditors and regulators will surface.

What are the best AI frameworks and standards?

The Act sets high-level obligations but does not prescribe how to meet them. That is where established frameworks come in. They give you a structured way to satisfy requirements like risk management, documentation, and human oversight, and several map directly onto EU AI Act compliance.

1. ISO 42001

ISO 42001 is a certifiable standard for managing AI through structured policies, controls, and continuous improvement. Because the Act does not dictate implementation methods, an AI management system built to ISO 42001 gives you a defensible structure for the Act's risk management and governance obligations.

2. NIST AI RMF

The NIST AI Risk Management Framework is a voluntary framework organized around four functions: govern, map, measure, and manage. It is strong on direction and weak on prescription, which is both its strength and its catch. 

As Walter Haydock observed, “It’s comprehensive, but it requires a lot of details to implement. It talks a lot about risk appetite or risk tolerance, but doesn’t really give you a roadmap for determining what those things are for a given organization.” 

His practical advice is still to start there: “Following a NIST framework is a good place to start. Having specific steps that you put into place to manage these known risks is the most important place to start.”

Scale matters here. Sandip Wadje put it plainly: “NIST has 120 controls for AI, maybe they’re good for a large financial institution, not for you. Find out what works for you.” For a smaller organization, the right move is to take the parts of the framework that fit your risk and maturity, not to implement all of it.

3. OWASP AI Security and Privacy Guide

The OWASP guide offers actionable best practices for securing AI systems and protecting privacy, from threat modeling through incident response. It is the most directly technical of these resources and pairs well with the prompt injection and data leakage risks covered above.

4. Google’s Secure AI Framework

Google's SAIF emphasizes secure AI development and deployment, built on principles like security by design and continuous monitoring. It is useful as an engineering-facing complement to the governance-facing frameworks.

5. GPAI Code of Practice

Now that it is published, the GPAI Code of Practice is the framework most tightly bound to the Act itself. It covers transparency, copyright, and safety, and signing on is a recognized way for GPAI providers to demonstrate compliance ahead of harmonized standards.

On standards specifically, CEN-CLC/JTC 21 is the joint technical committee developing harmonized standards for the AI Act. Once a harmonized standard is published in the Official Journal, products that conform to it are presumed to conform to the regulation.

 No such standards have been published yet, so the presumption of conformity is not available for any specific standard as of this writing, but providers should track JTC 21's output closely.

How to begin your EU AI Act compliance program: a practical starting point

Most organizations know they need to act, but not where to start. This five-step sequence gives you a defensible starting point that maps onto the Act's obligations. The work begins, as Kush Kaushik puts it, with context: “Every organization should have a context first of all defined for the AI, including the intended purpose, beneficial usage, and prospective settings in which the system should be deployed.”

1. Inventory your AI systems

Most organizations discover shadow AI here, tools that exist in the environment because someone needed them, not because IT approved them. Document everything you develop, deploy, procure, or integrate: third-party APIs, embedded AI features in SaaS tools, the model your customer success team started using last quarter. You cannot govern what you have not cataloged.

2. Classify by risk tier

Apply the Act's four risk categories to each system in your inventory. When a system sits near a boundary, default to high-risk until legal review confirms otherwise. Misclassifying a high-risk system downward is the more expensive mistake.

3. Assess your role

For each system, determine whether you are a provider, deployer, importer, distributor, or several of these at once. SaaS companies building AI into their own products almost always land in both the provider and deployer columns simultaneously. Both sets of obligations apply from day one.

4. Map controls to obligations

For high-risk systems, stand up risk management procedures, technical documentation, and human oversight design. For GPAI models, begin training data documentation and a copyright policy. This is also the right moment to heed Sandip Wadje's advice to revisit existing controls in light of AI: ask what each control now means given how AI changes your data flows and access patterns.

5. Set your compliance timeline

For most organizations, 2 August 2026 is the planning horizon. Work backward from that date to assign ownership and milestones, so the obligations land on named people rather than on the calendar.

A GRC platform supports this by giving you a single AI inventory, mapping each system's controls to the relevant obligations, and letting you automate evidence collection and control mapping instead of rebuilding the evidence package by hand for every framework. You can also explore how Scrut approaches AI risk management across these requirements.

Futureproof your AI compliance with Scrut

EU AI Act compliance is not a one-time exercise. As deadlines arrive and harmonized standards land, the obligations keep shifting. 

Scrut helps security and GRC teams maintain a single AI inventory, map controls to AI Act obligations by risk tier, and collect evidence continuously across multiple frameworks. 

Whether you are preparing for the August 2026 high-risk deadline or aligning ISO 42001 with the EU AI Act, you stay ready rather than reactive. Schedule a demo to see how it works.

‍