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

What are the layers of AI control?

Roughly four, from the bottom up: compute hardware, cloud access, model weights, and downstream applications. Each is regulated by someone, but how enforceable the rules are varies enormously, and policy debates often fail to say which layer they are about.

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

Above it is cloud access. The hardware stays at home while the user is abroad: nothing is exported, yet the capability is. Recent rules have therefore begun to treat who may log in as a matter for controls.

Above that are model weights, the trained parameters themselves. Weights are a file, and that fact alone makes controlling them fundamentally different from controlling the two layers below.

At the top are applications: who uses a model for what. This layer is closest to actual harm and the hardest to identify in advance, because 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 for those lines comes from even fewer suppliers; the further upstream you go, the easier control becomes.

Compute is also a textbook dual-use problem: the same accelerators may run drug design or military simulations, and nothing on the spec sheet tells the two apart. What is really being controlled, then, is not the chips but who may obtain them.

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

How are model weights fundamentally unlike chips?

Put simply, a chip that slips through can still be chased down; weights cannot. Physical goods still have a quantity and a location, and they depend on maintenance and spare parts, 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 puts the point of control almost entirely at the moment of release. Before release, the decision rests with the developer; after it, all that remains is restricting services, assigning liability, and monitoring use, and none of these can retrieve the file.

This is why the open-weights debate is not simply about whether openness is good. Openness brings auditability, independent research, and a more distributed set of suppliers, all of them real benefits; it is also the one choice that cannot be undone. Both sides are right. One is describing the gains, the other the lack of a way back.

A model served through an API, by contrast, preserves one thing: its use can be observed and stopped. Many regulatory frameworks therefore 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. The harm from most AI misuse accumulates: fraud, influence operations, and code vulnerabilities are problems of volume that can be corrected while they are being observed. Biological risk is different. A single success can cause harm that cannot be undone, so correcting course afterwards is not an option.

The other reason is that the barriers lie elsewhere. Causing real harm takes more than information; it also takes access to materials, laboratory equipment, and tacit skill. The most effective line of defence therefore often sits on the supply side rather than with the model: screening orders for synthetic DNA and RNA, for instance, or controlling access to laboratories. Model developers and the biotech supply chain have to do this work together; either one alone leaves a gap.

This also explains why rules in this area have moved faster than in other AI debates: there is an existing regime to build on. Biosecurity already has a control framework, so the new question is how to fit models into it, not how to build one from scratch.

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

Because these rules land on users, not only on developers. There is already a precedent for rules that cover who may access a model service, including foreign nationals inside the country. So the issue is not an AI company’s problem but an HR and compliance problem for any firm with a cross-border team that uses a cloud model.

The second reason is procurement. As the logic of economic security extends to AI, who built a model, where it runs, and where the data is kept may gradually become required fields in tender documents, much as security questionnaires did. Having your answers ready early costs far less than being caught without them.

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 bears on whether you can deploy on your own infrastructure at all. These get lumped together as “AI regulation”, yet they land on entirely different parts of an operation.