Ask a regulator what makes an AI model dangerous enough to warrant oversight, and you might expect an answer about what the model can do — whether it can help synthesize a pathogen, write working exploit code, or manipulate someone into a bad decision. Instead, the answer increasingly comes down to a number stamped in a training log: how many floating-point operations it took to train the thing. If that number crosses a line — commonly 10^25 FLOPs — the model gets a different regulatory status, whether or not anyone has demonstrated it's actually more dangerous than the model just below the line.
This is compute-based AI governance, and it's no longer a theoretical policy proposal. It's operational law in the European Union, it shaped (and briefly defined) US federal policy, and it's the backbone of how several governments currently decide which AI labs get extra scrutiny. Understanding how it works — and where it breaks down — matters for anyone building, deploying, or investing in frontier AI systems.
What a compute threshold actually is
A FLOP (floating-point operation) is a single arithmetic step — an addition or multiplication — performed during model training. Training a large model requires an enormous number of these operations, roughly proportional to the size of the model (its parameter count) multiplied by the amount of data it's trained on. Researchers estimate this quantity, often called "training compute," using well-established scaling formulas rather than counting operations one by one.
A compute threshold is a regulatory line drawn at a specific FLOP count. Cross it, and a model is presumed to fall into a stricter oversight category — subject to things like mandatory risk assessments, incident reporting, red-teaming obligations, or advance notification to a government body. Stay below it, and a developer generally faces lighter or no comparable obligations.
The appeal is that FLOPs are:
- Measurable before deployment. A lab knows its training compute budget before it ever runs an evaluation, so the threshold can trigger obligations early, not after harm occurs.
- Hard to fake retroactively. Cloud compute usage, GPU-hours, and cluster specifications leave a paper trail that's harder to obscure than, say, self-reported capability claims.
- Correlated (imperfectly) with capability. Empirically, more training compute has tended to produce more capable general-purpose models — this is the premise behind "scaling laws" that guided the last several years of frontier AI development.
That correlation is doing a lot of work, and it's also the threshold approach's biggest weakness — more on that below.
How the numbers actually work
FLOP counts for frontier models are almost incomprehensibly large, so it helps to see them written both ways.
| Notation | Approximate value | Rough real-world anchor |
|---|---|---|
| 10^23 FLOPs | 100,000,000,000,000,000,000,000 | Compute scale of several earlier-generation large language models |
| 10^25 FLOPs | 10,000,000,000,000,000,000,000,000 | The EU AI Act's "systemic risk" presumption threshold for general-purpose AI models |
| 10^26 FLOPs | 100,000,000,000,000,000,000,000,000 | The reporting threshold set in the 2023 US executive order on AI (later rescinded) |
A useful way to think about the jump between these numbers: each additional power of ten is roughly an order of magnitude more compute, which in practice means meaningfully larger clusters, longer training runs, and higher electricity and hardware costs. The gap between 10^24 and 10^25 FLOPs isn't a rounding error — it's the difference between a model trainable on a modest cluster and one that requires the kind of infrastructure only a handful of organizations worldwide currently operate.
Regulators don't expect companies to count operations manually. In practice, compliance relies on standardized estimation methods — using known formulas relating parameters, tokens, and hardware utilization — that labs are expected to calculate and, in some jurisdictions, report to a supervising authority.
Why regulators reach for compute in the first place
Government bodies writing AI rules faced a genuine problem: how do you regulate a technology whose capabilities are discovered through use, often after deployment, and where "harm" can range from biased hiring recommendations to assistance with weapons development? Capability-based rules — write law around what a model can actually do — require running extensive evaluations, agreeing on what constitutes a dangerous capability, and doing this fast enough to keep pace with model releases. That's slow, contested, and easy to game by simply not disclosing the capability that triggers a rule.
Compute is available as a shortcut because of a specific historical pattern: over the 2018–2024 period, the most capable general-purpose models tended to be the ones trained with the most compute. Scaling laws research from that era showed a fairly predictable relationship between compute invested and downstream performance on benchmarks. Policymakers concluded that flagging outlier levels of training compute was a reasonable, verifiable proxy for flagging outlier levels of general capability — not perfect, but auditable, and available before a model ever reaches the public.
There's also a practical enforcement logic. Training runs at the frontier require thousands of specialized chips running for weeks or months, procured from a small number of cloud and chip providers. That concentration makes compute a chokepoint regulators can actually monitor, unlike, say, the diffusion of a trained model's weights once released.
Why this matters right now
The clearest evidence that compute thresholds have moved from theory to enforcement is the European Union's AI Act. Under the Act, general-purpose AI (GPAI) models are presumed to carry "systemic risk" if the cumulative compute used for their training exceeds 10^25 FLOPs — a threshold that pulls in additional obligations around model evaluation, adversarial testing, incident tracking, and cybersecurity.
From August 2, 2026, the EU's AI Office gains the power to actually fine GPAI providers for non-compliance. That single date matters because it converts the 10^25 FLOP line from a classification exercise into something with real financial consequences attached. Before that point, a provider crossing the threshold faced obligations on paper; after it, the AI Office can act on non-compliance. The threshold itself doesn't change on that date — what changes is that the number now decides, with enforcement teeth behind it, which providers are inside the EU's systemic-risk regime and which are not.
This is the pattern to watch across jurisdictions: the FLOP number is set first, often years ahead of enforcement, and it quietly becomes the dividing line everyone builds their compliance planning around long before any fine is issued.
What this means for builders and businesses
If you're training foundation models, procuring frontier compute, or building products on top of general-purpose AI systems, compute thresholds create concrete planning questions rather than abstract policy debate.
- Model developers near the line have a real incentive to stay under it. A lab training a model at 9 × 10^24 FLOPs and one training at 1.1 × 10^25 FLOPs may produce models with barely distinguishable capabilities, but very different compliance obligations. Expect some developers to deliberately architect training runs to land just under published thresholds — a behavior regulators are aware of and actively trying to design around with parallel qualitative triggers.
- Downstream deployers inherit exposure indirectly. A business fine-tuning or deploying a systemic-risk-tier model doesn't itself cross a FLOP threshold, but it may face due-diligence expectations, contractual requirements from the model provider, or supply-chain risk questions from its own customers and auditors.
- Procurement and infrastructure decisions become compliance decisions. Where you train, how much compute you reserve, and how you document GPU-hours are no longer purely engineering or cost questions — they're inputs to a regulatory filing in some jurisdictions.
- Thresholds shape competitive dynamics, not just safety posture. A hard compute ceiling changes the calculus around whether to pursue a larger training run at all, potentially favoring companies pursuing efficiency gains (more capability per FLOP) over companies pursuing raw scale.
A quick comparison of the compliance postures
| Position relative to threshold | Typical obligations | Practical business question |
|---|---|---|
| Well below threshold | Baseline transparency and documentation requirements | Can efficiency gains deliver the capability we need without crossing the line? |
| Near threshold | Same as above, plus active monitoring of cumulative training compute | Do we track and log compute precisely enough to prove where we sit? |
| Above threshold | Systemic-risk obligations: evaluations, incident reporting, cybersecurity measures, possible advance notice to regulators | Do we have the governance function to meet reporting deadlines and respond to inquiries? |
The real limitations of measuring risk in FLOPs
Compute thresholds are a pragmatic compromise, not a scientifically validated measure of danger, and the gap between the two is where most serious criticism lands.
- Capability doesn't scale linearly with compute anymore. Algorithmic improvements, better data curation, architecture changes (like mixture-of-experts designs that activate only a fraction of parameters per inference), and post-training techniques such as fine-tuning and reinforcement learning can produce large capability jumps without a proportional compute increase. A smaller model trained more efficiently can match or exceed the practical capability of a larger, more compute-intensive one — while sitting comfortably under a FLOP threshold.
- Inference-time compute complicates the picture further. Some of the most capable recent systems get much of their performance not from training compute but from spending more compute at answer time — reasoning through a problem step by step before responding. A threshold pegged purely to training compute doesn't capture this at all.
- Thresholds create a moving target that ages badly. A number that looked appropriately restrictive when set can become either too loose (as hardware and algorithms improve, yesterday's frontier-defining number becomes tomorrow's mid-tier model) or arbitrary (once a large share of commercially available systems sit above it, the "systemic risk" label stops functioning as meaningful differentiation).
- It's an imperfect proxy for the harms regulators actually care about. A model trained with modest compute but fine-tuned specifically for a narrow harmful use case may pose more concrete risk than a much larger general-purpose model with strong safety mitigations. Compute measures scale of training investment, not intent, deployment context, or downstream safeguards.
- Verification is harder than it sounds. While cloud compute leaves records, organizations training on owned infrastructure, using distributed or federated training approaches, or operating outside jurisdictions with reporting requirements can make exact FLOP accounting difficult to independently confirm.
Most regulatory frameworks that use compute thresholds acknowledge these limits by treating the FLOP number as a presumption rather than an absolute determination — the EU AI Act, for instance, allows both upward designation (a regulator can flag a model as systemic-risk even below the threshold, on other evidence) and rebuttal (a developer can argue their above-threshold model doesn't actually pose systemic risk). In practice, though, the bright-line number does most of the day-to-day work, because presumptions are administratively cheap and case-by-case capability review is not.
Compute thresholds aren't just about training runs
Training-compute thresholds get the most attention because they're the cleanest version of the idea, but the same logic shows up in adjacent policy areas, and it's worth separating them so the terminology doesn't blur together.
- Export controls on chips use compute-adjacent metrics too — restricting the sale of accelerators above certain performance specifications to particular destinations, on the theory that limiting access to the hardware needed for large training runs is an upstream lever on the same risk that training-compute thresholds address downstream.
- Cloud compute reporting requirements ask infrastructure providers, rather than model developers, to flag when a customer's usage pattern looks like a large training run — effectively turning the threshold question into something cloud providers have to answer about their own customers, not something only the lab training the model self-reports.
- Cumulative versus single-run compute is another distinction that matters in practice. Some frameworks look at the compute used for a single training run; others look at cumulative compute across a family of related models or fine-tuning passes, which changes the calculus for organizations that iterate frequently on a base model rather than training one large model from scratch.
None of these approaches solves the core limitation described above — that compute is a proxy, not a direct measure of harm — but together they illustrate that "measure the resource, regulate the resource" has become a default policy instinct across the AI governance landscape, not a quirk unique to one law.
How this differs from capability-based regulation
It's worth being explicit about the alternative, because most debates in this space are really debates between two philosophies.
| Approach | How it decides who's regulated | Main advantage | Main drawback |
|---|---|---|---|
| Compute threshold | FLOP count crosses a fixed number | Measurable in advance, hard to fake, simple to audit | Weak, decaying link to actual capability or harm |
| Capability-based | Model performance on defined evaluations or benchmark tasks | Directly targets the risk regulators care about | Requires running and agreeing on tests; slower; easier to obscure results |
| Deployment/use-case based | Where and how the model is actually applied (e.g., hiring, credit, critical infrastructure) | Focuses on real-world harm, not model internals | Doesn't address general-purpose models before deployment; requires tracking downstream use |
| Hybrid (threshold plus rebuttal) | Compute sets a presumption; qualitative evidence can override it | Combines auditability with flexibility | Adds administrative complexity and litigation risk over classification |
Most mature frameworks, including the EU's, are converging on some version of the hybrid row — using compute as the trigger for a first pass, then layering capability and use-case considerations on top for the models that matter most. That's a tacit admission that compute alone was never meant to be a complete answer, just a workable starting filter given how fast the underlying models were shipping relative to how slowly capability-testing standards could be agreed upon.
What to watch next
A few developments will determine whether compute thresholds remain the dominant regulatory tool or get supplemented — or replaced — by other approaches:
- Whether thresholds get revised as training efficiency improves. If regulators don't periodically recalibrate the FLOP number, it risks either capturing far more models than intended or becoming irrelevant as a filter.
- How enforcement actually plays out post-August 2026. The EU AI Office's first enforcement actions against GPAI providers will signal how strictly the compute threshold gets applied in practice, and how much weight is given to qualitative risk factors alongside the raw number.
- Whether other jurisdictions converge on similar numbers or fragment. A global patchwork of different FLOP thresholds would create real compliance complexity for any lab operating across multiple markets, and would put pressure on international standard-setting bodies to harmonize definitions.
- Whether inference-time and post-training compute get folded into future frameworks. As reasoning-heavy, inference-compute-intensive systems become more common, expect proposals to measure "effective compute" or capability-adjusted metrics rather than raw training FLOPs alone.
- How smaller, highly capable models are treated. If efficient models under the threshold begin to match the practical capabilities of above-threshold systems, expect regulatory and public pressure to either lower the threshold or introduce capability-based triggers as a supplement.
FAQ
What is a FLOP in the context of AI regulation?
A FLOP (floating-point operation) is a single basic arithmetic calculation performed during model training, such as an addition or multiplication. Regulators use the total estimated FLOPs used to train a model — its "training compute" — as a proxy for how capable and potentially risky that model might be.
What is the EU AI Act's compute threshold?
The EU AI Act sets a presumption of "systemic risk" for general-purpose AI models trained using cumulative compute greater than 10^25 FLOPs. Models above that line face additional obligations, including risk evaluation, incident reporting, and cybersecurity requirements, and from August 2, 2026 the EU AI Office can fine providers found non-compliant.
Why do regulators use compute instead of testing what a model can actually do?
Compute is measurable before a model is trained or deployed, harder to misrepresent than self-reported capability claims, and historically correlated with general capability due to scaling laws. Capability-based rules require running and agreeing on evaluations, which is slower and easier to game by not disclosing results.
Can a company avoid a compute threshold by training a smaller but more efficient model?
Yes, and this is one of the main criticisms of the approach. Algorithmic efficiency gains, better data, and techniques like mixture-of-experts architectures can let a model achieve strong capability using less training compute, potentially keeping it under a regulatory threshold while performing comparably to models above it.
Does the United States have a compute threshold for AI models?
The US set a 10^26 FLOP reporting threshold for dual-use foundation models in a 2023 executive order, but that order was later rescinded, and US federal policy in this area has continued to evolve. Businesses operating across jurisdictions should track requirements separately rather than assuming one country's framework applies elsewhere.
Are compute thresholds the same as capability requirements?
No. A compute threshold measures the scale of resources used to train a model, not what that model can actually do once trained or fine-tuned. Most frameworks treat crossing the threshold as a presumption of risk that can, in principle, be rebutted or supplemented with additional qualitative evidence.
Will compute thresholds get replaced by other regulatory approaches?
Not immediately, but most policymakers treat them as a starting point rather than a permanent solution. Expect ongoing proposals to incorporate inference-time compute, capability evaluations, or "effective compute" metrics that adjust for algorithmic efficiency, especially as the link between raw training compute and real-world capability continues to weaken.
Teams that need help translating thresholds like these into concrete compliance and model-governance workflows can find hands-on support from Woyce Technologies.