You can't regulate an idea, but you can see a data center
The first two guides of this rung left you with a sharp, uncomfortable question. Guide 1 laid out the case for catastrophic and existential risk — and the wide, honest range of expert disagreement about it. Guide 2 examined takeoff, timelines, and the intelligence explosion. Suppose you now take even a slice of those worries seriously. The obvious next question is brutally practical: if some of this is real, what could anyone actually do about it, ahead of time, in the world as it exists? You cannot legislate against a mathematical idea. You cannot put a fence around an algorithm posted on the internet. So where is the handle?
Here is the opening that this entire guide is about: the most capable AI systems today are not merely ideas — they are physical. Training a frontier model takes a building full of specialized chips, drawing as much electricity as a small town, running for months, costing tens or hundreds of millions of dollars. You cannot inspect a model's mind, but you can watch, count, and gate the rare physical resource it takes to build one. That bet — govern the inputs, because the inputs are far easier to see than the outputs — is the heart of compute governance and the frontier-oversight regime built on top of it.
Reach for an analogy before any jargon. Nuclear weapons are hard to build not because the physics is secret — the basic principles are in textbooks — but because the inputs, above all enriched uranium, are scarce, detectable, and produced in a few identifiable places. So the world governs the bomb largely by governing the centrifuges. Compute governance makes the same wager about frontier AI: you may never be able to read a model's intentions, but you can attach a lever to the rare, conspicuous, physical thing it takes to create one. The whole field is an attempt to find handles on a technology that otherwise feels frictionless.
Why compute, of all things, is the governable input
Be precise about what goes into a frontier model. Roughly three things: compute (how much raw calculation you spend), data (what the model learns from), and algorithms (the recipes and architectures that turn compute and data into capability). Here "compute" means the total amount of computation used to train a model, usually measured in FLOP — floating-point operations, the individual arithmetic steps. A frontier training run today is on the order of 10^25 to 10^26 FLOP: a one followed by twenty-five or twenty-six zeros. The reason this number matters at all is the scaling regularity you met in guide 2: across many orders of magnitude, more compute (spent well, with matching data and parameters) has reliably bought lower loss and, often, more capability in a large language model.
Carry one caveat the whole way, though: scaling laws are empirical regularities — patterns observed so far — not laws of nature, and not a guarantee they continue. They could bend, plateau, or break. This matters enormously here, because the case for governing compute leans on the assumption that compute keeps tracking capability. If that link weakens, so does the lever. Treat "more compute means more capability" as a strong observed trend, not a theorem.
Now, of those three inputs, why is compute the one people reach for? Because compute has four properties the others lack, laid out clearly in recent governance research (Sastry and colleagues, 2024). It is detectable: a frontier-scale training run needs power, cooling, and thousands of chips in one place, which is physically conspicuous. It is excludable: chips are physical objects, so access to them can actually be denied — you cannot deny access to an idea. It is quantifiable: FLOP is a number you can estimate and write a threshold against. And the supply chain that makes the chips is extraordinarily concentrated. Data, by contrast, is everywhere and infinitely copyable; algorithms travel the planet as a PDF in seconds. Compute is the one input that is rivalrous, physical, and bottlenecked.
That last property — concentration — deserves a picture, because it is the precondition for everything else. The supply chain for cutting-edge AI chips runs through a startlingly narrow neck. One Dutch company, ASML, is the sole maker of the extreme-ultraviolet (EUV) lithography machines needed to print the most advanced chips. One Taiwanese company, TSMC, dominates leading-edge fabrication. One American company, NVIDIA, designs most of the accelerators used to train frontier models. When a whole industry passes through three or four firms, a handful of governments and companies sit at choke points where a lever can, in principle, be attached.
- Chip design and the specialized design software (EDA) — a few mostly-US firms produce the tools without which an advanced chip cannot even be drawn.
- EUV lithography machines — ASML is the only company on Earth that makes them, and a single machine costs hundreds of millions of dollars.
- Leading-edge fabrication — TSMC manufactures the great majority of the world's most advanced chips at a tiny number of fabs.
- Accelerator design and assembly — NVIDIA's GPUs (and a few rivals) are packaged into the servers that fill an AI data center.
- Data centers and cloud providers — a handful of large operators house the compute and rent access to it, the final point where usage can be seen and, if anyone chooses, gated.
What compute governance actually does — the mechanisms
With that picture in hand, compute governance can be defined cleanly: the practice of using the compute supply chain — and the measurability of training compute — as a lever for AI governance. It is not one policy but a toolbox, mostly assembled since around 2022. The useful thing for a beginner is to meet the tools one at a time, because each does something different and each has its own failure mode.
The first and most discussed tool is the compute threshold: a FLOP level above which a training run earns extra attention. Below the line, a training run is treated as ordinary and nobody is watching; above it, the developer incurs obligations — typically reporting to a government that the run is happening, and sharing the results of safety testing. A companion mechanism is KYC ("know your customer") for large compute purchases, where a cloud provider must record and, if required, report who is buying frontier-scale compute — the same logic banks use against money laundering, pointed at GPUs instead of cash.
The second tool reaches across borders: export controls. A government can restrict the sale of the most advanced AI accelerators, and of the equipment used to make them, to particular countries. This tool was born from old national-security export-control machinery, not from the AI-safety conversation — but because it directly shapes who can amass frontier-scale compute at all, it has become deeply entangled with it. That dual parentage — part geopolitics, part safety — is a tension we will return to, because the two logics do not always point the same way.
The third tool is the most futuristic and the least built: hardware-enabled mechanisms, sometimes called on-chip governance. The idea is to bake verification into the chips themselves — for instance, a chip that can cryptographically attest it only ran an authorized workload, or report its location, or enforce a usage cap. The appeal is verification without trust: you could check a claim about how a chip was used without taking anyone's word for it. Be honest about the status, though — this is largely early-stage research, mostly unbuilt, and contested on its own merits (it raises real privacy, security, and centralization-of-power concerns). It is a sketch of a possible future lever, not a tool in use today.
Training compute, rough rule of thumb:
C ~= 6 * N * D
N = number of model parameters
D = number of training tokens
C = floating-point operations (FLOP)
For scale (a publicly *estimated* figure -- never disclosed by the lab):
GPT-4-class run ~ 2 x 10^25 FLOP
Threshold triggers seen in real policy:
US EO 14110 (2023) > 10^26 FLOP -> report the run to government
EU AI Act 'systemic risk' > 10^25 FLOP -> extra obligations apply
Note: a FLOP count is a CRUDE PROXY for capability, not a measure of it.
The threshold gates SCRUTINY; it does not certify a model as safe.Frontier-model oversight: who watches the frontier
Compute governance is half of the title; frontier-model oversight is the other half, and the two interlock. First the noun: a frontier model is a highly capable, general-purpose model at or beyond the current cutting edge — one whose full range of abilities is not understood in advance and could, by accident or misuse, pose serious risks. Oversight concentrates here for the same reason a regulator inspects a new airliner more closely than a paper plane: the frontier is where the unknown, and the stakes, live. The threshold from the last section is precisely the device that decides which runs count as frontier and therefore fall into the oversight net.
What does oversight consist of, concretely? Mostly pre-deployment testing: before a frontier model is released, it is run through evaluations — especially the dangerous-capability evaluations you met in the evals rung, probing for abilities that would be alarming simply by existing, like meaningfully helping a novice toward a bioweapon or operating autonomously enough to replicate. The genuinely new development is who runs them. It is increasingly not the developer alone: independent third-party evaluators and government AI safety institutes — the UK's and the US's, among others, set up since 2023 — now get pre-release access to test frontier systems, so that the lab no longer purely grades its own homework.
Now watch the pieces snap together into one chain. A compute threshold is the trigger that pulls a particular training run into the oversight net. Once inside, an if-then commitment — written ahead of time into a developer's responsible scaling policy — specifies what evidence gates what action: if a dangerous-capability eval shows the model has crossed a defined threshold, then a specific response fires (stronger security, deployment limits, or pausing further scaling). The whole apparatus only works as well as its weakest joint, and the weakest joint is the eval itself: recall from earlier rungs that passing an eval is evidence on the tested cases, not a guarantee, and that a model could in principle sandbag — underperform on purpose to look safe. Guide 4 takes this chain apart in detail; here, just hold its shape.
A worked example: the 10^26 line, the EU AI Act, and the chip controls
Make it real with three concrete instances that exist in the world, each a different kind of lever. The first is a domestic reporting threshold. In October 2023 the United States issued an executive order (EO 14110) that, among much else, required developers to report to the government any training run above 10^26 FLOP, including the results of red-teaming and safety tests. To feel the scale: GPT-4 has been publicly estimated at very roughly 2 x 10^25 FLOP (OpenAI never disclosed the real figure), so the 10^26 line sat a notch above the most capable models of its day — deliberately aimed at the next generation, not the current one.
The second instance is a domestic obligations regime, and it is currently live. The European Union's AI Act — a leading piece of frontier AI regulation — presumes that a general-purpose model carries "systemic risk" once its cumulative training compute exceeds 10^25 FLOP. Cross that line and extra obligations attach: model evaluation and adversarial testing, assessing and mitigating systemic risks, reporting serious incidents, and ensuring cybersecurity. Notice the threshold here is set lower than the old US figure, roughly at GPT-4 scale — a different judgement about where "frontier" begins, encoded in the same kind of FLOP number.
The third instance reaches across borders: export controls. Starting in October 2022 and tightened repeatedly since, the United States restricted the sale of the most advanced AI accelerators and chipmaking equipment to China. The stated framing was national security, but the effect is squarely a compute-governance one: it shapes who, geographically, can assemble frontier-scale compute at all. Read it honestly and you see the double edge immediately. To some it is a safety-relevant brake on a dangerous capability race; to others it is primarily a geopolitical move that may simply spur a rival to build an independent supply chain — a question we genuinely cannot settle here, and that good analysts argue about in earnest.
Common misconceptions and pitfalls
A cluster of traps catches almost everyone new to this. (1) "Compute governance means banning AI, or confiscating GPUs." No — every real proposal targets only the largest training runs or the most advanced chips; your laptop, your phone, and the overwhelming majority of computing are nowhere near the lines being drawn. (2) "A FLOP threshold measures how dangerous a model is." No — FLOP is a crude proxy. It correlates loosely with capability across big jumps in scale, but it is not a capability measurement and certainly not a risk measurement; a smaller model trained cleverly can outperform a larger one. (3) "Above the threshold means dangerous; below it means safe." No — the threshold gates scrutiny, not a safety verdict. Crossing it triggers a look; staying under it is not a clean bill of health.
The subtler pitfalls are about how this all ages. (4) "A threshold, once set, stays meaningful." No — algorithmic efficiency keeps improving, so the compute needed to reach a given capability falls over time (by some estimates, something like a factor of a few per year). A fixed FLOP line therefore catches fewer models each year and has to be revisited, or it quietly stops biting. (5) "Training compute is the whole story." Increasingly false: inference-time compute (reasoning models that 'think' for longer at the moment of use) and the fine-tuning of already-released weights can both raise effective capability without a giant fresh training run — moving the action outside the frame a training-FLOP threshold draws. (6) "Compute governance stops misuse." Mostly no — it governs the creation of frontier models. Once a model's weights are openly released, no compute lever can recall them, and misuse of an existing model is a separate problem that needs separate tools.
What's still debated, and where to go next
The disagreement here is real and runs among serious people; report it, do not resolve it. On the optimistic side: compute is the most tractable lever we have — uniquely detectable, excludable, quantifiable, and bottlenecked — so it offers something rare in this field, a handle that can actually be gripped and verified. It buys time, and it touches only a handful of the largest runs rather than ordinary users. On the skeptical side: that handle may be slipping. Algorithmic efficiency, the rise of inference-time compute, and openly released weights all erode the link between training FLOP and real-world capability, so a lever built on that link weakens as the technology moves.
Three further fault lines are worth naming so you recognize them in the wild. First, concentration of power: a regime that gates the frontier could entrench the few incumbents who can afford the compliance, and invites worries about regulatory capture and about whoever controls the chokepoints. Second, civil liberties: the most verifiable mechanisms — KYC, hardware monitoring — are also the most invasive, raising real privacy and surveillance concerns. Third, geopolitics versus safety: export controls live at the seam between national-security logic and AI-safety logic, and the two do not always align. A measure that slows a rival can intensify a race — feeding the racing dynamics guide 2 warned about — rather than producing the coordinated caution that safety would want.
And step back to the deepest dependency of all. Whether compute governance is even worth it hinges on beliefs you were asked to hold open in the first two guides. If catastrophic risk is overstated, much of this is costly overreach; if it is real, this may be far too little. And — crucially for this lever — if takeoff turns out to be driven mainly by algorithmic insight rather than by raw compute, then governing compute grips the wrong variable. None of those priors is settled, which is exactly why honest people land in different places on compute governance while sharing all the same facts. Resist the pull to a tidy verdict; the calibrated position is that compute governance is a genuinely promising lever and a genuinely limited one.
Where to go next. You now have the input side of the picture: how the frontier is seen and gated. Guide 4 turns to what happens once a run is inside the net — responsible scaling policies, the if-then commitments that connect evals to action, and the safety institutions that are meant to make oversight credible. Guide 5 then widens the lens to international coordination and individual action, because a lever built on a global supply chain only bites if the major players move together — and that is a problem of trust and politics, not of FLOP. The throughline of this guide never changes: compute governance is a bet that the easiest thing to see, the physical inputs, can be a useful handle on the hardest thing to control, frontier capability. Promising, contested, and incomplete — a lever, not a solution.