Written and maintained by CASRAI Editorial Board
Last updated
Most frontier-AI governance mechanisms regulate the model or the developer — a transparency disclosure under California SB 53, a classification test under the EU AI Act, a voluntary responsible scaling policy. Compute governance is a different kind of lever: it works on the physical substrate underneath all of that — the chips, data centers, and cloud infrastructure a model is actually trained and run on — rather than on the model’s outputs, the developer’s disclosures, or a deployment decision. This guide defines the three concrete mechanisms that make up compute governance today: export controls, FLOP-reporting thresholds, and chip-level “know-your-customer” (KYC) requirements.
The case for treating compute as a governance target at all comes down to three properties researchers at the Centre for the Governance of AI (GovAI) laid out in their widely cited explainer, Computing Power and the Governance of Artificial Intelligence (Lennart Heim, Markus Anderljung, Emma Bluemke, Robert Trager, and co-authors, GovAI, February 2024): compute is detectable (large training runs require physically identifiable hardware), excludable (unlike a model’s weights, a chip cannot be copied and redistributed for free), and quantifiable (a training run’s compute can be measured in floating-point operations, or FLOPs, giving regulators a numeric threshold to write rules around). Those three properties are why compute — rather than, say, the training data or the resulting model — has become the point where several governments have chosen to attach binding rules.
Mechanism one: export controls on advanced AI chips
Since 2022, the U.S. Commerce Department’s Bureau of Industry and Security (BIS) has restricted the export of the most advanced AI-training chips and the equipment used to manufacture them, primarily to destinations including China. The GovAI explainer frames the intent directly: these controls “aim to hamper Chinese actors’ ability to develop frontier AI models” by denying access to the hardware a frontier training run requires, rather than trying to regulate the training run itself after the fact. Export controls are the oldest and most tested of the three mechanisms in this guide — they predate the FLOP-reporting and chip-KYC ideas below by roughly two years — and they operate at the point of sale, before a chip ever reaches a data center.
This is a distinct mechanism from, and should not be confused with, the university research-security obligations CASRAI covers elsewhere on this site — for example countries of concern under the CHIPS and Science Act or ECCN classification for research equipment. Those guides are written for university research-security and export-compliance officers who need to know whether a piece of lab equipment or a foreign collaboration triggers a disclosure or licensing requirement. This guide is written for a different audience — AI governance and policy professionals evaluating semiconductor export licensing as a lever for restricting who can train frontier AI systems in the first place. The two bodies of law share a keyword surface (both involve export licensing and countries of concern) but answer different questions for different readers.
Mechanism two: FLOP-reporting thresholds
Where export controls act on chips before they’re sold, FLOP-reporting thresholds act on training runs after compute has already been acquired — they require a developer to report to a regulator once a training run crosses a defined amount of compute, measured in floating-point operations. Two thresholds are already live and already covered in detail elsewhere on this site:
- The EU AI Act’s Article 51 sets a rebuttable presumption of “systemic risk” classification once a model’s training compute exceeds 1025 FLOPs — see CASRAI’s full breakdown in GPAI Systemic Risk: The EU AI Act Term Explained.
- California SB 53 uses a training-compute threshold of 1026 operations — ten times the EU figure — to define which developers count as “frontier developers” subject to its transparency obligations; the same order-of-magnitude threshold was used in the earlier federal AI-reporting requirement it draws on. See California SB 53: Frontier AI Law Explained.
The gap between 1025 and 1026 FLOPs matters in practice: it’s an order of magnitude, meaning a model that trips the EU’s presumption by a wide margin may still sit below the California threshold entirely. A developer operating across both jurisdictions has to track both lines separately, not treat “the FLOP threshold” as one number. The GovAI explainer flags the same structural weakness in any fixed numeric threshold: compute-per-dollar keeps falling, so a threshold written today “can become outdated fairly quickly as technology evolves” — which is why the EU AI Act separately gives the Commission delegated-act power to adjust its threshold, rather than fixing 1025 permanently in the statute.
Mechanism three: chip-level know-your-customer (KYC) requirements
The newest and least mature of the three mechanisms targets the cloud-compute layer rather than a chip sale or a completed training run. The GovAI paper proposes “know-your-customer (KYC) regimes for cloud AI training” — requiring cloud providers to verify who is renting large blocks of AI-training compute, similar in structure to financial KYC rules, so that a large training run can’t be assembled anonymously through a cloud account even if every individual chip involved was legally exported. The same paper also discusses a harder, chip-level version of the same idea: designing chips with deliberately “limited chip-to-chip networking” capability, which would make it physically more difficult to link enough hardware together for a frontier-scale training run without that link being detectable. Both proposals share the same goal as mechanisms one and two — making a large training run harder to assemble without leaving a trace a regulator can act on — but neither is close to the settled, already-enacted status of the export controls or FLOP thresholds above; treat this mechanism as the leading edge of the compute-governance discussion, not as existing law.
Why compute governance is a distinct lever, not a substitute for model-level rules
None of the three mechanisms above evaluate a model’s behavior, its outputs, or a deployer’s use case — that work is done by the model-level and deployment-level tools CASRAI covers elsewhere in this cluster, from frontier AI frameworks and responsible scaling policies to third-party evaluator standards. Compute governance instead answers a narrower, earlier question: who is physically capable of training a frontier-scale model at all, and can a regulator find out when someone crosses that line. The two layers are complementary — a lab’s responsible scaling policy typically defines its own internal capability thresholds in terms of compute, evaluation results, or both, which is exactly where the hardware layer this guide covers and the model-evaluation layer covered elsewhere on this site meet. See Comparing AI Safety Terms Across Frameworks for how several labs’ internal thresholds line up against each other.
How CASRAI’s NIKOLAI tracks this
Compute governance’s chip-level and infrastructure-level mechanisms — export controls that gate hardware access, and KYC regimes that gate who can rent it — sit at the hardware/infrastructure end of the same territory CASRAI catalogs independently as Security control and Security level, two elements in NIKOLAI’s Mitigations and Security track (N6). NIKOLAI defines a Security control as an individual security measure — such as access approval, hardware security keys, or weight encryption — mapped where possible to external control catalogues like NIST 800-171 or SOC 2; Security level is the graded statement built from those controls, describing “a developer’s model-weight and infrastructure security posture.” A chip-level KYC regime or an export-control license requirement is, in that vocabulary, an infrastructure-level control operating one layer below the model itself — the same conceptual layer N6 names, applied to hardware a lab doesn’t own outright rather than to a lab’s own internal access controls. CASRAI tracks this as one more example of that pattern, not as an implementation of any government’s or lab’s policy: NIKOLAI is CASRAI’s own, unendorsed reference project, and every mapping in its crosswalk tables is a shadow mapping — CASRAI’s own reading, not a definition any listed organization has agreed to. See NIKOLAI’s Mitigations and Security track (N6).
FAQ
Is compute governance the same thing as export controls?
No. Export controls are one of the three mechanisms that make up compute governance — the others are FLOP-reporting thresholds and chip-level KYC requirements. Compute governance is the broader category: any policy lever that targets the physical hardware and infrastructure a model is trained on, rather than the model, its developer’s disclosures, or its deployment.
What’s the difference between the EU AI Act’s compute threshold and California SB 53’s?
The EU AI Act’s Article 51 sets a 1025 FLOPs presumption of systemic risk; California SB 53 sets its frontier-developer threshold at 1026 operations, an order of magnitude higher. A model can cross the EU’s threshold well before it reaches California’s.
Are chip-level KYC requirements already law anywhere?
Not as a general, enacted regime as of this writing. The GovAI paper proposes cloud-compute KYC and limited-networking chip designs as policy directions worth developing, not as existing statute — treat this mechanism as the least mature of the three covered here.
How is this different from CASRAI’s research-security content on export controls?
CASRAI’s research-security cluster covers export-control compliance obligations for universities — for example, whether a piece of lab equipment requires an export license, or which countries trigger a research-funding disclosure under the CHIPS and Science Act. This guide covers a different question for a different reader: how chip export licensing functions as an AI-safety governance lever for the AI governance and policy professionals evaluating frontier-model oversight, not for research-compliance officers.
Does a higher FLOP threshold mean weaker regulation?
Not necessarily — it means fewer models are captured by that specific threshold, but it doesn’t say anything about the strength of the obligations that attach once a model does cross it. The EU AI Act and California SB 53 also differ in what happens after classification, not just in where the line is drawn.
