Dean W. Ball co-authored this piece before joining the U.S. Office of Science and Technology Policy. All views represented are purely those of the authors and do not necessarily reflect U.S. government policy.

At the heart of frontier artificial intelligence (AI) policy lies a key debate: Should regulation focus on the core technology itself—AI models—or on the technology’s uses? Advocates of use-based AI regulation argue that it protects innovation by giving model developers the freedom to experiment, free from burdensome licensing regimes and thickets of technical standards. Advocates of model-based regulation, on the other hand, argue that their approach concentrates the compliance burden on developers while granting users of AI the latitude to deploy the technology as they see fit, thus aiding technology diffusion in the long run.

Each of these familiar paradigms for regulating frontier AI faces serious objections. Use-based regulation can be just as onerous as model-based regulation—often much more so, as suggested by the EU AI Act and a gaggle of successor bills in various U.S. states. Although the burden of use-based regulation does not fall on developers in the first instance, it can nevertheless be expected to burden model development in serious ways, such as by deterring adoption through increased compliance costs for model users.

Model-based regulation, on the other hand, sets a decidedly suboptimal regulatory target. Powerful AI systems now utilize multiple baseline models that are integrated, or “scaffolded,” with other software and hardware. Increasingly, the capabilities and risks of these systems do not just derive from the baseline models involved, but also from their scaffolding and the computing power used to run them. Moreover, frontier AI development is advancing rapidly. A regulatory regime intended to target especially powerful frontier models by reference to models’ characteristics (such as the amount of compute used to train them) may quickly become out of date. To address this possibility, a regulatory body might be empowered to update the criteria that trigger model-based regulation. But that, too, may prove a difficult task, for reasons to be discussed.

In this paper, we suggest an alternative paradigm of frontier AI regulation: one that focuses on the large business entities developing the most powerful AI models and systems. Entity-based regulation is common in America, particularly in areas such as financial services and insurance, where risky products and services evolve quickly. Regulating AI models and uses poses serious challenges for policymakers; these approaches may fail in many circumstances to address the most distinctive and concerning risks posed by frontier AI development. Regulating corporate entities—something that U.S. law has done for centuries, often with considerable success—might do much better. A regulatory statute for frontier AI development should aim its coverage at large AI developers rather than AI models or uses.

We do not argue that entity-based regulation should be the exclusive way to regulate AI. We do not, for example, consider how to regulate so-called narrow machine learning systems that perform specific tasks, such as processing insurance claims, classifying images, and engaging in facial recognition. Many foreseeable negative uses of AI, including identity fraud and the distribution of child sexual abuse material, are already illegal. Still, it is possible that tackling potential negative uses of AI will require new governance approaches, which could include new laws.

Instead, our proposal focuses on how to structure preemptive risk regulation for the most sophisticated AI systems—both current and future. These so-called frontier AI systems may soon pose unique challenges, involving unprecedented levels of autonomous operation, the ability to engage in criminal behavior (such as blackmail or murder), the propensity to deceive users and developers (including during training), and the capacity to enable large-scale cyber attacks and the malicious development or deployment of biological weapons. Frontier AI systems are produced at significant cost (hundreds of millions or billions of dollars) by a relatively small number of actors (in the United States, five to ten firms). Like other proposals for frontier AI regulation, our proposal focuses on frontier AI risks—that is, the novel, emerging types of risks that the most cutting-edge AI systems may increasingly pose. How to identify and measure these risks, when exactly they will arise, and how to respond to them are all matters of considerable uncertainty and disagreement. One of the chief tasks of a frontier AI regulatory regime—arguably the chief task, at least for now—is to put society in a position to reduce such uncertainty and disagreement by enabling policymakers and the public to better understand the nature and magnitude of the risks posed by cutting-edge AI development. Among its other virtues, a regulatory regime that covers the large AI developers at the frontier—rather than particular frontier models or uses of those models—is most likely to achieve this goal. Or so we will argue.

Our claim is not that model-based and use-based regulation have no role to play in a frontier AI regulatory regime. Rather, we argue that they should be deemphasized in favor of a regulatory approach that focuses on the business entities producing the models and systems in question. More concretely, we suggest that the application of a frontier AI regulatory regime should be triggered by characteristics of the organizations developing AI models and systems at the frontier, rather than by the characteristics of those models or systems. Such an entity-based regime might be triggered by, for example, a certain aggregate amount of annual spending on AI research and development (R&D) or compute.

In its substance, too, frontier AI regulation should often focus on a frontier AI developer’s procedures and activities, rather than narrowly on the properties of the models it is developing. Put another way, although certain regulatory requirements might focus on model properties, these requirements should be integrated into a broader regulatory regime intended to address the risks that arise from the developer’s activities considered as a whole—including activities that do not pertain to model properties at all, such as (for example) handling novel algorithmic secrets or monitoring for the sabotage of internal safety critical systems by insider threats.

That said, this paper does not focus on the specific substantive requirements that a frontier AI regulatory regime might involve but on its general structure and orientation. A range of substantive regulatory requirements, from less to more stringent, is compatible with our general structural proposal. In this paper’s conclusion, we briefly highlight some of the possibilities without taking a stance on them.

We begin by describing the advantages and pitfalls of both model- and use-based AI regulation. We take Senate Bill (SB) 1047, a bill from the 2024 California legislative session, and House Bill (HB) 1709, a bill that was under active consideration in the 2025 Texas legislative session until mid-March, as illustrative paradigms. We then describe entity-based regulation for frontier AI firms and address how it improves upon shortcomings in both model- and use-based frameworks. We include sample statutory language to demonstrate how an entity-based regulatory trigger could be designed. We conclude by briefly suggesting (without endorsing) some possible examples of substantive regulatory requirements that could be attached to such a trigger.

The most prominent legislative proposal in the United States for model-based regulation to date is California’s SB 1047, which was put forward in the 2024 legislative session by State Senator Scott Wiener of San Francisco. It focused narrowly on frontier AI models—specifically, those requiring more than 10^26 floating point operations per second (FLOPs) of compute (essentially, mathematical operations, such as multiplication, involved in the training process) to train. The bill underwent substantial amendments during the legislative session, but its final form contained two principal components. First, SB 1047 would have required frontier AI developers to submit safety plans detailing how they would test for and mitigate the risk of “critical harms”—defined as certain kinds of outcomes causing mass casualties or over $500 million in damage. Second, the bill would have created legal duties (or codified and more concretely specified background legal duties) for frontier AI developers to exercise reasonable care to avoid such critical harms, and empowered the attorney general to seek monetary damages for critical harms caused by the failure to comply with these duties. 

There is much to be said about both the pitfalls and the merits of the bill, but we wish to leave such debates mostly aside. Instead, we will focus on a flaw noted, in some form, by many of SB 1047’s critics: the bill’s reliance on a model-based regulatory trigger, in other words, its use of a model property (training compute) to trigger its legal requirements.

Perhaps the most common criticism of the trigger was that it would come to cover far more than just frontier models as the cost of compute predictably fell over time. (To alleviate this problem, a later amendment of the bill added a secondary requirement that covered models cost at least $100 million in compute costs to train.) Other critics took aim at SB 1047’s choice of 10^26 FLOPs of training compute as its line for demarcating covered models. There was, and remains, no finding in the machine learning literature that suggessts that models with this characteristic are particularly likely to have catastrophic risk potential. Instead, as most supporters of the bill maintained, the regulatory threshold was a rough proxy: the aim of the threshold was to capture the next generation of frontier models—those that would come after GPT-4, Gemini 1.5, Llama 3, and Claude 3.

The use of a proxy is, in itself, no objection. The law uses proxies all the time to determine when regulatory requirements are triggered. The problem with model-based thresholds lies in the nature of the proxy they employ.

Shortly after SB 1047 was vetoed in September 2024, OpenAI released its next frontier model. It was not, as many had predicted, a massive model trained using much more compute than GPT-4. Instead, the company released o1, a model trained using reinforcement learning to “think” about user queries before answering. This model performed significantly better than any other frontier model, particularly in quantitative domains such as math and—importantly for cyber risk—software coding. Alongside o1, the company also released o1-mini, a far smaller version of o1 that itself could outperform many frontier models in coding and math.

There are disagreements about whether o1 itself would have been considered a covered model for purposes of SB 1047. But o1-mini almost certainly would not have been. Even more importantly, o1’s reinforcement learning-based approach scales with the amount of computational power (and time) the system is given to think when a user asks it a question—a variable known as inference or test-time compute. The same model, when given more time to think, reliably performs better on many tasks than it does with less time. Indeed, some have suggested that with enough thinking time, such models can be made to “simulate” the performance of far larger models. 

Compute-based thresholds make the most sense on the assumption that training compute will be the primary determinant of a model’s performance and its potential for dangerous capabilities. But the inference compute paradigm represented by o1 calls that assumption into question. And since the release of o1 in September 2024, basically all other frontier AI companies (such as Google and the Chinese AI company DeepSeek) have replicated this approach.

For now, at least, inference compute and inference-based reasoning techniques are likely to contribute as much to frontier model capabilities (and associated risks) as training compute. Even if the significance of inference compute fades in the future, other novel capability-determinative properties of models (or of their training techniques, or of the larger systems in which they are embedded) may emerge. For example, many sophisticated industry participants and observers expect that training runs at the frontier will make increasingly heavy use of powerful reinforcement learning methods (going well beyond classic fine-tuning methods such as reinforcement learning on human feedback) that are much less compute-intensive than the unsupervised learning methods that have been largely responsible for frontier capability gains to date. A threshold that relies on training compute will be insensitive to such developments.

Furthermore, the definition of training compute will become more complex and difficult to administer over time. When compute-based thresholds were first introduced, the standard view was that the vast majority (roughly 99 percent) of a model’s training compute budget would be utilized in pretraining (roughly, the process of teaching the model to predict the next token based on a training corpus representing nearly the entire internet), and only a small fraction of the compute budget would be devoted to modifying and augmenting the model’s behavior through post-training methods such as supervised fine-tuning and reinforcement learning from human feedback. OpenAI’s o1 approach makes heavy use of new reinforcement learning techniques at post-training, changing this ratio considerably. The exact ratio is unknown, but industry observers now suggest that post-training consumes anywhere from 10 to 20 percent of a model’s overall training compute budget. Many observers also expect this figure to increase over time.

Measuring the amount of compute used in training presents significant definitional difficulties. Here is a non-exhaustive list:

• OpenAI’s reinforcement learning process relies on the heavy use of synthetic data; should the compute required to generate this data count toward compute budgets?
• Model training runs routinely fail mid-process and must be restarted from an earlier checkpoint; should this extra compute be counted twice? If a novel and experimental training technique is applied to a model and fails in the sense that it seems to yield no appreciable capability gain, should the compute utilized to apply it nevertheless count?
• If frontier models acquire the capacity to learn continuously once deployed, should the definition of “training compute” be modified to include all compute used to run a model? That would threaten to render the scope of compute thresholds extremely capacious (and thereby dilute their ability to discriminate between capability levels). So, should this definition somehow reflect potential differences in the density of updates to the model’s weights during initial training as opposed to deployment? If so, how should the boundaries of these categories, which may be porous in practice, be legally defined?
• Currently, frontier AI developers are avidly attempting to substantially automate large swathes of AI research and development. Suppose that a model that is covered by a frontier regulatory regime (because it has been trained with enough compute to satisfy the compute threshold) is used by the developer to substantially automate the process of discovering a powerful new algorithmic architecture. And suppose that the developer subsequently trains a new model with that architecture, but the new model’s training compute does not independently satisfy the compute threshold. Should the new model be deemed to derivatively satisfy the compute threshold, because its architecture is causally downstream of a covered model? Should the answer be different if human ingenuity, or non-covered models, also played a very substantial role in discovering the new architecture? How should the respective causal contributions of these different kinds of inputs be assessed? What if the new model is then used to discover another algorithmic architecture, and new models are subsequently trained with that architecture – should these models also be deemed, derivatively, to satisfy the compute threshold?

The point is not that these questions are unanswerable. It is that, in practice, they are questions with many different conceivable answers. Compute-based regulatory triggers require laying down answers to these questions with considerable clarity. Given how quickly training and deployment processes are changing, and given how technically intricate the answers will often need to be, that will be a difficult task.

Moreover, in an AI policy regime driven by state-based laws (which seems to be the likeliest outcome in the United States), these questions may well be answered differently in different jurisdictions. Even in states that employ facially similar model-based triggers, different answers to these questions might yield the ungainly result that a covered model in one state is not considered a covered model in another. This could in turn inadvertently produce the sort of unruly regulatory patchwork that most hope to avoid. And since these subtle questions about how to measure compute can be answered in very different ways, industry actors may have an incentive to game the system to keep their models just below the relevant regulatory thresholds. Aware of this incentive, regulators could be motivated to investigate or audit frontier lab training practices—resulting in a substantial compliance burden for companies, the dilution of government resources, and a significant investigatory challenge for employees of regulatory agencies, without any commensurate gain in actual safety or security.

If compute-based thresholds were enacted, such drawbacks might take some time to become evident. But a more basic infirmity of compute-based thresholds is already apparent: as typically specified, at least, such thresholds are already failing to capture models released by frontier AI companies that may well have somewhat dangerous capabilities. For example, OpenAI’s o-series models were released in two sizes: full size (such as o1 and o3) and mini (such as o1-mini and o3-mini). It is not known whether any of these models cross the standardly proposed 10^26 compute threshold, but it is unlikely that the mini models cross these thresholds. These models represent substantial leaps in capability—the o3-mini, for example, matches the full-size o1’s capabilities in mathematics and coding, despite the o3-mini having been released just a few months after.

To be sure, frontier AI development is moving so quickly that the most powerful models released in the next few years are likely to surpass whatever regulatory compute thresholds are drawn today. This fact mitigates the risk of underinclusivity that inheres in model-based regulatory triggers. But the resulting overinclusivity is problematic in its own right.

For one thing, unless these triggers are often updated, the associated regulatory requirements will fall out of step with the unique risks and features of the most powerful AI systems—the systems truly at the frontier. Casting the regulatory net so broadly could divert regulators’ attention and resources away from those risks that are most concerning and genuinely in need of heightened attention. That is especially problematic given the government’s dearth of technical expertise and lack of regulatory capacity in this area. Moreover, as this regulatory net is cast more and more broadly, sweeping up more and more entities, it risks stifling the broader economy’s ability to innovate and integrate AI. To mitigate these problems, a regulatory body could be tasked with regularly updating the model-based regulatory triggers. But even assuming that this regulatory body would have high competence and capacity, this arrangement would reintroduce the difficulties described above. Even if updated as regularly and expertly as possible, a training compute threshold will prove an increasingly poor proxy for a model’s capabilities and risks insofar as inference compute, post-training reinforcement learning, or other methods continue to be responsible for frontier capabilities. The proxy is liable to degrade even further if automated AI R&D takes off and reduces training compute requirements (such as by finding new, more compute-efficient architectures) or if potentially less compute-intensive methods (such as neurosymbolic reasoning) come to drive a larger share of progress at the frontier.

Thus, compute-based thresholds face serious specification, implementation, and coverage challenges. One response, of course, is to suggest that some other property of models should serve as the trigger for frontier AI regulation. But for all the shortcomings of compute-based triggers, no one has yet devised a model-based regulatory trigger that might function as a better proxy for heightened capabilities and associated risks. Moreover, while a compute-based regulatory trigger’s full specification of training compute will likely prove intricate and unwieldy, it may well prove even more intricate and unwieldy to fully specify the definition of some technical property that is less familiar and well-understood.

Can model-based regulatory triggers be devised that do not rely on technical proxies, but instead reference dangerous model properties directly? Perhaps so, if models start to demonstrate certain clearly dangerous properties (such as a robust propensity to engage in certain forms of injurious deception). But in large part, the value of frontier AI regulation lies in its capacity to serve anticipatory and evidence-gathering ends. Frontier AI regulation should aim to improve our society’s collective epistemic position. That is, it should empower the public and the government to understand and evaluate the potential risks of frontier AI development before (and as) clearly dangerous model and system properties emerge; help policymakers plan for the emergence of such properties; and help them identify when such properties have in fact emerged.

For now, at least, the nature of such dangerous properties remains murky and contested. There is, for example, some preliminary experimental evidence that sophisticated models might try to deceive their developers to prevent themselves from being trained out of their initial goals and values. But it is contested whether these experiments are a fair portent of how models are likely to behave in the wild. More generally, there is a great deal of uncertainty regarding how to measure putatively dangerous properties or determine which properties would (if observed) be highly concerning. It will be difficult to articulate regulatory triggers that directly reference dangerous model properties when the nature, significance, and identification of those properties remains so unclear and controversial.

These difficulties are compounded by the fact that, if such dangerous properties arise, they are likely to do so while a model is being trained. Training is precisely when a model’s capabilities and propensities (and the nature and degree of their dangerousness) will be most difficult to ascertain. Indeed, the relevant capabilities may sometimes be fundamentally indeterminate, at least until (and perhaps even after) training is complete. Designing and enforcing regulatory triggers that reference such capabilities is thus likely to be especially difficult. Indeed, if a frontier AI regulatory statute were to utilize dangerous model properties as the triggers for its coverage, that would create quite perverse incentives for frontier AI developers to avoid investigating, analyzing, and disclosing the potentially dangerous properties of their models and systems. Such incentives could have especially pernicious effects given that the public is currently relying on the efforts of large AI developers to acquire information and understanding about the capabilities and risks of cutting-edge AI. This reliance may be disturbing, for obvious reasons. But it will likely be necessary for the foreseeable future—even if robust forms of regulation are enacted, and even if the independent auditing and testing ecosystem expands far beyond its current capacity.

To be clear, there are very difficult questions here that any meaningful frontier AI regulatory regime will have to grapple with. Our point is that, given how thorny, unsettled, and contested these questions are, it seems unwise to make the very application of a frontier AI regulatory regime depend upon providing an answer to them. In large part, the goal of a frontier AI regulatory regime should be to help policymakers and the public gain greater clarity on how these questions might be resolved.

What is more, there are some fundamental respects in which model-based regulatory requirements are simply inapposite: by their very nature, such requirements will not address risky activity at the frontier. Here are three examples.

First, some important safety and security risks do not derive from features of models at all. For example, suppose that an AI developer inadequately guards an extremely powerful and dangerous algorithmic secret, enabling a foreign adversary to steal that secret and develop extremely powerful models of its own. Or imagine that a developer fails to adequately vet employees and new hires for potential insider threats, leading to the sabotage of the firm’s internal safety-critical systems. Or suppose that a developer secretly or opaquely abolishes a core internal governance mechanism designed to guard against such risks. Regulatory directives targeted at the developer’s handling of its models will not address any such failure mode. (Of course, legislation or rulemaking could try to identify especially dangerous algorithmic secrets and directly subject them to regulation. But it would be difficult to formulate in advance the characteristics of algorithms that should trigger such regulatory requirements. Indeed, any attempt to do so might itself divulge valuable secrets to foreign adversaries.)

Second, frontier labs and many other AI researchers are actively pursuing so-called multi-agent reinforcement learning, which enables AI systems to tackle complex tasks by breaking them into simpler subtasks and deploying multiple agentic AI models in parallel to handle each one. One frontier lab has already confirmed that some of its leading offerings make heavy use of this method. The o-series mini reasoners, with their favorable performance and cost characteristics, could also be strong candidates for such systems. Does a multi-agent system with dozens or hundreds of mini models running in parallel pose less of a danger than a single full-size model just because the mini models were trained with less compute? An adequate regulatory regime should not bank on any such assumption, especially as progress in multi-agent system development advances.

Third, suppose a developer internally deploys a powerful model to, for example, make money on the financial markets. Obviously, the attendant risks will partly derive from the model’s characteristics. But these risks might also be a function of other systems, strategies, or personnel that the developer is utilizing in connection with the model. Or the risks might be a function of other models within the developer’s control, which do not themselves meet any model-based regulatory trigger. In short, regulatory requirements articulated purely with respect to the characteristics of frontier models could fail to address the broader array of risks that arise from a frontier model’s interaction with the developer’s other systems, models, and activities.

To provide another illustration of the general point, suppose that a developer’s most powerful frontier model can function as a highly sophisticated autonomous agent, but it has been developed or modified such that it lacks knowledge of any dangerous, non-public data regarding biological threat creation. Suppose the developer also possesses another model that is much less powerful, and generally much less dangerous, but that does possess knowledge of some such data on biological threat creation. Serious risks could arise from the interaction of these models that do not arise from either operating alone. Similarly, risks could arise from the interaction of a covered frontier model with a powerful algorithm or architectural secret that is segregated and custodied with inadequate care. The nature and magnitude of such risks will not be determined by model properties alone, but also by larger organizational properties of the developer, such as its security arrangements, insider threat monitoring, and procedures for assessing and monitoring internal deployments.

These observations about the limits and flaws of model-based regulation might be taken to suggest that use-based frontier AI regulation is the superior path to take. And use-based regulation may, indeed, avoid some of the problems discussed above. If a frontier AI company deployed its model to make money in financial markets, for example, a use-based regulatory regime could target some of the associated risks, in addition to risks arising from similar use by other parties.

But reliance on a use-based regulatory framework to address frontier AI risks faces serious challenges and drawbacks of its own. For one thing, many of frontier AI’s most concerning risks going forward—risks of deception and misalignment, for example—are not suited, by their nature, to be addressed at point of use. As already discussed, some of these risks are likely to materialize (if they do) during a model’s training. And even when such risks materialize during the model’s use, the dangerous properties giving rise to them will have been baked into the model during training. The model’s users will generally have little ability to detect these properties or competently address the associated risks. Indeed, the risks may be posed, in part, to the users themselves. When addressing the possibility that an advanced AI system might blackmail or defraud its users, for example, use-based AI regulation plainly makes little sense.

Moreover, insofar as legislators and regulators attempt to address frontier AI risks with a use-based regulatory scheme, they will need to identify up front the major risks that will attend various uses of frontier AI systems. That will prove immensely challenging. Increasingly powerful general purpose AI models will have an increasingly wide range of capabilities. In fact, frontier AI development may, in the future, open entirely new forms of scientific, commercial, and military activity. So, future uses of frontier AI models may often be highly difficult for legislators and regulators to foresee—especially since many of them are generalists without much expertise in AI development or much time to devote to understanding it.

Despite these observations, one might nevertheless champion use-based frontier AI regulation on the basis that it will prove less burdensome for AI innovation and diffusion than the alternatives. But recent experience with use-based AI regulation supports the opposite worry: it may be considerably more onerous and extensive than entity-based regulation (or model-based regulation, for that matter), precisely because it seeks to cover a much wider swath of activity by a much wider range of actors.

To illustrate, consider perhaps the most prominent instance of use-based AI regulation yet proposed: Texas’ HB 1709, a bill that was seriously considered in the state until mid-March 2025 and whose same basic framework has been proposed in at least a dozen U.S. states. HB 1709 sought to apply a form of civil rights law to developers, distributors, and users (corporations not deemed small businesses by the Small Business Administration) of AI systems. HB 1709 would have required all these groups to write “risk management plans” and “algorithmic impact assessments” for all uses of any AI system that makes decisions that could have a “material impact” on a consumer’s “access to, or terms and conditions of,” services (such as banking, insurance, healthcare, education, and transportation) and opportunities (such as employment). Importantly, the bill defined AI to cover both narrow machine learning systems and general purpose frontier AI systems.

If an insurance company or a bank deploys an AI system to make decisions regarding health coverage claims or loan applications, impact assessments and risk management plans could perhaps be reasonable and prudent. Narrow machine learning systems have been created to make such decisions, with mixed results in the real world. A general purpose AI system, however, can be used for far more than such a final decision. And HB 1709 defined “decision” as anything that could have a material effect on access to or terms or conditions of the service or opportunity in question. As a result, the law would not have simply covered the final decision but also many subsidiary decisions made in the process of reaching it.

This definition of a decision as any small choice leading to a larger one would have significantly complicated the implementation of the law. For example, say that a small business is seeking to hire a new employee and advertises the job on social media. Employment decisions count as “high-risk” under HB 1709 and all other similar algorithmic discrimination bills that are under consideration or have been enacted. The social media algorithm(s) used by the small business are “deciding” who sees the job application, so it is conceivable that the simple act of posting a job listing on social media is a “consequential” use of an algorithm. Thus, the business would plausibly need to write an algorithmic impact assessment and a risk management plan for its use of social media. Conceivably, the same could even be true if an employer uses a language model to help draft a job description (assuming, at least, that the description meaningfully differs from what the employer would otherwise have drafted). The text of HB 1047, by its terms, appears to imply such conclusions; to stave them off, the employer would need to depend upon the solicitude of a state judiciary willing to deem these conclusions implausible or absurd. And these are only two of the literally millions of benign AI use cases, regulated by HB 1709 and other algorithmic discrimination laws, that might fairly be regarded as “consequential.”

Thus, HB 1709 would have imposed significant compliance burdens on the users or deployers of AI systems. Moreover, it would have forced those deployers to answer complex questions about the technical underpinnings of those systems that even expert AI researchers might struggle to answer. The burden of grappling with such questions might have deterred some corporate users from adopting AI in the first place. Even for those corporations that may have been undeterred by the regulatory burden, the law would have likely centralized AI adoption strategies within the senior management of firms.

Such centralization often hinders the creative and widespread adoption of new general purpose technologies, which generally benefit from a more decentralized and experimental approach, as researcher Jeffrey Ding has explained. Ding observes that the economic benefits of new technologies (especially general purpose technologies) often stem from diffusion rather than novel inventions. It is not just language models themselves that promise increases in productivity, or new consumer experiences and scientific discoveries, but instead the creative and widespread use of those models throughout the economy.

New uses of AI models may challenge assumptions about how business is done, how communication should be conducted, and how society should function. Entrepreneurial and technological dynamism flows from uses of technology that challenge the status quo. Regulations on use risk killing such innovation in its cradle. Any regulation written today about the optimal way to use technology will implicitly encode into law existing assumptions about the way the world should work. In this way, use-based regulation can inadvertently outlaw new and beneficial ideas.

So, use-based frontier AI regulation can be a perilous proposition—both from the perspective of encouraging innovation and diffusion in frontier AI and the perspective of addressing frontier AI development’s distinctive and most troubling risks. To be sure, some use-based regulation may nevertheless be warranted; our point is not that the use or deployment of AI in particular contexts should never be regulated. Instead, it is to highlight the immense humility and caution lawmakers should exercise when contemplating creating rules to govern the unfathomably vast range of possible uses of a powerful new macro-invention. Especially at the frontier, where model capabilities are likely to be especially general and broad, use-based regulation should not be the first resort.

There is an alternative regulatory approach that largely avoids these difficulties. Rather than attempting to target models—fast-evolving and novel artifacts, which are often a leaky abstraction for the risks of frontier AI development—or their vast range of uses, policymakers can target a far older and more stable structure: the corporate entities (or, in some cases, closely related groups of entities) that produce and deploy frontier models.

Under an entity-based approach, when an entity satisfies a triggering condition specified in statute or regulation, such as a specified aggregate amount of annual spending on AI R&D, the entity will be subject to a regulatory regime intended to address the distinctive risks of developing AI at the frontier—risks arising from the company’s training, testing, custody, and deployment methods in addition to the properties of its models.

In American regulatory history, entity-based regulation has often been employed when the character of the product in question is fast-changing and varies significantly throughout a given industry. For example, many financial and insurance services in the United States are regulated largely (though not exclusively) via entity-based regulation; many financial institutions face different regulatory requirements based on entity characteristics, such as size. By contrast, in industries such as pharmaceutical drug development, regulatory requirements are triggered by, and in the first instance apply to, individual products (such as particular drugs or drug lines) rather than the entity making them. The process of drug development is protracted and does not change appreciably from year to year. Frontier AI development could not be more different.

While both financial products and pharmaceuticals can pose major risks, financial services are offered in an ongoing manner, and failure in a bank’s processes at any time can turn a safe financial product into a high-risk one overnight. By contrast, a pharmaceutical product that has been manufactured and shipped into the market cannot, under most circumstances, suddenly become riskier because of some action taken by the firm. When the riskiness of a product or particular activity depends, in a pervasive and ongoing way, on the riskiness of a firm’s larger set of activities, entity-based regulation makes a great deal of sense.

Widely deployed frontier AI systems could easily pose systemic risks similar to those of large financial institutions. These risks need not even be the most catastrophic potential risks from future AI systems, such as enabling bioweapon development or large-scale autonomous cyber attacks. Consider a frontier AI system used by hundreds of millions of individuals, government agencies, businesses, and other organizations. Such a system would mediate billions of dollars of commerce a day, propagate information throughout businesses in every industry, and facilitate significant scientific advancements. It would also face a huge variety of constantly evolving risks, such as jailbreaking (when a user intentionally tries to subvert a model’s safeguards to get the model to output disallowed content); adversarial prompt injection (when internet material that an AI agent might encounter is used to trick the agent into revealing sensitive user information or otherwise act against the intentions of the user or model developer); and sleeper agent–style attacks (when malicious messages are placed into a model’s training data, with or without the developer’s knowledge, to cause the model to malfunction or act against users’ interests based on a post-deployment trigger event).

Any one of these attacks could cause countless systems across the economy to fail or malfunction unpredictably. Notably, these attacks could cause dramatic harm even if the models under attack do not possess an innate capacity to inflict catastrophic harm. There is no such thing as a safe model per se—ensuring the safety of a broadly deployed AI system will require continuous monitoring, just as such monitoring is required today for many economically valuable software systems. More generally, it is extraordinarily difficult to ensure that a highly capable AI model is safe by looking at the model’s properties in isolation. In fact, in many cases, it is not particularly perspicuous or helpful to describe AI safety as a “model property” at all. Often, safety is best understood principally as a property of the systems and processes in which a model is embedded. And at least for the foreseeable future, the most widely deployed (and therefore most systemically risky) systems and processes are likely to be built and controlled primarily by the business entities at the frontier of AI development (or entities to whom they are delegating control).

Indeed, a vulnerability in one of a developer’s models, systems, or processes could readily compromise other models, systems, and processes that the developer creates, utilizes, or controls. Imagine, for example, that a model that is dangerously misaligned with its developer’s intentions is used to create new models; update existing models; or monitor the developer’s cybersecurity protections, insider threat detection, or AI R&D processes going forward. Or imagine that a developer’s due diligence process for detecting and measuring concerning behavior in its models is secretly co-opted by an insider threat. In these ways and others, critical failures in the risk management protocols of the largest AI developers can be expected to propagate far beyond the particular model, system, or process that is directly compromised. It seems unwise, therefore, for frontier AI regulation to orient itself toward the riskiness of particular models rather than the larger tapestry of risky activities at the frontier.

An entity-based regulatory scheme could be triggered by a variety of different firm characteristics—for example, the amount of money a firm spends on AI R&D or on AI compute. A trigger for entity-based regulation could be written into a statute by defining both the general set of activities involved in frontier AI research and a regulatory trigger based on firm spending on that research. For example:

• For purposes of this Act, “covered artificial intelligence research and development” means any activity intended to develop or train one or more advanced artificial intelligence models—particularly deep neural networks or comparable machine learning architectures—on extensive, diverse datasets of natural language or other modalities, with the express or foreseeable aim of enabling the model to perform a wide range of intellectual tasks, solve problems across multiple domains, and exhibit adaptability or reasoning capabilities comparable to or surpassing that of typical human cognition.
• For purposes of this Act, a “covered frontier developer” is an individual or entity that has spent more than $1 billion in the prior calendar year, or plans to spend more than $1 billion in the current calendar year, on covered artificial intelligence research and development. 

This is simply illustrative language, which is not intended to capture the range of design possibilities. Many other possibilities are conceivable. For example, policymakers could vary the dollar amount used in the trigger. Similarly, the trigger could focus purely on an entity’s spending on compute rather than its overall R&D spending, which would include a much broader range of expenditures. Or the trigger could be disjunctive (for example, it could require either a certain amount of spending on compute or a certain amount of spending on overall R&D) or conjunctive.

It could make sense, as the circumstances and exigencies of frontier AI development evolve, for policymakers to modify the entity-based regulatory trigger they initially specify. Fortunately, an entity-based regulatory trigger will likely need to be changed much less frequently than a model-based regulatory trigger; the nature of the companies at the frontier of AI development (and their spending on R&D, compute, and so on) is likely to change far less quickly than the AI models and systems at the frontier. Moreover, generalist legislators and regulators are likely to have less difficulty tracking the first sort of change than the latter sort of change.

A trigger that focuses on an entity property, such as annual R&D spending, has other virtues as well. If such a trigger is set sufficiently high, it will obviously avoid covering smaller companies. It will thereby reduce burdens on innovation and experimentation by startups and small technology companies, and reduce regulatory pressures toward market concentration. It will also direct the government’s scarce regulatory resources in this area toward where they are needed most. Even if money were no object, the time, attention, and technical competence of legislators and regulators dealing with frontier AI development will not be in abundant supply anytime soon. Avoiding the dissemination and dilution of these resources should be a chief priority for those who wish to see frontier AI regulation succeed—as well as those who wish to minimize compliance burdens on startups and smaller tech companies. Entity-based regulatory triggers are more promising, in these respects, than model-based ones.

In addition to regulatory triggers that focus purely on entity qualities such as aggregate R&D spending, there are also intriguing possibilities that somewhat blur the distinction between model-based and entity-based regulation. For example, a statute might employ a model-based trigger for a regulatory framework whose substance is entity-oriented, in the sense that it covers the entity’s risky activities (including risky activities that do not pertain to how the entity deals with its models, let alone the particular models singled out by the trigger). Thus, for example, an entity-oriented regulatory statute could apply its requirements to any developer that has trained at least one model with 10^26 FLOPs of training compute, or at a cost of at least $100 million in training compute. Conjunctive or disjunctive possibilities for the trigger are conceivable as well (for example, a regulatory statute could apply to any entity that has trained a model with over 10^26 FLOPs of compute and annually spends or plans to spend a certain amount of money on compute or R&D).

A statute that combines a partly or wholly model-based regulatory trigger with entity-focused regulatory substance will enable many of the benefits of entity-based regulation described above. For example, it will enable the regulatory framework to cover aspects of a developer’s practices (such as its governance procedures or insider threat detection protocol) that do not pertain (at least not directly) to its development and handling of models. But such a statutory design will nevertheless incur some of the characteristic drawbacks of utilizing a model-based regulatory trigger. While this paper does not address this sort of statutory design further, it is well worth considering. Certainly it could be a sensible, intermediate step toward a (more fully) entity-focused regulatory trigger in future statutes (or statutory updates).

One objection that might be pressed against entity-based regulation is that it is vulnerable to bad faith evasion through accounting shenanigans or corporate engineering. Sophisticated AI developers might, for example, attempt to create different corporate entities and parcel out R&D expenses among them to ensure that no one entity is spending more than the threshold dollar amount that triggers regulation. In other contexts, however, the law has developed techniques to address such mischief: think of veil piercing doctrines in corporate law, substantive consolidation techniques in corporate bankruptcy, the integrated enterprise test in labor law, and common control tests in banking regulation. In fact, similar techniques would likely be even more successful here. The universe of regulated entities is likely to be small; there are few companies that can credibly claim to be at the frontier of AI development. It seems likely, therefore, that bad faith evasion attempts by such firms would be particularly obvious.

A different and perhaps more concerning objection to entity-based AI regulation is that it will prove underinclusive. In the future, highly dangerous AI capabilities might massively proliferate, such that models considerably behind the frontier pose a substantial risk of enabling a wide range of bad actors to (for example) create or deploy highly destructive bioweapons. If such proliferation occurs or is about to occur, entity-based AI regulation may not be an adequate approach for addressing risks from powerful AI. But even in such a world, we think, it will be necessary; there will still be distinctive risks arising from the activities of the firms developing the most powerful models and systems. Some of these risks may be distinctive in kind (think of risks arising from sophisticated agentic deception and scheming during training), while others may be distinctive in degree (think of bioweapons-related risks that are especially concerning, in part because they partly derive from unprecedented agentic capabilities). Investigating and understanding the capabilities and risks of the most advanced AI systems will remain an acute societal need, and it will continue to warrant a distinctive regulatory approach at the frontier. That approach, we have argued, is entity-based AI regulation.

Of course, this leaves open the question of how the vast residuum of potentially serious risks from AI systems behind the frontier should be regulated. This is obviously a large and difficult question, and we do not have any very good answer. If the development of highly risky AI systems of a certain kind (for example, systems that pose significant biological weapons–related risks) is concentrated within a manageable number of firms behind the frontier, a different entity-based framework could conceivably be formulated to govern them. But, of course, that assumption is unlikely to hold for long in the sort of hyper-dangerous world of powerful capabilities proliferation we are contemplating. In such a world, stringent regulations on the use and possession of sufficiently powerful models could conceivably be called for, but such restrictions would pose serious risks to personal liberty. And their efficacy in the absence of intensive geopolitical coordination is open to serious doubt, especially as indefinite measures.

One measure that would seem amply justified in such a world is massive societal investment in rendering critical infrastructure more resilient to the malicious use of powerful AI models. And the necessary defensive measures will likely include the broad deployment of frontier AI models, for such models are especially likely to possess powerful defensive capabilities—again raising the question of how AI development and deployment at the frontier should be regulated.

Entity-based regulation is a framework for regulatory policymaking—it is not itself a worked out set of policies. Our aim here is not to evaluate the specific forms that entity-based regulation might take, especially since we may disagree about those details. Instead, we will try to give a sense of the spectrum of possibilities.

At a minimum, entity-based regulation might involve transparency requirements: obligations on covered developers to disclose (to the public, the government, and/or other appropriate parties) certain salient features of their riskiest activities (such as training, safety testing, and assessment and monitoring of insider threats and high-stakes internal deployments), and to disclose when certain particularly risky capabilities or propensities have plausibly emerged in their models or systems. While the idea of transparency often proves popular, thorny issues remain, such as which particular requirements to impose and how general or detailed those requirements should be. But meaningful transparency requirements of some kind seem prudent and warranted.

At the other end of the spectrum, regulation might require the sort of highly intensive government engagement that characterizes nuclear safety regulation. Nuclear power plants face constant, rigorous oversight by government regulators. This includes site-specific operating licenses, continuous inspections, strict safety protocols, stringent personnel security clearances, and intensive formal training requirements for operators. AI labs could conceivably be subjected to similarly intensive regulatory oversight and demands.

Between these poles lie a range of intermediate possibilities. For example, covered developers might be required to formulate and adopt risk management protocols that identify and address certain novel kinds of risks that their activities might pose. Going further still, they might be required to adopt organizational structures and governance mechanisms intended to ensure that such protocols are properly applied, carefully updated, and meaningfully enforced internally. For example, covered developers might be required to appoint a chief risk officer, who reports directly to the board of directors, or to engage independent safety auditors when making certain decisions that are particularly risky or high-stakes according to the developers’ own risk management protocols (or, perhaps, those of their industry peers).

Many of these decisions will, of course, involve AI models and systems. In that sense, an entity-based regulatory regime will need to address many of the same issues as a model-based regulatory regime. Precisely because it deemphasizes the leaky abstraction of a model, however, an entity-based regulatory regime will often handle these issues in a more attractive and tractable manner.

Consider, by way of illustration, the question of how to structure transparency and disclosure requirements. Under a model-based regulatory regime, such requirements would be triggered by properties of models: frontier AI developers would be required to make certain significant disclosures (regarding risks, capabilities, and mitigations) when releasing a new model that satisfies some specified criterion, such as a threshold amount of training compute. But what counts as a new model? Frontier models and systems are not always built from scratch; they can be created by fine-tuning, combining, and scaffolding existing models. Clearly, it makes little sense to require significant disclosures whenever an existing model’s weights (or its scaffolding) undergo a minor tweak, or whenever some minor change is made to how the model is provided through an API or otherwise deployed externally. Put another way, a very exacting definition of what counts as a “new” model or release would be unworkable and burdensome. But given how quickly the technical features of frontier AI models and systems are liable to change—and given how much uncertainty there is about which technical features, exactly, give rise to serious risks—attempting to specify more general criteria for what counts as a new model or release could easily miss the mark. Such criteria could easily make a poor fit with the underlying capabilities and risks that warrant identification and disclosure.

An entity-based regulatory frame suggests a more promising approach. For example, a covered AI developer might be required to disclose at regular intervals (to the public, the government, or another suitable party) whether it has discovered major new capabilities, or dangerous new propensities, in any of the models or systems that it is training, storing, or deploying, and what tests and precautions it has employed to this end. And if, between these intervals, a covered developer decides to make a major decision that is likely to involve a substantial capability gain or pose a substantial marginal risk of causing certain forms of severe harm—whether that decision is characterized as releasing a new model, changing an existing model, integrating an existing model into a new system, or engaging in some new form of training or algorithmic design—the developer might be required to disclose that decision, as well.

Under such a regime, no linguistic or conceptual difficulties involving the definition or specification of a model need arise, for nothing of legal significance turns on drawing the boundaries between different models or differentiating between old models and new. To be sure, many substantive difficulties will remain—involving how to detect and characterize new capabilities and behaviors, how to measure and mitigate the associated risks, and so on. But these problems of classification and measurement are not produced by some distorting conceptual map; they derive from the difficulty of the underlying terrain.

Consider another illustration of the point. Policymakers might wish to require that frontier AI developers transparently provide to the public or the government model specs, that is, documents specifying how a model or system is supposed to behave under various important conditions. For the sorts of reasons already given, however, it will be difficult for regulation to lay down in advance what counts as a new model or system, such that this transparency requirement is triggered with respect to it. Under an entity-based regulatory regime, there is no need to do so. Instead, a covered developer can simply be required to ensure that—however the developer wishes to define the boundaries between its different models or systems—for each model or system it has made available to the public, that model or system is covered by some up-to-date model spec that the developer has transparently disclosed.

So structured, a model spec transparency requirement would be harmonious with current practice in at least some frontier labs, which provide a single model spec for all their publicly available models. Of course, a frontier lab might wish to instead provide multiple model specs, for models or systems that it wishes to behave in different ways. Under the sort of regime we are suggesting, the developer would be perfectly at liberty to do so.

So here, again, an entity-based regulatory trigger can achieve the same substantive goals as a model-based regulatory trigger without getting mired in the conceptual and linguistic difficulties—regarding how to distinguish between different models or systems and how to define when a model should count as a new one—that characteristically afflict the latter. And, as discussed above, an entity-based regulatory framework can naturally address certain important kinds of practices and decisions (such as governance procedures, the handling of algorithmic secrets, and the detection of insider threats) that a model-based regulatory framework cannot. To be clear, it is not obvious how, if at all, to regulate such practices and decisions. But it is unwise to force the general structure of frontier AI regulation into a procrustean, model-based mold that artificially puts such practices and decisions out of scope.

What substantive regulatory requirements should an entity-based regulatory framework adopt? That depends on a host of difficult empirical and predictive issues—issues on which reasonable minds might disagree. What kinds of severely harmful outcomes might frontier AI systems cause, and how large are these risks? How much of a lead, if any, does the United States possess over authoritarian adversaries in frontier AI development, and what kinds of regulation might erode (or protect) the country’s lead? What kinds of regulation would exacerbate risks of authoritarian capture or increase the costs of limited bureaucratic capacity and competence?

Both of us are quite uncertain about the answers to these questions, and we may be inclined to answer them somewhat differently. We recognize, moreover, that the answers are liable to change over time. However these questions are best answered, and however our society navigates its collective uncertainty about them, we believe that the legal framework for frontier AI development should generally treat the characteristics of entities (or related entities acting in concert), rather than characteristics of models or uses, as its principal regulatory trigger. And while the substance of this entity-based regulatory framework may in part pertain to models and uses, it should do so in the context of a more fundamental concern with the broader risks of the entity’s activities, considered together rather than in isolation.

These views could be mistaken, of course. Maybe entity-based regulation warrants a somewhat more modest role in frontier AI regulation (and model- or use-based regulation warrants a somewhat more prominent role) than we are currently inclined to suppose. The optimal mix of these different regulatory strategies requires further investigation. So does the choice among different kinds of entity-based (or hybrid model-based/entity-based) regulatory triggers, as well as their precise legal formulations. So the thoughts in this paper are offered in an exploratory rather than dogmatic spirit. Nevertheless, we are fairly confident that entity-based regulation should play a significant role in frontier AI governance. The scope, design, and implementation of entity-based frontier AI regulation warrant careful consideration.

We are grateful to many friends and colleagues for valuable conversations about these issues, and thank Jon Bateman, Miles Brundage, and Tino Cuéllar for helpful comments on this paper, as well as Alana Brase, Haley Clasen, Helena Jordheim, and Lindsay Maizland for excellent editorial support.