What is the EU AI Act? Risk Tiers, Deadlines, and Compliance

The EU AI Act is the world's first comprehensive AI regulation. It entered into force on August 1, 2024, and its obligations are phasing in over a three-year period through August 2027. If your organization builds, sells, or uses AI systems that affect people in the EU, this regulation applies to you, regardless of where your company is headquartered.

The Act isn't a single switch that flips on one date. It's a staggered rollout, with some obligations already enforceable, some landing this year, and others still ahead. That structure makes it easy to either panic about deadlines that don't apply to you yet, or miss ones that already do.

Here's what the Act actually covers, what's already enforceable, what's still ahead, and what enterprises should be doing right now.

Why it matters even outside the EU

The Act applies based on impact, not location. If your AI system affects EU residents, whether you're a provider building the system or a deployer using someone else's, the rules apply. A US or Asia-based company selling software into the EU market is just as exposed as a company headquartered in Berlin.

This catches a lot of teams off guard. "We're not an EU company" is not the exemption people assume it is. The Act follows the same extraterritorial logic the EU already applied with GDPR: what matters is where the output lands, not where the company is registered. A hiring platform built in Seattle that screens candidates for an EU-based employer is squarely in scope. A chatbot built in Singapore that serves EU customers is in scope. The businesses genuinely outside the regulation are the ones with no EU market exposure at all, and for most software companies today, that's a narrower group than it sounds.

It's also worth separating two roles the Act treats differently: providers, who build and place AI systems on the market, and deployers, who use those systems under their own control. The same company can be a provider for one system and a deployer for another, and the obligations differ sharply between the two. Getting this distinction wrong is one of the most common early missteps, especially for companies that integrate or customize a third-party model closely enough that they've effectively become a provider without realizing it.

The four risk tiers

The Act classifies AI systems into four tiers, and your obligations scale with the tier.

• Unacceptable risk. Banned outright. Examples include social scoring systems that assess people's trustworthiness based on behavior, and manipulative AI that exploits vulnerabilities like age or disability to distort someone's decisions.
• High risk. Heavily regulated. Examples include AI used in hiring and candidate screening, credit scoring, biometric identification, and critical infrastructure management. This tier carries the heaviest documentation and oversight requirements: risk management systems, data governance standards, technical documentation, logging, and human oversight all apply here.
• Limited risk. Transparency obligations apply. Chatbots and deepfake generators fall here; the requirement is disclosure, not restriction. Users need to know they're interacting with AI, or that content has been artificially generated or manipulated.
• Minimal risk. Little to no obligation. Most everyday AI applications, like spam filters and recommendation engines, sit in this tier and are largely left unregulated.

Most compliance effort concentrates in the high-risk tier, which is also where classification gets genuinely difficult. A CV-scanning tool that ranks applicants sounds like ordinary software until you realize it now falls under the same rules as biometric identification. Correctly classifying your systems is the first real decision point, and it's one many organizations get wrong by defaulting to whichever tier feels least disruptive rather than the one that actually applies.

Deadlines that already passed

Some of the Act's obligations have been live for a while, and if your organization hasn't addressed these, you're not early. You're behind.

• February 2, 2025: prohibited practices banned, and an AI literacy obligation took effect for providers and deployers. In practice, this means organizations need to be able to show that staff working with AI systems have sufficient literacy for their role and seniority. Most organizations still have no baseline documentation on file for this.
• August 2, 2025: general-purpose AI (GPAI) model obligations kicked in, covering technical documentation, training data summaries, and copyright policy. These obligations attach at the model level, regardless of how the model is used downstream, so any organization building on top of a GPAI model inherits exposure here even if they didn't train the model themselves.
• August 2, 2026: Article 50 transparency obligations took effect. Chatbots, deepfake generators, and other limited-risk systems now need to disclose that people are interacting with AI, or that content has been artificially generated or manipulated, and national authorities began enforcing the AI literacy obligation. High-risk Annex III obligations were originally due this same date too, but the Digital Omnibus deferred those further. Transparency wasn't part of that deferral, so it's enforceable now.

What's still ahead

Those high-risk deadlines didn't disappear. The Digital Omnibus on AI, a set of amendments negotiators from the Council of the European Union, the European Parliament, and the European Commission reached provisional agreement on in May 2026, pushed them back much further than originally planned:

• December 2, 2026: the obligation to label synthetic audio, image, and video content in a machine-readable, detectable format, for systems placed on the market before August 2, 2026. Systems placed on the market after August 2, 2026, still need to comply from their launch date.
• December 2, 2027: the new deadline for standalone high-risk AI systems under Annex III, deferred from the original August 2, 2026 date. This covers systems like hiring tools, credit scoring, and biometric identification that aren't embedded in another regulated product.
• August 2, 2028: the new deadline for high-risk AI systems embedded in already-regulated products, such as medical devices and machinery, deferred from the original August 2, 2027 date.

None of this is a reprieve. It's a staggered runway, not an exit ramp. The Digital Omnibus adjusted timing and added some targeted simplification, but it didn't remove any core obligation. Organizations that read "deadline extended" as "problem solved" are setting themselves up for a scramble later, especially since conformity assessment itself typically takes six to twelve months once a system is ready for it.

What enterprises should do

None of this needs to wait for a regulator to come knocking. Here are a few concrete steps you can take now to put you ahead of the next deadline:.

• Inventory every AI system in use, including third-party and open-source models. You can't classify risk on systems you haven't mapped, and most organizations underestimate how many AI touchpoints exist across APIs, embedded model integrations, and legacy systems.
• Classify by role and risk tier for each system, not once for the whole organization. Know whether you're a provider or a deployer per system, since the line can shift if you rebrand, fine-tune, or otherwise modify a third-party model closely enough to become its provider.
• Check documentation against what auditors actually expect: technical files, risk management records, data governance evidence, logging and traceability, and human oversight controls. A privacy policy and a marketing page are not technical documentation.
• Validate vendor claims independently. A vendor marketing a tool as "EU AI Act ready" is not the same as a system that's been tested against the Act's actual requirements. Some vendors are now charging 20 to 30% more to cover certification and engineering overhead, which makes it worth confirming what you're actually paying for before you take the label at face value.
• Set internal deadlines ahead of official ones. Waiting until the regulatory deadline to start is how gaps get discovered too late to fix cheaply. Most compliance gaps in AI systems get locked in during the scramble from proof of concept to production, and untangling them after a system is live costs far more than catching them beforehand.

The penalties of non-compliance

Fines under the Act exceed GDPR's. Article 99 sets a three-tier structure: up to €35 million or 7% of global annual turnover for prohibited practices, whichever is higher; up to €15 million or 3% of turnover for most other high-risk and transparency violations; and up to €7.5 million or 1% of turnover for supplying false or misleading information to regulators. For a company with €1 billion in revenue, the top tier alone means €70 million of exposure. Small and medium enterprises get the lower of the two figures instead of the higher one, so the structure doesn't scale down proportionally the way the fixed euro amounts might suggest.

The Act doesn't replace GDPR either. Both apply concurrently to any AI system processing personal data, which means organizations already carrying GDPR compliance overhead now have a second, overlapping framework to satisfy, not a substitute for the first.

As of mid-2026, no fines have yet been made public under the AI Act's own Article 99 penalty regime, since the machinery to enforce the highest-profile obligations only recently switched on. That's not a reason to relax. Enforcement regimes like this tend to start slowly, driven by complaints and high-profile incidents, then accelerate once the regulator has tested its own authority. GDPR followed exactly this arc: early years were quiet, and the companies that built compliance infrastructure before enforcement ramped up spent far less than the ones that waited. There's no reason to expect the AI Act will play out differently, and the deferred high-risk deadlines only extend the window companies have to prepare before that enforcement curve begins.

Where to start

None of this requires solving everything at once. It requires knowing where you actually stand: which systems you have, what role you play for each one, what risk tier they fall into, and whether your documentation would hold up against an actual audit rather than a self-assessment.

TestDevLab's EU AI Act compliance audit is built around exactly that gap. It's a technical and operational review, not a legal opinion, so it tests whether your systems behave the way your documentation claims they do, and flags the triggers, like a rebranded third-party model, that can quietly convert a deployer into a provider before anyone notices.