IntermediateUpdated 2026/08/08

What Do AI Controls Actually Control — Chips, Models, or Uses?

All three, with very different odds. Chips are controllable because they are physical, cross a border, and come from few production lines. Model weights are files — once copied there is no second chance. Uses, for the most part, only become visible after the fact.

Read this first: Never Sold to America — So Why Do Export Controls Still Reach You?

All four layers are regulated — only one has irreversible mistakes

Layer	Which action it stops	Who can enforce it	If it leaks, can it be recovered?
Compute hardwareChips and fab equipment	Shipment and installation. Physical goods cross customs, and every batch has a quantity, a serial number, and a delivery address.	Customs and export authorities, plus the suppliers themselves — advanced-node chips come from very few lines, and the concentration rises upstream.	Yes. Goods that slip through still have a location and a count, and still depend on maintenance, firmware, and spares — there is leverage afterwards.
Cloud accessHardware at home, user abroad	Login and account provisioning. Nothing is exported; what leaves is the right to use.	The service provider, because only it can see who is using what. Enforcement lands on corporate identity verification and customer screening, not on a border.	Partly. Accounts can be closed and quotas withdrawn, but a training or inference run already completed cannot be undone — what stops is the future, not the past.
Model weightsThe trained parameters themselves	The moment of release. Before it the decision belongs to the developer; after it, it does not.	Effectively only the developer. Weights are a file; copying needs no licence, leaves no trace, and passes no authority.	No. The copies are unlimited, their locations unknown, and they need no further support to run. This is the one irreversible layer of the four.
Downstream applicationsWho uses a model for what	The use itself. But the same request in another context is a different act, which is hard to define in advance.	The sector regulators that already exist — financial, medical, electoral, biosecurity. This layer needs no new AI statute, because the conduct is already regulated.	Depends on the harm. Fraud and influence operations can be corrected while being observed; biological risk cannot — which is exactly why it is carved out.

Much of the AI control debate is four layers talking past one another. Laid out, the difference is not only difficulty: the enforcer changes, and so does the nature of a mistake. Hardware relies on customs and suppliers, services on a company’s own customer screening, applications on the sector regulators that already exist — and weights on almost nobody but the developer.

The right-hand column is the point, because it sets how careful the decision has to be beforehand. Reversible layers can be corrected in flight: a chip that slips through still has a location, a count, and a dependence on maintenance. Weights do not — once copied the copies are unlimited, unlocated, and self-sufficient. Which is why both sides of the open-weights argument are right: one is describing the gains in auditability and independent research, the other the absence of a way back.

Source: Impactful Creative, compiled from the four-layer logic described on this page and our coverage of AI national security rules and AI biosecurity governance

What are the layers of AI control?

Roughly four, bottom to top: compute hardware, cloud access, model weights, and downstream applications. Each is regulated by someone, but enforceability differs enormously — and policy debate often fails to say which layer it is about.

The bottom layer is chips and manufacturing equipment, and it fits traditional export controls perfectly: physical goods, crossing customs, from a supply base concentrated enough to track shipment by shipment.

Above it is cloud access. The hardware stays home while the user is abroad — nothing is exported, yet the capability is. Recent rules have therefore started treating who may log in as a control question.

Above that are model weights: the trained parameters themselves. Weights are a file, and that single fact makes their control logic fundamentally unlike the two layers below.

At the top are applications — who uses a model for what. This layer is closest to actual harm and hardest to identify in advance: the same request, in a different context, is a different act.

Why does regulation almost always start with compute?

Because it is the only layer with everything traditional control requires: the item can be defined, its movement observed, its origin traced. Advanced-node chips come from a handful of production lines, and the equipment that builds those lines from fewer suppliers still — controllability rises as you move upstream.

It is also a textbook dual-use problem: the same accelerators may run drug design or military simulation, and the spec sheet cannot tell them apart. So the control is not really on the chips but on who may obtain them.

The approach has a boundary, though. Controlling hardware controls the ability to train new models; it does nothing about models already trained — and those already exist as files. That is the key to the next question.

How are model weights fundamentally unlike chips?

In a sentence: a chip that slips through can still be chased; weights cannot. Physical goods retain a quantity, a location, and a dependence on maintenance and spares, so mistakes can be mitigated afterwards. Once weights are copied, the copies are unlimited, their locations unknown, and they need no further support to work.

That concentrates the control point almost entirely on the moment of release. Before release the decision belongs to the developer; after it, what remains is restricting services, assigning liability, and watching usage — none of which retrieves the file.

Which is why the open-weights argument is not simply “is openness good”. Openness brings auditability, independent research, and a more distributed set of supply options — all real benefits — and it is also the one choice that cannot be undone. Both sides are right; one is describing the gain and the other the absence of a way back.

A model served through an API keeps one thing by contrast: use can be observed, and it can be stopped. This is why many frameworks treat served models and released weights separately — the risks differ in kind, not in degree.

Why is biological risk so often carved out for separate treatment?

Because it is one of the few risks where once is enough. Most AI misuse accumulates — fraud, influence operations, and code vulnerabilities are problems of volume that can be corrected while being observed. Biological risk is not: a single success can be unrecoverable, so correcting afterwards is not available.

The other reason is that its gates are elsewhere. Causing real harm takes more than information — it takes material access, laboratory equipment, and tacit skill. So the effective line of defence often sits on the supply side rather than the model side: screening orders for synthesised sequences, controlling laboratory access. It is work model developers and the biotech supply chain have to do together; either alone leaves a gap.

It also explains why rules here have moved faster than in other AI debates: there is an existing regime to attach to. Biosecurity already has a control framework, and the new question is how to fit models into it rather than how to build one from nothing.

The line falls at release — every box after it is narrower

Before training: access to compute and dataEffective — and the broadest collateral
The only moment that can stop a model from existing, and where export controls actually operate. The cost is that it does not distinguish purpose: the same resources carry drug design, weather modelling, and every other kind of research — most of what is blocked is not the risk.
During training: evaluation and safety testingEffective — for risks already known
Measuring capability and failure modes while the model is still inside the development environment. The constraint here is not enforcement but imagination: what gets measured is what someone thought to measure, and unanticipated capability is exactly what matters most.
At release: served, or weights publishedThe last reversible decision
The two forms of release leave entirely different room afterwards. Served, use can be observed and stopped; weights published hands over every option at every later moment at once. This box is the line in the figure.
At use: access control and abuse detectionOnly exists for served models
Customer screening, rate limits, content policy, anomaly detection. All genuinely effective, and all resting on the premise that somebody is serving the model — a self-hosted copy sits outside every one of them.
After the fact: liability and disclosureWorks only where harm accumulates
Most misuse accumulates, so correcting afterwards still means something: fraud, influence operations, and code vulnerabilities are problems of volume. Biological risk is not — a single success can be unrecoverable, and for it this box effectively does not exist.

Effective, at an explicit costConditional — depends on how it was releasedAfter the fact only — useless against irreversible risk

The same layer is far more or less enforceable depending on when you act, so “which layer” is only half the question. The top two boxes work, at the cost of sweeping in legitimate use and of seeing only anticipated risks. The bottom two each carry a precondition: the tools available at use only exist for served models, and after-the-fact accountability only works where harm accumulates.

The middle box is the line, and the only truly irreversible decision point. It sets not just this release but how many options remain in the two boxes below — which is why many frameworks treat served models and published weights separately. Their risks differ in kind, not in degree.

Source: Impactful Creative, compiled from the intervention points described on this page and our coverage of AI national security rules and AI biosecurity governance

Why should this matter to people who do not build AI?

Because these rules land on use, not only on development. Regimes already exist that treat who may access a model service as in scope, including foreign nationals inside the country — which is not an AI company’s problem but an HR and compliance problem for any firm running a cross-border team on a cloud model.

The second reason is procurement. As the logic of economic security extends to AI, who built this model, where it runs, and where the data stays will become required fields in tender documents, much as security questionnaires did before. Knowing your own answers early is far cheaper than being asked cold.

The third is the most practical: which layer is regulated determines how you are affected. Hardware-layer controls hit cost and lead time; service-layer controls hit user lists and audit obligations; the weights argument decides whether you can deploy on your own infrastructure at all. These get compressed into the phrase “AI regulation”, and they land on entirely different parts of an operation.

Terms used here

Dual-use — Technology, products, or know-how with both civilian and military applications. Dual-use character complicates export control determinations: whether the same chip, algorithm, or drawing is controlled depends on end use and end user — neither of which is typically visible to the exporter. Compliance burden accordingly shifts from product classification to customer due diligence.
Export Controls — Legal instruments restricting the transfer of specified technology, products, or services to specified recipients on national security grounds. The defining feature of modern export controls is extraterritorial reach: if a product contains controlled technology, the rules may bind even when manufacture and sale occur entirely outside the controlling state. Control list updates therefore become compliance events that multinationals must track line by line, not a single-market regulatory matter.
Entity List — A roster of organizations that may not receive controlled technology or products without a licence. The effect extends well beyond those named: suppliers, seeking to avoid their own violations, routinely adopt internal standards stricter than the rule and cut off anyone with a plausible connection. This over-compliance makes the true blast radius of a listing impossible to infer from the legal text alone.
Economic Security — The policy turn that treats economic dependence as a security risk to be managed: supply of critical inputs, leakage of critical technology, and ownership of critical infrastructure all move from commercial questions to national security ones. The practical consequence is a transfer of decision rights — matters once settled by procurement and legal now pass through security review, with neither the timeline nor the veto in the company's hands.