When the European Parliament adopted the AI Act in March 2024, the headline practically wrote itself: the world’s first comprehensive AI regulation, built on a risk-based architecture sorting AI systems into four tiers—prohibited, high-risk, limited-risk, and minimal-risk. Politicians celebrated the clarity. Commentators called it predictable. Lobbyists claimed victory or defeat depending on their constituency. What almost nobody bothered explaining was the question that will determine whether the framework actually functions: who decides which systems fall into which category?

The answer is not the Parliament. Not the Council. Not even the Commission acting alone. The classification work that gives the AI Act its practical meaning is being carried out through harmonized standards developed by CEN-CENELEC, the European standardization organizations, under mandates from the Commission. It is being shaped through delegated acts that the Commission can adopt without returning to the ordinary legislative procedure. It is being elaborated through implementing acts that translate broad category descriptions into specific technical requirements. These instruments receive a fraction of the scrutiny that the AI Act itself generated during its two-year legislative journey. Yet they will determine whether a healthcare triage model, a recruitment screening tool, or a content moderation system is treated as high-risk—and therefore subject to conformity assessment, post-market monitoring, transparency obligations, and the full weight of regulatory supervision.

The Classification Architecture Everyone Celebrated

The AI Act’s risk-based framework was designed to be intuitive. Annex III lists specific use cases automatically classified as high-risk: biometric identification, critical infrastructure management, education and vocational training access, employment and worker management, essential services access, law enforcement, migration and border control, and the administration of justice. Each category comes with a general description that, on its face, seems clear enough. A system used to evaluate job applicants is high-risk. A system used to filter spam is not. The architecture was politically attractive precisely because it appeared to sort the world into legible containers without requiring case-by-case judgment.

But that apparent clarity dissolves on contact with actual systems. Consider a healthcare triage model that uses machine learning to prioritize patients in emergency departments. Is it high-risk because it manages access to essential services? Or is it minimal-risk because a human clinician reviews every recommendation before action is taken? The AI Act’s text offers a general principle—human oversight reduces risk—but does not specify how much oversight is sufficient, what kind of oversight counts, or whether a human reviewer who rubber-stamps algorithmic recommendations constitutes meaningful supervision. These are not edge cases. They are the central cases. Most real AI systems sit at the boundary between categories, and the classification decision determines the regulatory burden they face.

The framework does anticipate this problem. Article 7 allows the Commission to amend Annex III by delegated act, adding or modifying high-risk use cases as the technology evolves. Article 73 provides for harmonized standards that, when adopted by CEN-CENELEC, create a presumption of conformity for systems that meet them. Article 40 permits the Commission to adopt implementing acts establishing technical specifications when harmonized standards are insufficient or absent. Together, these provisions create a secondary legislative architecture that will do the real classification work—and that operates almost entirely outside the political spotlight.

Where the Real Classification Work Happens

The Commission issued its standardization request to CEN-CENELEC in mid-2024, asking the European standardization bodies to develop harmonized standards covering the AI Act’s requirements for high-risk systems: risk management systems, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, and robustness. This request is not a formality. It is the mechanism by which the AI Act’s abstract requirements become concrete technical specifications that developers can implement and conformity assessment bodies can verify.

The work happens in technical committees composed of national standards body delegates, industry experts, academic specialists, and—occasionally—civil society representatives. The committees deliberate over definitions, thresholds, testing methodologies, and documentation formats. They decide what constitutes adequate data quality for a training dataset, what level of accuracy is sufficient for a high-risk system, how robustness should be tested, and what information must appear in technical documentation. These are not minor elaborations. They are the substantive content of the regulation, translated from political language into engineering specifications.

The parallel to other risk-classification regimes is instructive. Google’s Site Reliability Engineering framework operationalizes abstract risk concepts into concrete operational thresholds through service-level objectives and error budgets—translating the principle that some risk is acceptable into measurable parameters that engineering teams can work with. The Google SRE book’s treatment of embracing risk demonstrates how a risk-based framework requires detailed translation from abstract categories into operational, measurable terms before it can function in practice. The AI Act faces the same translation challenge, but instead of being resolved by engineering teams within a single organization, it is being negotiated across dozens of national standards bodies, hundreds of technical experts, and multiple competing industry interests.

NIST’s Cybersecurity Framework offers another relevant parallel. The CSF 2.0 process—quick-start guides, community profiles, informative references, mappings—shows how a published risk framework evolves through continuous technical elaboration rather than remaining static legislative text. The NIST Cybersecurity Framework’s structure of profiles and informative references illustrates how standards bodies fill the gap between a published framework and its operational reality through technical instruments that receive minimal public or legislative scrutiny. CEN-CENELEC’s work on the AI Act follows a similar logic, but with even less transparency: NIST publishes draft profiles for public comment, while CEN-CENELEC technical committee documents are accessible primarily to committee members and national delegations.

The Transparency Problem Nobody Framed as a Problem

During the AI Act’s legislative passage, transparency was a central political demand. Civil society organizations pushed for public registries of high-risk systems, mandatory fundamental rights impact assessments, and disclosure obligations for deployers of AI in sensitive contexts. The final text includes several of these measures. But the transparency debate focused almost entirely on the use of AI systems after they are classified. The classification process itself—the work of deciding which systems count as high-risk—was treated as a technical implementation detail rather than a political decision.

That framing matters because the classification process is where the politics actually happens. When a technical committee decides that a recruitment screening tool must meet a certain accuracy threshold to qualify for the high-risk conformity presumption, it is making a decision about the burden the AI industry will bear. When a delegated act adds a new use case to Annex III, it expands the scope of regulatory supervision without a parliamentary vote. When an implementing act establishes technical specifications that override the absence of harmonized standards, it creates de facto law through a procedure that most citizens—and many parliamentarians—do not know exists.

The institutional structure of CEN-CENELEC compounds the transparency deficit. Technical committee participation requires resources: travel to meetings, technical expertise to contribute to drafting, and institutional standing to be appointed as a national delegate. Large technology companies and established industry associations can afford this participation. Small companies, civil society organizations, and academic researchers often cannot. The result is a classification process in which industry influence is structural rather than conspiratorial—embedded in the participation requirements themselves rather than exerted through lobbying or campaign contributions.

Delegated Acts: The Legislation Nobody Voted On

The AI Act grants the Commission power to adopt delegated acts under Article 7 to amend Annex III, adding or modifying high-risk use cases. This is not an unusual mechanism in EU law—delegated acts are a standard feature of the regulatory architecture, designed to allow technical updates without reopening the entire legislative file. But in the context of the AI Act, delegated acts carry particular weight because the risk classification determines the entire regulatory burden a system faces.

The scrutiny framework for delegated acts is theoretically strong. Parliament and Council have the right to object to delegated acts, and they can revoke the delegation itself. In practice, this scrutiny is sporadic. The European Parliament’s capacity to monitor delegated acts across all policy areas is limited by staff resources and committee workload. Delegated acts on AI classification will compete for attention with delegated acts on financial regulation, environmental standards, product safety, and dozens of other policy areas. The political incentive to scrutinize a technical amendment to an annex of a regulation adopted two years ago is low. The technical capacity to evaluate whether the amendment is justified is lower still.

Meanwhile, delegated acts on AI policy are increasingly where the real rulemaking happens. The AI Act’s framework is designed to be updated through these instruments as the technology evolves, which means the regulation’s substantive scope will be defined through a series of Commission decisions made over the coming years, each determining whether new categories of AI systems fall within or outside the high-risk regime. The Parliament that spent two years debating the AI Act’s risk tiers will have, at best, a procedural veto over these decisions. The public that followed the legislative debate will have almost no awareness that they are happening.

The Standards Gap: What Happens When Harmonized Standards Do Not Materialize

The AI Act’s conformity presumption depends on the existence of harmonized standards. If a system meets a harmonized standard, it is presumed to comply with the corresponding requirements of the regulation. If no harmonized standard exists, developers must rely on the regulation’s text directly, which is too general to serve as a technical specification, or on implementing acts that establish common specifications as a fallback.

The problem is that harmonized standards take time to develop, and the AI Act’s compliance deadlines do not wait. The first wave of obligations—prohibited practices and AI literacy requirements—applied from February 2025. The high-risk system requirements for certain sectors apply from August 2026, with extensions for certain classifications. CEN-CENELEC’s technical committees are working against these deadlines, but the complexity of the task means harmonized standards for many high-risk categories will not be ready in time.

This gap creates a regulatory limbo. Developers of high-risk systems that should be subject to harmonized standards will instead face the regulation’s general requirements without technical specifications to guide compliance. Conformity assessment bodies will have to evaluate systems against criteria that have not been standardized. National market surveillance authorities will have to enforce requirements that are technically underspecified. The result is a period of regulatory uncertainty that benefits actors with the resources to navigate ambiguity—large companies with legal teams—and penalizes those without: startups, small developers, public sector deployers.

The implementing act fallback is not a satisfactory substitute. Common specifications adopted by the Commission are meant to be temporary measures, not permanent replacements for harmonized standards. They are developed through a faster procedure than standardization, but with even less stakeholder participation. And they carry less legitimacy than harmonized standards, which at least benefit from the procedural authority of the standardization system, even if that authority is imperfect.

Why Institutional Memory Matters More Than Legislative Text

The AI Act’s long-term effectiveness will depend less on the text that Parliament voted on than on the institutional infrastructure that interprets, updates, and enforces that text over time. This infrastructure includes CEN-CENELEC technical committees, Commission delegated act procedures, the AI Office’s coordination role, national market surveillance authorities, conformity assessment bodies, and the courts that will eventually interpret ambiguous provisions.

Each of these institutions will develop its own understanding of what the AI Act’s risk categories mean in practice. Technical committees will produce standards that embed certain assumptions about what constitutes adequate risk management. Conformity assessment bodies will develop evaluation methodologies reflecting their institutional expertise. Courts will interpret disputed classifications in ways that create precedent. None of these interpretations will be subject to the kind of political debate that accompanied the AI Act’s passage. They will accumulate through institutional practice, gradually becoming the de facto meaning of the regulation.

The challenge for anyone trying to understand or influence EU AI policy is that this interpretive work is scattered across institutions with different cultures, different incentives, and different levels of transparency. Tracking the AI Act’s evolution requires following technical committee drafts, monitoring delegated act consultations, reading implementing act proposals, attending AI Office stakeholder meetings, and watching court cases as they move through national judiciaries toward the European Court of Justice. The institutional knowledge required to do this well exceeds what most organizations can sustain, which is why the field will be dominated by specialized consultancies, large law firms, and well-resourced industry associations.

The Documentation Challenge for Affected Organizations

For organizations building or deploying AI systems that may fall within the AI Act’s scope, the classification uncertainty creates a practical documentation challenge. They must maintain records demonstrating their reasoning for placing a system in a particular risk category, anticipating that the classification may be challenged by market surveillance authorities, contested by competitors, or revised by future delegated acts. The documentation must be detailed enough to survive regulatory scrutiny but flexible enough to accommodate evolving standards.

This is not a trivial requirement. A company developing a content moderation system that uses machine learning needs to document why it believes the system is not high-risk, what evidence supports that assessment, how the system’s design addresses potential harms, and what monitoring mechanisms will detect if the classification should change. The documentation must be intelligible to regulators who may not understand the technical details, precise enough to support a legal argument, and structured in a way that allows updates as the regulatory landscape shifts. Organizations building internal tools to manage this kind of structured documentation—whether through policy templates, classification decision trees, or an AI script writer that helps structure compliance narratives—are responding to a genuine gap between what the regulation requires and what most organizations can produce without dedicated support.

The Real Politics of Classification

The AI Act’s risk-based framework was politically successful because it offered the appearance of clarity without requiring legislators to make the hardest decisions. Parliament did not have to vote on whether a specific healthcare triage model is high-risk. It voted on a framework that delegates that decision to technical committees, Commission delegated acts, and the gradual accumulation of institutional practice. This is not a criticism unique to the AI Act—it is a feature of modern regulatory architecture, where legislatures set frameworks and secondary bodies fill in the details. But it means the political debate over AI regulation is not finished. It has simply moved to venues where most people are not looking.

The organizations that understand this shift will shape the AI Act’s practical meaning. The ones that do not will find themselves subject to a regulatory framework that was negotiated without their input, interpreted according to standards they did not know were being written, and enforced through classification decisions they had no opportunity to influence. The gap between the AI Act’s celebrated risk tiers and the classification infrastructure that will give them meaning is where the real politics of AI regulation now resides. It is not a gap that will close on its own.

For policy professionals, journalists, and researchers who care about how AI is governed in Europe, the task now is to follow the secondary instruments that will determine the regulation’s substance: the CEN-CENELEC technical committee outputs, the delegated act proposals, the implementing act drafts, the AI Office guidance documents. These are not glamorous venues. They do not generate headlines. But they are where the AI Act’s risk categories will acquire their practical content—and where the political decisions that Parliament deferred will actually be made.