As jurisdictions around the world take their first steps toward regulating the most powerful AI systems, such as the EU AI Act and the US Executive Order 14110, there is a growing need for effective enforcement mechanisms that can verify compliance and respond to violations. We argue that compute providers should have legal obligations and ethical responsibilities associated with AI development and deployment, both to provide secure infrastructure and to serve as intermediaries for AI regulation. Compute providers can play an essential role in a regulatory ecosystem via four key capacities: as securers, safeguarding AI systems and critical infrastructure; as record keepers, enhancing visibility for policymakers; as verifiers of customer activities, ensuring oversight; and as enforcers, taking actions against rule violations. We analyze the technical feasibility of performing these functions in a targeted and privacy-conscious manner and present a range of technical instruments. In particular, we describe how non-confidential information, to which compute providers largely already have access, can provide two key governance-relevant properties of a computational workload: its type—e.g., large-scale training or inference—and the amount of compute it has consumed. Using AI Executive Order 14110 as a case study, we outline how the US is beginning to implement record keeping requirements for compute providers. We also explore how verification and enforcement roles could be added to establish a comprehensive AI compute oversight scheme. We argue that internationalization will be key to effective implementation, and highlight the critical challenge of balancing confidentiality and privacy with risk mitigation as the role of compute providers in AI regulation expands.

§ EXECUTIVE SUMMARY
tocsectionExecutive Summary

Introduction — Jurisdictions around the world are taking
their first steps toward regulating AI, such as the EU AI Act and the US
Executive Order 14110. While these regulatory efforts mark
significant progress, they lack robust mechanisms to verify compliance
and respond to violations. We propose compute service providers (compute providers below) as an important node for AI safety, both in
providing secure infrastructure and acting in an intermediary role for
AI regulation, leveraging their unique relationships with AI developers
and deployers. Our proposal is not intended to replace existing
regulations on AI developers but rather to complement them. (<ref>)

Compute Providers' Intermediary Role — Increasingly large
amounts of computing power are necessary for both the development and
deployment of the most sophisticated AI systems.
Consequently, advanced AI models today are trained, and deployed in
data centers, housing tens of thousands of “AI accelerators”
(specialized computers for AI applications). Because of the large
upfront cost of building this infrastructure and economies of scale, AI developers
often access large-scale compute through models like
Infrastructure as a Service (IaaS), also often described as cloud
computing. (<ref>)

The intermediary role of compute providers in relation to AI companies and regulators.

Some leading AI firms currently manage their own data centers or
maintain exclusive partnerships with leading entities in this domain,
known as hyperscalers. Notably, the most advanced AI research is
currently being conducted at or with these hyperscalers (e.g., Microsoft
Azure, Amazon Web Services (AWS), Apple, Bytedance, Meta, Oracle,
Tencent, and Google Cloud). While this situation presents complex
challenges for regulatory oversight, our discussion also encompasses
scenarios in which compute providers are internal to or closely linked
with an AI firm.

We focus on frontier AI systems, which
have the potential to give rise to dangerous capabilities and pose
serious risks. As these systems necessitate extensive amounts of compute
to train and deploy at large scales, targeting compute providers becomes
a promising method to oversee the development and deployment of such
systems. Furthermore, this target narrows the regulatory scope to the
smaller set of key customers who are building AI systems at the
frontier, thereby minimizing the burdens associated with regulatory
compliance and enforcement. (<ref>)

Governance Capacities — We propose that compute providers can
leverage their crucial role in the AI supply chain to secure
infrastructure and serve as the intermediate node in support of
regulatory objectives while maintaining customers' privacy and rights.
They can facilitate effective AI regulation via four key capacities: as
securers, record keepers, verifiers, and, in some
cases, even enforcers. Reporting represents a related yet
distinct dimension, wherein compute providers provide information to
authorities as mandated by law or regulations. (<ref>)

4cGovernance Capacities

1cSecurity     1c lightgrayRecord Keeping     1cVerification     1c lightgrayEnforcement
Helping provide physical and cybersecurity measures to secure the AI model, related intellectual property, and personal and confidential data.
The selective collection, organization, and maintenance of high-level information of a compute provider’s infrastructure usage, such as a customer’s compute usage data.
Actively verifying customer identities, specific activities, and high-level AI systems’ properties.
Restriction or limitation of compute access to customers or workloads for non-compliant customers.

Enables shared security standards to protect the public good, such as safeguarding critical infrastructure and helping prevent model theft.     Increases visibility into AI development, links customers and their usage to real-world actors, and enables post-incident attributions and forensics.     Ensures that the deployment and development of AI systems adhere to regulations or company policies and reported properties.     Directly impacts the capability of customers to develop or deploy advanced AI systems, ensuring adherence to rules.

t]@>p@Help prevent IP (e.g., algorithms), model weights, and training data from being stolen by malicious actors.
Help prevent attacks on large-scale deployments of foundational models that could shut down dozens of critical services nationwide.
t]@>p@Obtain insights into national compute use trends for policy formulation, such as compute distribution (e.g., US NAIRR).
Enable monitoring for suspected violations of the reporting requirements under Executive Order 14110.
Collect information on the environmental impact of AI compute use.
t]@>p@Confirm compliance with mandatory reporting over training compute thresholds.
Verify compliance with data usage guidelines for frontier AI training.
Verify if the deployed frontier AI system has an adequate license or certification.
t]@>p@Restrict access to customers lacking licenses as an AI developer for their system.
Refuse to deploy an unlicensed or non-compliant AI model.
Disable AI systems that demonstrate activity that is undesirable, uncontrollable, or in violation of regulations (e.g., computer worm-like AI system).

Summary of the key governance capacities that compute providers can enable.

Focusing on essential data that informs without compromising privacy and confidentiality.

Technical Feasibility — Our analysis indicates these
governance capabilities are likely to be technically feasible and
possible to implement in a confidentiality- and privacy-preserving way
using techniques available to compute providers today. Compute providers
often collect a wide range of data on their customers and workloads, for
the purposes of billing, marketing, service analysis, optimization, and
fulfilling legal obligations. Much of this data could also be used to
support identity verification, as well as verifying technical properties
of workloads. At a minimum, providers have access to billing information
and can access basic technical data on how their hardware is used. This
likely makes it possible for compute providers to develop techniques to
detect and classify certain relevant workloads (e.g., whether a workload
involves training a frontier model) and to quantify the amount of
compute consumed by a workload. Verification of more detailed properties
of a workload, such as the type of training data used, or whether a
particular model evaluation was run, could be useful for governance
purposes but is not currently possible without direct access to customer
code and data. With further research and development efforts, compute
providers may be able to offer “confidential computing” services to
allow customers to prove these more detailed properties without
otherwise revealing sensitive data. (<ref>)

Constructing an Oversight Scheme — Via Executive Order 14110 the US
government is already beginning to implement record keeping roles for
compute providers by requiring them to implement a Customer
Identification Program (essentially a Know-Your-Customer (KYC) program) for foreign
customers, and to report foreign customer training of highly capable
models to government. Expanding the role of compute providers to also
record and validate domestic customers using compute at frontier AI
thresholds could enable the US government to identify and address AI
safety risks arising domestically. Complementing these measures with
verification and enforcement roles for compute providers could further enable
the construction of a comprehensive compute oversight scheme, and ensure
that AI firms and developers are complying with AI regulations. (<ref>)

Additional measures, implemented by the Department of
Commerce, would strengthen the intermediary role of compute providers
and enable a compute oversight scheme.

Technical and Governance Challenges — To realize a robust
governance model, several technical and governance challenges remain. These include identifying additional measurable properties of
AI development that correspond to potential threats, making workload classification methods robust to potential evasion, and
formulating privacy-preserving verification protocols. (<ref>)

The success of our proposed oversight scheme hinges on its multilateral
adoption to prevent the migration of AI activities to jurisdictions with
less stringent oversight. For an international framework to be durable
and effective, it must address concerns from non-US governments.
Cooperation will need to account for complex privacy and oversight
issues associated with globally spread data centers. Compute provider
oversight may affect competition in the AI ecosystem and raise concerns
about issues of national competitiveness, and, consequently, this may
influence the ability of US providers to offer products globally,
including to foreign public-sector customers. Industry-led
privacy-preserving standards could help ensure trust, but further
research is needed to incentivize broad
international buy-in to a global framework. (<ref> and <ref>)

Conclusion — Compute providers are well-placed to support
existing and future AI governance frameworks in a privacy-preserving
manner. Many of the interventions we propose are feasible with the
current capabilities of compute providers. However, realizing the
full potential necessitates addressing technical and governance
challenges, requiring concerted efforts in research and international
cooperation. As governments and regulatory bodies move to address AI
risks, compute providers stand as the intermediate node in ensuring the
effective implementation of regulation. (<ref>)

§ INTRODUCTION

As governments, international organizations, and regional bodies
formulate approaches for governing advanced AI, we ask: how can
authorities gain visibility into development and deployment practices
and enforce rules? The visibility is currently obscured because frontier
AI development largely takes place within the private sector and often
relies on self-reporting by AI companies, which may not always be
reliable due to growing incentives to obfuscate the results
[Anderljung et al., 2023, Mulani & Whittlestone, 2023, Whittlestone & Clark, 2021].
Ongoing governance processes worldwide require answers to this question.

Jurisdictions including China, the European Union (EU), the United
Kingdom (UK), and the United States (US) are attempting to impose new
reporting requirements on AI firms and compute providers
[Future of Life Institute, 2024, Jiang & Cao, 2023, Secretary of State for Science, Innovation and Technology, 2023, Senator Scott Wiener, 2024, Sheehan, 2024, The White House, 2023]. They are also beginning to
regulate the development and deployment of models with potentially
harmful capabilities. Yet, enforcing these rules proves challenging;
without appropriate mechanisms, it is difficult to detect
violations [Hacker, 2023, Whittlestone et al., 2023]. Governance
approaches, such as the recent US Executive Order
[The White House, 2023] and the EU's proposed AI
Act [Council of the European Union, 2024], have not
developed practical means such as robust spot-checking (randomized
inspections to ensure compliance) and evidence-gathering mechanisms for
achieving these goals.

This paper demonstrates how compute providers—firms who make
computing resources (“compute” below)[For a discussion of
compute as a governance node, see
[Sastry et al., 2024].] available
for AI development and deployment—can effectively serve as an
intermediary for frontier AI governance between governments and the
firms developing and deploying AI. In this role, compute providers can
act as a first line of detection of violations of a governance regime
and even defend against violations.

§.§ Compute Providers' Intermediary

Large amounts of computing power are necessary for both the development
and deployment of frontier AI systems. Consequently, advanced AI models
are trained, and deployed, in data centers[Our focus is
on the entities that own and operate data centers, prioritizing the
“legal entity” level of abstraction over the physical locations or “data
centers” themselves.], housing tens of thousands of AI accelerators.
Because of the large upfront cost of building this infrastructure
, AI developers often access large-scale compute through
models like IaaS[This discussion extends
to services that offer hardware access with sufficient flexibility for
customer-defined usage, which may occasionally encompass certain
Platform-as-a-Service (PaaS) offerings. However, our emphasis is on
scenarios in which usage surpasses certain AI compute thresholds that
are of relevance for frontier AI. In contrast, services providing
access to pre-configured AI models (Software-as-a-Service, or SaaS)
fall outside our defined scope of compute providers. (The suggested
governance capacities could still help if the regulation of these
services is desired.)], also often described as cloud
computing.[The term “cloud” is more associated with a specific
business model rather than the underlying activity of providing
compute resources. For this context, we prefer the term “compute
providers” to accurately reflect the focus on the provision of
computing power. This choice also allows us to include entities that
predominantly provide their computational resources internally (e.g., Meta [Janardhan, 2023]) within the scope of our discussion.] Throughout this
paper, we refer to entities that provide access to this computational
power as compute providers.

Some AI firms currently manage their own data centers or maintain
exclusive partnerships with leading compute providers, known as
hyperscalers.[The most notable hyperscalers include
Microsoft Azure, Amazon Web Services (AWS), Apple, Bytedance, Meta,
Oracle, Alibaba, Tencent, and Google Cloud
[Vailshery, 2024].] Notably, the
most advanced AI research is currently being conducted at or with these
hyperscalers.[Many prominent AI companies either operate as
hyperscalers themselves or maintain strategic partnerships with them.
For example, OpenAI's collaboration with Microsoft
[Microsoft Corporate Blogs], 2023], and
Anthropic's associations with AWS and Google Cloud
[Amazon.com, Inc., 2023, Anthropic, 2023] , exemplify such
relationships. While this situation introduces complex challenges for
regulatory oversight, our discussion also encompasses scenarios in which
compute providers are internal to, or closely linked with an AI
firm.[These relationships and the concentrated market for
large-scale compute have given rise to antitrust and competition
concerns, drawing scrutiny from regulators, including an ongoing
inquiry by the US Federal Trade Commission
[Federal Trade Commission], 2024] and an
investigation by the UK Competition and Markets Authority
[Milmo, 2023]. While we acknowledge the need to
carefully analyze how enhanced regulatory measures may impact
competition issues in the sector, we expect the impact to be limited
and not broadly significant. This is due to the focused scope of the
measures, targeting only those compute providers capable of supporting
large-scale AI infrastructure and customers who are running
large-scale workloads costing tens to hundreds of millions of dollars
or more. A detailed discussion of these antitrust concerns requires
broader analysis and is beyond the scope of this paper. For example,
an AI company should not be able to circumvent the proposed guidelines
by categorizing its usage as internal provisions or failing to identify
itself as a customer. This would ensure comprehensive coverage of all
relevant forms of compute provision for frontier AI.

*Figure 1: The intermediary role of compute providers in relation to AI companies and regulators.

§.§.§ Regulatory Intermediaries

The use of private sector entities as regulatory intermediaries is not a
new concept [Abbott et al., 2017, Abbott et al., 2017, Hay & Shleifer, 1998]. Regulations for the aviation
industry require airline operators to maintain security plans, keep
records on passengers, verify passenger identities, and deny boarding in
response to specified violations
[ECFR, 2024, Aviation Transport Security Act, 2005]. In the context of communication
service providers, some governments have enacted data retention policies
that require the collection and retention of information on customers'
activities for a specified amount of time
[Australian Attorney-General’s Department, 2015, Country Legal Frameworks Resource, 2023]. Internationally coordinated
anti-money laundering and counter-terrorism financing standards require
financial institutions to keep records, verify identities, and act to
prevent illicit flows of money
[Financial Action Task Force, 2023].

Compute providers are already subject to regulations that dictate
operational standards and data management practices. For example, laws
targeting Child Sexual Abuse Material (CSAM) impose obligations on
compute providers to detect and report such content
[Amazon.com, Inc., 2023, Biden, 2008, European Union, 2011]. Data protection regulations, such as the General
Data Protection Regulation (GDPR) in the EU, set stringent requirements
for data handling, privacy, and user consent, which significantly affect
how compute providers manage and secure user data [AWS, 2024, European Union, 2016, Google Cloud, 2021]. Additionally, legislation aimed
at combating terrorism and extremism may require compute providers to
monitor and restrict the dissemination of harmful content
[European Union, 2021].

§.§ Focus on Frontier AI

The customer base of AI compute providers is diverse, ranging from
individuals and small enterprises to large corporations and government
agencies. However, the primary focus of this paper is on a subset of AI
systems known as frontier AI. Frontier AI systems are defined as
“highly capable general-purpose AI models that can perform a wide
variety of tasks and match or exceed the capabilities present in today's
most advanced models”
[UK DSIT, 2023].[Also
see Section 2.1 of Anderljung et al., 2023.]
These systems represent the frontier of current AI capabilities and
currently require substantial compute resources for their development
and operation [Anderljung et al., 2023, Sastry et al., 2024, Sevilla et al., 2022].

Given the significant compute and research demands, only a small number
of entities possess the necessary resources to develop frontier AI
systems. This paper addresses primarily large corporations for
regulatory consideration. The intent of the proposed regulatory
frameworks is not to encompass the entirety of compute
providers' customer base indiscriminately. Rather, the
focus is limited to those actors who are in a position to develop or
deploy frontier AI systems—based on their compute usage—warranting
closer scrutiny and potential regulation. This targeted approach ensures
that regulatory measures are both effective and proportional, avoiding
unnecessary encumbrances on smaller entities or individual users who do
not fall within the relevant frontier AI activities.[In
<ref>, we elaborate on privacy and confidentiality
considerations, emphasizing that our proposed regulatory measures are
specifically aimed at key actors in frontier AI development, rather
than being broadly applied to the entire customer base of compute
providers, such as individuals.
Heim & Egan, 2023 and
Egan & Heim, 2023 also discuss the idea of
“above-threshold compute usage.”]
Sastry et al., 2024 discuss the importance of
compute for frontier models in more detail and examine the conditions
under which compute, and by extension, compute providers, serve as
effective policy levers, as well as scenarios and conditions where their
impact is limited.

§.§ Overview of our

We suggest that compute providers can play a key role in governance
regimes similar to the examples listed above via four key capacities: as
securers, record keepers, verifiers, and
enforcers. Security can restrict access to AI-related IP, such as
the model weights, from bad actors. Record keeping allows selected
information gathering for insights into AI activities and allows for
post-incident attribution. Verification includes checking customer
activities and AI systems to verify compliance with regulations and
standards. Enforcement entails the restriction or limitation of compute
access for non-compliant customers.

We analyze the technical means of performing each of these functions.
Concerning security, we outline the role many compute providers
already serve in establishing baseline levels of physical,
infrastructure, and network security, and briefly discuss how this role
should be expanded to address more sophisticated threats. Regarding
record keeping, we describe the information that is likely
already available to compute providers and the potential insights it can
offer. Regarding enforcement, we review the capabilities of data
center providers to facilitate the enforcement of standards, either of
an external governance regime or of their own terms of service.

We focus much of our technical analysis on the role compute providers
could play in verification in a targeted and privacy-conscious
manner. We describe information that is already available to compute
providers that can be used for four sub-categories of verification:
workload classification, compute accounting, verification of properties
of code and data (“detailed workload verification”), and identity
verification, such as Know-Your-Customer (KYC) regimes
[Egan & Heim, 2023, Smith, 2023]. Several of these
techniques could be used in real-time to establish whether a customer is
engaging in an activity that might be subject to regulatory oversight.
If compute providers were to implement these techniques, they could
likely distinguish whether their customers are engaging in activities
such as training a large model, or engaging in inference at scale, as
well as quantify the amount of compute consumed by large workloads

After describing the technical possibilities, we focus on the US,
explaining how some of the techniques we describe can facilitate
compliance with the mandates of the Biden Administration's 2023
Executive Order 14110 on Safe, Secure, and Trustworthy AI (hereafter
“the AI Executive Order”) and support its overall objectives
[The White House, 2023]. We identify a set of next
steps for compute providers to verify that model developers have met
their Section 4 requirements under the AI Executive Order. We further
argue that the broad goals of the AI Executive Order could benefit from
the full range of techniques described here, particularly when
internationalized. In the final section, we highlight the technical and
governance challenges and opportunities for technical governance and
policy research.

§.§ Limitations and Future Research

In this paper, we propose a conceptual model wherein compute providers
improve the efficiency and effectiveness of the developing regulatory AI
ecosystem. Our discussion is not a comprehensive policy blueprint ready
for implementation. While certain aspects of our proposal may be
directly actionable, other aspects require more evaluation.
Our primary objective is to argue for particular roles for compute
providers and to stimulate a debate: Should compute providers embrace
the roles we have outlined? Which of the proposed activities are most viable, and which
require further research?

While we emphasize the need to internationalize our proposed concept, we
acknowledge that this aspect is not explored in detail, especially the
legal aspects. The complexity of such an analysis extends beyond the
scope of this paper, calling for detailed legal and policy analysis. Our
aim is to motivate more research in this domain, recognizing the need
for a more comprehensive investigation into the intricacies involved in
applying these regulatory concepts across different jurisdictions. This
is particularly relevant given the intricate challenges that have
emerged in the past, such as those surrounding the EU-US Privacy Shield,
and others [Buttarelli, 2018].

Some of the suggested regulatory measures may have implications on
privacy and confidentiality for customers of compute providers and we
recognize that increasing legal reporting requirements must be carefully weighed
against the potential for misuse or government overreach. However, our
focus—frontier AI—largely pertains to compute-intensive workloads
undertaken by a limited number of corporate entities. This simplifies
the regulatory landscape with respect to information describing these
workloads and the companies running them, as stringent privacy
regulations like the GDPR safeguard the personal data of individuals
(“natural persons”), while typically imposing fewer constraints on data
related to companies (“juridical person”).

The urgency of this discourse is magnified by the KYC requirements outlined in the US's AI Executive Order, with
implementation currently being progressed through the Department of
Commerce's proposed rule [Federal Register, 2024].[Especially,
as some of the currently proposed measures may be overly broad,
potentially violating confidentiality principles.] Reaching a
comprehensive and thoughtful regulatory framework requires going beyond
unilateral measures, which could lead to unintended adverse
consequences. International coordination is crucial to address the
questions arising from the intersection of AI regulation with
international trade law, confidentiality, and privacy. This paper
contributes to the dialogue and advocates for an AI regulatory framework
that is collaborative, nuanced, effective, and globally
inclusive and responsive.

§ GOVERNANCE CAPACITIES OF COMPUTE PROVIDERS

In the current ecosystem, frontier AI models are trained and deployed
using large compute clusters consisting of thousands to tens of
thousands of AI accelerators [Pilz & Heim, 2023, Sevilla et al., 2022]. The concentrated supply chain, in
addition to the detectability, excludability, and quantifiability of
physical computing hardware, makes compute a particularly effective node
of governance compared to other inputs to AI development
[Belfield & Hua, 2022, Pilz & Heim, 2023].

Therefore, the physical infrastructure required for AI development and
deployment can be used as an instrument to enhance existing AI
regulations—making them more efficient and effective while enabling
new policies. Compute providers can perform these functions via four key
capacities: as securers, to protect IP; record keepers,
enabling data collection for analysis and future reference; as
verifiers of customer activities, enabling appropriate oversight;
and as enforcers, taking actions against norm and rule
violations. We discuss these capacities in this section in more detail.

This approach offers a nuanced alternative to broad measures such as
chip export controls [Allen, 2022], positioning compute providers
as a more precise and adaptable governance mechanism within the AI
supply chain. Unlike controls on physical computing hardware, the
dynamic model of compute provision affords a higher degree of
flexibility and specificity (Table 1 in Heim & Egan, 2023).

§.§ Compute Providers in the AI Compute Supply

In the AI supply chain, compute providers act as an intermediary,
offering computational resources to customers. These providers house
large numbers of chips in their data center facilities, operating them
cost-effectively in large quantities with necessary elements such as
power, land, cooling, and connectivity, and optimizing them for
developing and deploying AI models (<ref>). With current
technologies, training large AI systems requires physically co-located
chips. This has caused much of contemporary AI deployment and
development to occur in large facilities, wherein compute is made
available to customers digitally and remotely, often through models like
Infrastructure as a Service (IaaS) or cloud computing. The compute
provider industry has seen significant consolidation in recent years due
to the economic advantage of scale [Richter, 2024].

The compute supply chain including compute providers
in the middle. Like the production of state-of-the-art AI chips, compute
providers' market shares are concentrated. (Figure from Sastry et al., 2024.)

By capitalizing on their position as infrastructure providers, compute
providers can play a key role in regulating AI companies. Leveraging
compute in this manner can help reduce regulatory burdens because each
compute provider (i) typically services multiple AI firms,[The
size of the customer base of compute providers varies significantly.
Typically, compute providers offer their services to a wide range of
entities, with most usage falling outside the scope of our primary
concern in this paper (see <ref>).
Nonetheless, our analysis also includes large compute owners who
exclusively use their resources internally. For example, a major
technology company cannot circumvent the guidelines proposed in this
discussion by merely categorizing its usage as “internal provisions”
or not identifying itself as a “customer.” This approach ensures
comprehensive coverage of all relevant forms of compute provision for
frontier AI.] thereby streamlining the regulatory process, and (ii)
screens potential targets for regulation by the scale of compute usage
(which can be supplemented by further criteria), whether it is used for
training or deployment. This follows the model of how financial
institutions operate under KYC schemes
[Financial Crimes Enforcement Network, 2005, Financial Crimes Enforcement Network, 2024, Egan & Heim, 2023],
although compute providers with the capacity for frontier AI development
and deployment are much fewer in number than banks.

§.§ Governance Capacities

Compute providers can facilitate effective AI regulation via four key
capacities. They can be securers, record keepers,
verifiers, and, in some cases, even enforcers (<ref>).

4cGovernance Capacities

1cSecurity     1c lightgrayRecord Keeping     1cVerification     1c lightgrayEnforcement
Helping provide physical and cybersecurity measures to secure the AI model, related intellectual property, and personal and confidential data.
The selective collection, organization, and maintenance of high-level information of a compute provider’s infrastructure usage, such as a customer’s compute usage data.
Actively verifying customer identities, specific activities, and high-level AI systems’ properties.
Restriction or limitation of compute access to customers or workloads for non-compliant customers.

Enables shared security standards to protect the public good, such as safeguarding critical infrastructure and helping prevent model theft.     Increases visibility into AI development, links customers and their usage to real-world actors, and enables post-incident attributions and forensics.     Ensures that the deployment and development of AI systems adhere to regulations or company policies and reported properties.     Directly impacts the capability of customers to develop or deploy advanced AI systems, ensuring adherence to rules.

t]@>p@Help prevent IP (e.g., algorithms), model weights, and training data from being stolen by malicious actors.
Help prevent attacks on large-scale deployments of foundational models that could shut down dozens of critical services nationwide.
t]@>p@Obtain insights into national compute use trends for policy formulation, such as compute distribution (e.g., US NAIRR).
Enable monitoring for suspected violations of the reporting requirements under Executive Order 14110.
Collect information on the environmental impact of AI compute use.
t]@>p@Confirm compliance with mandatory reporting over training compute thresholds.
Verify compliance with data usage guidelines for frontier AI training.
Verify if the deployed frontier AI system has an adequate license or certification.
t]@>p@Restrict access to customers lacking licenses as an AI developer for their system.
Refuse to deploy an unlicensed or non-compliant AI model.
Disable AI systems that demonstrate activity that is undesirable, uncontrollable, or in violation of regulations (e.g., computer worm-like AI system).

*Table 1: Summary of the key governance capacities that compute providers can enable.

Focusing on essential data that informs without compromising privacy and confidentiality.

These governance capacities are distinct from but related to obligations
to report information to governments. In many cases, it will be
appropriate for compute providers to collect and retain information
internally and only provide information to governments in response to
existing legal authorities (for example, identified violations of
sanctions, or in response to legal warrants). In other cases, for
example, where a customer is undertaking a large training run,
regulators may see fit to mandate proactive reporting. Record keeping
can ensure that compute providers are aware of, and able to comply with,
broader regulations to increase visibility and oversight.

Overview of the different governance capacities
and how they relate to three actors: customers (the AI developers and
deployers), compute providers, and regulators.

§.§.§ I. Security

Compute providers, as custodians of sensitive data and AI-related IP,
have a distinct capacity for governing and implementing information
security measures that protect AI systems.

The security measures implemented by compute providers to help protect AI company's models,
intellectual property, and confidential data.

Frontier AI models represent considerable financial, computational,
research investments, and powerful tools that could be misused for
financial or political gain; this makes them highly attractive to cyber
attackers and other adversarial actors
[Cottier, 2023, Sevilla et al., 2022]. Security measures should extend beyond
safeguarding model weights to include the protection of the model's
architecture, its algorithmic innovations, training data, and other
related intellectual property (IP) [Nevo et al., 2023]. Therefore, it is
important to take robust cybersecurity measures proportional to these
risks. These measures could be legally mandated, as with the physical
and cybersecurity precautions currently required from data centers that
handle HIPAA- and ITAR-compliant health
[Office for Civil Rights, 2016] and defense data[ITAR
compliance requires arms-related data to be secured from foreign
persons. There is no formal certification process for cloud providers,
although many choose to be audited by a third-party organization
certified under the Federal Risk Authorization Management Program
(FedRAMP) [Code of Federal Regulations], 2024].,
as preventing the theft of potentially dual-use AI intellectual property
and disruption to critical AI infrastructure are matters of public
good.[Such regulations could be enforced by chartering or
registration (for example, firms cannot accept federally insured
deposits unless chartered as a bank, credit union, or thrift)
[Congressional Research Service], 2023], or tied to a license to
acquire specialized AI compute hardware, as is already in place for
the export of certain equipment from US companies [AMD, 2024].

Such a measure should take into account existing industry practice:
Large-scale compute providers already allocate significant resources to
physical and cybersecurity, given strong business incentives to keep
clients' sensitive data secure (including, in some cases, classified
government data [Lohr, 2023]. When multiple AI firms utilize a
single compute provider, they inherently benefit from the
provider's comprehensive physical and cybersecurity
measures, which benefit from the economies of scale and significant
investment. Nevertheless, compute providers remain vulnerable to
malicious cyber actors and can be the subjects of successful cyber
attacks [Gatlan, 2023, Vanian, 2024]. The potential for frontier AI
to be stolen, misused, or to become critically important infrastructure,
may warrant the development of stronger security requirements for the
compute providers that train and deploy them. This necessity was
reflected in the voluntary White House Commitments
[The White House, 2023] and the Hiroshima International Guiding
Principles for AI, which advocate for strengthened safeguards in this
domain [European Commission, 2023, European Commission, 2023].

It is crucial to acknowledge that the responsibility for ensuring
information security does not rest solely with compute providers. The
efficacy of their security measures requires robust security practices
and collaborative efforts by AI companies themselves. Without these
companies' proactive engagement in safeguarding their operations, the
protective mechanisms implemented by compute providers could prove
ineffective. Therefore, these efforts are not substitutive but rather
complementary, with both compute providers and AI companies sharing

§.§.§ II. Record Keeping

Record keeping describes the process of collecting, organizing, and
maintaining information on a compute provider's
customers and their infrastructure usage. Compute providers are
inherently record keepers by virtue of their role and technical
necessity. They store and process valuable technical data during large
AI deployments and training runs for billing purposes, resource
management, and service-level agreement tracking (see <ref> for
more detail). Provided that robust privacy protections are in place,
this information could be useful to regulators in overseeing the
development of advanced AI systems. We recommend that regulators and
providers focus on essential data that informs AI regulation without
compromising privacy and confidentiality (which we discuss in more
detail in <ref>).

The compute provider collects and manages essential
usage data on the AI company and its infrastructure usage, focusing on key data that helps validate regulatory compliance without compromising privacy. This facilitates greater transparency into AI advancements,
could link compute use to real-world actors, and enables effective
post-incident response and forensics.

Record keeping serves three main purposes: it allows more visibility
into the developments of AI generally, helps link customers and their
usage to real-world actors, and enables post-incident attributions and
forensics. First, it provides visibility into AI developments, which is
important for monitoring the trajectory of AI systems and their compute
requirements across various sectors
[Sastry et al., 2024]. As we have seen
demonstrated by recent national compute initiatives
[Center for Open Science, 2019, UK DSIT & Donelan, 2023, The European High Performance Computing Joint Undertaking, 2023, U.S. National Science Foundation, 2024], compute provision can be a
mechanism to guide AI development and formulate policies for a
beneficial distribution of compute resources [Besiroglu et al., 2024, Sastry et al., 2024]. By gathering aggregated and
anonymized compute usage data, governments are better positioned to
formulate policies that mitigate unequal access, reduce market
monopolization, address potential negative impacts, and boost beneficial
innovations aligned with national objectives
[Sastry et al., 2024].

Second, record keeping enables compute providers and regulators to
identify their customers and the corresponding legal entities (KYC).
With the development of frontier AI regulations, it will likely become
necessary to verify the identity of compute customers utilizing large
amounts of compute and ensure that they have the necessary
certifications and safeguards in place, if they plan to build and deploy
advanced AI systems. Furthermore, countries may wish to enforce export
controls on compute, restricting the sales of data center capacity to
actors with improper sources of funding (e.g., terrorist organizations)
or originating from sanctioned geographical areas
[US BIS & US DOC, 2023, Heim & Egan, 2023].

Third, and related to customer verification, record keeping enables
post-incident attributions and forensics
[O'Brien et al., 2023].[An example
of this could be in the event of an AI system malfunctioning and
causing financial loss or physical harm, record keeping allows for the
traceability of the AI's development and deployment
process, helping to identify the origin of the fault
(forensics) and parties responsible (attribution).]
Information about developers and their activities is critical for
assigning liability or enhancing existing systems in the aftermath of
incidents. This is akin to mandatory record keeping in the financial and
telecommunications industries for law enforcement purposes
[legislation.gov.uk, 2014, U.S. Securities and Exchange Commission, 2003]. We
propose careful legislation that requires compute providers to maintain
relevant records while taking into account privacy concerns and the
regulatory burden. This is especially important in cases of potential
unlawful use where the developers may not keep adequate records in the
absence of legislation. For example, high-level compute utilization data
could be made available to regulators upon request, while detailed
retained information may be kept confidential unless required for
enforcement or legal proceedings.

In contrast to verification, which is introduced below, record keeping
does not require active processing by the compute provider. Instead, it
describes the collection of specific data, which is already happening to
some extent, to make more information available to governments. For
example, it could inform national policy decisions and strategies
[Whittlestone & Clark, 2021], and help prevent and
respond to serious incidents (where required under warrants and/or by
regulation). The use of aggregated and anonymized compute usage
statistics could offer valuable insights into trends in AI development
and corresponding compute demands (e.g., to learn more about the impacts
of the compute divide [Ahmed & Wahed, 2020, Besiroglu et al., 2024]). This approach allows regulators to understand and
respond effectively to the evolving needs of the AI economy without
encroaching upon the privacy and confidentiality of companies. This
could operate on a need-to-know basis, ensuring that only pertinent
information is gathered and utilized in a way that minimizes regulatory

Furthermore, transparency requirements for environmental accountability,
particularly in the context of compute providers' substantial energy
consumption, have been suggested
[OECD, 2022]. Mandating reports on
the environmental impact of compute providers could equip regulatory
bodies with the insights necessary to fulfill environmental objectives.
The EU already has implemented reporting requirements.[“Under
the directive, owners and operators of data centers with 500 kilowatts
or more of installed IT capacity will need to report their 2023 energy
performance by May 15, 2024. That includes statistics about installed
power, incoming and outgoing data traffic, total data stored and
processed, energy consumption, power usage, temperature set points,
waste heat utilization, and use of renewable energy.”
[Korolov, 2023]] Concurrently, numerous compute providers are
already advancing toward greater environmental transparency and have
pledged to undertake climate initiatives. [Amazon.com, Inc., 2024, Microsoft Azure, 2024, Google Cloud, 2024].

§.§.§ III. Verification

Compute providers can also actively verify customer compliance with
regulatory requirements, providing AI firm oversight. Similar to banks
and other financial intermediaries, compute providers can actively
verify the identity of customers and key customer activities, checking
that the properties of AI systems being deployed or developed match
customer reporting. This might include verifying the type of
computational workload run by the customer (e.g., training an AI model,
or deploying a model at scale) as well as claims about the total amount
of compute used, or the type of data used in the training process.[Hardware-enabled mechanisms for verification and enforcement
of governance regimes are discussed in
Aarne et al., 2024 and
Kulp et al., 2024.]

The compute provider actively verifies the AI
company's identities, specific activities, and/or
properties of AI systems for regulatory compliance.

As we will discuss in <ref>, some of these capabilities, such as
identifying whether a customer is training or deploying an AI model, can
likely be implemented using existing data collected by compute
providers. Providers could use this information to catch regulatory
violations, including breaches of model training requirements, wherein
developers avoid reporting requirements and the unauthorized deployment
of AI models at scale.

Verification rules should balance between regulatory requirements,
customer privacy laws, and safety considerations, similar to record
keeping practices. Spot checks (including those triggered by reports or
events that raise suspicion) may be adequate for less risky activities,
while continuous monitoring to ensure that customer-submitted records
are accurate may be mandated for riskier ones. Providers can then check
if mandated or adequate risk practices are applied. AI safety
regulations could be applied only to those using large amounts of
compute and waived for smaller customers. Additional factors may warrant
further examination, like a history of non-compliance or inclusion on
restrictive lists like the US Department of Commerce's
Entity List, which serves to protect national security interests. The
standardization and aggregation of reporting processes across providers
is crucial for ensuring effective cross-provider verification. This
uniformity prevents AI developers from evading regulations by splitting
their training or deployment activities among multiple providers.

Verification becomes vital in cases of behavior that may indicate
non-compliance, such as a failure to report details of a training run
mandated by regulations like the AI Executive Order. For example, if
there is credible evidence of a sophisticated AI model having been
trained, regulators could request certain verifications from compute
providers to confirm that model developers or providers are in
compliance. This approach is similar to selective tax audits, providing
the regulation with more enforcement capability [Advani et al., 2023].
Even though immediate action might not be taken, having access to such
information allows for inspection if necessary, especially in response
to suspicious activity. Compute providers could respond to such
regulatory requests by verifying customer activities and providing an
additional check that model developers are following rules. This process
may involve asking customers to provide justifications or evidence for
their activities in the same way that financial institutions can inquire
about suspicious transactions from their clients.

Unlike record keeping, verification demands more proactive engagement
from compute providers. Verification could span a wide range of
different specific activities and may include confirming the identities
of customers who use substantial compute resources or checking that the
workload being executed matches their declared type. In complex cases
(such as frontier model training) or direct violations of reporting
requirements, the compute provider may flag the case and refer it
directly to regulators. It is important to note that several open
questions regarding privacy and technical feasibility must be
investigated and potentially addressed prior to implementation. These
considerations are discussed in the <ref>.

For illustrative purposes, imagine a scenario in which regulations
require AI developers to report their compute usage, or notify a
government prior to training a model above a certain compute threshold,
as has been outlined in the AI Executive Order. In such cases, an AI
developer could be required to provide information about compute usage
to the provider. This allows customers to demonstrate that their
computing power was employed for specific purposes, such as training
several smaller models rather than a single larger model, which might be
subject to different compliance standards. The provider then checks that
the actual usage is consistent with the developer's
representations. If inconsistencies are identified, the compute provider
can flag these events for further investigation and compliance checks.
This arrangement, which uses compute providers as an intermediary, helps
minimize regulatory burdens on the AI industry. Similarly, a compute
provider could require a model developer to provide proof that they have
appropriately notified the government of a threshold-exceeding training
run prior to the compute provider allowing access to related compute.

§.§.§ IV. Enforcement

Compute providers can also aid regulatory enforcement. By virtue of
controlling the AI data centers themselves, providers have the ability
to directly deny access to rule-breaking customers, and, therefore,
prevent the customer from developing or deploying certain kinds of AI
systems with that provider. The compute provider might limit compute
resources devoted to workloads that raise red flags pending further
investigation. Similarly, record keeping and verification processes
could trigger regulatory enforcement measures by other actors, such as
the Department of Justice in the US.

The compute provider detects violations by the AI
company, e.g., via the verification process, and can take appropriate
enforcement actions, such as restricting or limiting access to compute.

In addition to assisting governmental enforcement, compute providers can
enforce their terms of service (ToS). By expanding their ToS to include
stipulations on AI development and usage to promote safety, providers
can autonomously enforce compliance. This self-regulation approach goes
beyond merely reacting to government regulations; it could be an active
promotion of responsible AI practices—reflecting the
providers' commitment to ethical standards in AI

Direct enforcement by compute providers can come in multiple forms. On
the most basic level, regulation could be crafted to require providers
to refrain from providing compute to developers to train a model above a
certain threshold until the developer proves they have taken appropriate
regulatory steps, such as notifying the government of a large training
run or obtaining relevant approvals. Providers could also help
regulators enforce rulings (e.g., when a license is denied, or when a
government is trying to prevent a malicious actor from accessing
compute) or automatically deny the execution of AI software depending on
whether the model is approved. More fine-grained restrictions, such as
slowing access or limiting certain workloads until the proper regulatory
approvals are issued (similar to financial service providers temporarily
flagging a transaction for further review), could also be enforced.
Compute providers could monitor the activity of customers using large
amounts of compute that have stated they are not engaging in model
training for signs they are circumventing the types of requirements laid
out above.

Enforcement works most effectively in conjunction with verification.
Detected violations can be promptly acted upon through the compute
providers' capabilities. However, it is crucial to keep
these two capacities distinct. Enforcement actions can be based on
information beyond what is verified by compute providers, for example,
in response to intelligence provided by law enforcement agencies.
Likewise, violations identified through the verification process may be
addressed through means other than restricting compute access. For
example, if a customer is found to be out of compliance with existing
regulations, or the compute provider's ToS, the provider can restrict
their access to the computational resources completely and report them
to the relevant authorities. The provider can also use less onerous
enforcement mechanisms, e.g., turning off the workload of concern,
reducing the amount of available compute resources, or fining the actor.

§ TECHNICAL FEASIBILITY OF COMPUTE PROVIDERS' GOVERNANCE

This section examines the technical feasibility of activities within
each of the governance capacities introduced in the previous section.

We assess feasibility in the context of the technical capacities
available to compute providers today, and the capacities that could
foreseeably be developed. An overview of the technology stack available
to compute providers can be found in
and is recommended for readers unfamiliar with data center technology.

[breakable,boxrule=1pt,enhanced jigsaw, sharp corners,pad at break*=1mm,colbacktitle=lightgray,colback=lightgray,colframe=black,coltitle=black,toptitle=1mm,bottomtitle=1mm,width=,fonttitle=,parbox=false,title=Key terms used in this section

Workload: A computational task, defined by a specific instance
of software (i.e., written or compiled code) that will be run on a
hardware configuration. For example, training an AI model is a type of
workload. The input data to the workload may or may not be known in

Operation (OP): A single calculation run on computer hardware,
typically a multiplication or addition of two numbers. AI workloads
usually involve large numbers of matrix-multiply operations, which are
implemented as repetitive multiplications and additions (known as

AI accelerator: A hardware device (typically a specialized
chip) designed for fast and efficient execution of AI workloads.
Typically AI accelerators excel at simple, parallel calculations, which
can also be useful for graphical and scientific computing workloads.
This is an umbrella term for both current hardware paradigms (such as
GPUs and TPUs), as well as novel future designs.

Node: A single computer within a data center. Each node is a
distinct unit with its own processing power, memory, and storage,
capable of running a workload by itself, or in collaboration with other
nodes. Each node may contain multiple AI accelerators.

(Computing) cluster: A group of linked nodes that can work
together to process workloads. Typically used for workloads requiring
significant computational resources, such as large-scale AI training.

Data center: A facility that hosts computing clusters (or other
computing infrastructure) and provides the supporting infrastructure
needed to operate them efficiently.

In summary, compute providers are responsible for maintaining secure
premises, and physical and network infrastructure. They also operate
controls over that infrastructure (at both the hardware and software
level) that allow them to grant and revoke hardware access to particular
customers, store and maintain customer data, track hardware performance,
and debug technical issues. These same tools could allow compute
providers to engage in security, record keeping, verification, and
enforcement for frontier AI regulation, while preserving existing
industry norms surrounding confidential and private data. <ref>
maps these governance capacities onto the relevant technical capacities
available to compute providers, and indicates the current feasibility of
using them.

c]@C@Governance capacity
c]@C@Relevant technical capacities of compute provider
c]@C@Current technical feasibility
to -3.4Security     t]@p@Physical security (e.g., locks, guards, surveillance).
Infrastructure-level security (e.g., access controls, secure firmware, resource isolation).
Network security (e.g., firewalls, network authentication).
Providing additional cybersecurity services (e.g., user access management, encrypted storage).     Feasible for low-end threats (in a supporting role). Many compute providers provide decent default levels of physical, infrastructure, and network security. With adequate customer investments in cybersecurity, these measures are likely sufficient against opportunistic attackers, but not against well-resourced and persistent expert attackers.

to -.5t]@C@Record keeping     t]@p@Data record collection and maintenance (e.g., for required verification activities).
Securing data records (e.g., encryption at rest and in transit, managing access).     Highly feasible. Compute providers can (and do) collect a wide variety of records on customers and their activities. These records are typically kept secure, and retained for as long as necessary to comply with relevant regulations or support internal business use cases.

to -6Verification     t]@p@Identity verification: ensuring a customer and/or user is who they say they are.
Workload classification: determining whether a customer workload falls within a category relevant to regulatory requirements (e.g., training a very large AI model).
Compute accounting: estimating the number of operations consumed by a workload (e.g., to validate compute threshold-based reporting requirementsFor example, see the training compute threshold-based reporting requirement in the AI Executive Order [The White House, 2023].).
Detailed workload verification: verifying aspects of the specific code or data used in a workload (e.g., to validate whether a customer is complying with reporting requirements for certain high-risk training dataFor example, the AI Executive Order [The White House, 2023] creates specific reporting requirements on developers for models primarily trained with biological sequence data. It may become useful for these kinds of reporting requirements to also be validated by compute providers, or for compute providers to offer verification tools to developers (e.g., “confidential computing” services).).     t]@p@Identity verification: likely feasible with a sufficiently rigorous process, focused on customers accessing large-scale compute resources.
Workload classification: likely feasible for detecting large-scale pre-training and inference workloads.
Compute accounting: feasible, with multiple approaches possible for large-scale pre-training/inference workloads.
Detailed workload verification: currently not possible without directly observing customer code or data. “Confidential computing” techniques could change this.

to -1.7Enforcement     t]@p@Account-level enforcement: revoking service access to particular customers/accounts/users.
Model-level enforcement: revoking service access where services are used to deploy particular models, or where models are displaying dangerous behavior (e.g., a computer worm-like AI system).     t]@p@Account-level enforcement: highly feasible, compute providers have both physical and software management-based control over their hardware; this is widely used.
Model-level enforcement: currently not possible without directly observing customer code or data. This may become possible with some technical effort.

Overview of relevant technical capacities available to
compute providers and an assessment of their technical feasibility.

§.§ Security

Compute providers usually provide security at certain technology layers,
whereas other layers are left up to customers
[Google Cloud, 2023, AWS, 2024, CoreWeave, 2023].
The compute provider is typically responsible for:

* Physical security, which includes protecting data center
premises with locks, cameras, guards, and surveillance.

* Infrastructure security, which includes ensuring that
hardware is up-to-date with the latest firmware security patches,
securely disposing of old hardware, restricting physical/virtual
access to infrastructure to approved personnel for management and
maintenance purposes, and ensuring appropriate isolation of critical
system resources across different customers and workloads

* Network security, which includes operating firewalls and
providing other forms of network-level security and isolation.

These physical, infrastructure, and network security measures are
sufficient to provide customers with a baseline level of information
security, one that many customers could not achieve on their own.

Customers are then generally held responsible for the parts of the
technology stack they have control over, which encompasses many aspects
of cybersecurity, including protecting data generated or collected by
their workloads, ensuring their employees are well-trained in security
best practices, and implementing access control policies based on
different permission levels. Many compute providers, especially larger
providers, offer cybersecurity software-as-a-service products for their
customers to help them implement these measures; many of these products
are free and/or standard with infrastructure offerings. These additional
services typically provide the customer the ability to:

* Securely manage user access to resources in their account

* Work with encrypted data storage in transit and at rest

* Manage and secure inbound/outbound traffic from nodes

* Define different levels of security within different regions of their

In the context of protecting frontier AI workloads, if a customer is
working with a security-conscious compute provider, and the customer has
systematically implemented industry best practices for cybersecurity,
they are likely well-protected against most opportunistic attackers.
However, these measures are almost certainly inadequate to defend
against well-resourced, expert attackers, such as nation-state-backed
hacking groups (also known as “advanced, persistent threats (APTs)”).
Such threats are of significant concern for frontier AI, given the
potential economic returns of model theft, and risks of misuse
[Nevo et al., 2023].

As discussed in <ref>, it is therefore important to strengthen
security standards for frontier AI workloads. In addition to requiring
strong cybersecurity standards for frontier AI developers, regulators
could define enhanced security standards for compute providers who offer
infrastructure capable of training frontier models to close security
gaps.[For an example of what such standards might look like,
see security requirements in the Federal Risk Authorization Management
Program (FedRAMP). FedRAMP assigns different levels of requirements
depending on the sensitivity of the use case
[FedRAMP], 2024].

§.§ Record Keeping

Record keeping is highly feasible using tools and metrics currently
available to compute providers, who already collect a wide range of data
on customers and service usage for:

* Accurately billing customers

* Marketing new services to customers

* Maintaining and optimizing service provision

* Detecting and responding to fraud, abuse, security risks, and
technical issues

* Complying with legal obligations, such as financial record keeping

Compute providers also share these records with third parties for
activities such as:

* Exchanging information with other companies for fraud prevention,
detection, and credit risk reduction

* Providing third-party vendors with information for promotional and
marketing purposes

* Complying with legal obligations, such as an enforceable government

Compute providers typically have well-defined privacy policies around
these records, including specific retention and security policies based
on the sensitivity and business- or legal use cases for different kinds
of records. Some of this data will likely be useful for verification
activities relevant to frontier AI governance. The specific data
attributes generally collected by compute providers can be found in
<ref> below, mapped onto specific use cases for governance
purposes. This information is based on conversations, public data
collection, and privacy policies available from a representative sample
of large and small compute providers [AWS, 2024, CoreWeave, 2022, FluidStack, 2022, Google Cloud, 2024, Lambda Labs, 2022, Microsoft, 2024].

§.§ Verifying

There are a range of verification activities that compute providers
could perform to support frontier AI governance. Primarily, it will be
useful for compute providers to verify the identity of any customer
seeking to access a hardware configuration capable of efficiently
training a frontier model (“identity verification”), as discussed in
Egan & Heim, 2023 and by Microsoft
[Smith, 2023]. It may also be useful for compute providers to
serve as an independent form of validation for different properties of
frontier AI workloads. We find that data attributes already widely
available to compute providers can likely enable them to adequately
verify two key properties of a workload that are currently highly
relevant for frontier AI governance:

* The stage of the AI lifecycle the workload fits into, e.g.,
large-scale model training or inference (“workload classification”)

* The quantity of compute consumed by the workload (“compute accounting”)

In the future, it may also be useful for compute providers to verify aspects
of the particular code or data used in a workload, such as the specific
model that was deployed, or the type of data used to train a model. We
describe such activities as “detailed workload verification.”
Currently, this is largely not possible without directly observing
confidential customer code or data. However, with some technical
development work, it may become possible to implement wider use of
“trusted execution environments” to allow customers to prove certain
properties of their workloads to their compute provider (or directly to
a regulator) without revealing other sensitive data
[Aarne et al., 2024, NVIDIA, 2023]. We now describe each of these
potential verification activities in more detail.

§.§.§ Identity Verification

Identity verification (also commonly known as “Know-Your-Customer
(KYC)”) is a useful measure to ensure customers are meeting applicable
rules, and enforce relevant penalties. This may include ensuring
particular developers are reporting relevant large-scale training runs
or enforcing export controls that prevent certain customers (e.g., those
with links to foreign military/intelligence organizations) from
accessing particular services. In the beginning of 2024, the US Department of Commerce
proposed new regulations that place explicit identity verification
requirements on US compute providers offering services to foreign
customers [Federal Register, 2024].
Egan & Heim, 2023 discuss in further detail the
mechanisms of a KYC scheme for customers accessing large-scale compute,
drawing on lessons from the financial sector.

c]@C@Attribute category
c]@C@Uses (in terms of specific verification activities)
c]@C@Involves collection of data not already widely collected?Based on our current understanding and insights gathered from interviews, and given publicly available information.     c]@C@Current state of collection, validation, and possible circumventionIn this column, we collect information on whether each data attribute is already collected, and if not, how it could be collected. We also list whether it might be possible for customers to falsify each data attribute in order to avoid information being verified.
c]@p@Customer information
e.g., name, billing address, credit card data, IP addresses, date and time of access, device identifiers, language     c]@C@ Identity
verification     c]@C@No, already collected.     c]@p@Compute providers already collect a wide range of customer information.
Customers can potentially spoof much of this data to try to avoid identification.

c]@p@Billing-related technical information
e.g., hardware configuration requested by a customer, number of hours that hardware resources are used     c]@C@Workload classification
Compute accounting     c]@C@No, already collected.     c]@p@Already collected by compute providers for billing purposes. Highly difficult or impossible for customers to alter to avoid monitoring.

c]@p@Cluster-level technical information
e.g., power consumption, network bandwidth utilization between nodes     c]@C@Workload classification
Compute accounting    c]@C@ No, already collected.      c]@p@ Already collected by compute providers for service health monitoring and maintenance. Customers could modify their workloads to avoid certain forms of cluster-level verification, likely with performance penalties.

c]@p@Node-level technical information
e.g., AI accelerator core utilization, AI accelerator memory bandwidth utilization     c]@C@Workload classification
Compute accounting     c]@C@Potentially, already collected.While examining customer data is out-of-scope, collection and analysis of certain types of metadata could risk exposing details of the customer’s data.     c]@p@Possible to collect using existing tooling, and collected by some compute providers.See Weng et al., 2022 and Google, 2024. Customers could modify their workloads to avoid certain forms of node-level verification, likely with performance penalties.

c]@p@Workload-level technical information
e.g., code, data, hyperparameters     c]@C@Workload classification
Compute accounting
Detailed workload verification     c]@C@Yes, currently not collected.     c]@p@Compute providers cannot typically retain or inspect this information (by design). Confidential computing tools could potentially be developed to verify information in a privacy-preserving manner.

An overview of the categories of data attributes
available to compute providers and how they can be used for different
verification activities.

Identity verification of this kind appears feasible, but we recommend
that policymakers consider several strong caveats. As described above,
compute providers typically collect a range of information relevant to
verifying customer identities. This includes
[AWS, 2024, CoreWeave, 2022, FluidStack, 2022, Google Cloud, 2024, Lambda Labs, 2022, Microsoft, 2024]:

* Personal information, such as legal names, user names, email
addresses, phone numbers, and government-issued identification

* Information about customer organizations and the people in those

* Financial information, such as credit card and bank account
information, and tax identifiers

* Service-related information, such as the locations from which users
are accessing the service, time zones, the type of device a user is
using to access the service, the language used on that device, web
cookies describing sites previously visited, and IP addresses used
when accessing the service.

This equips compute providers with large amounts of useful information
for verifying the identity of customers seeking to access infrastructure
sufficient to efficiently run frontier AI workloads. Because such
customers will by definition be few in number, best practices for
identity verification could be drawn from more involved identity
verification activities such as those conducted in other industries. One
example is the “enhanced due diligence” process used in financial
sectors for higher-risk customers or transactions, which can involve
commissioning intelligence reports on customers or their “beneficial
owners” (the entity that ultimately owns or controls the customer
[Financial Action Task Force, 2003]. These kinds
of measures may be necessary to successfully perform identity
verification in situations where a well-resourced illicit actor is
actively trying to obfuscate their identity.

In performing identity verification, it is important for regulators and
compute providers to bear in mind potential trade-offs with user privacy
and data privacy regulation in different jurisdictions. It would likely
be useful for identity verification requirements to be standardized
across different jurisdictions. We discuss these challenges in <ref>.

§.§.§ Workload Classification

“Workload classification” describes a scenario where an infrastructure
provider is attempting to classify a workload into a particular
category. We will consider, from a frontier AI governance perspective,
what these categories might be, and how they might be differentiated.

First, it is useful to know whether a workload relates broadly to AI.
Frontier AI workloads will generally all use AI accelerators, but not
all workloads that use AI accelerators will necessarily be AI workloads.
For example, graphics and scientific computing workloads sometimes use
AI accelerators. However, these workload categories can likely be
differentiated using observable properties of the workload. Examples of
such properties are outlined in <ref> in the Appendix. Within the
broad category of AI workloads, there are several sub-categories of
workload, corresponding to stages in the AI model's life cycle, that are
useful to differentiate from a governance perspective:

* Design, in which researchers and engineers experiment with
different model designs, algorithms, and datasets.

* Training, in which a model learns from a large dataset.
Typically known as “pre-training” to distinguish from enhancement.

* Enhancement, in which a trained model is further refined
using a smaller data set (e.g., fine-tuning), sometimes using
techniques such as reinforcement learning.

* Deployment in which a trained model is used in an operational
setting, e.g., to make new predictions (“inference”).

Simplified AI Lifecycle including training,
enhancement (e.g., fine-tuning), and deployment (i.e., inference). (Figure from Sastry et al., 2024.)

Each of these categories can be distinguished based on scale, among
other attributes. Given the large scale of the frontier AI workloads we
are interested in detecting and classifying, we can place a strong
initial filter on which specific workloads warrant attention, ignoring
the vast majority of workloads run on a compute provider's
infrastructure. As discussed by Sastry et al., 2024, the training
stage, where compute demands are especially high, is an especially
practical stage to monitor.[See Section 3.C of Sastry et al., 2024.]

The simplest method of workload classification might be based purely on
the hardware configuration (in terms of types and numbers of devices)
available to a customer. For example, in 2024, if a customer has
requested a hardware configuration involving tens of thousands of AI
accelerators, connected together using a high-bandwidth network fabric,
it becomes much more likely they intend to engage in large-scale
training, relative to other customers. Combining this information with
the amount of time the hardware is being used can tell us whether it was
possible for a customer to run a particular workload (e.g., pre-training
above a particular scale), which could provide grounds for a more
detailed investigation. These coarse methods are possible using data
already available to compute providers for billing purposes. See <ref> below for more information on these
kinds of approaches.

More precise methods for frontier workload classification might involve
manually defining some technical characteristics of relevant workloads,
or training a machine learning classifier using cluster- and node-level
technical information to predict whether a workload falls into a
relevant category. Compute providers could also collect declarations
from customers about the workloads they are running, and use that
information as a reference point for classification. These approaches
are based on the assumption that different kinds of workloads will have
characteristic and learnable features. As an example, we expect
frontier-scale training in 2024 will likely have several distinguishing
features relative to other possible workloads. These could include the
number of accelerators used (tens of thousands), the peak operation
throughput utilization of accelerators over time (fairly constant), the
patterns of communication between and within nodes (following specific
patterns corresponding to different forms of parallelization), and
limited outbound/inbound communication to external networks, such as the
Internet, during the training run. According to six interviews with
commercial compute providers, including both large and smaller
providers, these kinds of cluster- and node-level characteristics are
often already collected and used to understand customer workloads to
optimize their services.[Interviews conducted between October
2023 and February 2024] Research released by Google, Microsoft, and
Alibaba demonstrates some of the ways this technical information is
collected and analyzed for business purposes
[Jeon et al., 2019, Tirmazi et al., 2020, Weng et al., 2022]. Some of
this data has been released as public data sets that can be used to
develop workload classification techniques
[Alibaba, 2024, Google, 2024].

Workload classification techniques using these kinds of data have been
studied in different contexts. [Tang et al., 2022]
introduced the “MIT Supercloud Dataset,” containing node-level
technical information for over 3,000 AI accelerator-based workloads.
Workload classifiers trained on this data have reached 95% accuracy at
distinguishing AI workloads across ten different model architectures
[Weiss et al., 2022]. Other research on workload
classification for different kinds of high-performance computing
workloads has reached similar levels of accuracy
[Banjongkan et al., 2018, Terai et al., 2017], including classifiers
trained only to use data on power draw [Copos & Peisert, 2020, Köhler et al., 2021].

However, there are several ways these findings may not be representative
for frontier AI workload classification in a production environment.
First, the authors mostly generated labeled data by running workloads
themselves, which likely involved a level of standardization in software
and datasets that would be unrealistic for real-world conditions.
Second, this research typically involved a small number of different
hardware configurations and scales, whereas these parameters will likely
vary further in production contexts. Lastly, even a 5% error rate may
be prohibitively high in production, given the potential consequences of
reporting a false positive to a regulator.

Compute providers offering large-scale AI clusters are likely to have
the expertise to address these technical challenges. In doing so, we
recommend that compute providers—in collaborative efforts where
possible—consider a range of technical approaches for classification,
ranging from simple manually defined thresholds through to
machine-learning based classifiers. These methods could also be combined
with other useful data and processes, such as by soliciting customer
declarations on the intended use/purpose of a hardware configuration or
workload, and by conducting follow-up investigations in cases where
classification confidence is low. box1Box 1 demonstrates what a workload
classification process combining these elements might look like.

[breakable,boxrule=1pt,enhanced jigsaw, sharp corners,pad at break*=1mm,colbacktitle=lightgray,colback=lightgray,colframe=black,coltitle=black,toptitle=1mm,bottomtitle=1mm,width=,fonttitle=,parbox=false,title=Box 1: An example process for frontier AI workload classification.

* The compute provider lists the specific set of hardware configurations and scales they offer that are sufficient for efficient training of frontier AI workloads (i.e., within defined cost/time boundaries). Given that compute providers tend to specialize in particular hardware configurations (e.g., AI accelerator types and node configurations), this number could be quite small.

* The compute provider collects labeled cluster- and node-level data on workloads simulated or run on each of these configurations. Compute providers offering similar hardware configurations may benefit from coordinating to produce larger datasets.

* The compute provider creates technical thresholds to define relevant workload categories based on their identifying characteristics, and tests them on the collected data. This could include training ML-based workload classifiers. It may be the case that a single classification approach works well for a range of different hardware configurations and/or scales, or that more specific classifiers are required for different configurations.
* In operation, for any customer seeking access to or already using a relevant hardware configuration, the compute provider could then:

a. Ensure they have performed adequate identity verification.

b. Collect declarations from the customer on the intended use of the hardware configuration, and/or declarations on the nature of any sufficiently large workload run on that configuration.

c. Validate these declarations by running automated classification on workloads that use that configuration, and conduct follow-up analyses where useful, especially in cases where classification confidence is low.

For an example of an approach for simulating workloads on large clusters, see Sliwko & Getov, 2016.

The difficulty of classifying workloads increases if a compute customer
is actively trying to disguise the nature of their workload. This kind
of obfuscation may become likely in cases where a customer has a strong
financial, criminal, or political incentive to avoid regulatory
oversight. Such incentives are likely to grow when frontier AI models
become both more attractive for criminal activities and more
economically lucrative. Analogous practices can be observed in the
finance sector, where illicit actors have engaged in “structuring”
(breaking up a single transaction into several smaller transactions) to
avoid automated transaction reporting from their bank to the regulator
[Linn, 2010]. We discuss and list these
challenges in <ref>.

§.§.§ Compute

We introduce “compute accounting”: measurements and techniques to produce an estimation of the amount of compute consumed
by a customer running one or more workloads on a specific compute
cluster. These techniques are comparatively similar to the previous
section on workload classification (<ref>). However, rather than establishing the class of a workload, compute accounting
aims to determine its magnitude. Moreover, compute accounting is
useful even when the workload is not classified at all, as an estimate
of the total amount of compute used by a given customer is an upper
bound for a single (unknown) workload. From a practical governance
perspective, compute accounting could be used as an input to workload
classification, and/or as a standalone metric to determine whether a
particular workload has exceeded a compute-based reporting threshold.

The amount of compute used by a given workload is a useful metric from a
governance perspective. In the context of AI training, novel
capabilities (and related risks) are likely to first emerge in models
that require large amounts of compute
[Pilz et al., 2024, Sevilla et al., 2022]. In the context of AI inference,
compute is correlated with the scale and processing speed of the
deployment: how many copies of the model are being run, and how fast the
model is operating (the throughput, e.g., tokens per second for LLMs).
Insofar as the model is capable enough to potentially cause harm, these
factors could then be correlated with risk and the need for enhanced
oversight (Appendix I of O'Brien et al., 2023).

More formally, the total computing power of a rented cluster and how long a customer has
access to it results in a quantity of available compute—a “compute
budget.” The customer is then choosing how to allocate that budget
across different workloads. For example, a given set of AI accelerators
could be used for a single training run, multiple small training runs,
or model deployment (<ref>). In cases where compute is being consumed by a customer (as opposed to hardware sitting idle), the amount of compute consumed can be attributed to at least one workload. The addition of
workload classification allows fractions of that usage to be ascribed to workloads of particular types.

Three example scenarios of a set of AI accelerator
nodes running different workloads over time. Compute accounting establishes the amount of compute used over
time, while workload classification can differentiate between these
three scenarios by mapping compute usage to specific workloads.

We can estimate the compute budget via two different approaches:

* Theoretical compute budget estimation: calculated using the
assumed throughput (measured in OP/s) of the hardware potentially
involved in the workload, and multiplying it by the time the hardware
is being used.

* Empirical compute budget estimation: calculated using actual
measurements from the hardware that can serve as more direct proxies for compute consumption. For example, aggregating AI
accelerator core utilization and time-in-use data across all AI
accelerators involved in a workload, and multiplying by the peak
capacity of each core.

Theoretical compute is a derivative of empirical compute, useful for
establishing an estimate in circumstances where empirical measurements
are not available. As exact circumstances and configurations differ between compute
providers, not all attributes of both theoretical and empirical compute
are likely to be observable. However, in practice, both kinds could be
used to inform an overall estimate of compute usage for a particular
instance of running a workload (<ref>).

A spectrum of possible compute usage metrics for AI workload
analysis, from low-level measurements, such as on-chip calculations, to
more high-level measurements, such as the hardware available to a
customer. Each of these metrics can be synergistically combined to enhance the accuracy and sensitivity of workload classification and compute accounting.

Regardless of whether the approach is theoretical or
empirical, it will be important for compute providers to estimate both throughput (OP/s) and total quantity of
operations (OP). This provides crucial information to detect cases where a customer is evading a
reportable compute threshold by utilizing multiple compute providers or
accounts to sequentially perform partial training of a model. In this
case, the throughput available to the customer is necessary to identify
that a rate of compute usage corresponding to a reportable
threshold has been reached, even if the reportable threshold itself has
not. We discuss this in <ref>.

Measuring Theoretical Compute
— Theoretical approaches measure the potential for a certain amount
of compute to be used for one or more workloads within a given time
frame. This is easier to measure than empirical compute, and in the
simplest form is equivalent to hardware resources a customer has been
allocated to access within the cluster. For any given compute provider,
the number of customers with access to sufficient theoretical compute to
train a frontier model will be small.[For example, to meet the
AI Executive Order's reporting requirement of 1026
operations for a training run, a customer will need access to around
60,000 cutting-edge AI accelerators (Nvidia H100) for 90 days,
assuming a utilization of 34%.] This makes theoretical compute a
useful measure for determining which specific customers are relevant for
a frontier AI regulatory regime. This can be calculated using data
already available to compute providers for billing purposes (<ref>). Relevant data for measurement of compute are:

* Node assignment: Compute providers can bill customers for
on-demand nodes (a full or partial node) at a granularity
ranging from seconds to hours [AWS, 2024], or
reserved nodes ranging from days to months
[AWS, 2024]. Theoretically, the used compute budget
can be calculated using this information by summing the theoretical
peak performance of the AI accelerators in each node, multiplying it
by the time the node is available to the customer, and the assumed
average utilization of the AI accelerators.[“Utilization”
in this context refers to the usage as a proportion of the node's
theoretical peak computational performance.]

* Data ingress/egress: Data into and out of the cluster is
metered and sometimes billed [Google Cloud, 2024, Microsoft Azure, 2024, Pal et al., 2021]. The communication of nodes within the cluster to endpoints
outside the cluster, as well as the amount of data transferred and
time when communication occurs, can inform whether nodes outside the
cluster participated in a training run or deployment.

The exact procedures to allocate, measure, and invoice customer usage
for billing purposes are not publicly available for any major provider.
However, every provider must have internal control systems and
diagnostics to record this information accurately, as well as status
reporting and other telemetry to maintain the health of their clusters
(such as the state of individual machines and network switches). While
billing information provides a widely-measured baseline for customer
compute usage, intra-cluster network information such as the network
topology can provide greater detail. Specifically, knowledge of whether
two nodes are capable of communicating within a cluster informs whether they may
participate in running the same parallel workload.

Theoretical compute, while relatively simple to calculate in most cases,
is useful primarily to establish an upper limit on the total compute
budget of a customer. To map compute usage onto a particular workload
requires additional information at the cluster or node level, as
previously covered in <ref>.

Measuring empirical compute
— Measurements of empirical compute usage involve observations of a
cluster's hardware-level characteristics, often measurements of the node
itself (perhaps from a hypervisor or other privileged software) or
inter-node communication fabric. Empirical compute, in contrast to
theoretical, can provide a highly precise and accurate accounting of the
amount of compute, though some limitations exist. We consider that two
categories of measuring empirical compute exist: operations and
data transfer. Operations refers to the mathematical
calculations performed as part of a workload (most frequently
multiplication and addition for contemporary AI workloads). Data
transfer refers to the movement of the data necessary to perform those
calculations: network links from node-to-node, or chip-to-chip within a
node or loaded from an AI accelerator's memory.

While these properties are essentially metadata, compute providers would
need to detail collection and observation of this within their terms of
service with very clear guidelines about how the data will be collected,
stored, and used. While strict internal policies are
necessary to ensure the integrity of such metadata, this kind of usage
policy would likely not require any significant deviation from existing
policies for sensitive customer data handling, or deviation from the kinds of data that are already often collected
[AWS, 2024, CoreWeave, 2022, FluidStack, 2022, Google Cloud, 2024, Lambda Labs, 2022, Microsoft, 2024].

Within a given node, opportunities to measure empirical compute include:

* Operations performed on AI accelerators: Individual chips
contain performance counters to measure information such as the
number of instructions executed [Wikipedia contributors, 2023]. A vendor
tool may be required to access this information
[NVIDIA, 2024].

* Data flow to/from AI accelerator's memory: The rate at which
data is written to or read from the AI accelerator's memory can be
observed over time, allowing measurement of throughput and quantity,
and can inform an estimation of the total number of operations
performed [National Energy Research Scientific Computing, 2024, Williams et al., 2008].

* Data traffic between accelerators and other nodes:
Node-to-node and chip-to-chip communication is an indicator of
participating in the same workload, even if the workload itself cannot
be classified [Merritt, 2023, NVIDIA, 2024, Shoeybi et al., 2020].

Even without privileged software access to the node, other measurements
of cluster operations are useful to inform an estimate of empirical

* Power consumption: In cases where precise chip utilization is
not observable, measurements of power consumption (of a node or
individual AI accelerators within a node) can help inform an estimate.
The amount of power consumed by each node is considerably higher when
a node (or even an individual AI accelerator [NVIDIA, 2024]) executes a workload compared to idle. However, power consumption does
not simply scale linearly with performance
[Patel et al., 2023], though specific
calibration for a device may enable improved estimation. Power consumption will typically be a way of measuring both operations and data transfer, as both these activities consume energy within a node.

* Data traffic between nodes: Granular information such as the
number of data sent to and from the node, the source and destination of
this data, and the timing with which they are sent can inform how
multiple nodes are cooperatively executing the same workload.

While many of these measurements alone provide limited insight, combining
measurements can provide more insight into
the compute usage of a particular workload (<ref>). Empirical measurements form an upper bound for compute usage, as not every
operation can be known to have contributed to a workload.

§.§.§ Detailed Workload

To verify compliance with regulations on the development or deployment
of frontier AI systems, it may be useful for a compute provider to
validate more fine-grained features of a workload, such as whether a
particular training dataset was used, the model architecture, or whether
a particular model evaluation was run. We call such activities
“detailed workload verification.” This form of verification differs
from workload classification in that it will almost always require
knowing certain properties of the code and/or data used by the customer.

One undesirable form of workload verification would simply require
compute providers to have direct access to customer code and data.
However, this level of access is not acceptable, as compute providers
will not access customer data without permission unless required to
maintain the health of their cluster or legally compelled
(see AWS, 2024, and other terms of services from
compute providers). Internal risk management processes, such as auditing
access to customer data by employees, typically govern details such as
when access occurred, by whom, and whether it was authorized.

However, using privacy-preserving technologies built into data center
hardware, it may become possible for a compute provider, in
collaboration with a customer, to verify particular properties of a
workload without observing any other information—only the required
verification result needs to be shared
[Aarne et al., 2024]. As one example, many modern
CPUs and AI accelerators, such as NVIDIA's H100, and data center CPUs
from AMD and Intel, come equipped with a “trusted execution
environment” (TEE), allowing the AI accelerator/CPU's customer to
assert the confidentiality and integrity of code/data, while exposing
only the code/data they choose to, and having full control over who they
expose it to (<ref>). Techniques that leverage a TEE in this way
are often known as “confidential computing.” Compute providers are
increasingly making these features available to customers
[AWS, 2024, Microsoft, 2024, Microsoft, 2023].

Using confidential computing techniques allows an
“attester” (customer) to share high-level information about a workload
with a “verifier” (e.g., a compute provider or a regulator) such that
the verifier can trust the information, without the attester sharing any
additional code or data. (Adapted from
Aarne et al., 2024.)

Using confidential computing techniques, customers may be able to
provably verify particular governance-relevant properties of their
workloads to their compute provider or directly to a regulator. For
example, a customer may wish to demonstrate that they ran a particular
model evaluation, obtained a particular result on a model evaluation, or
did (not) use a particular dataset during training. However, these
techniques have yet to be fully validated and implemented in production contexts. Several organizations are
actively researching and developing software for using confidential
computing to allow privacy-preserving auditing of models
[Mithril Security, 2024, OpenMined, 2023, OpenMined, 2024]. There has also been some work on expanding these
techniques to allow privacy-preserving auditing of training workloads
(e.g., the dataset used, or quantity of compute consumed), though this
area is less well-explored
[Choi et al., 2023, Mithril Security, 2024].[Choi et al., 2023 propose a method for verifying training data, but it requires
sharing of sensitive data with the verifier. Making the scheme fully
privacy-preserving is discussed but left for future work by the
authors.] If regulatory
requirements on compute providers end up requiring them to validate more
fine-grained properties of workloads, these kinds of methods could be
used to achieve this in a way that preserves customer confidentiality
and privacy. In the meanwhile, we encourage compute providers and
developers to explore and develop these techniques to ensure they can be
implemented without meaningful performance penalties, and while
preserving other aspects of customer experience and confidentiality.

§ CONSTRUCTING AN OVERSIGHT

Incorporating roles for compute providers in security, record keeping,
verification, and enforcement, accompanied by appropriate reporting,
could form the basis of an effective compute oversight scheme. Such a
scheme could enable greater visibility of AI development and help ensure
the adoption of appropriate safeguards. There is an opportunity to build
on and complement existing policies around compute governance occurring
around the globe.

This section looks at the US as a case study. We examine the Biden
Administration's 2023 Executive Order 14110 on Safe, Secure, and
Trustworthy AI (“the AI Executive Order”)
[The White House, 2023]: outlining the ways in
which it progresses record keeping requirements for foreign customers
and signals a need for greater verification and enforcement
capabilities. We then explore what additional steps might be required to
enlist compute providers in administering a more comprehensive compute
oversight scheme, and where further research is needed. We highlight the
importance of internationalizing a compute oversight scheme, and outline
some of the key challenges that need further attention and analysis
before this proposal is ready for adoption.

Unlike proposed US foreign customer identification rules for
IaaS providers [Federal Register, 2024], we focus on oversight of
only frontier AI model development and deployment, rather than all
compute use. While we explore these issues in the US context, similar
analyses could also be done for other jurisdictions, like the EU, and in
the international context. We encourage further policy analysis in this

*Figure 2: Additional measures, implemented by the Department of
Commerce, would strengthen the intermediary role of compute providers
and enable a compute oversight scheme.

§.§ Case Study: Compute Providers' Intermediary Role in the

§.§.§ Record Keeping and Reporting in the AI Executive

The AI Executive Order acknowledges the importance of compute providers
in AI regulation, and begins to impose record keeping and reporting
requirements. First, under the authority of the Defense Production Act
(DPA), it requires firms owning or developing clusters capable of
collectively providing more than 1020 OP/s with more
than 100 Gbit/s networking bandwidth[Threshold as stipulated by
the AI Executive Order. Note it is subject to updates.] to report its existence and location. Once
implemented, this measure would provide the US Government with
visibility of the most significant compute infrastructure in the US.
While the high reporting threshold will not capture all compute clusters
capable of training frontier AI, it will nevertheless be useful in
identifying relevant industry stakeholders that would play a role in
frontier AI governance.

Additionally, leveraging the powers of the International Emergency
Economic Powers Act (IEEPA), the AI Executive Order requires that
compute providers identify and report to the Department of Commerce when
a foreign person uses their services to train a frontier AI
model.[In this case, models trained on with more than
1026 operations and occurring on frontier
infrastructure.] The Department of Commerce has proposed rules to
implement this that would require US compute providers (and their
foreign resellers) to maintain Customer Identification
Programs.[The proposed rules also require US IaaS providers and
their foreign resellers to verify the identities of all foreign
customers. This broader measure has come under criticism for being
ineffective in addressing cyber threats, giving rise to privacy
issues, and impacting the competitiveness of US compute provision
[National Security Telecommunications Advisory Committee], 2023]. This
paper does not engage in analysis of this broader measure, and instead
focuses on the subsection of compute for frontier AI. As outlined in
the introduction, this narrower focus only captures a small number of
AI firms and compute providers, which mitigates much of the concern
around regulatory burden (see discussion in <ref>.

§.§.§ Potential for Verification

The AI Executive Order offers the potential for compute providers to
exercise verification capacities. In a direct sense, the proposed rules
would require US compute providers to take a risk-based approach to
verifying the identities of foreign customers and their beneficial
owners, whether the customer is running a training workload with
particular technical properties, and reporting large training runs by
foreign customers to the Department of Commerce
[Federal Register, 2024]. In an indirect sense, the AI Executive
Order introduces a range of requirements for AI developers, which will
eventually require verification capacities to be effective. For example,
AI developers are required to report on the training of large models,
the cybersecurity protections taken to secure model weights, and the
results from red-team testing according to guidelines developed by the
National Institute of Standards and Technology (NIST). While the AI
Executive Order does not address how these measures will be verified,
compute providers could become governments' natural partners for
checking compliance.

The AI Executive Order and the proposed rules for IaaS providers give
compute providers a role in enforcing regulations—enabling
the Government to require the compute provider to prohibit or limit
access to an account or an entire jurisdiction—but only when it
involves foreign customers with demonstrated patterns of using US IaaS
for malicious cyber-enabled activity. There is currently no explicit
authority that requires compute providers to stop a foreign customer
training a frontier model that might be used maliciously in the future. The existing authorities also would not apply in cases where risks arise from models being
developed domestically.

§.§.§ Future Additions

The AI Executive Order lays the groundwork for an institutional
structure that could support a compute oversight scheme. Importantly, it
begins to build greater AI understanding and regulatory capacity within
the US government, establishes clearer government accountabilities for
frontier AI governance, and establishes foundational elements of a
broader regulatory framework. Yet it falls short of a comprehensive
oversight scheme. Additional steps are required to effectively identify
and manage emerging risks and enable proportionate oversight of frontier
AI development. We outline potential measures to achieve this, including
ensuring proportionate information security practices, expanding and
streamlining record keeping requirements, enhancing verification roles,
and establishing enforcement capabilities.

Ensuring proportionate information security practices
— Given the potential risks associated with frontier AI, further work may
be warranted to ensure cybersecurity standards are proportionate to
risk. Because compute providers are custodians of sensitive data and IP
for a broad range of clients, actions they take to improve security will
benefit all their AI developer customers and their respective
users.[Note, however, that strong cyber security at the
infrastructure level alone is insufficient. AI firms will still need
to implement and maintain strong cyber security practices on their own
systems (<ref>).]
Further cooperation between industry and government (including bodies
like NIST and CISA) is required to consider what cybersecurity standards
are most appropriate for entities that hold sensitive frontier
AI-related IP. This could be informed by the risk profiles underpinning
the cybersecurity standards and practices that are currently being
developed by leading AI companies, as per their voluntary White House
commitments to manage AI risks
[The White House, 2023].

Expanding and streamlining record
— While the proposed rules require US compute providers to keep records on
foreign AI developers, significant AI-related risks may also arise from
domestic AI development. This may make it appropriate to expand the role
of compute providers to also undertake KYC on domestic developers of
frontier AI to enable a more comprehensive oversight scheme
[Smith, 2023]. Under the AI Executive Order, domestic AI
developers are themselves accountable for reporting their own frontier
training runs to the Department of Commerce. Using the compute provider
to collect information that could then be used to validate these
processes would help improve their effectiveness and ensure compliance.
In this way, KYC could be implemented as a cohesive scheme, drawing on
lessons from the financial sector
[Egan & Heim, 2023].

In addition to using training compute thresholds, other measures should
be employed to create a more precise risk-management system. The current
1026 operations threshold minimizes regulations on
existing systems while capturing next-generation models that may pose
significant dual-use risks. However, below-threshold compute could also
be relevant in identifying problematic trends (e.g., from entities in
particular geographic regions) and entities trying to break up workloads
over multiple compute providers [Heim & Egan, 2023].
Furthermore, the threshold should be constantly re-evaluated as frontier
AI evolves and algorithmic innovations reduce the cost of training
powerful systems and if our understanding of how to predict risks from
compute in particular systems grows
[Pilz et al., 2024]. On the training side,
indicators like training data (similar to the biological sequence data
criterion referenced in the AI Executive Order), the architecture of the
AI model, or the way training is conducted could all be useful proxies
for identifying risk levels from new AI systems. On the deployment side,
which does not currently fall under the purview of the AI Executive
Order, factors like the use of customer data (e.g., voice or images),
the scale of deployment, the level of access to the outside world (e.g.,
via the internet or physical effectors), and the ability to act with
limited direct supervision could be used to set a range of regulatory
thresholds [Shavit et al., 2023]. Developing
more nuanced thresholds, beyond blunt compute capacity and usage, will
require further research and collaboration between government, compute
providers, AI developers, and broader civil society.

Enhancing verification
— There is an opportunity to leverage compute providers' verification
capabilities to help ensure both foreign and domestic AI developers are
complying with AI safety standards and requirements. The AI Executive
Order requires AI developers to report the total amount of training
compute and whether biological sequence data was used to train their
frontier models, as well as the outcomes of safety testing. However,
there are presently no verification methods specified for these
requirements. The ability of compute providers to capture insights from
the metrics described in <ref> could enable verification to be
performed while minimizing privacy tradeoffs. For example, rather than
reporting all metrics to the US government, compute providers could
instead only report when they have reasonable grounds to suspect a
violation of regulations or standards has occurred. Verification
mechanisms will need to be resilient against evasion and exploitation.
For example, privacy-preserving information sharing between compute
providers could be used to help identify and manage attempts to break
training runs down into smaller segments, or to obfuscate compute
utilization patterns. As regulatory frameworks develop, there may be an
opportunity for compute providers to play a role in advancing both
responsible training requirements for frontier model developers,
including notification and use of secure infrastructure, and
pre-deployment safeguards, for example by requiring frontier model
providers to demonstrate they have government approvals prior to placing
a model on the market. Such approvals could be made contingent on the
evaluation of highly capable models to a specified standard
[O'Brien et al., 2023].

Privacy protections could also be aided by the application of
confidential computing standards, which technically limit the ability of
compute providers to `look in' at sensitive data [IBM, 2024, OpenMined, 2023]. Further work is required to explore the possibilities
of data verification in a privacy-preserving way, particularly
mechanisms to identify when a developer is using biological sequence

Establishing enforcement
— To effectively leverage compute providers in an intermediary enforcement
role, the US government would need to implement additional authorities
and requirements for them to effectively halt training runs or
deployment in response to violations of set controls and safety
standards. Such authority could be linked to a comprehensive regulatory
scheme with components such as developer licenses, training risk
assessments, pre-deployment risk assessments, and the monitoring of
criminal activity through models after deployment
[Anderljung et al., 2023], supplemented by a process
for appeal and corrective action. To draw parallels from other
industries, financial and aerospace regulators use a range of factors,
like customer risk profiles, track records, and company practices, to
evaluate the level of oversight necessary. AI developers with a pattern
of risky behavior may warrant stricter oversight in order to purchase
computing power. The ability to deploy an AI model at a large scale may
also be linked to model licensing and proper privacy and safety
precautions on the part of the compute customer in the future.

Once appropriate authorities have been established, there are several
ways compute providers could help enforce rules. It could be desirable
to be able to prevent or pause runs if the total amount of compute used
exceeds the limit permitted by present approvals, if deployed models are
actively causing harm, or if the developer is on the Entity List.
Compute providers already have the ability to ration or cut off compute
access to their customers. Therefore, key work that will need to be done
here includes:

* establishing formal rules for when AI developers can and cannot access
compute at a particular scale,

* creating formal channels of communication between compute providers
and regulators, and

* clearly establishing respective roles and authorities between
government and industry.

§.§ Regulating the Compute Providers

For compute providers to effectively contribute to AI regulation
downstream, they themselves also need to be subject to appropriate
oversight and compliance measures. They are both intermediaries and
agents: they act as pass-throughs that offer computing power (in the
form of hardware, often acquired from other firms) to AI developers, and
they make autonomous choices on pricing, select customers, and provide
differentiated services.

The AI Executive Order requires that compute providers declare the
existence and location of large-scale compute clusters, and the total
amount of computing power available in each cluster. Ad hoc
investigations and spot checks would help ensure compute providers are
incentivized to prioritize this obligation. A chip registry, where
policymakers mandate the reporting of the sale and transfer of
cutting-edge AI chips, could also help ensure compliance
[Fist et al., 2023, Fist & Grunewald, 2023, Sastry et al., 2024]. But the need to verify compute
provider compliance would be significantly heightened should they take
up the key role of screening AI developers. Ongoing training and
government and industry engagement could help ensure expectations are
clear and requirements are met in a way that minimizes regulatory
burden. Additional government capacity would likely be required to
ensure appropriate spot checks and investigations can be carried out. To
help ensure compute providers play an appropriate role in providing
secure infrastructure and advancing verification and enforcement, there
may also be a role for the licensing of compute providers themselves,
similar to the way in which operators of critical infrastructure are
licensed in other domains
[Australian DITRDCA, 2024, California Energy Commission, 2024, OFWAT, 2024].
Ensuring that government-established regulations are upheld and not
tampered with will be key.

In cases where the compute provider and AI developer are the same firm
or linked by a close partnership, additional steps should be considered.
These arrangements are common for many leading AI companies, which
either build AI data centers for their own products, for example,
Google, or maintain close financial ties with their compute providers,
like OpenAI with Microsoft and Anthropic with Amazon. The strength of
these ties has prompted recent antitrust concerns: in January 2024, the
US Federal Trade Commission began an inquiry into these partnerships
[Ward & Hu, 2024]. In such cases, there are unusually
strong incentives to collude on false reporting, as rapid progress in AI
development is in both entities' financial interests. This warrants
additional external scrutiny and reporting. A whistleblower scheme could
assist in identifying and addressing noncompliance, but in the longer
term, prudential regulations may be needed to create an accountable
compute ecosystem and ensure that providers are fit for acting as
regulatory pass-throughs. Compliance with these regulations could be
linked to maintaining operating licenses or accessing cutting-edge AI
chips. These rules should ensure sufficient independence between compute
providers and their customers, and that advanced AI and compute
capabilities are safeguarded and accessed in an equitable manner. Steps
to limit the partnerships that create the strongest incentives for
collusion, including via antitrust law, could also help ensure proper
oversight. In many industries, there are restrictions on how platform
providers may operate on their own platforms, as such operations can
involve anti-competitive market practices; a similar approach may
mitigate unfair practices in the cloud computing market.

§.§ Domestic Government

Given the strong public interest in managing the risks of frontier AI, a
robust government involvement will be key to the success of an oversight
scheme [Anderljung et al., 2023]. Building on
existing efforts, the US could establish a centralized authority within
the Department of Commerce responsible for AI risk management and
engagement with compute providers and AI developers. Locating both
industry opportunity and risk management within the same department,
alongside other AI-relevant agencies like NIST, will help enable a
holistic, proportionate approach to frontier AI controls. It could also
support alignment with the Department's Bureau of Industry and
Security's (BIS) work on compute hardware controls, which leverages
channels of engagement with similar stakeholders. This authority should
work closely with industry, researchers, and other government
stakeholders to ensure a holistic approach to AI governance.

Additional regulatory and legislative authority will likely be required.
The IEEPA provides the US government with broad abilities to control
transactions with foreign persons in circumstances where the President
declares a National Emergency
[Congressional Research Service, 2024]. This could provide the
power for scrutiny and enforcement against foreign persons
accessing US compute, but the requirement to maintain a constant state
of `national emergency' for these rules to apply could be criticized as
government overreach [Boyle & Lau, 2021].
The government is also limited in its ability to effectively utilize
compute providers as a node for domestic oversight. While the DPA allows
the government to require information from companies to undergo
industrial base assessments, this falls short of establishing ongoing
channels of information sharing and verification, and there are
currently no clear mechanisms for checking compliance. The development
of new legislation should involve thorough consultation with industry
and affected stakeholders, as well as international counterparts.

§.§ International

A harmonized international approach will be essential for the success of
a comprehensive compute oversight scheme: both to manage complex
cross-jurisdictional oversight and privacy issues, and to minimize the
risks of customers and businesses relocating to other jurisdictions to
avoid regulations. International standards that preserve privacy and
confidentiality should be explored as key components of the solution.

Cross-jurisdictional oversight issues
— Existing cross-jurisdictional data, privacy, and oversight issues
associated with compute providers with a global presence will be
amplified in the context of AI compute oversight. Many large compute
providers employ globally distributed data centers to enable low-latency
international service provision and resilience to local disruptions. For
example, while headquartered in the US, major compute providers like
Microsoft and AWS have data centers spread across many regions and
jurisdictions [AWS, 2024]. However, this
distributed architecture can result in contradictory local and domiciled
regulatory requirements. This has been evident in the law enforcement
context, with the US enacting the Clarifying Lawful Overseas Use of Data
(CLOUD) Act in 2018 in response to impositions on its ability to access
data from US compute providers when that data was stored in a foreign
data center [Rep. Collins, 2018].

In the context of AI compute providers, cross-jurisdictional oversight
is of particular sensitivity, due to both the commercial value of
frontier AI model weights, as well as the strategic significance of AI.
With both the US and China actively competing to be the world leader in
AI [The White House, 2023], there would be strong
incentives for states to misuse any access they may attain through a
compute provider oversight regime. For example, China's 2017 National
Intelligence Law stipulates that PRC citizens and corporations must
assist with China's national intelligence efforts, if directed
[China Law Translate, 2017],
and in 2022, the US government used its powers under the Foreign
Intelligence Surveillance Act to order Microsoft to give it access to
between 42,000 and 43,996 accounts
[Microsoft, 2022]. This creates a low-trust
environment that could diminish the competitiveness of compute providers
in countries that have oversight regimes and diminish international
support for such a scheme.

Privacy-preserving standards
— To support international cooperation on mutually beneficial AI safety
oversight, compute providers could play a leading role in working with
governments to establish privacy-protecting compute provision norms and
standards. The need to balance private interests with state interests,
and security with privacy, is not new. In 2017, Microsoft proposed
making major technology companies akin to a `Digital Switzerland' –
refusing to side with governments in any cyberattack and instead
upholding a neutral and trusted environment
[Smith, 2017]. However, in 2022, major technology
companies took an active stance in response to Russia's invasion of
Ukraine: Microsoft played an active role in defending Ukrainian
government systems and networks [Farrell & Newman, 2023] and SpaceX
immediately provided Ukraine with free access to its Starlink satellite
networks [Jones et al., 2023]. This has
demonstrated a growing willingness of private technology companies to
play an active role in geopolitics and this shift showcases the
limitations of voluntary rules and norms [Farrell & Newman, 2023]. In
this environment, technical solutions could be key to establishing the
trust and reliability necessary for customers to trust
internationally-owned compute providers in the context of an oversight
scheme. In particular, confidential computing techniques
[Confidential Computing Consortium, 2022] could ensure compute
providers cannot be compelled by governments to hand over sensitive data

Notwithstanding privacy-preserving standards to protect sensitive
customer data, requirements for compute providers to report on customers
in foreign jurisdictions will raise significant interjurisdictional
privacy challenges. Even between close partners like the US and EU,
privacy protections have already come into conflict with free data flows
across jurisdictions. For example, the EU-US Privacy Shield
[European Commission, 2016] and its predecessor,
the International Safe Harbor Privacy Principles
[EU Agency for Cybersecurity, 2000], designed
to allow data sharing between the EU and US, were both overturned by the
European Court of Justice because of their failure to appropriately
uphold EU citizens' privacy rights [BBC, 2020].
Their replacement, the 2022 EU-US Data Privacy Agreement, is also
under scrutiny, with privacy groups announcing their intention to
contest it in court [Kim, 2023]. Unilateral US
action to require reporting on foreign compute customers will likely
evoke similar privacy challenges that could inhibit US compute
providers' abilities to serve global customers. To manage privacy issues
with close allies, the US could develop tailored agreements that enable
its oversight requirements to be met through compute providers reporting
to the government of the allied country within which their customer is
domiciled. This could be made contingent on some level of information
exchange between the US and partner government. It could also serve to
incentivize uptake of a consistent scheme amongst like-minded countries.
We encourage further research to explore these issues in more depth.
Ultimately, to be successful, a comprehensive compute oversight scheme
will need to incorporate and gain a multilateral agreement for privacy
protections that balance privacy and national security.

Consistent international approaches
— Unilateral action by any one country—even those with a significant IaaS market share like the US—also risks incentivizing compute
providers and customers to shift to lower regulatory environments. This
could erode the market share of jurisdictions with greater oversight,
diminishing the ability of governments to oversee and address emerging
risks [Egan & Heim, 2023]. The already broad
geographic spread of major compute providers' data centers, and the
ability to access them remotely, could potentially enable the global
compute market to be more easily restructured. Unilateral action would
also push malicious actors and high-risk projects into jurisdictions
with lower scrutiny, thereby undermining efforts to increase AI safety.
Achieving the greatest consistency possible across international
jurisdictions will be key to ensuring that efforts to increase oversight
are effective and robust to evasion.

Ultimately, given the global nature of the compute industry, some form
of international agreement will be needed for monitoring and
verification frameworks to be durable. International compute oversight
coordination could be developed in a similar form to the Financial
Action Task Force, which currently works to achieve international
consistency in the application of anti-money laundering and
counter-terrorism financing (AML/CTF) safeguards and regulations
[Financial Action Task Force, 2024]. A similar body for compute
oversight could facilitate information sharing and help align regulatory
approaches and enforcement between international jurisdictions
[Egan & Heim, 2023]. Yet, while a majority of
jurisdictions have strong shared incentives to combat organized crime
and terrorism financing, there is a risk of differing incentives in the
compute oversight context. Some states, particularly those skeptical of
AI-related risks, may actively promote lower regulatory environments in
an attempt to attract economic activity and investment – similar to how
Ireland has used low corporate tax rates to successfully attract
multinational corporations to be domiciled there
[Alderman, 2021]. Initiatives seeking to build a
shared understanding of AI-related risks, like the 2023 UK Safety Summit
[UK Government, 2024], will continue to be important for strengthening
alignment on compute issues. Many countries, for example, India, UK, and
Japan, are also exploring options to build greater sovereign compute
capacity [Government of India, 2023, Nagao, 2023, UK Research and Innovation, 2023]. This increasing self-reliance could
lower interest in common international approaches that might impact
national goals. Ensuring international buy-in to a compute oversight
scheme would therefore require substantial diplomatic engagement
alongside broader economic incentives.