Every general description of “AI governance” eventually has to answer a narrower question: on a Tuesday morning, what does the person responsible for compliance actually do? They do not read principles. They open a worksheet, a rack of documentation requirements, or a procurement checklist, and they make a determination that has to survive an audit. This article follows that work at the level of the actual document: the statute clause a classification decision cites, the framework function an audit trail is organized around, the standard clause a certification body checks, and the guidance memo a procurement officer applies. It treats fact, vendor claim, analysis, scenario, and prediction as five different things and labels each one as it appears.
Classifying a system’s risk tier under a real framework
The EU AI Act - Regulation (EU) 2024/1689 - is the most detailed operative example of tiered AI risk regulation currently in force, and its classification mechanism is a useful place to start because it is unusually explicit about its own logic [1]. Article 6 sets out two independent routes by which a system becomes “high-risk,” and a deployer has to check both, not just the one that seems more obviously relevant [2].
The first route runs through existing product-safety law. If a system is intended for use as a safety component of a product already covered by Union harmonisation legislation - listed in Annex I, covering categories like machinery, toys, lifts, and medical devices - and that product must undergo third-party conformity assessment under that legislation anyway, the AI system inherits high-risk status automatically. This route matters in practice because it means an AI component bolted onto a medical device or an elevator control system does not get evaluated on its own terms; it is swept in by the product it lives inside.
The second route is standalone: Annex III lists specific use areas - among them employment and worker management, access to essential services such as credit scoring, law enforcement, migration and border control, and the administration of justice - where an AI system is deemed high-risk purely by virtue of what it is used for, independent of any other product it might be embedded in [2]. A résumé-screening tool used to shortlist applicants sits squarely in Annex III’s employment category regardless of how technically simple the underlying model is; classification tracks function, not sophistication. This is the detail practitioners find counterintuitive: a shallow logistic regression used to rank loan applicants is high-risk, and a much larger model used for an internal engineering task with no Annex III use case is not. Risk tier is a property of deployment context, not of parameter count or architecture.
The practical classification workflow, in most compliance programs, is therefore a two-question worksheet run against every deployed system: does this system serve as a safety component of an Annex I product requiring third-party conformity assessment, and does its intended use fall inside one of the eight Annex III categories. A “yes” to either triggers the high-risk obligations - risk management systems, data governance requirements, technical documentation, human oversight, and conformity assessment before market placement. This is why the acceptance-testing worksheet in the images accompanying this article is drawn clipped to a physical board rather than embedded in a workflow tool: in a surprising number of organizations, the first classification pass is still done by a person reading Annex III’s list against a plain-language description of what the system does, because the legal test is fundamentally about use, which software cannot self-report reliably.
Analysis: this two-route structure has an asymmetry worth naming. The Annex I route piggybacks on decades of existing product-safety infrastructure - notified bodies, harmonised standards, established conformity procedures - so an AI component inside a CE-marked medical device inherits a mature assessment apparatus. The Annex III route has no such inheritance; standalone AI uses in employment or essential services are being assessed against conformity infrastructure that is still being built as the Act phases in. Expect the Annex III route to be the site of most early enforcement friction, simply because the assessment capacity behind it is newer.
Building an audit trail a NIST AI RMF-aligned review will accept
The NIST AI Risk Management Framework (AI RMF 1.0), published in January 2023, is voluntary in the United States but has become a de facto reference vocabulary even for organizations operating under binding regimes elsewhere, because its four functions - Govern, Map, Measure, Manage - give auditors and deployers a shared structure for organizing evidence [3]. In practice, an audit trail that claims RMF alignment is not one document; it is four separate evidence streams, each retrievable on its own, because each function answers a different question a reviewer will ask.
Govern evidence answers “who is accountable, and under what policy”: org charts naming the accountable executive, a written AI policy, and records showing the policy was actually applied to a specific system rather than existing only as a template. Map evidence answers “was the context and the intended use documented before deployment”: the same use-case description that feeds an Annex III classification decision belongs here too. Measure evidence answers “what was actually tested, and against what threshold”: test protocols, red-team reports, and quantitative results, not just a vendor’s marketing benchmark. Manage evidence answers “what happens when something goes wrong”: incident logs, a documented escalation path, and evidence that residual risk was accepted by someone with the authority to accept it, not merely noted.
NIST extended this structure for generative AI specifically in July 2024 with AI 600-1, the Generative AI Profile, which identifies twelve risk categories - among them confabulation, information integrity, data privacy, and CBRN-related capability uplift - and maps more than two hundred suggested actions onto the four RMF functions [4]. This profile is why a generative-AI deployment’s audit trail looks different in kind from a classical model’s: a Measure artifact for a classification model might be a precision-recall curve, while a Measure artifact for a generative system has to include a substantiated confabulation rate on domain-relevant prompts, because “the model answers” is not itself evidence that the answer is grounded.
Fact vs. analysis: NIST AI RMF 1.0 is explicitly voluntary and sector-agnostic; it does not by itself create a legal obligation [3]. The evidentiary structure above is our analysis of how organizations operationalize the framework in an actual audit, not a requirement quoted from the document itself - the standard describes functions and suggested actions, not a mandated evidence taxonomy. Where it does carry binding weight in the United States is through incorporation by reference: OMB M-24-10 directs federal agencies to build their own AI governance and risk management practices with reference to the RMF and to use the generative AI profile for genAI risk assessments, which is where a voluntary framework becomes a federal compliance obligation for covered agencies [6].
If a real number belongs in the audit-trail conversation, it is a threshold, not a measurement,
and it should be written as a model rather than asserted as fact. A deployer setting an acceptance
gate on a generative system’s confabulation rate might define a simple pass condition against a
sampled evaluation set of size
This is a standard one-sided Wald confidence bound, included here only because it exposes a real
assumption practitioners often skip: a raw sampled error rate without its confidence interval says
nothing about whether the true rate is actually below a threshold, especially at the sample sizes
(
Certification against a standard: what ISO/IEC 42001 actually checks
ISO/IEC 42001, published in December 2023, is the first international management-system standard for AI, and it is worth being precise about what a certification against it actually verifies [5]. Like its predecessors in the ISO management-system family (27001 for information security, 9001 for quality), 42001 does not certify a model’s accuracy or a benchmark score. It certifies that an organization has a system - documented policies, an AI risk-management process, lifecycle controls, and third-party supplier oversight - and that the system is actually followed, verified by an external auditor sampling records rather than by an audit of the AI system’s outputs directly.
This is the detail the accompanying figure of a load-testing rig is meant to make legible: a conformity-assessment bench in this world exists to check whether the management process around a deployment is intact, not to declare the model itself compliant. An organization can hold ISO 42001 certification while operating a mediocre model, and can, in principle, fail certification while operating an excellent one, if its lifecycle documentation and supplier-oversight records are incomplete. Certification is a claim about organizational discipline, portable across whatever model the organization happens to be running this quarter - which is also its main limitation as a regulatory tool: it verifies process, not outcome, and a regulator relying on it as a proxy for safety is relying on an assumption that good process reliably produces safe outcomes, which is plausible but not something the certificate itself asserts.
Vendor-claim flag: certification bodies and consultancies market ISO 42001 alongside EU AI Act compliance as though the two map cleanly onto each other. They do not. The AI Act’s conformity assessment requirements for high-risk systems are a distinct legal obligation with their own technical documentation and post-market monitoring requirements; a 42001 certificate can be used as supporting evidence of a mature management system, but it does not substitute for the Act’s own conformity assessment procedure, and any claim that “42001 certification equals AI Act compliance” should be read as marketing shorthand, not as a legal equivalence.
Procurement: how governments actually gate an AI purchase
OMB Memorandum M-24-10, issued in March 2024, is the clearest public example of procurement-side AI governance because its minimum practices are specific enough to check against, rather than being general principles [6]. Before a covered U.S. federal agency can use a safety-impacting or rights-impacting AI application, the memo’s minimum practices require: completing a documented impact assessment of the intended purpose and the characteristics of the training data; testing the application’s performance in a real-world context rather than relying solely on a vendor’s own evaluation; an independent internal evaluation feeding into an authority-to-operate determination; and ongoing monitoring with a documented fail-safe procedure. Rights-impacting systems carry an additional layer: an assessment of effects on equity and fairness, and a mechanism for collecting feedback from the people actually affected by the system’s decisions.
The consequence for a vendor selling into this market is structural, not cosmetic: an agency cannot lawfully accept a system on the strength of a vendor’s benchmark sheet. The acceptance checklist has to be completed against the agency’s own real-world test, which is why the procurement-bay image in this article shows a barcode scanner sweeping a physical checklist next to an unboxed server rather than a signed contract - acceptance, under this regime, is a testing event, not a delivery event. M-24-10 also directs CFO Act agencies to stand up governance boards within ninety days of the memo’s issuance, with cross-functional representation from IT, cybersecurity, data, and budget offices, which is the organizational precondition for the Govern function described in the RMF section above actually being exercised rather than merely documented [6].
Scenario, clearly marked: a hypothetical illustrates the gate’s bite. Suppose a vendor offers an automated benefits-eligibility screening tool with a published accuracy figure from its own internal test set. Under M-24-10’s minimum practices, that published figure cannot substitute for the agency’s independent real-world test, and the rights-impacting overlay would additionally require the agency to solicit feedback from applicants before relying on the tool’s output to deny a benefit. A vendor whose only evidence is an internal benchmark should expect the acceptance process to take materially longer than the sales cycle implies, because the testing step is not negotiable under the memo’s own language.
Liability: what has and has not been settled
It is tempting to describe AI liability as a settled field with a clear directive behind it. It is not, and getting the current state wrong is a common and consequential error. The European Commission’s proposed AI Liability Directive, first published in September 2022 to adapt non-contractual civil liability rules to AI systems, was formally withdrawn from consideration - the Commission signaled its intent in its February 2025 Work Programme, and the formal withdrawal notice was published in the Official Journal in October 2025, following industry objections that the proposal would add legal complexity without corresponding benefit [8]. The Commission reserved the right to bring forward a different proposal later, but as of this writing there is no EU-level harmonized AI-specific liability regime in force; liability claims involving AI systems in the EU currently fall back on each member state’s existing general liability and product-liability law, applied to AI systems without AI-specific adaptation.
Analysis: this withdrawal is easy to misreport as “the EU decided AI liability doesn’t need special rules.” The more accurate reading is a stalemate: a genuine, unresolved disagreement between consumer-protection advocates who wanted a lower evidentiary burden for claimants harmed by opaque AI systems, and industry groups who argued the added complexity would chill deployment without demonstrated benefit. Both positions have some support; the withdrawal resolves the disagreement procedurally, by removing the proposal, not substantively, by settling which position was right. A practitioner advising a client on AI liability exposure in the EU today should treat the gap as live regulatory uncertainty, not as evidence that liability risk is low.
Compute governance: regulating the hardware underneath the model
A distinct governance lever operates not on the deployed system but on the chips that trained it. The Bureau of Industry and Security’s export-control regime for advanced computing hardware is the clearest working example, and its recent history is itself a case study in how quickly this layer of governance can move. In January 2025, BIS issued the Framework for Artificial Intelligence Diffusion - the “AI Diffusion Rule” - which grouped countries into three tiers of licensing stringency for advanced chips, computing hardware, and even AI model weights, with a small group of close allies exempted from licensing entirely and most of the rest of the world routed through a data-center-operator licensing program with a presumption of approval [10]. That rule never took effect: in May 2025, the Department of Commerce signaled its intent to rescind it, directed enforcement staff not to enforce it, and subsequently issued replacement guidance - a policy statement on advanced computing integrated circuits, industry guidance aimed at preventing diversion of controlled chips to restricted destinations, and specific guidance on how an existing general prohibition applies to China-bound advanced computing hardware [9].
The practical governance mechanism this produces, independent of which specific rule is currently in force, is a chain-of-custody problem: a chip manufacturer or cloud operator has to be able to show where a controlled part physically is, because “diversion” - a controlled chip crossing into a restricted destination through an intermediary in a permitted country - is the enforcement target that guidance keeps returning to. This is why the compute-metering image in this article shows a physical asset tag being pressed onto an accelerator card rather than a software license key: export-control compliance for advanced computing hardware still runs partly through the same physical chain-of-custody discipline used for any other controlled dual-use good, tag and serial-number tracking included, layered underneath the software-level usage metering that cloud operators also maintain.
Prediction, with horizon and disconfirmation condition: given the pattern of the Diffusion Rule’s issuance and rescission within four months, we expect the U.S. government to issue at least one further substantial revision to advanced-computing export-control rules before the end of 2027, rather than settling on the current guidance-only posture. This rests on the assumption that the underlying policy disagreement - balancing chip-industry export revenue against diversion risk to restricted destinations - remains unresolved, and on the observable indicator that BIS has already described the current guidance as an interim step pending a replacement rule [9]. The prediction would be disconfirmed by the guidance-only regime remaining unchanged through 2027 with no new proposed rule published in the Federal Register.
Competition effects and the international coordination problem
Two threads tie the preceding sections together. First, compute governance and procurement rules both have a competition dimension that is easy to miss when reading them purely as safety instruments: a licensing regime that exempts a small tier of allied countries, or a procurement gate that only well-resourced vendors can clear quickly because they alone can fund the independent real-world testing an agency requires, concentrates capability among incumbents as a side effect of rules written for other reasons. This is not a claim that either regime was designed to entrench incumbents - it is an observation that risk-tiered and testing-gated regimes have this effect regardless of intent, and it is worth tracking as a distinct policy question from the safety question the rule was written to answer.
Second, none of the frameworks above were built to interoperate with each other, and the practical work of reconciling them falls to bodies like the OECD, whose AI Principles - first adopted in 2019 and updated in May 2024 to address generative AI and foundation models specifically - function less as binding law and more as the common vocabulary that lets a EU regulator, a U.S. agency, and a national standards body recognize each other’s classification and audit terms as describing comparable things [7]. The 2024 update added explicit treatment of environmental sustainability and of misinformation amplified by generative systems, changes that track what a five-year-old set of principles could not have anticipated in 2019. With forty-seven adherents including the EU, the Principles are the closest thing this field has to a shared reference point, but they bind no one directly - the mutual-recognition desk pictured in this article’s closing figure, where a reviewer checks whether one jurisdiction’s certificate satisfies another’s requirements, is where that shared vocabulary either does or does not translate into an actual accepted document, one case at a time.
What a practitioner should actually take from this
Classification, audit, certification, procurement, liability, and export control are six separate compliance problems, each anchored to a different piece of law or standard, each producing its own kind of paper trail, and none of them substitutable for another - an ISO 42001 certificate does not satisfy an Annex III classification obligation, and a NIST RMF-aligned audit trail does not by itself clear a federal procurement gate. The discipline this demands of a deployer is less about mastering any one framework in depth and more about keeping the six kinds of evidence in separate, retrievable files, because that is exactly the granularity at which a regulator, an auditor, or a procurement officer will eventually come asking.
