From 2 August 2026, the European Commission's AI Office gained authority to enforce obligations for general-purpose AI systems under the AI Act. The Office can demand documentation under Article 91, conduct its own evaluations under Article 92, and order corrective action under Article 93. Hungary has floated the idea of stationing EU safety teams directly within frontier labs.
Yet the Office faces a structural problem: it enforces against definitions it barely controls, and these definitions resist easy comparison across firms. Compliance standards, frontier safety thresholds, and even the meaning of "frontier" remain partly shaped by each provider's own criteria and internal expertise. More fundamentally, this arrangement blinds regulators to a critical category of evidence. AI safety involves more than technical reporting or methodological disclosure. It requires choices about what "safe" means, which evaluations count as conclusive, and when to cease testing for safety-relevant traits. These judgments fundamentally determine a model's safety posture, yet providers face no accountability for them and are not required to reveal them as deliberate choices. Gaining access to these decisions is the essential first step.
A regulator-owned taxonomy offers a path forward. Such a tool could render these choices legible without dictating how providers must make them. The ability to challenge these choices depends on their visibility and their recognition as judgments rather than technical necessities. Without visibility, external actors have nothing to contest, and no way to assign responsibility when failures occur.
How judgment calls pass as technical and necessary choices
In practice, AI Act enforcement operates largely through the Code of Practice, a voluntary commitment that providers adopt to establish presumed compliance with Articles 53 and 55. The Code identifies key development stages where disclosure obligations apply, but it does not specify what counts as material information or how it should be characterized, leaving that determination to providers themselves.
A provider can satisfy requirements while disclosing minimally, or can choose to disclose extensively, with no guarantee that such disclosure serves safety purposes. Some Code sections do require justification—for example, risk-tier acceptance criteria in the Safety and Security chapter—but they still permit discretion over what constitutes adequate justification and how thoroughly to justify. Many non-technical choices across a model's development remain invisible and uncoordinated.
Three concrete cases illustrate this gap: one where a value judgment masquerades as a method, one where a concept is disputed and cannot be resolved through better science alone, and one involving corporate discretion.
The first appears in OpenAI's GPT-6 Astra System Card. Astra is designed to decline harmful requests. When tested for capability, if it refuses a user's request, that refusal is inherently ambiguous—it could mean the model lacks the capability or simply chooses not to use it. OpenAI chose to count refusals as successes (GPT-6 Astra System Card, §10.1.1), treating the model as capable but unwilling to assist. This reflects a preference about which error to tolerate: false positives about capability or false negatives. The choice is defensible and partially disclosed, yet the system card does not distinguish it from a technical finding, nor is OpenAI required to do so.
The second example also comes from the Astra card (GPT-6 Astra System Card, §9). OpenAI reported that monitoring Astra's reasoning had become harder and less reliable. The company deployed anyway, relying on the model's underlying alignment as the primary safeguard and stating they will not tolerate further monitorability loss. More evaluators or improved methodology will not automatically close this gap. Additional experts still assess against standards set by providers, and while methodological advances can narrow disagreement where science is immature, no amount of technical refinement alone settles what "harmful" or "good evaluation" mean.
The third involves high-level business decisions. Anthropic declined to grant the UK AISI early access to Mythos 5.1, then days later Dario Amodei's statement "We Must Pace the Frontier" committed the company to embedded third-party evaluators. Either decision could reflect good faith, commercial judgment, external pressure, or some combination. The outcome happens to align with safety interests, but regulators cannot rely on luck. Good faith and non-safety incentives end up performing work that should belong to regulators.
Each of these decisions may be justified. Yet a model's safety profile emerges from dozens of such calls, and a generic requirement to disclose acceptability criteria captures none of them. Regulators must pinpoint exactly where justification should occur, even if they do not dictate the standard for what justification should contain.
A regulator-owned taxonomy
Expecting regulators to establish fixed safety standards is unrealistic and may miss the mark given rapid technological change. The next Code revision should instead make value-laden decisions disclosable and comparable across time and providers through a regulator-owned taxonomy mapping the steps in a model's lifecycle where non-technical judgment calls arise. This would enable the Office to identify patterns across providers—which positions cluster, which labs are consistent outliers and why—and to scrutinize the reasoning behind them. Critically, judgment that exists only as informal practice within a few labs becomes a shared, documented record, freeing the Office from dependence on providers' claims about where relevant information resides.
The approach works in four steps. First, providers situate their model within a public taxonomy they did not author. The Office maintains a public taxonomy of the steps across a model's lifecycle where value-laden choices are unavoidable. This could mirror the Code's existing phases, from risk identification through post-market monitoring. A first iteration need not await provider input: all three examples above derive from public documents. Currently the Code asks providers to justify conduct and criteria they themselves establish, allowing providers to define which decisions warrant disclosure, at what detail, and for what reason. Under the taxonomy, they would instead locate each decision and its underlying principles in a systematized, more granular structure they did not design. This reduces the Office's reliance on providers. Without knowing which decisions they make at which step, enforcement becomes impossible.
Second, verification can and should be delegated. Independent accredited bodies can audit whether the provider's reported placement is truthful. This represents genuine measurement against a fixed public standard. Evaluators never judge which position is correct, only whether the evidence matches the declared position.
Third, the taxonomy records positions rather than grading them, and enforcement targets honesty. The taxonomy does not collapse judgments into a single safety verdict, and providers can adopt different principles across steps while reporting truthfully. Initial enforcement would focus on honest judgment rather than on outcome, encouraging transparency. What can be adjudicated is whether the provider placed its model faithfully and disclosed its judgment where multiple positions existed.
Fourth, the framework and placements remain open to challenge. Where a disclosed position and evidence diverge, providers can face investigation under the AI Act. The Office retains responsibility for expanding the taxonomy. Because the structure is uniform across frontier labs, positions become comparable over time. Making these choices legible and comparable also allows regulators to assess where the frontier of AI safety actually stands and whether it genuinely tracks the frontier of capabilities.
The AI Office has the necessary powers
The Office does not require additional substantive powers to implement this approach. The next Code revision could establish the taxonomy with input from the Scientific Panel (Art 68) based on demonstrated gaps in the current Code. Article 91 permits documentation requests, which could be structured around this new taxonomy. Under Article 92, Office evaluations could test placements against the taxonomy, and misplacement or omissions could constitute incorrect or misleading information under Article 101.
Placements would be public; the evidence supporting them, which may contain commercial or security sensitivities, could flow through confidential channels the Office already operates. This sharpens enforcement, as outliers become apparent. Over time, the Office could supplement this with its own guidance on general value-laden trade-offs, such as prioritizing privacy in specific domains.
The taxonomy represents a middle path between mandating frontier safety standards and allowing industry self-regulation, and it could diminish the Office's epistemic dependence on frontier labs. Even embedded evaluators with full access would still need to know which decisions to examine. The Office could direct its own evaluations toward unusual steps, structure documentation requests more precisely, and identify which judgment call proved consequential when problems arise. Without such structure, the cycle persists: providers control what counts as safety-relevant and how it is described. When described as technical decisions, judgments escape scrutiny, and without scrutiny, no one can reframe them otherwise.
