The EU AI Act: What It Actually Requires, and Why Most Teams Are Behind

Most people in enterprise AI have heard of the EU AI Act. Very few have actually read it. The gap between "we know this is coming" and "we understand what we need to do" is enormous — and the window is smaller than most teams realise. Some provisions have been law since February 2025. More land in August 2026. The AI Act is not abstract regulation for someone else to worry about. If you build AI, buy AI, or use AI in any professional capacity that touches EU users, it applies to you — regardless of where your company is registered. Here's what it actually says.

The context: The AI Act uses a risk-based structure. Not all AI is regulated equally. The Act places every AI system into one of four tiers based on how much harm it can cause, and the obligations scale accordingly. This is the framing everything else sits within.

The concept: Think of it like food safety regulation. Most food (minimal risk) just needs to not poison anyone — no special labelling required. Some food (limited risk) needs ingredient labels. High-risk food (like infant formula, medical nutrition) needs certifications and audits. And some things are simply banned — not regulated, but prohibited outright. The AI Act follows the same logic. Most AI has no mandatory obligations. Some needs transparency labels. High-risk AI needs formal assessments. And a specific list of AI practices are illegal in the EU — full stop.

The problem: The banned list is more surprising than people expect. Since 2 February 2025, it is illegal in the EU to: use AI to detect emotions in workplaces or schools; build or use systems that scrape faces from the internet or CCTV to build recognition databases; deploy AI that infers race, religious beliefs, political opinions, or sexual orientation from biometric data; use predictive policing AI based solely on profiling; and run real-time facial recognition in public spaces for law enforcement without specific judicial authorisation for a specific case. These are not future restrictions. They are current law. Teams using tools in these categories — including some "engagement monitoring" workplace platforms and some proctoring tools — are already operating unlawfully in the EU.

The pattern: Do the banned-list audit first. It takes a day. Review every AI tool in your stack that operates in the EU. For anything touching biometrics, emotion detection, or behavioural scoring, check it against the February 2025 prohibitions. If something is on the banned list, the compliance path is not "document it properly" — it's stop using it.

The context: The "high-risk" tier is where most of the Act's substantive obligations live. Conformity assessments, technical documentation, human oversight requirements, bias-free training data mandates, incident reporting, registration in an EU database — all of this applies specifically to high-risk AI. The question that matters is: which systems qualify?

The concept: The Act defines high-risk through two routes. Route one: AI embedded in products already regulated under EU safety law — medical devices, machinery, aviation equipment. If the existing product needs third-party certification, the AI inside it is automatically high-risk. Route two: eight specific categories of use cases listed in Annex III of the Act. These are: biometric identification; critical infrastructure management; education (admissions, assessment, proctoring); employment (recruitment, performance evaluation, task allocation); access to essential services (credit scoring, insurance underwriting, benefits eligibility); law enforcement; migration and border control; administration of justice. If your AI does any of these things for EU users, it is high-risk.

The problem: Most enterprise AI teams assume "high-risk" means AI being used in extraordinary settings — medical diagnostics, criminal justice. They do not think of their CV-screening tool, their performance management system, or their credit decisioning engine in those terms. But all of those systems sit squarely in the Annex III categories. A US fintech with EU customers using AI to approve or reject loan applications has a high-risk AI system under the Act, regardless of where the company is headquartered.

The pattern: Map every AI system against the eight Annex III categories. Be honest. The escape clause exists (systems that only do narrow procedural tasks or don't replace human assessment can self-declare as not high-risk) but it requires a documented determination that can withstand regulatory scrutiny. If a system makes decisions or recommendations that significantly affect individuals — employment, credit, education, benefits — assume it is high-risk and work back from there.

The context: For every high-risk AI system, Article 10 of the AI Act mandates specific data governance requirements. These are not about data protection in the GDPR sense. They are about the quality and representativeness of the data used to train the system in the first place. This is where many teams will find their biggest compliance gap.

The concept: Imagine you are trying to build a fair hiring process. You have a pile of historical CVs and hiring decisions. The problem is that history reflects bias — past hiring decisions were made by humans with blind spots, in a company culture that may not have been inclusive. If you train an AI on that data without examining it, you bake the bias in. Article 10 requires providers to actively audit training data: is it relevant? Is it representative of the population the system will affect? Are there errors? Where are the gaps? And critically — does the data embed historical biases that the system might amplify? This is not a one-time check. It must be documented and maintained as the system evolves.

The problem: Most organisations that have deployed AI using historical operational data have not done this analysis. The data was "what we had." The model was trained because it improved metrics on a test set. Whether the training data was representative across age, gender, ethnicity, or socioeconomic background was not systematically evaluated. The AI Act requires that this is now done — and documented — before you can legally deploy high-risk AI in the EU.

The pattern: Start the data audit now, not during conformity assessment. Pull your high-risk systems' training datasets and ask: which groups does this model affect? Are those groups proportionally represented in the training data? Are there known historical biases in how that data was generated? Document the answers. Where gaps exist, either expand the training data or constrain the system's claimed scope of use. The GDPR/AI Act tension (you may need to process sensitive categories to check for bias) is real — document your legal basis carefully.

The context: The EU AI Act was deliberately designed with extraterritorial reach, modelled on the GDPR. The jurisdictional rule is simple: if your AI system affects people in the EU, the Act applies to you. Nationality, company registration, server location — none of these are exemptions.

The concept: The GDPR established that EU data protection rights follow EU residents, not EU companies. The AI Act does the same for AI. A company in California that sells HR software used by a German employer to screen job applications is a provider of a high-risk AI system under the Act. It needs technical documentation. It needs to conduct a conformity assessment. It needs to register in the EU AI database. And it needs to appoint an EU Authorised Representative — a legal entity established in the EU that can be held responsible for the company's AI Act compliance. Without one, the company cannot legally place a high-risk AI system on the EU market.

The problem: Many non-EU companies are not taking this seriously because they lack a physical EU presence and have assumed the regulation does not reach them. The GDPR experience is instructive here. For years, US companies ignored GDPR. Then came multi-hundred-million-euro fines against Meta, Amazon and others. The AI Act's penalty structure is even sharper: up to 7% of global annual turnover for prohibited AI violations. A company with $10 billion in global revenue faces exposure of up to $700 million per violation. The enforcement machinery exists and will be used.

The pattern: Non-EU companies should conduct the same high-risk AI mapping as EU-based companies, then layer on two additional steps. First, identify which systems have EU users and categorise them accordingly. Second, for any confirmed high-risk AI systems with EU exposure, appoint an EU Authorised Representative — this is a legal prerequisite, not an optional formality. Build the supply chain due diligence into vendor contracts: if you are deploying AI built by a third party, get representations about their AI Act compliance status.

The context: Chapter V of the AI Act introduces a separate, parallel set of obligations for General Purpose AI (GPAI) models — the large foundation models like GPT-4, Claude, Gemini, and Llama that an entire ecosystem of applications is built on. These obligations have been in force since 2 August 2025. If your AI product is built on top of one of these models, you are in a dependency relationship with an entity that has its own regulatory obligations — and understanding that relationship matters for your own compliance.

The concept: Think of GPAI rules like building code for the structural steel used in construction. Individual builders are responsible for their buildings, but the steel suppliers have their own certification requirements. If the steel is non-compliant, the whole building is affected. The AI Act requires all GPAI model providers — including those based in the US — to produce technical documentation about their models, publish summaries of training data, and comply with EU copyright law. The largest models (above 10²⁵ FLOPs training compute, roughly GPT-4 class and above) are classified as "systemic risk" models and face additional obligations: adversarial testing, systemic risk evaluation, cybersecurity requirements, and incident reporting to the EU AI Office.

The problem: Developers building products on top of foundation models often treat the model as a black box. The AI Act makes that position legally uncomfortable. If a deployer builds a high-risk AI application using a GPAI model, the deployer is responsible for their application's compliance — but the foundation model provider is responsible for providing the information that makes that compliance possible. The Act requires GPAI providers to give downstream developers the documentation they need to understand the model's capabilities and limitations. If that documentation is unavailable or inadequate, compliance becomes harder to demonstrate.

The pattern: Audit your foundation model dependencies. For each GPAI model you use in a high-risk application: does the provider publish GPAI compliance documentation? Have they published a training data summary? Are you operating within the model's documented intended use? These questions matter because your conformity assessment for the application layer needs to account for what the underlying model was designed to do. If you are building on a model with inadequate documentation, that is a compliance risk you are inheriting.

The context: The most common misconception about the EU AI Act is that it is a future regulation — something to prepare for later. This is incorrect. The Act has been in force since August 2024. Prohibited practices have been illegal since February 2025. GPAI model obligations have applied since August 2025. And the high-risk AI compliance deadline is August 2026 — three months away as of this writing.

The concept: Think of the AI Act's rollout less like a single regulation that switches on, and more like a series of overlapping deadlines, each bringing new obligations into effect. The prohibited practices tier was the first wave — already past. The GPAI tier was the second wave — also past. The high-risk AI tier is the third wave — approaching fast. And the full enforcement machinery for GPAI providers (including the EU AI Office's penalty powers against foundation model companies) only fully activates in August 2026. After that, the Act is fully operational across all tiers. What looks from the outside like "a future regulation" is actually a regulation that is already partially in force and completing its rollout.

The problem: Most organisations have been treating August 2026 as the single deadline. They have not noticed that they were already non-compliant with the February 2025 banned list, or that GPAI obligations have been active since August 2025. And the AI Omnibus agreement of May 2026 has created additional confusion — it extends some deadlines (the general high-risk deadline moves to December 2027 in most interpretations), which has caused some teams to assume they have even more time. But the Omnibus does not change the prohibited list or the GPAI rules. Those are in force now.

The pattern: Map your compliance posture to each tier's actual effective date, not to a single assumed deadline. Prohibited AI: must be compliant now (February 2025 was the deadline — you are already late if anything on the banned list is live). GPAI: must be compliant now if you are a foundation model provider. High-risk AI: full compliance required by August 2026 for pre-existing systems, December 2027 under the Omnibus for most — but conformity assessments and documentation must be built well in advance of those dates. AI literacy training for staff: legally required now, with no transition period.

If a regulator walked into your organisation today and asked to see your AI inventory, your classification of each system against the Annex III categories, your documented reasoning for why certain systems are not high-risk, your training data governance records, and your AI literacy training programme — what would you hand them? For most organisations, the honest answer is: not much. The EU AI Act is not primarily a legal problem. It is a data and engineering problem dressed in legal language. The organisations that treat it that way, starting now, will be in a fundamentally different position from those that delegate it to legal and wait.

Sources: EU AI Act full text (artificialintelligenceact.eu), European Commission AI Office, AI Omnibus Council agreement May 2026, Latham & Watkins GPAI analysis, Future of Privacy Forum conformity assessment guidance, BSR 2025 implementation review