Computing Power and the Governance of Artificial Intelligence

1 Introduction and Summary

• Compute has become a central enabler of recent AI progress, including large language models and generative AI, as performance often improves with additional training compute.Governments are already investing in domestic compute, restricting exports, and subsidizing access, but these efforts do not exhaust possible interventions.Source: §1 · p. 3
• Compute governance can improve visibility into AI, steer resources toward beneficial uses, and enforce restrictions on reckless or malicious development and use.These capacities could support public safety and equitable access to AI capabilities.Source: §1 · pp. 3, 5
• Compute governance is not sufficient for all AI governance because approaches beyond compute may be needed for small-scale uses with major risks, such as specialized military AI.The paper presents compute governance as one part of a broader governance approach rather than a complete solution.Source: §1 · pp. 3–4
• The paper treats policymakers broadly, including governments, company decision-makers, lawmakers, standards bodies, and international coalitions.This expansive definition includes authorities able to change norms, policies, processes, laws, or specific behaviors.Source: §1 · p. 4
• AI compute is an attractive governance target because it is detectable, excludable, quantifiable, and produced through a highly concentrated supply chain.Large-scale development often requires specialized chips in substantial data-center infrastructure, while key supply-chain steps are dominated by few actors.Source: §1 · pp. 4–5
• Compute governance should be designed and updated carefully because poorly implemented mechanisms can produce harmful outcomes, including privacy risks and other unintended consequences.The paper recommends focusing on industrial-scale compute and using privacy-preserving practices and technologies.Source: §1 · pp. 4, 6

A Visibility

• The report illustrates visibility mechanisms including public compute-based capability estimates and required reporting of training compute by cloud providers and AI developers.These mechanisms are presented as examples rather than prescribed policies.Source: A Visibility · p. 6

1. Differentially advancing beneficial AI development

• Compute allocation can be used to redistribute AI development and deployment across and within countries.The passage identifies redistribution as an illustrative allocation mechanism without prescribing a specific policy.Source: §1 · p. 6

4. Digital norm enforcement

• Compute governance faces risks from privacy concerns, leakage of sensitive information, centralization of power, and incentives for diversion, evasion, circumvention, or decoupling.These risks are presented as non-exhaustive limitations of compute governance.Source: §4 · p. 6, §1 · p. 7, §3 · p. 7

5. Implement all controls with substantive and procedural safeguards

• The paper recommends excluding small-scale and non-AI compute, developing privacy-preserving technologies, and using compute controls only where ex ante controls are justified.These safeguards are proposed in response to compute governance’s potential downsides.Source: §2 · p. 7

2 Overview of AI Capabilities, AI Governance, and Compute

• AI governance context includes the lifecycle from development to deployment and ongoing efforts to leverage compute for governance purposes.The overview covers how AI capabilities are created, defines AI governance, and reviews four current compute-governance examples.Source: §2 · p. 8, Creating AI Capabilities · p. 10

Creating AI Capabilities

• AI capabilities are produced from data, algorithms, compute, and human capital, with compute serving as the substrate that executes algorithms over data.The paper calls data, algorithms, and compute the “AI triad,” while human capital orchestrates these inputs.Source: Creating AI Capabilities · pp. 8–9
• Deep learning’s disproportionate compute intensity makes it central to this analysis but also biases the discussion toward viewing compute as especially important.The paper justifies this focus by deep learning’s prominence in current deployments and policy discussions.Source: Creating AI Capabilities · p. 8

2 Overview of AI Capabilities, AI Governance, and Compute

• Frontier AI development increasingly depends on large compute budgets, access to computing clusters, and the ability to use them effectively, but specialized systems can achieve impressive capabilities with much less compute.This limits the reach of compute-centered governance for some narrow or low-compute applications.Source: Creating AI Capabilities · p. 10

Creating AI Capabilities

• Training is typically the most compute-intensive development stage, while enhancement methods such as fine-tuning and reinforcement learning from human feedback usually require much less compute.Training requirements depend on architecture, model size, data, reuse, and the training algorithm.Source: Creating AI Capabilities · p. 11
• Deployment requires inference compute that scales with model architecture, parameter size, and the number of deployed instances, so larger and more performant systems generally require higher per-inference budgets.Although efficiency methods exist, large-scale services can require centralized high-performance infrastructure to serve many users.Source: Creating AI Capabilities · p. 11

AI Governance

• AI governance covers norms, policies, laws, processes, and institutions governing AI research, development, deployment, and use, alongside tools such as performance standards and training requirements.Source: AI Governance · p. 12

Compute Governance Today

• Compute governance is already practiced through domestic infrastructure investment, access subsidies, export controls, and compute-based reporting requirements.Examples include national AI compute resources, semiconductor restrictions, and Executive Order 14110 notifications for training runs above specified thresholds.Source: Compute Governance Today · pp. 13–16
• Compute governance efforts are unevenly distributed across countries, and poorly executed policies could undermine their benefits through privacy, security, economic, and centralization risks.The paper recommends thoughtful, flexible design and safeguards including attention to industrial-scale compute and privacy-preserving practices.Source: Compute Governance Today · pp. 13, 19
• Compute subsidies can address industry–academia disparities, but relying on major cloud providers may reinforce their power and increase vulnerabilities for countries outside the U.S. and China.Source: Compute Governance Today · pp. 14–15
• Export controls may restrict compute access for targeted actors, yet they can intensify geopolitical tensions, harm beneficial applications, centralize power, and accelerate supply-chain independence.Source: Compute Governance Today · pp. 15, 18
• Compute-based licensing and reporting remain contested because they may create barriers to competition, regulatory capture, espionage risks, and privacy or security harms.Training-compute thresholds are also only high-level proxies for model capabilities and may require revision as algorithms and hardware advance.Source: Compute Governance Today · pp. 18–19

• Compute used to train frontier systems is a strong indicator of potential impact, while deployment scale also determines how widely a model’s effects may reach.Training frontier systems can cost tens of millions of dollars, and widespread deployment to millions of users requires substantial total compute.Source: §3 · p. 20
• Compute is technologically feasible to govern because hardware is detectable, excludable, quantifiable, and produced through concentrated supply chains.Hardware can be identified, counted, tracked, and measured through operations per second, bandwidth, memory, and related technical features.Source: §3 · p. 20
• Unlike compute, data, algorithms, and trained models are generally shareable intangible goods, while human capital is much harder to quantify.Source: §3 · p. 20
• These properties establish the paper’s foundation for investigating compute-governance approaches and motivate an analogy between compute and uranium in nuclear governance.Source: §3 · pp. 20–21
• Released model weights can allow many individuals to run a model independently, so widespread deployment does not necessarily require centrally owned compute.Source: §3 · p. 20

The Importance of Compute for Frontier Models

• The compute used to train notable machine learning systems doubled roughly every six months on average, increasing 350 million-fold over 13 years.Epoch’s data report a 5.6-month doubling time between 2010 and March 2023.Source: The Importance of Compute for Frontier… · p. 21
• Compute investments have reliably delivered capability improvements, supporting a scaling-based approach in which simple algorithms exploit increasing computational resources.More compute also allows researchers to run more experiments to validate algorithmic ideas.Source: The Importance of Compute for Frontier… · p. 21
• Scaling laws describe how model performance changes with model size, data, and training compute, with fundamental performance measures generally improving smoothly as these variables increase.For language systems, performance is typically measured using cross-entropy loss on next-word prediction.Source: The Importance of Compute for Frontier… · pp. 21–22
• Reported sudden capability improvements should be interpreted cautiously because discontinuous evaluation measures can make gradual performance changes appear abrupt.The underlying dispute concerns whether continuous surrogate measures can reliably anticipate performance on discontinuous tasks.Source: The Importance of Compute for Frontier… · p. 23
• The scaling-law curves were later revised, but subsequent research retained the general conclusion that increasing scale produces strong returns.The original figure is reproduced from Kaplan et al. (2020), with the qualification that Hoffmann et al. (2022) found differently shaped laws.Source: Figure 6 · p. 24
• Compute is also essential for deployment, where serving frontier models at scale requires specialized data centers and often thousands of AI chips.Most available AI compute may be used for operating models rather than training them, although deployment compute does not map cleanly onto impact because applications and users differ in risk.Source: The Importance of Compute for Frontier… · p. 24
• Access to compute has become a de facto currency for frontier language models, influencing who can build them, how quickly capabilities diffuse, and how providers price outputs.Large compute orders can take months or years to fulfill, reflecting scarcity even for companies with multibillion-dollar budgets.Source: The Importance of Compute for Frontier… · pp. 21, 25

The Feasibility of Compute Governance

• Compute governance is underpinned by four properties: detectability, excludability, quantifiability, and supply chain concentration.Together, these features distinguish compute from several other inputs to AI progress.Source: The Feasibility of Compute Governance · p. 25, Figure 7 · p. 26

Detectability

• Large AI supercomputers are detectable because they require tens of thousands of chips, substantial power, specialized facilities, and extensive cooling and networking infrastructure.Such facilities can span several football fields, cost billions of dollars, and require complex permitting and power allocation.Source: Detectability · pp. 25–26
• Detection is incomplete because facilities may be concealed, data centers host non-AI workloads, and identifying a facility does not reveal which models it runs without potentially privacy-invasive monitoring.Decentralized training across many data centers or lower-quality compute could further undermine detectability.Source: Detectability · pp. 25–26

Excludability

• Compute is excludable and rivalrous: chip owners or cloud providers can prevent unauthorized users from accessing or simultaneously using the same hardware.This makes compute allocable or withholdable in ways that differ from published data and algorithms, which can be copied at low cost.Source: Excludability · pp. 26–27

Quantifiability

• Compute can be quantified through chip counts and specifications such as operations per second, memory, bandwidth, and communication capacity.Hardware specifications can help estimate resources, set access thresholds, and verify compliance, while training-compute measures remain incompletely standardized.Source: Quantifiability · pp. 28–29
• Hardware-based compute measurement is more transparent than directly quantifying talent, whose evaluation is difficult and constrained by privacy, association, and freedom-of-thought concerns.Common productivity indicators such as h-index and citation counts are field-dependent and favor older researchers.Source: Quantifiability · p. 29

Supply Chain Concentration

• High-end compute supply chains are highly concentrated, with TSMC dominating advanced chip fabrication, ASML supplying EUV lithography, NVIDIA holding over 90% of data-center GPU design, and cloud services dominated by a few providers.High entry barriers and slow supply expansion increase the current governability of the chain, though these conditions may change.Source: Supply Chain Concentration · pp. 29–30
• A significant fraction of frontier development and deployment compute is currently hosted in relatively few data centers containing large numbers of AI chips.This does not extend straightforwardly to decentralized edge inference, which is not expected to be suitable for training or executing the most powerful models.Source: Supply Chain Concentration · p. 31, Figure 10 · p. 31

Regulating Development Versus Regulating Deployment

• The case for compute governance does not establish that it is necessary, since comparable outcomes might be achieved through other governance approaches focused on deployment.The paper presents compute governance as promising rather than sufficient on its own.Source: Regulating Development Versus… · pp. 31–32
• Edge compute used for inference is expected to remain decentralized and unsuitable for training or executing the most powerful models, limiting the scope of compute-based controls.A single actor is not expected to control most inference edge compute.Source: Regulating Development Versus… · p. 31
• Deployment regulation alone may be inadequate because individual model copies can run on little compute, spread widely, or be stolen and deployed by actors that are difficult to monitor.This makes reliable identification of all relevant deployments difficult.Source: Regulating Development Versus… · p. 33
• Some models may create disproportionate risks even in narrow or internal deployments when their outputs can spread widely or affect critical systems.Examples include pathogen design, sophisticated computer viruses, and models that autonomously pursue unintended goals.Source: Regulating Development Versus… · p. 33
• Regulation of frontier-model development can supplement deployment controls because development is more tractable to monitor through its necessary inputs, especially compute.An upstream approach can provide more assurance than focusing solely on AI systems and applications.Source: Regulating Development Versus… · pp. 33–34
• Compute governance can also steer resources toward beneficial and defensive AI applications rather than only restricting harmful use.This role complements monitoring and enforcement of development activity.Source: Regulating Development Versus… · p. 34

4 Compute Can Enhance Three AI Governance Capacities

• Compute can strengthen AI governance by increasing visibility, allocating capabilities, and enforcing norms and laws.These capacities overlap and interact, and the policy ideas discussed are exploratory rather than established as feasible or desirable.Source: §4 · pp. 35–36
• Visibility helps policymakers identify AI actors, anticipate capability changes, make decisions, track outcomes, and support international agreements through signaling and verification.Compute governance can add tools for regulatory visibility across domestic and international contexts.Source: §4 · pp. 35–37
• Compute governance is less effective for small deployments because inference can require less compute than training, models can be optimized for wider hardware, and post-training changes can alter behavior.It can nevertheless help identify actors with the largest inference capacities, which may correlate with risks and opportunities.Source: §4 · p. 35

4. Privacy-preserving workload monitoring

• Visibility mechanisms can expose strategically and commercially sensitive information, enable espionage or misuse, and undermine their own governance objectives.Chip registries also raise questions about privacy, oppressive or corrupt use, and the treatment of small-scale consumers; geospatial monitoring may misidentify general-purpose data centers and be evaded.Source: §4 · pp. 37, 38, 40, 41
• Public compute information, cluster reporting, cloud-provider reporting, chip registries, and workload monitoring offer complementary ways to estimate capabilities, track compute, and support oversight.These mechanisms include forecasting future capabilities from scaling and compute trends, reporting large training runs, tracing chip transfers, and using workload signatures or cryptographic attestations.Source: §4 · pp. 38–39
• Compute reporting and traceability could enable post-incident shutdowns, attribution, environmental assessment, and reduced uncertainty about international capability races.Providers could help identify deployers and promptly shut down offending systems, while more transparent and verifiable compute use could alleviate information asymmetries and competitive race dynamics.Source: §4 · pp. 39, 42
• Compute usage is a useful high-level risk proxy for general-purpose frontier AI systems but not necessarily for narrow AI capabilities.Training-compute thresholds can trigger additional scrutiny, but their effectiveness depends on trustworthy reporting, information security, accurate data, and complementary mechanisms such as external auditing.Source: §4 · pp. 39–40
• Naive workload monitoring is impractical and risks privacy and human rights because low-level workloads may be difficult to interpret and contain sensitive information.Possible privacy-preserving approaches include aggregate cluster metrics, distinctions between training and inference signatures, cryptographic workload logs, and proof-of-learning linked to data centers.Source: §4 · pp. 41–42
• Greater research and investment in verifiable information-sharing could increase visibility into AI capabilities, development, and deployment, supporting stronger international agreements.Many technical mechanisms for this information-sharing remain nascent, and in some cases they could instead increase race dynamics (Emery-Xu, Park, and Trager 2023).Source: §4 · p. 43
• Poorly scoped or insecure AI workload monitoring could threaten personal privacy and the security of commercially sensitive information.The paper discusses these risks and possible mitigation approaches in Sections 5.A and 5.B.Source: §4 · p. 43
• Allocation steers AI progress by changing compute access among actors and projects according to policymakers’ preferences for AI development and deployment.Examples include government investment in domestic AI supercomputing capacity and allocating government-owned supercomputers, such as through the NAIRR.Source: §4 · p. 43

1. Differentially advancing beneficial AI development

• Compute tracking, APIs, inspections, and researcher interviews could help navigate the transparency–security trade-off in arms-control contexts.The proposed techniques are described as somewhat analogous to nuclear information barriers.Source: §1 · p. 43
• AI presents distinctive control challenges because its major evolutions occur in human minds, applications evolve in laboratories, and deployment is difficult to observe.Unlike nuclear weapons, AI is digital, conceptual, and not readily countable as a physical object.Source: §1 · p. 43
• Allocation through compute is more feasible than allocation through data or algorithms, although economists debate cash versus in-kind transfers.The paper links compute-based feasibility to compute’s unique features while noting theoretical support for cash transfers among many economists.Source: §1 · p. 43

4. Collaborating on a joint AI megaproject

• Compute allocation can prioritize risk-reducing and defensive AI, but effective subsidies also require oversight and sufficient human capital.Policymakers could support safety technologies, cyberdefense, and biosecurity, while subsidized access remains subject to governance because poorly overseen funding can enable risky research.Source: §4 · pp. 45, 47
• Positive geographic redistribution could advance global equity and Global South AI capacity, but infrastructure constraints favor long-term capacity building, multistate projects, and interim subsidies.Simply reserving chips for the Global South is likely suboptimal for now because large data centers require specialized knowledge and enabling infrastructure.Source: §4 · pp. 47–48
• Compute redistribution must balance equity against state capacity and misuse risks, because restricting access to low-capacity states can deepen computational inequality.Within countries, redistribution could also narrow the compute gap between industry and academia, startups, and community-based efforts, addressing concentrated power through ideas like the NAIRR.Source: §4 · pp. 47–49
• Compute governance can accelerate AI through semiconductor support or decelerate it when security, safety, or societal preparedness lag behind progress.Compute is especially suitable for pace modulation because its availability is comparatively easy to verify, although unilateral slowing may fail in competitive environments.Source: §4 · pp. 49–50
• A regulated compute quota could cap AI progress, but would raise prices, harm compute-constrained users, reduce investment, and provide little control over recipients.Artificial supply constraints may also face opposition from chipmakers and are unlikely to increase producer profits in an already concentrated market.Source: §4 · p. 50
• A government-operated compute reserve could regulate chip release, screen large users, and adjust supply to safety evidence while preserving future production incentives.However, the reserve’s significant downsides include the possibility of granting excessive power to its administrators; it could also use reserved chips for lower-risk purposes during braking periods.Source: §4 · pp. 50–51
• A compute reserve could slow AI progress by modulating its pace, but it would not roll back progress or affect existing compute access and could increase compute costs.The reserve would require substantial upfront government capital, while held chips could lose value as hardware improves.Source: §4 · pp. 51–52
• Entrusting policymakers with authority to modulate the pace of an entire technical field could be misused, making the conditions for doing so an open question.The passage characterizes this as a sweeping power that society rarely entrusts to policymakers.Source: §4 · p. 52
• A “CERN for AI” could pool countries’ funding to build and operate shared, capital-intensive compute infrastructure for AI research, potentially including next-generation fabs.The proposal draws on international projects such as CERN, the ISS, and ITER, whose fixed capital costs exceed the budgets of individual universities and some countries.Source: §4 · p. 52
• An international project could address legitimacy concerns associated with large corporate or national AI projects and make frontier-AI safety and security more efficient through consolidation.If participant countries raised significant safety or security concerns, the project could temporarily halt before proceeding.Source: §4 · pp. 52–53
• The megaproject could provide computing for large AI research, train frontier models for shared societal benefit, pursue AI for public goods, or focus specifically on AI safety.Possible public-good applications include clean energy, medical research, and sustainable development goals; public organization could also alter competitive incentives for private companies.Source: §4 · p. 53

• Structured access could provide API access across participating nations, while licensed entities could receive model weights to offer local APIs or fine-tune models.Secure weight transfer would be extremely challenging and require strong information security and protections against misuse.Source: A CERN for AI could consider several… · pp. 53–54
• A CERN for AI could build trust among otherwise adversarial countries through incremental, conditional investment in a shared project.Participants could withhold investment over safety or security concerns, potentially making the arrangement stabilizing if incentives align.Source: A CERN for AI could consider several… · p. 54
• Centralizing AI control in one international organization could risk monopolization by an oppressive or illegitimate government.The desirability of such an institution would depend heavily on its governance structure, which existing proposals do not clearly resolve.Source: A CERN for AI could consider several… · p. 54
• Compute allocation is a blunt policy tool because it requires reliable ex ante judgments about beneficial projects and harmful actors.Users combine beneficial, benign, and harmful activities, while determined actors may circumvent access restrictions.Source: A CERN for AI could consider several… · p. 54
• Compute-based enforcement could combine monitoring, penalties, access restrictions, and hardware or software controls that limit harmful workloads.These technically enabled mechanisms might prevent some harmful uses outright or respond automatically after misuse occurs.Source: A CERN for AI could consider several… · p. 55

Implementation trade-offs

• Hardware enforcement may resist tampering more effectively than software, but hardware additions can introduce security risks and software controls remain easier to modify.Hardware mechanisms travel with chips throughout their lifetimes, whereas software implementations are more flexible but can be modified by malicious actors.Source: §4 · pp. 55–56

Safeguards and limitations

• These enforcement mechanisms are not implementation-ready and should supplement, rather than replace, traditional governance and integrity verification.Their feasibility and robustness remain unproven, and remote control can create privacy, security, financial, safety, and abuse-of-power risks.Source: §4 · pp. 56, 58

Compute caps

• Restricting chip-to-chip networking could limit the large clusters required for training highly capable models while preserving broader chip access.Pre-authorized chips could communicate at unrestricted bandwidth, while external communication is limited; the optimal bandwidth threshold requires further research.Source: §4 · p. 57

Hardware-based remote enforcement

• Modified chips could remotely attest to legitimate operation, disable prohibited workloads, or enforce use-case policies through cryptographic authorization.Such mechanisms could support workload visibility, license renewal, performance reduction, or complete shutdown when authorization expires or is illegitimate.Source: §4 · pp. 56–58

Multiparty control

• Multiparty control could require cryptographic approval from regulators, auditors, or international bodies before especially risky training runs begin.The proposal is future-oriented and speculative, drawing an analogy to nuclear permissive action links while raising concerns about veto power, information security, and sensitive disclosures.Source: §4 · pp. 58–59

Conditional access

• Cloud providers could condition access to large-scale compute on risk-reducing requirements such as model audits and restrict access when violations are detected.This approach is more flexible and context-sensitive than broadly denying access to chips, but regulatory mandates may be preferable to provider discretion because providers may overgrant access.Source: §4 · p. 60

5 Risks of Compute Governance and Possible Mitigations

• Compute governance can infringe privacy, expose commercially sensitive information, impose economic costs, and centralize political and technical power.Visibility requirements may reveal private activities or trade secrets, while centralized control can enable surveillance, regulatory capture, suppression, and poor decision-making.Source: §5 · p. 61, Limitations · pp. 62–64

Limitations

• Compute governance should be scoped carefully because monitoring large clusters still creates tenant-privacy, security, and sensitive-disclosure challenges.Cloud customers need assurance that their intellectual property is protected, while government and military data centers may be especially sensitive targets.Source: Limitations · p. 62
• Poor information security could leak trade secrets, increase compliance costs, accelerate dangerous capability proliferation, and undermine trust in AI governance.Risks arise from disclosures by model developers, cloud providers, data centers, and semiconductor supply chains.Source: Limitations · pp. 62–63
• Algorithmic efficiency, cheaper hardware, and decentralized training can reduce the compute, cost, and data-center concentration needed for a given capability.Compute governance may remain more effective for frontier models if scaling continues to reward a small number of actors, but that condition could change.Source: Limitations · pp. 64–65
• Low-compute specialized models and post-training modifications can produce dangerous capabilities outside the reach of compute-focused controls.Examples include protein-folding systems trained with 10^23 operations, models that can be run with little inference compute, and safety features removed using one GPU and $200.Source: Limitations · p. 66
• Actors may evade controls through smuggling, lower-grade chips, cloud access, algorithmic innovation, or development of separate supply chains.Long-term decoupling could reduce strategic interdependence and weaken the ability to govern AI through compute.Source: Limitations · pp. 66–67

Guardrails for Compute Governance

• Compute governance should be carefully scoped to address the largest risks while reducing impacts on consumers and individuals.The authors frame safeguards as necessary because compute governance can create serious unintended consequences.Source: Guardrails for Compute Governance · p. 67
• The paper organizes its recommendations into five overarching principles for guarding against compute governance risks.The authors explicitly state that further research on guardrails has high value and that the principles are not exhaustive.Source: Guardrails for Compute Governance · p. 67

1. Exclude small-scale AI compute and non-AI compute from governance

• Compute governance should generally exclude consumer-scale compute and non-AI chips because frontier AI resources are a distinct, concentrated subset of computation.Current controls target advanced data-center chips, very large data centers, and frontier training runs; training at 10^26 operations could cost at least $100 million from a cloud provider.Source: §5 · p. 68
• This separation may weaken as many gaming GPUs or decentralized systems become capable of training models, requiring greater reliance on non-compute policy tools.The technical feasibility of linking gaming GPUs is not ruled out, even though current decentralized training is infeasible and would incur performance penalties.Source: §5 · p. 69

Guardrails

• Privacy-preserving governance should narrowly target large-scale purchasers and use limited indicators such as chip hours, chip types, and GPU networking.Secure communication, restricted access, and narrowly tailored disclosures can reduce exposure of personal, commercial, and national-security information.Source: §5 · p. 70
• Compute controls are best reserved for catastrophic or national-security risks where ex post penalties could not adequately compensate for harm.Because allocation and enforcement measures act upstream and can be blunt, ordinary externalities generally favor post hoc mechanisms such as taxes, fines, or penalties.Source: §5 · p. 71
• Regulators should review controlled technologies, thresholds, detection methods, and policy effectiveness at least annually because AI capabilities and technologies change rapidly.Controls can become either too loose or too strict as technologies and risk profiles change.Source: §5 · p. 71
• Compute controls should include statutory substantive limits and procedural safeguards such as notice and comment, whistleblower protections, judicial review, and public reporting.Safeguards can constrain regulated entities, requested information, and permissible controls while preserving accountability and some flexibility.Source: §5 · p. 72

• Compute is comparatively regulable because it is detectable, excludable, quantifiable, and produced through a concentrated supply chain.Source: §6 · p. 73
• Compute governance can enhance regulatory visibility, direct resources toward safe and beneficial uses, and enforce restrictions on irresponsible or malicious AI.Source: §6 · p. 73
• The paper recommends carefully scoped measures that address major risks while reducing effects on consumers and individuals.Source: §6 · p. 73
• Many proposed compute-governance mechanisms remain exploratory sketches rather than fully developed policies, requiring further work on design and implementation.Source: §6 · p. 73
• Hardware and software progress will reduce the effectiveness of many compute-governance mechanisms by lowering the hardware cost of achieving comparable AI capabilities.Source: §6 · p. 73

A The Compute-Uranium Analogy

• Both uranium enrichment and AI training transform difficult-to-produce inputs through capital-intensive processes into outputs usable for safe or harmful purposes.Source: A The Compute-Uranium Analogy · p. 75
• The analogy is limited because high-capability models have broader uses, chips are the processing location rather than the processed material, and compute lacks radioactivity-based detection.Source: A The Compute-Uranium Analogy · pp. 75–76
• The analogy suggests tracking chip fabrication, advanced AI chips, and data-center destinations using identifiers, monitoring, and supply-chain controls.Source: A The Compute-Uranium Analogy · p. 76
• Compute may be more governable than nuclear materials in some respects because parts of its supply chain have only a single company.Source: A The Compute-Uranium Analogy · p. 76
• Model-weight release can let moderately skilled actors bypass large training-compute requirements, unlike nuclear design information, motivating cybersecurity and preemptive safeguards.Source: A The Compute-Uranium Analogy · pp. 76–77
• Nuclear governance offers a proof of concept for governing a globally sought dual-use technology, despite continuing proliferation and institutional shortcomings.Source: A The Compute-Uranium Analogy · pp. 76–77

B Research Directions

• Verification can expose sensitive information because inspections and workload monitoring may intrude on privacy, especially where trust is low and competition is high.Source: B Research Directions · pp. 78–79
• Compute governance research must examine regulatory flight, geopolitical competition, responsible provision, scaling limits, and pilot studies before large-scale deployment.Source: B Research Directions · pp. 78–79