Engineered Regulation for AI Systems

In every industry where failure is consequential, we learned to engineer control into a system before we trusted it to run. With AI, we are skipping that step. The discipline we are missing has a name: engineered regulation.

Engineered Regulation for AI Systems

No one runs a refinery with a big red button and good intentions. Before the plant starts, engineers design the control loops that hold temperature and pressure where they belong. They add independent safety systems that take over when those loops fail. They run the analysis that shows, layer by layer, that the whole arrangement keeps the risk of a serious event below a defined limit. The emergency shutdown is the last line of defense, not the plan. If your safety case depends on someone hitting the button in time, you have already lost.

Every high-consequence industry works this way. Aviation defines a flight envelope and builds protection to keep the aircraft inside it. Nuclear power uses layers of protection that are deliberately independent, so that whatever defeats one layer cannot defeat the next. Pharmaceutical manufacturing builds quality into the process and establishes the range of conditions under which the product is known to be sound, instead of inspecting for defects at the end. Medical devices are verified and validated against their intended use before they reach a patient.

The common thread was learned the hard way, usually after an accident: you cannot bolt control onto a dangerous system afterward, and you cannot inspect safety into it. You engineer it in, and you produce the evidence that it holds - this is called systems integrity.

We are not doing this with AI.

We are connecting capable, fast, semi-autonomous systems to the software that runs our companies — the systems that move money, change records, send messages, and make decisions — and we are governing them with filters at the edges and a switch to turn them off. We have a growing stack of rules that say AI must be safe, fair, transparent, and accountable. What we do not have is the means to keep those promises while the system is running. We are deploying AI without the ability to regulate it, and calling the result innovation.

Two meanings of "regulate"

Part of the confusion comes from one word doing two jobs.

When most people hear "regulate AI," they picture governments writing rules — a new act, a sector standard, an agency. That is one meaning, and those rules matter. But there is another form of regulation, an engineering meaning. To regulate a system is to keep it operating between the lines, where it is supposed to be: to sense what it is doing, compare that against the goal, and correct the difference, continuously, fast enough to matter. A thermostat regulates temperature. A governor regulates an engine. A pilot and an autopilot together regulate a flight.

The world is busy producing the first kind of regulation and assuming it produces the second. It does not.

A law that says AI must be safe is not an AI that is being kept safe, moment to moment, by something built to keep it that way. Writing the rule and keeping the promise are different acts. Anyone who has worked in a regulated industry knows that a certificate on the wall is not the same as a system under control.

AI is about to relearn that lesson at speed.

You cannot control what you cannot match

There is a basic principle in cybernetics, the study of control, known as requisite variety: to control something, your means of control has to be at least as varied and as quick as the thing you are controlling. If the system can do a thousand things and your oversight can recognize ten of them, you are not in control of the other nine hundred and ninety.

This is exactly where AI agents put us. An agent's range of behavior — the model, the tools it can call, the situations it can wander into, the steps it can chain together — is enormous, and it acts at machine speed.

The oversight we wrap around it is narrow and runs at human speed. A person reviewing an agent's work afterward, or a dashboard someone checks each morning, cannot keep pace with a system taking hundreds of actions every second. The loop is open. We are not steering. We are watching, and often watching a recording.

Controls at the edges, no one at the wheel

Look closely at how AI is actually held in check today and you find two things: filters and fences.

There are filters that screen what goes into the model and what comes out. There are fences that limit what an agent is allowed to touch. Both are useful. Neither is regulation.

They sit at the boundary and inspect or block; nothing in them steers the system toward keeping a promise. And the favorite fallback, the kill switch, is the weakest possible answer dressed up as a strategy. By the time anyone detects that an autonomous agent has gone wrong, it has usually already acted, and many of its actions cannot be undone. Money has moved. Data has left. The message has been sent. You cannot un-ring that bell with a button.

The industry calls its approach "defense in depth," borrowing the language of nuclear and process safety. But to a safety engineer that phrase means something specific: layers that are independent, so that whatever defeats one does not defeat the others. The AI version fails that test. The model, the filter checking the model, and the second model watching the first are mostly the same kind of thing, with the same blind spots. An attack or a failure that slips past one tends to slip past all of them. Stacking layers that fail together is not depth. It is one layer wearing several hats.

Two more habits from the safety world are simply absent. We have no operating envelope for AI — no defined region of safe operations within which the system is known to behave, and no plan for what happens at the edge of it. And we have no honest accounting of how much risk each safeguard actually removes, because no one can put a credible number on a filter or a monitor. In a refinery, that accounting is required before you are allowed to operate. For AI, it does not exist.

How complex systems really fail

Decades of investigating accidents — in aviation, rail, oil and gas, and healthcare — taught us that large failures rarely come from one broken part. They come from the connections between the levels of an organization slowly pulling apart. The people setting direction lose touch with what is happening on the floor. Pressure to move faster and spend less nudges everyday practice a little closer to the edge. Nothing looks wrong on any given day, until an ordinary event meets a system that has quietly drifted into a dangerous place.

Now put an autonomous AI agent into that picture. It does not just do a task. It often acts and then reports on its own action, which means the people who are accountable are looking at a version of reality the agent produced. It can replace a layer of human judgment without anyone noticing what that layer was doing behind the scenes. It speeds up the drift and dims the feedback at the same time. The one thing we most need to see — the gap between what is supposed to happen and what is actually happening — is exactly the thing an unregulated agent hides.

Safety is built, not hoped for

You will sometimes hear that safety, or alignment, will "emerge" from a capable enough system. In engineering, that is not how it works. Safety does not appear on its own when the parts run together. It is a property of the whole system that has to be designed in and held in. You define what safe means for this system in this setting, you build it to produce that outcome, and you generate the evidence that it does. "Safe" is not a certificate you earn once. It is a promise you keep continuously, or it is not safety at all.

That is the point the current approach keeps dodging. Calling an AI safe because it passed a test last month is like calling a bridge safe because it stood up on opening day. The real question is whether it keeps standing, under load, over time — and whether you designed the bridge to carry the weight.

The discipline we are missing

None of this calls for a new theory. The hard parts are mostly solved, in pieces, by fields that have kept dangerous and complex systems under control for a long time. Control engineering knows how to close a loop and hold a system inside its limits. Process and functional safety know how to layer independent protection and prove it is enough. The organizational sciences know how to put accountability where it belongs and keep human judgment in the system. Compliance, done well, knows how to turn an obligation into a promise that the accountable party actually keeps.

What we have not done is bring these to bear on AI, deliberately and together. That is the work worth naming: engineered regulation — building AI we can keep between the lines, in the engineering sense of the word, instead of merely ruled in the legal one. It treats the safe, secure, and accountable operation of AI as an engineering problem with an evidence burden, not as a policy to be written or a box to be ticked.

In practice it means four things:

1. Build AI systems that can be regulated — that sense, compare, and correct toward the obligations they carry and the promises they need to keep.

2. Define the envelope they operate within and the independent layers that hold when something fails.

3. Bind every consequential action to a person who is accountable for it, with a view of what the system is really doing: intended and unintended.

4. And produce the evidence that the promises are being kept while the system runs, not once a year.

We expect exactly this of a pressure vessel, a drug, an aircraft, a trading system. We should expect it of the AI we are now handing real authority. Today we are building that AI without the capability to keep it under control, and assuming the control will sort itself out. In every other field, that assumption is how accidents are made.

The Path Forward

The encouraging part is that the organizations best placed to contend with AI are the ones already working in regulated, high-consequence environments. They have the engineering habits, the safety culture, and the accountability structures. The task in front of them is not to invent something new. It is to extend what they already know how to do to handle a new hazard— one that is fast, capable, and, for now, out of control.

The way forward is not a new science but an integrated one. The methods mostly exist, scattered across the fields that have spent decades keeping dangerous systems in hand: functional safety, which proves that protection layers are independent and sufficient; process safety and HAZOP, which find the deviations before they become disasters; control theory and cybernetics, which close the loop and hold a system inside its limits; and systems approaches like STAMP and STPA, which treat safety as a control problem across the whole organization, not a hunt for the one broken part.

Each was forged after hard lessons in its own domain. None of them, alone, is built for a hazard that is fast, capable, and semi-autonomous. Brought together — deliberately, as a single engineering discipline rather than a shelf of separate standards — they are. That is the work: not to wait for AI safety to be invented, but to integrate what we already know how to do, and aim it at the hazard now in front of us.

---

Raimund Laqua, P.Eng., is the founder and Chief Compliance Engineer of Lean Compliance. A licensed Professional Engineer, he helps organizations close the assurance gap at the centre of AI adoption — applying digital engineering and engineered regulation to build justified confidence that their AI systems will keep the promises they've made. Assurance is not inspected in after the fact; it is engineered in.

If your organization is putting AI to work in a high-consequence environment, let's talk.