SEARCH

For years I've watched the same thing happen across every regulated sector I've worked in. The obligations are documented. The controls are implemented. The audit gets passed. And still, when something goes wrong, you find that no one — not one identifiable person, not one accountable part of the organization — was holding the thing that failed. It's tempting to call this negligence: managers handing their responsibilities off to consultants, departments, and auditors. There is some truth to that. But the cause runs deeper, and it is structural. The obligations went unowned because the organization gave them away. It assigned them to a function — compliance — and a function cannot own an obligation it's not responsible to meet. The Structural Mistake Somewhere along the way, organizations decided that compliance obligations belong to the compliance department. The decision sounds reasonable. However, as it turns out, it is the source of the problem. The compliance function doesn't run the plant, treat the patient, write the code, approve the loan, or ship the product. It reports on whether those who do appear to be following the rules. But the obligation isn't met in the report. It's met in the work — in operations, on the line, in the decisions managers make every day. Put ownership of the obligation in a function that only observes the work, and you separate ownership from the place the obligation lives. That separation is the structural mistake. The people doing the work treat compliance as someone else's concern, because structurally it is. The compliance function documents and escalates, but it cannot make the obligation true. Custody Is Not Ownership This is the difference between custody and ownership. Custody asks: can I show the requirement was met? Ownership asks: do I have the capabilities to meet our commitments? The first is satisfied by evidence. The second is satisfied only by capability — a system that does what the obligation requires, under real conditions, whether or not anyone is auditing it that week. A compliance function can hold perfect custody. It cannot hold ownership, because ownership lives where the work lives. When the organization assigns obligations to compliance, what it creates is custody without ownership — a documented record that the requirement was addressed, sitting next to an operation where no one is accountable for the capability to meet it. You can have perfect custody and no ownership. Most organizations do. This is not a scandal. It is the predictable result of putting the obligation in the wrong place. Why Telling Managers to Own It Fails So the answer would seem obvious: tell the managers to take ownership. Push it back to the line. But you cannot fix a structural problem with an exhortation. Tell a line manager to own compliance and they hear "do more compliance tasks." Tasks are the only form of compliance the structure has ever shown them. The compliance function holds the obligation; the manager only ever receives fragments of it to carry out. So when you ask them to own the outcome, they hear more work, not more ownership. Owning the capability to meet an obligation is not in their vocabulary, because the structure was never built to put it there. This is not a motivation gap. It is a structural one. And it does not close because someone gave a speech about accountability. AI Exposes the Latency For many compliance programs, this misplaced ownership is a latent risk. The deficiency was always there. Nothing had triggered it yet. The procedure existed, the box was checked, and the gap between custody and capability sat dormant. It might surface years later. It might never surface at all. Organizations lived with it not because it was safe, but because the bill came due slowly, if at all. That is changing. In a growing number of domains, AI among them, an unowned obligation no longer waits to become a problem. The risk shows up earlier and it costs more. Organizations are routing their obligations — privacy, safety, quality, financial integrity, legal and ethical commitments — through AI systems that act faster than anyone can supervise. An AI cannot own any of them. It cannot accept responsibility when an obligation is unmet. It can generate the documentation, pass the check, and give you better custody than you have ever had. It cannot give you ownership. Deploying AI into an organization that already put ownership in the wrong place does not close the gap. It widens it, and faster. "The system didn't flag it" becomes the new "the auditor didn't catch it" — one more place to send accountability that belongs to those responsible for the work. The Shift That Matters Most The shift is not from reactive to proactive, or from manual to automated, or from one framework to a better one. It is structural: from compliance owning the obligations to the organization owning them. In practice, that means moving from compliance management to managed obligations. Today we manage the compliance function — the program, the reporting, the audit calendar. What needs managing is the obligation itself: the commitment the organization has made, managed by the person with managerial accountability for the work that meets it. The obligation moves from a function that reports on it to a manager who is answerable for it. Compliance does not disappear in this shift. It stops being the owner and becomes what it should always have been: the function that coordinates, assures, and holds the organization to what it has committed to. Not the place obligations go to be reported on. The function that makes sure the real owners are meeting them. Once obligations are managed by those accountable for the work, the operational questions can be answered — because only the owners can answer them. What did we commit to? What capability does meeting it require? Do we have it? None of these are answered by a function reporting from the side. They are answered where the obligation lives, by the manager accountable for meeting it. Until ownership moves, those questions have no one to answer them. This is the realization that changed our consulting practice. We began with operational compliance — making obligations work in operations rather than on paper. That was right, but it did not go far enough. Operations are where obligations are met, but they are not where obligations are owned. Ownership belongs to the organization: its leadership, its management, its accountable lines of work. So the practice had to align to that. We changed from operational compliance to organizational compliance, because that is where the obligations live. The obligations were always the organization's. The wrong structure just made it easy to forget.

Today many organizations use AI that is general. It was trained on the public record, not on any one sector or business. It does not know your mission, your values, your goals, your processes, your protocols, or your standard operating procedures. When you ask it a question, it answers from what is common across everyone, not from how that knowledge applies to the particulars of what you do. In a regulated, high-risk domain this is a problem. The general model gives you the most common answer, which may not be a standard, and is rarely yours. It reverts to common knowledge when common practice is the wrong practice for your plant, your patient, or your portfolio. And it does this without warning. It is as confident when it is guessing as when it is correct. An advisor that cannot tell you when to doubt it is not an advisor. The answer is not a smarter model. The answer is to govern the model with your knowledge. Curation of knowledge — including institutional knowledge — becomes an essential part of governing AI. This is not a new problem. The medical profession has already faced the challenge of using AI where a wrong answer carries real consequences, and what the medical community is doing transfers to any sector. What medicine did The clinical field did not build a model to replace doctors. According to a 2025 study in Bioengineering (Pingua et al.), trying to train medical knowledge directly into the AI worked worse than keeping that knowledge in a separate, trusted source the AI looks up when answering. The approach comes down to three things: keep the knowledge separate from the AI, organize it and rank it by authority, and ground every answer in it with a qualified person accountable for the decision. The model provides the reasoning. The organization provides the knowledge. Trust comes from keeping the intelligence under the organization's control, not the model's. Building the regulator Medicine showed three of these parts: keep the knowledge separate, rank it by authority, and put a qualified person in charge. An engineered regulator adds a fourth — a check that catches the model when it deviates from institutional knowledge — which is the part most deployments, medical ones included, still leave out. Together these form a structure that gives the model an authoritative reference to work from, checks its answers against that reference, and keeps a person accountable. The method does not depend on the industry, but the particulars will. Replace the medical content with your own and the structure applies — for engineering, finance, energy, aviation, pharmaceuticals, or government. A regulator has four parts. 1. The reference: your authoritative knowledge This is what the model must conform to — your specialized knowledge together with your obligations, values, and goals. It is the standard the advisor is measured against, so it has to be built deliberately. Set the order of authority first. Decide what the advisor is for, and which sources take precedence when they disagree: your current procedures and standards first, your approved records next, then sector guidance, then general knowledge last. This order is the governing rule. It stops general knowledge from overriding your specific obligations. Curate the knowledge, including institutional knowledge. Gather the authoritative material — mission, values, processes, procedures, standards, and the specialized knowledge of how the work is actually done — and tag each source with its authority, its owner, and its version. Do not dump documents into the system. Ungraded knowledge makes the advisor less reliable, not more. The curation is most of the work and most of the value. Tie the reference to your change process. Obligations, values, and goals change. When they do, the curated sources are updated through the same controlled process that governs every other change in the organization. This keeps the advisor current, and keeps the reference visible and owned rather than buried in the model. 2. The grounded model: answers drawn from the reference The model supplies the reasoning, but it must reason from your reference, not from the public average. Ground answers in your knowledge, not in the model. Have the advisor answer from the curated sources and cite them. Keep the knowledge external and current, never built into the model, where it would freeze and fall out of date. Adapt the model for communication, not for rules. Adjust it to use the terms and format of your field. The rules, limits, and procedures stay in the reference. If something would change tomorrow, it belongs in the reference, not the model. 3. The comparator: detecting deviation This is the part most systems leave out, and the part that makes a regulator a regulator. A comparator is simply a check that measures one thing against another. Here, the model's answer is compared against the reference to detect when it has deviated — substantively wrong against your knowledge, or in breach of an obligation. Check the output independently. The check cannot be the same model grading its own answer; it shares the same blind spots. Deviation is detected by a separate step — rules for the firm limits, comparison against the reference for everything else. Require citations, and make refusal the default. When there is no authoritative source for a question, the advisor says so. It does not improvise. A missing source is itself a signal that the answer is outside the reference. Calibrate, and keep it calibrated. Confirm that the advisor's confidence matches its actual reliability — certain where it is grounded in an authoritative source, hesitant or silent where it is reaching. Then maintain that match as the organization and the questions change. Validation is a gate you pass once. Calibration is a discipline you keep. 4. The accountable person A regulator needs an owner — in fact, two kinds. A qualified person owns every decision. The advisor advises. A competent person makes the call and is accountable for it. The model gets them to the right answer faster; it does not decide. A qualified person owns the reference. Someone must own what counts as authoritative knowledge and what counts as deviation, and keep it current as the organization changes. The reference does not maintain itself. Path forward A general AI cannot be trusted in a high-stakes domain because it is general. It does not know you, and it does not know when it is wrong relative to your situation. Closing that gap does not require a better model. It requires building a regulator around the one you have — an authoritative reference of your own knowledge, answers grounded in that reference, an independent check for deviation, and an accountable person who owns it. Start with the reference. The knowledge, the judgment, and the accountability are already yours; the work is making them explicit enough for the model to be measured against them. The model supplies general reasoning. The trust comes from the regulator you build around it.

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: Build AI systems that can be regulated — that sense, compare, and correct toward the obligations they carry and the promises they need to keep. Define the envelope they operate within and the independent layers that hold when something fails. 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. 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.

Compliance is now vulnerable. Every promise you've made — privacy, security, quality, financial integrity, legal adherence, ethical values — now runs through systems that are unreliable, uncertain, and unable to align with your mission. So ask the hard questions: Does your AI know your obligations, your values, your promises? Does it follow your processes, your standard operating procedures, your policies? Will it cost you your legal license — or your social license — to operate? Most organizations can't answer those questions. Their AI risk register looks like this 👇 — every line high probability, high severity, all red. They're obligation risks — the effect of AI uncertainty on commitments across every part of their organization. They've named the risk. However, they don't know how to make certain they'll meet their obligations and keep their promises. How will they give stakeholders the assurance that they can stay between the lines — or will AI cause them to drift from their mission? That's what AI assurance is for — engineered, operational guardrails that keep AI between the lines and your mission on track, part of the golden thread of assurance. If this describes your situation, let's talk.

There is a quiet assumption running underneath the loudest investment of our age, and Sunday is a good day to bring it into the light. We are building compute. Enormous, almost unimaginable quantities of it. We are miniaturizing computers at one end — fabricating features measured in handfuls of atoms — and scaling them up at the other into hyperscale clouds that span continents. The capital is real, the engineering is genuine, and the people doing it are among the most capable we have. I do not doubt any of that. What I have been turning over is a smaller, more stubborn question: Are we inventing, or are we accelerating? Some say we must build this capacity ahead of demand, the way the railways were laid before the freight existed, the way fibre was buried dark in 2000 and waited years for the traffic that finally lit it. There is wisdom in that. You cannot discover what you have no room to experiment in, and slack capacity is how an era leaves space for the unimagined. I accept the argument. And yet I notice what the capacity is being measured in. Tokens per second. GPU-hours. Throughput, utilization, cost per unit. These are the metrics of a mature commodity, not a young invention. We are provisioning ahead of a demand denominated entirely in the units of the world we already have. That is the first thing worth naming plainly. AI adoption is delivering efficiency, not innovation — and we have begun to mistake the one for the other. Adoption and innovation are not the same move. Adoption bolts the new capability onto the work we already do and makes it faster and cheaper. Innovation changes which things are possible at all. Almost everything the AI economy sells today is the first kind — summarize the document, draft the email, deflect the support ticket, take the cost out of a task we already knew how to do. That is efficiency, and efficiency is what you reach for when you have accepted the problem as given and are only negotiating its price. It is the safest possible use of a general-purpose technology, because the return is legible to a finance committee this quarter. It is also, almost by definition, not innovation. Innovation asks a different question: what was previously unsolvable — not merely expensive — that now becomes possible? What problem was on no one's roadmap until the capability arrived? The rule we forgot to change Eliyahu Goldratt gave us the clearest lens for seeing this clearly, and he gave it to us a generation ago. He argued that every new technology must answer four questions. What is its power? What limitation does it diminish? What rules did we adopt to live with that limitation, back when it was binding? And what rules should we use now that it no longer is? Everything hangs on his iron law: technology is necessary but not sufficient. A new technology delivers its benefit only if it diminishes a real limitation and we change the old rules that grew up around it. Install the technology, keep the rules, and you get nothing — or worse, you automate the constraint and call the automation progress. He wrote this, pointedly, about ERP — an industry that spent fortunes on infrastructure and reaped disappointment, because companies bought the new system and preserved their old rules. They paved the cow paths. Adoption, in other words, is precisely the act of keeping the rules — which is why adoption can only ever return efficiency. I have come to believe AI is having its ERP moment, now, at civilizational scale and three orders of magnitude more capital. We are installing extraordinary new technology on top of rules we have not stopped to question. And what are those rules? Every rule of the Information Age was a rule for accommodating a single limitation: the human being as the processor of last resort. Dashboards, reports, business intelligence, the whole apparatus of moving and shaping data into information — all of it exists because, at the end of every pipeline, a person had to read the output and decide. And to decide well, they needed one coherent picture — a single version of the truth. The truth, however, was scattered across systems and inconsistent with itself. So we built an architecture to manufacture coherence: extract the truth from where it lay, assemble it into one authoritative version, and bring it to the centre where a person could trust it and act on it. That is the rule. Assemble the truth and bring it to the centre, because a human must be able to act on one version of it. The doorman's fallacy From here, the conclusion looks obvious. It is also wrong. The tempting reading is simple: the human is the bottleneck, so remove the human. Take them out of the loop, out of the decision, out of the act — all of it slow, all of it friction, all of it in the way. Let intelligence reach the data directly, at speed and at scale, with the capacity to act. It sounds like the future. And it is, of course, the wrong conclusion to the wrong question — the doorman's fallacy wearing the language of intelligence. The fallacy, you will remember, is this: a shop sees a doorman and decides he merely opens doors — a function a sensor performs for a fraction of the cost. So they remove him. And they discover, too late, that the doorman was never only opening doors. He was greeting regulars by name, watching the street, turning away trouble, holding something the throughput metric could never see. Define a role by its most visible mechanical function, optimize that function away, and you destroy the invisible value you never knew you were buying. The human at the end of the Information Age pipeline was never only processing. They were judging what mattered. They held the intent the processing served. They were the accountable agent — the one who answered for the result. The Information Age had fused three things into a single human seat: intelligence, intent, and accountability. They lived together only because they had to. To apply judgment at the point of decision, a person also had to do the processing there, because only a person could do either. What AI actually diminishes is not the human. It is the necessity of that fusion. Processing no longer requires a person to be present. And the moment you see that, Goldratt's last question changes its answer entirely. The rule that must die is not "humans in the loop." It is the belief that the human in the loop was only a processor — that the seat held a function and nothing more. Take the processing away and what remains is not an empty chair. It is the part that was always the actual work: deciding what matters, holding the intent the work served, standing answerable for the result. The machine can take the processing. It cannot take that. And a corporation that reads the whole seat as overhead — that optimizes away the function and assumes the value came with it for free — has made the doorman's mistake with its own judgment. What efficiency cannot provide And here's the thing. Efficiency is something you can buy. Value is something you need to create. The capacity to act — the speed, the scale, the throughput — is a supply problem, and we are solving it magnificently with fabs and clouds. But the things that make an act worth doing were never in the supply. Intent. The judgment that weighs what matters against what merely counts. The answerability of someone who can be held to the result. None of these arrive with the compute. They were carried by the very person we were so eager to optimize away, and removing the person does not hand them to the machine. It simply leaves them behind. The machine inherits the doing and none of the answering. That is the danger I keep returning to. The efficient future, pursued without care, gives us systems that act at speed and scale with no one answerable for the acting — enormous capability in the service of no particular value, because value was the expensive, human, unmeasurable thing we had quietly decided we could do without. What we are really choosing Which brings me, on this Sunday, to the pivot underneath all of it. We are being asked, quietly and without a vote, to become technology-driven corporations rather than corporations driven by mission, values, and judgment. The shift is presented as inevitability — the technology is here, the capacity is built, adoption is the only rational response — and in that framing the corporation reorganizes itself around what the technology can do, rather than around what the institution is for. This is the doorman's fallacy raised to the level of the enterprise, and then to the level of the age. We mistake the door-opening for the doorman. We see in mission, values, and judgment a kind of friction — slow, expensive, human — and we imagine that removing the friction is the same as keeping the value. It is not. Mission is intent. Values are the standing promises an institution makes about what it will and will not do. Judgment is the moral agent exercising accountable choice. These are precisely the things that do not arrive free with the compute. They are the things being orphaned while we celebrate the buildout. So here is where the threads connect. The infrastructure is necessary and is not sufficient. The efficiency is real, and it is not innovation, and it is not value. And the corporation that lets the technology drive will have optimized everything it could measure and surrendered everything it could not — fast, scaled, capable, and answerable to no one for anything that matters. The technology cannot supply intent. It cannot hold a mission. It cannot bear accountability, because it cannot be answered to. Those remain, stubbornly and permanently, the work of moral agents — of people who decide what the whole apparatus is for and stand answerable for the answer. We can provision the substrate. We can buy capacity ahead of demand. What we cannot buy, ahead of demand or at any price, is the judgment that decides what the capacity is for. Technology is meant to serve the mission — to help an enterprise do what it exists to do, and become what it is trying to become. The danger of this moment is the inversion: the mission quietly bending to serve the technology instead, until the enterprise organizes itself around what the tools can do rather than what it is for. And for most enterprises, what AI adoption actually delivers is narrower than the promise — the same things done faster, the familiar work made cheaper. It does not, on its own, invent what did not exist, imagine a different way of working, or transform a business into something new. Those are acts of mission, not of adoption. Adoption with no mission to serve only carries the enterprise faster toward wherever it was already heading. Necessary, but not sufficient. The sufficient part — knowing what it is all for, and answering for it — was never going to come from the machine. It comes from us, or it comes from nowhere.

We have been here before. In the enterprise, there have always been two kinds of searches. The first looks for the exact answer you get from a query (deterministic). The second looks for the closest answer you can find through full-text search (probabilistic). We knew the difference, and we learned how to use each kind. Full-text search gave us the approximate answers. It returned a ranked list of the most relevant results — useful when you are browsing, less so when you need the emergency shutdown procedure. But it presented its results as what they were: ranked, approximate, and left to your judgment. AI does not. It returns its most probable answer as though it were the answer, with no ranking and no indication of confidence. Some of what it returns is accurate, some is close, and some is invented outright — presented together, with nothing to tell them apart. And AI doesn't tell you which is which. Ask for the emergency shutdown procedure and there is a correct answer and an incorrect one. The procedure AI returns may be close to the one you need, or synthetic — created in real time. Either way it is presented with the same confidence, and the two are difficult to tell apart. However, using the wrong procedure may result in serious consequences. For AI to be reliable in the enterprise, it has to do what full-text search never had to: handle both kinds of answers at once. It has to draw the exact answer from structured records and the approximate one from documents, and distinguish between them — returning facts as facts and estimates as estimates. That is the difficult part. It is doable. However, it is not yet being done.

Just because AI may not yet be regulated does not mean compliance should sit on the sidelines. Compliance has always struggled to know how it creates and preserves value. AI now presents both the opportunity and the necessity to do so. Here is why. Organizations everywhere are adopting AI. Many are slowly realizing that adoption is not the objective: AI must create value. But this prompts a question few are asking. Not what value is AI creating, but what value is it losing? This is where compliance comes in. The losses fall squarely within our concern, and we should be the first to see them coming. What we mean by Value Most organizations measure value as margin: revenue, cost, productivity, output. That is shareholder value, and it is real. But it is not the whole of what an organization creates, nor the whole of what its stakeholders depend on. Stakeholder Value is everything an organization delivers to all of its stakeholders: quality, safety, security, sustainability, integrity, reputation, and ultimately trust. This is what we call Total Value. Customers, employees, regulators, and communities extend their trust because the organization makes commitments and keeps them. Stakeholder Value is, in essence, the measure of promises kept. Organizations create this value through two kinds of work. Productivity work creates margin. Certainty work keeps promises: the programs and functions that manage risk, meet obligations, and protect the opportunity to succeed. Both are essential to mission success. The difficulty is that only one of these is measured well. Margin appears on every dashboard. Promises kept appear on almost none. When an organization can see only half of the value it creates, it can destroy the other half without noticing. I believe AI is now being used in ways that do exactly that. The doorman fallacy Rory Sutherland describes what he calls the doorman fallacy. A hotel defines the doorman's job as opening doors. An automatic door opens doors better and at lower cost, so the doorman is eliminated. Only afterwards does the hotel discover what the doorman actually did. He provided security, hailed taxis, remembered guests, and signaled something about the establishment itself. None of this was in the job description, so none of it was considered when the job was automated. The hotel saved a salary and lost a function. The fallacy is this: define a role by its measurable tasks, automate the tasks, and unintentionally eliminate everything else the role was doing. We are now committing this fallacy at enterprise scale, and the roles being reduced to task lists are precisely the ones that create the certainty half of Stakeholder Value. What goes into the job description, and what does not Before a role can be delegated to AI, it must first be written down. The job description captures what is legible: the tasks, the outputs, the artifacts. A safety manager's role becomes: conduct risk assessments, track corrective actions, deliver training, file reports. A compliance officer's role becomes: monitor obligations, map controls, collect evidence, produce attestations. A manager's role becomes: allocate resources, track indicators, review performance. Each of these task lists is automatable, and each is being automated now. What never makes it into the job description is harder to name but no less real. The walk through the plant where something does not look right. The credibility that leads an operator to admit a near-miss. The authority to stop a job that no one else would stop. The judgment that a transaction is technically clean and still should not proceed. The accountability that cannot be transferred to something that cannot be held to account. These roles were never task lists. They were regulatory functions, the means by which the organization kept its promises. The tasks were how the function was performed, not what the function was. When the tasks are automated, the function does not transfer. It should remain, because the organization still needs it, but it does not. It is eliminated. Losses that book as gains What makes this more serious than the hotel's mistake is that AI performs the legible portion of these roles better than the people did. More assessments are completed, obligations are tracked faster, and the documentation is impeccable. Every indicator suggests the function is improving at the very time it is being hollowed out. These are Stakeholder Value losses that book as gains. The margin gains are real and immediate. The risk & compliance losses are equally real but deferred, and our accounting captures the first while remaining blind to the second, because promises kept were never on a balance sheet. The doorman's salary was a line item. What the doorman did was not. However, there is a second mechanism that compounds the first. The capabilities that never made it into the job description were developed by doing the work that did. The engineer who reviews a thousand routine calculations develops the judgment that catches the one that matters. When the routine work is delegated, the apprenticeship is deleted along with the job. The first generation after delegation still includes people who understand what the role really was. The second generation will not. We are likely to discover the truth of the doorman fallacy at the point when no one remains who can name what was lost in the first place. When the promises come due An organization can perform every task and keep none of its promises. This is the known failure of procedural compliance, conformance to procedures without the capability to be effective, and it is the very problem operational compliance exists to address. AI does not resolve this failure; it accelerates it, performing the procedures flawlessly while whatever capability stood behind them is eliminated. That is how AI destroys Stakeholder Value: the gains show up on every dashboard, the losses show up nowhere, and obligations go unmet until a failure no indicator predicted. The Grenfell Tower fire showed us how such losses are discovered — at the event, when it becomes clear that no one was performing the part of the process that was never written down. The fallacy is avoidable The doorman fallacy is a fallacy, not a fate. It is, at its root, an error in application: the job description specified the tasks and missed the function. But the failure that allows this error lies in governance and leadership, and that is also where the solution lies. Much is said today about AI governance. Frameworks are published, committees are formed, policies are written, and its parts are described in detail. Yet describing the parts of governance is not governing. To govern is to steer — to set the direction of the organization, decide what must be protected while pursuing that direction, and intervene when the organization drifts. Leaders who are steering do not automate away the functions that keep their promises, because they know what those functions are and why they exist. The fallacy occurs when delegation proceeds from a description of tasks. It is avoided when delegation proceeds from a definition of function, and that definition is a leadership responsibility. Before automating a role, leaders should be able to answer: What is this role for? What promises does it keep? What must remain true after the automation? Who remains answerable, and with what authority and what information? The hotel never asked what the doorman was for. It asked what he did. Leaders who ask the first question will still delegate tasks to AI, but they will deliberately preserve the functions that keep their promises: lodged in accountable people, supported by machines, designed rather than assumed. Compliance must not sit on the sidelines This is also a call to the compliance profession. Organizational obligations were never limited to what regulators require; they include every promise the organization has made to its stakeholders. Those promises are at risk now, not when the regulations arrive. Compliance, safety, and quality professionals are the people who know what these roles actually do. We know what the doorman was doing. That knowledge carries a responsibility: when AI adoption reduces these roles to task lists, we are the ones who must speak up. Waiting for regulation is itself a form of the fallacy — defining our own role by its prescribed tasks and missing its function. AI will not be the end of Stakeholder Value. Ungoverned delegation will be, one reduced role at a time, with every indicator favourable until the promises come due. Describing AI governance is necessary, but it is not sufficient. The work ahead is to practise it: to steer, and to define what the doorman was doing before automating the opening of the door. And this steering needs to include the function of risk & compliance. If your organization is adopting AI and you want to steer that adoption — so that you continue to meet your obligations and keep your promises — reach out to us at Lean Compliance. This is the work we do.

The regulatory landscape has changed, as I have been writing about for almost a decade. For a long time, compliance asked one thing of an organization: that procedures were in place, and that there was evidence they had been followed. That's procedural compliance, and it's well served. A certificate or an audit gives you exactly that — confirmation of procedural integrity. It's useful, honest work, and it isn't going away. But increasingly, boards, stakeholders and regulators want more. They want to know that obligations are being met continuously, reliably, and with assurance — not only that procedures exist, but that the organization has the capabilities and capacity to keep its promises. That is what is called operational compliance. While we can certify for procedural compliance, up until now we have not had something similar for operational compliance. That gap is what I've been working on, and it's why we developed the Golden Thread of Assurance. The idea is straightforward: trace an unbroken line from the obligations that organizations own, through the promises that put capabilities into practice, to the evidence those promises are being kept — and keep that line unbroken as things change, so that nothing falls through the cracks. What it gives you is confidence not merely that a program functions — that its parts are in place and operating — but that it is effective: that your program is capable of delivering the benefits of compliance. The Record of Assurance is the "certificate" of verified assurance capabilities — assurance that is engineered: designed in on purpose, not assumed or asserted. Where a conformance certificate confirms your procedures, the Record of Assurance confirms your capacity to continuously meet your obligations — not something you display, but capability you can trust. None of this replaces procedural certification. It adds what was missing. Procedural compliance has long had its certificate; operational compliance now has something of its own. If program assurance matters to your mission success, start with a Golden Thread Diagnostic: a fixed-scope assessment of one program — in safety, security, quality, environmental, or AI governance that has to be trusted — against the six properties of the Golden Thread of Assurance. It identifies where each property is met, where the gaps are, and the roadmap to a Record of Assurance. Message us to scope one

When we use AI in its most common form, we come to realize something about it. The large language models (LLMs) behind it have been trained on public knowledge, not on the knowledge your organization, business, or institution owns. We can provide a model with our documents to process, but this does not change the model. It does not learn that way. The exchange is one-directional in a way that is easy to miss. The model answers our prompts and forgets us, but the data we send does not simply disappear. It is used. Not to make the model better understand our business, but for something else entirely. That something else is the point of this article. The drive for AGI What is happening right now is a drive toward artificial general intelligence, or AGI. This is not a backdrop to AI development. It is its organizing goal. The work is to make intelligence broader, more general, and more capable, and every major provider is steering toward it. However, that drive has hit a wall. The large language models have been trained on very nearly everything humanity has written down, and the supply of fresh, human-generated public text is all but exhausted. To keep expanding a general intelligence, the frontier model providers need a new source. This source contains the knowledge that was never public in the first place, the knowledge held privately inside organizations: institutional knowledge. This is why your data is wanted, and it is worth being exact about the purpose. Institutional knowledge is being harvested not to make any particular organization more capable, but to advance the general project. It is wanted precisely because it is what the general intelligence lacks. Fed into the general model, an organization's distinctive, hard-won knowledge becomes the material from which the next general intelligence is built, and then sold back to everyone, including you. AI development has run out of public knowledge. The knowledge it needs next is yours. This puts a question to every organization that it has not been asked to consider. Are you adding AI to your intelligence, or adding your intelligence to theirs? The tale of two intelligences To answer it, we have to be clear about what intelligence is. Intelligence is not a thing one possesses. It is the capacity to apply knowledge to a situation in order to decide how to act, and it does not exist apart from that application. Knowledge must be applied before it can be considered as intelligence. Every organization is already an intelligence by this measure. In many ways it is the first artificial intelligence that humans created. An organization applies what it knows to the situations it faces, decides, acts, and answers for the result. This intelligence is built from the organization's values, its accumulated knowledge and experience, and the aggregated judgment of the people who work within it. That applied knowledge is its substance, and it is exactly what the general models now want. Call it institutional intelligence. Artificial intelligence in the form of large language models is a general intelligence in name, but by this measure it is not yet intelligent at all. It is trained on the world's public knowledge, built to serve everyone, and committed to no organization's ends. It knows nothing of your business, your history, or your way of working. An LLM treats your knowledge as data to be processed and acquired. It is capability waiting to be applied, and it becomes intelligence only when it is brought to bear on a real situation that someone must act in and answer for. The intelligence that matters does not live in the model. It lives wherever and whenever the model is applied. So which of the two intelligences is the relevant one for your organization? The general intelligence knows a great deal in general and nothing about you. The institutional intelligence is the only one that knows your situation, carries your constraints, and has to answer for what it decides. For your organization, the relevant intelligence is your own. The model can inform it, but it should not replace it. Science versus engineering There is an older distinction that is helpful for understanding what is going on right now. It is the difference between the scientific method and the engineering method. Science expands what we know. Engineering applies it. Neither discipline outranks the other, but they are not the same work, and they do not answer for the same things. Science produces knowledge for everyone and is accountable to no particular outcome. Engineering takes that knowledge, applies it to a particular problem under particular constraints, and answers for whether the result stands or fails. The drive for AGI is following the scientific method. It expands a general intelligence, and it is a legitimate and powerful enterprise. But it is not the work of any single organization, and its benefit does not accrue to any single organization. Feeding it your knowledge is participating in someone else's science research and experimentation. The work that matters for an organization follows the engineering method, applying knowledge to achieve a particular end or objective. When it comes to AI engineering, the task is to take the general capability and apply it to your own mission, your own constraints, and your own ends, and to answer for the result. The textbook contains the knowledge. The engineer applies it, and answers for whether the bridge stands. The drive for AGI follows the scientific method. Applying it to your business follows the engineering method. This engineering cannot be left to the AGI provider. The frontier provider builds the science, the general model. Applying it is a different discipline, and it belongs to the party that has the particular knowledge, carries the constraints, and answers for the outcome. The frontier provider has none of these, and its interest runs the other way. It gains when your knowledge is taken up into the general model, not when that knowledge stays applied to your mission alone. Waiting for frontier model providers to deliver applied AI is to ask the science to do the engineering, and to ask the party that profits from your knowledge to act against its own interest. The work is the organization's, because the stake is the organization's. One could also object that the frontier providers are doing both, science and engineering. It is true that they engineer, and heavily. But their engineering serves their mission, which is to advance the general intelligence, not yours. Engineering always answers to whoever holds the stake, and for the frontier provider that party is never you. There are two engineering efforts here, pointed at two different ends, and only one of them is pointed at your mission. AI adoption versus applied AI AI adoption is the use of the general intelligence as it is delivered. The organization brings its prompts, its documents, and its way of working to a general model, and in doing so it adds its intelligence to the model's. No engineering is done, the beneficiary is the AGI provider, and the knowledge flows toward AGI. This is the default, the thing that happens when nothing further is done. There is a second cost, quieter than the first. As an organization leans on the general model, it begins to adapt itself to the model rather than the other way around. Its people defer to the general answer, and its own judgment, the particular way it knows and decides, falls out of use. Adoption depletes institutional intelligence twice over. It feeds the general intelligence, and it lets the institutional one wither from disuse. The organization drifts toward AGI and away from itself. Applied AI is the engineering of that general capability into the organization. The model is applied to the organization's own mission, under its own judgment, toward its own ends. The knowledge stays where it belongs and is put to work there. The engineering is done, the beneficiary is the organization, and the intelligence that results is its own. This does not happen on its own. It is work, and it is the work most organizations have not yet done. It is also more than pointing a general model at a problem. For AI to be applied, the model has to be operationalized and contextualized within the business: brought into its work, its decisions, and its constraints, and made to operate there. At present this rarely happens. A general model, used as delivered, processes information about the organization without ever coming to know it. It reads what is put in front of it and keeps nothing. A model that knows you is one that has been shaped by your institutional knowledge and carries it. The end of applied AI is a model of your own, one that knows you, not a general one that processes information about you. A model that processes information about you is not a model that knows you. Most organizations believe they have applied AI. Most have only adopted it. Engineer your own intelligence The choice in front of every organization is this. You can adopt AI and let your knowledge feed a general intelligence that serves mostly the AI provider, or you can apply AI and build an intelligence that is your own. The first looks like the easier path, but it is not a free one. You pay for it, you supply the knowledge that makes it worth more, and the intelligence it builds belongs to someone else. The second is work. It is the engineering of a general capability into your mission, your constraints, and your ends, until what you have is not a borrowed model but an intelligence that knows you and answers to you. That work will not be done for you by the AGI providers, whose interest runs the other way, and it will not happen on its own. It is yours to do, because the intelligence it builds is yours to keep.

Raimund Laqua, P.Eng., PMP We need to talk about the collapse of governance and management. Much of what gets written these days about governance is really management wearing governance clothing. Frameworks, control libraries, risk registers, maturity models, oversight committees — all of it operates on the parts of a system. None of it sets direction or steers toward mission outcomes. We kept the word governance and filled it with the work of the layer below. Nowhere is this clearer than in AI adoption. We are not governing AI. And to be honest, we are not managing it either. It isn't only that we lack the accountability structures — though we do. We also lack the operational functions that provide the means of regulation across the organization. We don't have managing directors using programs to regulate systems. We don't have managers using management systems to regulate processes. The machinery that would keep an organization on course was never built, or was dismantled, and what replaced it doesn't regulate anything. The deeper problem is that most people no longer know what it means to regulate. Not regulation in the sense of rules and regulators — regulation in the sense of a regulator: sensing where you are and correcting the drift, but also anticipating what is coming and directing toward where you mean to be. That is what every layer of an organization is supposed to do for the layer beneath it. It is how an organization stays between the lines, ahead of risk, and on mission. Few understand why self-regulation is needed at all, let alone how to build it. And so many are finding they are unable to bridge the gap between organizational ends and operational means. The direction sits at the top. The work happens at the bottom. Between them, where the regulating should be, there is nothing. It is now all reduced to declared intent at the top, and reported activity at the bottom. Both are operating as open loops hoping that the business might survive. This was sustainable for a while, because the organization still ran on residual institutional knowledge — people who had learned to regulate when the function was still real, and who kept things on course out of habit and judgment even after the structure that taught them was gone. But this knowledge is a depleting reserve. It is not being replenished, This leads to where we are today. We are handing the work to AI agents that have no sense of where the organization is going — agents that do exactly what the collapsed organization trained everyone to do: go here, then move there, at machine speed and at scale. You cannot regulate an agent like that with oversight that only watches and a gate that only blocks. And the people who were holding the organization on course are being automated out of the very positions where that judgment lived. The reserve is draining at the same moment the demand for regulation is rising. We have turned organizations into action processing machines without regulation at accelerating speeds towards an end that no one knows. This is the problem our Organizational Regulation Model was built to address: bringing regulation back into the organization, deliberately, at every level. Not more oversight. Not thicker policy. Regulation in the sense of a regulator — the means by which an organization governs across every layer. Managing directors regulating systems through programs. Managers regulating processes through management systems. Each layer keeping the one below it true to where the organization as a whole is trying to go. It is how an organization becomes able, once again, to stay between the lines, ahead of risk, and on mission — to close the gap between what it intends and what it does. We had this once. We let it collapse. And we could not have chosen a worse moment to do it. Rebuilding it is no longer a choice — it is necessary. Raimund Laqua, P.Eng., PMP, is the founder of Lean Compliance, helping organizations operationalize governance through the Organizational Regulation Model. Learn more at leancompliance.ca.

That's the line being sold to executives right now — wrapped in maturity models, readiness assessments, and seven-dimension frameworks. And it's patently false. This is an old argument dressed up in AI clothing. When a technology fails to deliver, blame the organization for not being ready to receive it: Your workflows are too fragmented Your processes are too manual Your processes lack ownership Your data isn't clean enough Your business has too many regulations Of course existing systems aren't ready for AI. They weren't designed for AI. They were designed for humans. And there’s the rub. Decades of institutional knowledge are embedded in current workflows, processes, applications, and systems. That knowledge is what keeps organizations running, customers served, and obligations met. It is governed by compliance programs, audited, and held to standards of care. AI enters this environment with none of that. It carries no institutional knowledge. It was not built to the same standards of care. It is not designed to follow existing policies. It is not designed to keep promises. It is an uncontrolled system — and when introduced into a regulated environment, it becomes an organizational hazard. AI hasn’t earned the trust that organizational systems took decades to build, and that leaders rightly expect from any technology they deploy. But instead of acknowledging that AI isn't ready, it's easier to say you are the one at fault. You need to lead more. You need to start using AI more. You don't want to be left behind. And if AI isn't working — don't blame the technology. The problem is with you. It's time for AI providers to earn the trust they are asking decision-makers to give. AI needs to become ready for use — and that’s on the AI provider.

Compliance investment has been climbing for decades. Effectiveness has not. The difference is rarely effort or budget. It is whether the program is built to deliver outcomes or built to create reports and pass audits. Compliance 1 (Procedural) is adherence and conformance oriented. Reactive. Internal controls — managerial, procedural, attestation-based. Compliance 2 (Operational) is performance and outcome oriented. Proactive. System controls — engineered into the work, instrumented, outcome-bearing. Where each domain stands today: 💚 C2 — Total Quality Management. TQM, Six Sigma, statistical process control. Engineered into how work is done. 🧡 C2 / C1 — Process and functional safety. Hazard analysis, layered protection, stated integrity, continuous instrumentation, independent verification. The reference discipline every other domain is reaching toward. 💛 C1 / C2 — Occupational safety. Operational controls in some applications, procedural in most. 💛 C1 / C2 — Cybersecurity. Components present but no integrating discipline. 💛 C1 / C2 — Enterprise and operational risk. Internal control frameworks, pockets of Compliance 2 in specialized fields. 💛 C1 / C2 — Quality management systems. Document control, internal audits, management reviews. ❤️ C1 — Finance (integrity, anti-money-laundering, fraud, anti-bribery, sanctions). Operational capability present, legal architecture pulls against it. ❤️ C1 — Environmental compliance. Permits, reporting, attestation-based. ❤️ C1 — AI safety and Responsible AI in practice. Policy frameworks, review processes, attestations. The integrating Compliance 2 discipline does not yet exist. ❤️ C1 — Data privacy. Procedural, attestation-based, breach-reporting-driven. ❤️ C1 — Sustainability disclosure. A disclosure regime, not an operational one. These placements describe typical practice. Any of these domains can be — and in some organizations is — managed through a Compliance 1 lens regardless of where its discipline could take it. Different compliance domains, different lineage, different maturities. From Compliance 1 to Compliance 2. From producing reports to delivering outcomes. Compliance doesn't just report what's there. It creates what's not there: safety, security, sustainability, quality, responsible AI, legal adherence, and more.