Regulate the AI Developers, Not the AI
Newsletter Issue 60 (Research Spotlight): The case for entity-based AI rules is gaining traction.
AI systems are getting more powerful, but the real risk often lies with the companies behind them. In this research spotlight, we discuss a scholarly article “Entity-Based Regulation in Frontier AI Governance” published on the Carnegie Endowment for International Peace website. It explores why current rules that focus on AI tools themselves are missing the mark, and why regulators should start paying closer attention to the people and firms building these systems.
Why Models Alone Will Not Do
The growing fascination with AI governance has produced a near-obsession with models: parameters, compute thresholds, and other technical markers that sound impressive but do not always tell the full story.
While these criteria might have seemed sufficient in the GPT-3 era, focusing solely on the model as the object of regulation today risks overlooking how the very architecture and training processes of frontier AI systems are evolving.
The Carnegie Endowment article Entity-Based Regulation in Frontier AI Governance hits this nail directly on the head: if you are chasing the model, you are already behind.
Its central argument is the recognition that certain advances, particularly those involving reinforcement learning and the deployment of multi-agent AI systems, are beginning to outpace the narrow technical triggers that have dominated early policy conversations.
These AI systems do not always come with clearly defined weights or sit neatly within a singular model boundary. Some frontier systems are modular, continuously learning, or blending together multiple architectures.
Trying to police them solely through model-centric triggers will not suffice.
Even the more sophisticated triggers, like counting the total floating point operations (FLOPs) used in training, are beginning to show signs of weakness. These metrics might offer rough indicators of system complexity or potential power, but they also introduce enforcement headaches.
What does it mean to enforce a threshold like 10^26 FLOPs across a global industry where compute is dispersed, modular, and sometimes shared between partners or subcontractors?
More importantly, what do regulators do with systems that evolve after deployment?
The paper rightly observes that the future of risk is not sitting politely inside the architecture of a single generative model. Some emerging risks stem from systems learning dynamically after deployment, or from how they are integrated into workflows that involve significant human or financial decision-making.
The real concern is often less about the power of the base AI models and more about the conduct of those developing and operating them at scale.
In that light, trying to futureproof governance by setting static model-based thresholds feels a bit like regulating space travel by counting how tall the rocket is.
This is where the Carnegie paper makes its most compelling point.
The industry needs a pivot toward entity-based regulation. This is a practical acknowledgment that the real locus of control, design, and deployment lies with the firms building and operating these systems.
Developers choose architectures. They decide how much training compute to apply. They determine when and how models get reviewed, updated, and embedded in services. It makes more sense to anchor regulatory triggers in the behaviour and capabilities of these companies than in abstract model features.
By identifying developers through clear and observable criteria, such as annual spending on AI R&D, the report suggests a way to cut through the noise.
Spending thresholds are not perfect, but they are publicly visible and harder to fudge than opaque declarations about parameters.
They also align better with capacity: a developer spending hundreds of millions on frontier research is far more likely to influence high-risk outcomes than a student fine-tuning a model in their bedroom.
The point here is not that models are irrelevant; they still carry risk and need technical scrutiny.
However, models are not autonomous actors. The decision to build them, train them, connect them to real-world tools, and continue their development sits with identifiable legal persons.
Governance must be smart enough to follow the trail of responsibility, not just the file size of a neural network.
Regulators should avoid building policy regimes that are forever chasing the next parameter threshold.
The path forward lies in recognising that risk flows from a combination of design choice, deployment strategy, and institutional capability.
Regulate the Developer, Not the Tool
There is a recurring problem in how regulators approach frontier AI: the overwhelming temptation to focus on the technology itself, rather than the people and organisations deciding how it gets built, deployed, and monetised.
The article challenges this instinct and argues persuasively that real regulatory attention must be directed at the developers behind these systems.
If a generative model creates chaos, the chaos did not spring into existence on its own. Someone funded it, designed it, tested it, scaled it, and launched it with great excitement.
This is where the concept of entity-based regulation earns its keep. The paper makes it clear that if policymakers want to manage risk effectively, they must begin with the legal persons responsible for these systems. These entities are the decision-makers.
They choose architectures, tweak capabilities, train for specific use cases, and control access.
Yet for some reason, current regulatory thinking often drifts into model-centric fantasy-treating models like they are independent actors (with personhood) with no attachment to corporate or institutional agendas.
The article draws attention to a critical gap: most frontier risks emerge not because a system exists, but because an organisation chose to release it, scale it, or plug it into sensitive infrastructures.
That is why the developer matters more than the tool.
A model is only as risky as the environment it is placed in, the safeguards it is given, and the incentives shaping its use. It is hard to understand any of that without looking directly at the organisation behind the system.
Rather than chasing technical definitions or trying to freeze progress at a particular parameter size, the paper calls for a clean pivot toward regulatory triggers that focus on the behaviour, size, and capacity of developers.
This makes practical sense. Regulators already have experience overseeing entities.
Financial regulators supervise banks. Media regulators oversee broadcasters. There is no reason AI developers should be viewed as an untouchable exception.
One especially important insight from the report is the proposal to use annual AI R&D spending as a threshold to define which developers fall under regulatory obligations.
This is clever. It provides a transparent, quantitative, and forward-looking way to distinguish serious developers from hobbyists.
If a company is spending hundreds of millions on AI development, it likely has the potential to cause harm at scale and should be subject to targeted rules.
This focus on entities also sidesteps some thorny implementation problems. Trying to regulate AI by its applications quickly turns into a labyrinth of sector-specific rules that confuse everyone and satisfy no one.
Targeting the developer allows for oversight that cuts across sectors.
Whether a company is building a system to generate text, run simulations, or assist with code, the entity’s overall practices and capacity for responsible design should be front and centre.
Of course, this does not mean regulators should ignore models entirely. Technical audits, evaluations, and reporting still matter.
But those tools must sit within a broader framework that treats organisations, not isolated pieces of software, as the unit of accountability.
As the paper notes, developers are best placed to assess risk because they possess the context, the design knowledge, and the operational discretion that third parties often lack.
In short, you regulate who builds the tool, not just what the tool does.
Frontier AI systems do not deploy themselves. They are the result of choices, and choices are made by organisations. Let us start the conversation there.
The Limits of Use-Based Rules
Use-based regulation sounds appealing in theory because it promises a world where rules follow the purpose, not the pipeline. Unfortunately, reality has been far less cooperative.
As highlighted in the article, attempts to regulate AI based on use cases have produced confusion, inconsistent outcomes, and a tendency toward rules that are either too broad or too vague.
One major issue is that use-based rules are difficult to apply consistently when AI systems are general-purpose.
A single model might be used for drafting emails on Monday, writing code on Tuesday, and managing energy grids by the weekend.
Trying to regulate each of these use cases individually requires a level of foresight and flexibility that most regulatory frameworks cannot support.
The article points out that this fragmented approach leaves significant gaps while simultaneously slowing down legitimate uses of the technology. It is regulatory multitasking at its least effective.
Another complication is that once a system is released, developers may no longer control how it is applied.
If a model fine-tuned for medical summarisation ends up assisting in military logistics, it becomes unclear who is responsible and under which regime.
Regulating based on use without a clear entity-based framework means accountability gets passed around like a hot potato, and very few are willing to catch it. This encourages overcompliance, underutilisation, or both.
The paper notes that some jurisdictions are already discovering these limits.
The EU’s AI Act, which leans heavily on risk-based use categories, has had to include new provisions to capture general-purpose systems because use-based categories failed to anticipate how broadly these systems would spread.
In contrast, a framework that identifies developers and sets obligations based on their capability and intent offers a cleaner way to manage risk at its source. 🎯
Instead of chasing every possible use case, the paper recommends a more grounded approach.
Focus on those building systems that are capable of high-impact uses, and hold them to account regardless of where their models end up.
Developers already know their systems can be used across sectors.
The governance regime should reflect that reality without trying to write a separate rulebook for every application scenario.
TL;DR: Research Spotlight
Frontier AI risks come from how systems are built and used, not just their technical features. Focusing only on model thresholds or compute misses wider concerns like reinforcement learning, post-deployment changes, and multi-agent behaviour.
Developers, not tools, should be the primary focus of regulation. Organisations building and deploying advanced systems have the knowledge, resources, and control to manage risks responsibly.
Use-based regulation creates vague, overlapping, and fragmented rules. General-purpose AI tools complicate enforcement, making it hard to define accountability or apply consistent safeguards.
Entity-based regulation recommends identifying covered developers by observable criteria like R&D spending, not just the models they produce. This method is more transparent, enforceable, and resistant to gaming.
Oversight should target high-risk capabilities and operations, like synthetic media generation or autonomous actions, and require structured disclosures, testing, and risk management plans.
This entity-based regulatory model builds on existing global practices and can complement technical standards. It shifts the focus from chasing AI outputs to governing the people and institutions who design and scale them.
That is it for this research spotlight. If you have thoughts on entity-based regulation or how frontier AI should be governed, we would love to hear from you.
Your feedback helps inform future newsletters and keeps the conversation grounded and relevant.
If we focus regulation on the biggest spenders in AI, how do we handle smaller developers whose tools end up causing significant harm later?