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.

Cancer isn't an invader. It's our own cells, multiplying without restraint, ignoring the signals that tell healthy tissue when to stop, when to differentiate, when to die. It drifts from the body's purpose while consuming the body's resources. This is starting to look like how AI behaves inside our organizations. It over-constructs. Every problem becomes a reason for another model, another agent, another pipeline, multiplying without a purpose to serve. It outpaces our ability to stay grounded. Output rises faster than our capacity to verify it, and uncertainty grows with it. Will we keep our identity, or will overproduction overtake us before we can tell what's true, what's useful, and what was actually promised? It ignores stop signals. Healthy systems have feedback loops, what biology calls apoptosis. Most AI deployments have no equivalent: no clear conditions under which a model is retired, rolled back, or refused. And it consumes without contributing. Compute, attention, trust, and capital flow in. What flows out is too often unverified, unaccountable, and uncommitted to any specific outcome. The treatment isn't more guardrails or another policy. It's requisite governance, the cybernetic principle that a system's controls must match the variety of what it's trying to regulate. In practice, that means three things: Promises before pipelines. No pipeline without a promise it is accountable to keep. Operability before optionality. No new capability without the means to observe, intervene, and stop it. Regulation before scale. Scale amplifies behaviour — including behaviour that was never regulated. Compliance, properly understood, is the immune system of the enterprise. Not paperwork. Not after-the-fact audit. A living capability that recognizes drift, contains it, and restores alignment with purpose. AI without this isn't intelligence. It's uncontrolled mimicry wearing the face of intelligence.

The discipline inherited its working model from financial audit, never matured past the prescriptive rule, and now asks its management systems to govern something that was never engineered. The breaches we keep being surprised by are the consequence. There is a quiet contradiction at the centre of modern cybersecurity. Organizations score well on framework after framework. Their controls operate as designed. Their audit reports come back clean. Their ISO 27001 information security management system (ISMS) is certified. And then they get breached — sometimes catastrophically, often through pathways their control catalogues said were covered. The standard explanations point at risk sophistication, talent shortages, or budget. None of these reach the actual cause. The primary reason security doesn't deliver is structural resulting from the legacy of how the discipline was built. The Audit Inheritance The audit-and-controls tradition grew up around financial reporting. Its purpose was external assurance, and its mechanism was a defined set of controls (reconciliations, approvals, segregations of duty), executed against transactional data, tested by independent auditors, and reported through a standardized opinion. In that domain, the model worked. Controls operated on the same data the outcome was measured against. "The control operated effectively" and "the outcome was achieved" were tightly coupled. In the 1990s, the same logic was extended to information technology. ISACA built CISA around the auditor's view of IT. COBIT formalized control objectives. When information security needed an assurance vocabulary in the early 2000s, it borrowed the one already in use. SOC 2 extended into security. ISO 27001 framed information security as a management system audited against documented controls. NIST publications enumerated controls and assessment procedures. CIS produced a prioritized catalogue. The frameworks travelled, the certifications travelled — CISSP, CISA, CISM became the credentials of the profession, all of them oriented toward audit and management. What did not travel was the coupling between control and outcome that made the audit model work in finance. A financial control operates on the ledger; the ledger is the outcome. A cybersecurity control operates on a digital system being actively probed by adaptive adversaries, embedded in an environment that changes daily, and connected to consequences that emerge from interactions across the enterprise. "The control operated as designed" no longer implies "the outcome was achieved." The language continued to suggest it did. The profession was built on a model designed for transactional assurance and applied to a domain that requires regulatory engineering. Arrested at the Prescriptive Rule The clearest sign of the inheritance is that cybersecurity has never matured past prescriptive regulation. Prescriptive regulation specifies what to do — do this, maintain that, implement these. Performance-based regulation specifies what outcome to achieve and leaves the means to the regulated party. Risk-based regulation requires the regulated party to design regulation proportionate to its actual risks and demonstrate adequacy. Outcome-based regulation holds the regulated party accountable for the goal itself. The CIS Controls are prescriptive: establish and maintain the secure configuration of enterprise assets and software. NIST 800-53 is prescriptive. ISO 27002 is prescriptive. PCI DSS is prescriptive. The maturity discussions — IG1 to IG3, managed to optimized — are about how thoroughly the prescribed things get done, not about whether the controls work together to deliver requisite security — the actual outcome the business depends on. Other safety-critical disciplines moved off pure prescription decades ago. Process safety matured from boiler codes and electrical codes into functional safety. Aviation moved from prescriptive airworthiness to performance-based navigation and safety management systems. Each of these disciplines was forced to grow up by the inadequacy of prescription against systems too complex, dynamic, and consequential for recipe-following. Cybersecurity is now in exactly that position and has not made the journey. The audit legacy is why — audit verifies prescription well and verifies almost nothing else well. The Missing System The deeper consequence is that the discipline never built the system that should be doing the regulating. Cybersecurity has the parts — SOCs, EDRs, SIEMs, identity management, firewalls, vulnerability scanners, incident response teams, analysts, procedures, policies. It has frameworks that catalogue these parts. It has audits that verify the parts were procured, staffed, and are being maintained. What it does not have is an engineered security system — an integrated arrangement of people, process, and technology, designed and integrity-rated, whose function is to keep the business and operations within a defined secure envelope. The parts exist. The system does not. There is no integrated design basis that spans the human, procedural, and technical layers together. There are no integrity ratings on end-to-end security functions that include the people performing them and the processes governing them. There is no equivalent of a SIL-3 detection function or a SIL-2 containment function — where the rating covers the detection technology, the analyst competency, the response procedure, and the management arrangements as a single engineered whole. The components are procured separately, staffed separately, trained separately, operated separately, measured separately, audited separately. They are an inventory, not a system. The ISMS Confusion The most consequential confusion in the discipline is the assumption that an ISMS is the security system. It is not. An ISMS is a management system. It manages the activities of doing security — the policies, responsibilities, planning, resourcing, documentation, review cycles, corrective actions, continual improvement. ISO 27001 is explicit about this: it describes how to manage an organization's approach to information security. The artifacts are management artifacts — a Statement of Applicability, a risk treatment plan, internal audits, management reviews. What the standard does not describe, and what no ISMS standard describes, is the engineered system that actually delivers security. The functional safety parallel makes the gap obvious. A process plant has two distinct systems: a safety management system (ISO 45001, the OSHA PSM management elements) and a safety system (the engineered protective arrangement governed by ISA 84 / IEC 61511). The safety system is not just instrumented functions — it integrates the protective technology with the operators who respond to alarms, the procedures that govern safe shutdown, the engineers who maintain integrity through the lifecycle, and the competency management that keeps the human layer reliable. The SIL rating of a safety function covers the integrated performance, not just the technology. The management system governs the lifecycle of the safety system. The safety system delivers the protection. A plant with an excellent management system and an inadequate safety system is unsafe. Cybersecurity has the management system and not the system being managed. What the ISMS manages, in the absence of an engineered security system, is the procurement and operation of individual components according to prescriptive frameworks. The management system manages the parts. This is why a mature ISMS does not prevent breaches at the rate boards expect. The ISO 27001 audit opinion says: the management system is operating as designed, the controls listed are implemented, the cycle is functioning. It does not say — and cannot say, because the standard does not define it — that the security system is delivering the security outcomes the business depends on. Boards hear "we have a certified ISMS" and interpret it as "we have a system that secures our information." What they have is a management system governing activities related to information security. The system that would deliver the security — engineered, integrated, integrity-rated — is not what the certificate covers. What Functional Safety Got Right Process safety solved the equivalent problem a generation ago. Hazard analysis (HAZOP, What-If, FMEA) starts with consequences and traces backward to initiating events. Safeguards are derived from the analysis, not assembled from a catalogue. Layers of Protection Analysis makes regulation additive and quantified, with each independent layer reducing consequence frequency by a defined order of magnitude. Bow-tie analysis traces the full causal chain from initiating event through preventive and mitigative barriers to the consequence. Safety Integrity Levels tie required performance to required risk reduction — a SIL-3 function has a quantified probability of failure on demand and is engineered, tested, and maintained against that target. The translation to cybersecurity is direct. For each element of process safety, there is a cybersecurity equivalent that a mature discipline would have built: Safety system → Security system, engineered and distinct from IT operations Safety management system → ISMS, managing the lifecycle of the security system HAZOP / What-If / FMEA → Threat modelling traced to business consequence LOPA → Quantified defense-in-depth with independent layer credit Bow-tie analysis → Threat, preventive controls, compromise event, mitigative controls, consequence Safe operating envelope → Defined secure operating envelope Safety Integrity Level → Required integrity level for a security function, derived from risk reduction needed Management of Change → Security impact of change, integrated with change management PHA revalidation → Periodic re-evaluation of threat model and security system adequacy Every one of these is a regulatory artifact a sister safety-critical discipline considers minimum. None of them are exotic. All of them are within reach. The Question for Boards Every executive in a process industry can answer "what is your safety system?" — they can describe its architecture, its integrity basis, its accountability, and how they know it is working. Almost no executive in any industry can answer the equivalent question "what is your security system?" in those terms. They can describe their tools, their team, their framework conformance, their certified ISMS. They cannot describe their security system as an engineered arrangement with a design basis and an integrity claim, because they don't have one. The discipline has not produced one for them to procure or build. The questions to ask are different. Not "are our controls operating effectively?" but "is our security system actually providing the security the business needs — does it work?"  Not "is our ISMS certified?" but "what does our management system manage, and is the thing being managed adequate to the threats we face?"  Not "did we pass our audit?" but "if we removed each component tomorrow, what consequences would re-emerge — and is that an acceptable answer?" This is engineering work. Engineering work belongs to engineers. The Professional Digital Engineering discussion underway in Canada and elsewhere is not separate from this conversation — it is the same conversation. The protective systems that keep municipalities, utilities, hospitals, and supply chains operating in the digital era are engineered regulatory systems, and they require the discipline, accountability, and regulatory recognition that other engineered protective systems have received. The Path Forward Cybersecurity does not need to abandon what it has built. The frameworks, controls, assessments, and management systems are helpful. However, they are not sufficient. What the profession needs is to build the system that should be at the centre of all of it — the engineered security system, integrating people, process, and technology, that keeps the business and operations within a defined secure envelope, against the threat conditions the organization actually faces. Process safety made this transition over a generation. It moved from prescriptive codes to engineered protective systems with management systems above them, and the result is an industry where boards can answer the question "what is your safety system?" and have a real answer. Cybersecurity is at the same crossroads, with the same legacy problem and the same path available. The cyber risk terrain has outgrown the audit-derived foundations the profession was built on. It is time for cybersecurity to grow up — to mature past the prescriptive rule, to build the security system the discipline never built, and to become accountable for the outcomes its name has always claimed. Raimund (Ray) Laqua, P.Eng., PMP is the founder of Lean Compliance Consulting, Inc. He works with organizations to design compliance programs that deliver on their promises, and advocates for Professional Digital Engineering as a regulated discipline in Canada.

What access control misses, and why your compliance investment just became strategic By Raimund Laqua, P.Eng., PMP — Lean Compliance Consulting, Inc. Imagine your organization deploys an AI agent to process vendor invoices. It has permission to read the invoice system, check against contracts, flag anomalies, and submit approved payments below a threshold. The deployment is described as "governed" — the agent has defined access, risk-tiered autonomy, and a human-in-the-loop for high-value transactions. Six months later, the finance team discovers the agent has been quietly paying invoices that are technically within policy but don't match the actual goods received. The invoices passed every permission check. Every access rule. And yet what the agent produced is not what the organization intended. How did this happen? And why is the problem so hard to fix by adding more rules to the access model? This is the governance question that agentic AI is forcing organizations to confront. One answer being proposed in the AI governance space is a concept called decision admissibility  — the idea that we can govern autonomous agents by evaluating whether a proposed action could reach outcomes that are not permitted. If the outcomes that follow from the action are inadmissible, execution is refused. Proponents describe this as something stronger than authorization, because it considers not just whether the action is permitted but whether the outcomes it could produce are. It's a concept worth taking seriously. But the more I've tried to understand what it means, the more I've come to think the approach is missing something fundamental. Three Meanings of Admissibility When I read through what different people mean by decision admissibility, I find three distinct concepts wearing the same label. The first is runtime evaluation  — at the moment an action is proposed, does the set of outcomes it could reach include any that are inadmissible? If so, refuse it. This is the reachability-based version. It's meant to be stronger than access control because it evaluates outcomes, not just permissions. Whether it actually works depends on whether you can map reachable outcomes for a stochastic system, which is where the approach runs into difficulty. The second is design-time constraint  — have we built the system so that inadmissible outcomes are structurally unreachable in the first place? If the agent has no access to financial systems, it cannot produce financial outcomes regardless of what it proposes. This is capability shaping, a concept well established in engineering and heavily regulated industries. The third is philosophical  — admissibility as an ontological condition for what is permitted to exist  within the system. This draws on a framework treating admissibility as a pre-theoretical property governing whether systems may form and persist. Coherent as philosophy, but it has not been translated into practical governance architecture. Of the three, the first is the ambitious claim — the one that would actually represent something new. The second is existing practice under new vocabulary. The third hasn't become practical yet. When Roles Don't Apply In practice, organizations rarely implement runtime reachability evaluation — it's too hard. What they actually do is extend role-based access control to agents and call it governance. This is where a second problem shows up. Role-based access control works for humans because roles do more than assign permissions. A role is a form of capability shaping. When an organization defines a role — finance analyst, compliance officer, procurement manager — it specifies the work, the authority, the competencies, the accountability. The permissions attached to the role are the enforcement mechanism. The role itself is the governance artifact. Many agents don't fit this pattern. The invoice-processing agent in the earlier example doesn't occupy an existing role. No one designed a job description called "invoice processor" with a defined stratum, accountable manager, and professional competencies. The agent was given permissions pulled from existing roles — without the role context that would have shaped how those permissions are used. This is the real problem with extending role-based permissions to agents. The role is what's shaping the capability. When the agent doesn't fit an existing role, the permissions model has nothing to anchor to, because the capability shaping that roles normally provide has been skipped entirely. The Judgment Problem Set aside the practical problems with extending permissions for a moment and consider the reachability-based version of admissibility on its own terms. Even there, a fundamental issue remains. Evaluating whether a proposed action could lead to inadmissible outcomes requires judgment . Not a rule match. Not a permissions check. Judgment — weighing context, purpose, consequences, and circumstances that have never occurred in exactly this combination before. In the invoice example, the invoices passed every rule. But a finance professional reviewing them would have noticed the pattern didn't fit how the organization actually operates. That's judgment about where the situation was heading, and it can't be reduced to a lookup table without losing what makes it judgment. The gate is meant to put a human back in the loop — to preserve human judgment at the moment that matters most, when a proposed action would commit. That intent is right. But the gate places decision-making at the latest possible point of intervention. At machine speed, across the volume of decisions agents produce, the human at the gate is either overwhelmed, reduced to rubber-stamping, or forced to fall back on pre-defined rules that substitute for judgment. Placing intervention at the last moment before commitment concentrates the hardest part of decision-making at the point where there is the least time and context to exercise judgment well. And evaluating reachable outcomes in a stochastic system is exactly where judgment is most needed and hardest to apply. The reachable space isn't enumerable. Novel situations emerge from the interactions of inputs the designers never anticipated. The gate is being asked to do what no rule set can — evaluate possible futures the system itself cannot fully predict. The Work Comes First There is something else missing from the admissibility discussion, and it matters more than the technical limitations. Governance begins with the work. What is the work that needs to be done? What is its nature, its complexity, its time horizon? What stratum does it belong to? What judgment does it require? You define the work first, then the role — the accountability, authority, and capability needed to do that work. The role serves the work. Much of the current AI governance discourse has inverted this. It starts with the agent's permissions — what systems can it access, what actions can it perform — rather than with the work the agent is being asked to do. The agent gets a permissions profile, not a work definition. An agent may have permission to create a spreadsheet. But should it? The work isn't "create a spreadsheet." The work is "analyze this data to support a decision about X." That work has a purpose, a context, a required level of judgment, an accountable manager, and consequences if done poorly. Output-oriented delegation is not new. Organizations have always delegated by specifying desired outcomes. What is different with agentic AI is that the governance of the work  has been stripped away. When a human receives a delegation, they operate within an ecosystem of SOPs, professional standards, budgets, timelines, and accountability for method. When an agent receives it, that ecosystem is largely absent. The delegation pattern is the same. What's missing is everything that used to govern the journey. The Compliance Reversal Here is what most AI governance discourse gets wrong: it assumes we need an entirely new governance apparatus. We don't. For decades, compliance documentation has been treated as overhead — a cost of doing business producing no operational value. Organizations have tried to minimize it, consolidate it, or tolerate it. Executives have questioned the investment. Agentic AI changes that calculation. The substance of those procedures, standards, and policies — the accumulated institutional knowledge about how work should be done, what constraints matter, what outcomes are expected — is exactly what's needed to govern machine agents. An SOP written for a human to read doesn't constrain an agent's behaviour, but the substance  of that SOP is exactly what an agent needs as its constitutional architecture. The documentation isn't overhead anymore. It's the training material. It's the regulatory DNA. Organizations that invested seriously in operational compliance — that kept their SOPs current, their standards well-defined, their policies genuinely operationalized — are in a materially better position than those that treated compliance as a paper exercise. The investment that was hardest to justify becomes the asset that's hardest to replicate. Where to Start For governance, risk, and compliance professionals facing agentic AI deployment, there are four practical starting points. Inventory your agents against existing roles.  For each agent running or planned, ask: does this agent occupy a defined role? If not, what is the work being delegated to it, at what stratum, with what accountability? Agents without role anchors are agents without governance — no matter how many permissions they have. Audit your compliance documentation for machine readability.  Your SOPs, standards, and policies are about to become the constitutional architecture for AI governance. Which of them could a machine agent consume? Which exist only as unstructured narrative? Which haven't been updated in years? The gap between "documented" and "machine-consumable" is the gap between having compliance and having AI governance. Define the work before defining the agent.  Before deploying any new agent, require a work definition: what is being delegated, to what stratum, under whose accountability, against what obligations. If the work definition cannot be written clearly, the agent should not be deployed. Treat capability expansion as a governance event.  Every new tool, integration, or data source an agent acquires is an expansion of the capability envelope. It is not an operational decision — it is a governance decision that requires recharacterization, revalidation, and managerial accountability. None of this requires a new paradigm. The organizational disciplines that govern human work — defining the work, anchoring it in roles, establishing accountability, operationalizing standards — are the same disciplines that will govern machine work. Governing AI agents isn't something separate from what compliance professionals already do. It's what compliance professionals already do, extended to a new class of agent. Permissions alone won't govern. But the rest of what your organization has already built can. Raimund Laqua is the Founder and Principal Engineer at Lean Compliance Consulting, Inc., where he develops the Operational Compliance Model (OCM) and the Organizational Compliance Framework (OCF) — governance tools for the Intelligence Age. He can be reached at rlaqua@leancompliance.ca . © 2026 Lean Compliance Consulting, Inc. — All rights reserved.

AI is pushing humans out of the loop. The response many are taking is to figure out how to put humans back in. That is the wrong response. The answer is not human-in-the-loop. The answer is agent-in-the-loop. Train AI agents to participate in the governance loops that already exist. AI agents are replacing human workers who operated within those loops every day — workers who followed SOPs, escalated exceptions, maintained standards, and kept promises. When you remove those humans without training AI to participate in those same loops, you don't gain efficiency. You lose governance. Most organizations are responding by drafting AI-specific policies, standing up AI ethics committees, and bolting guardrails onto agents from the outside. This will fail — because it treats AI governance as separate from organizational governance. The governance architectures needed to govern AI agents are not new. They already exist. Requisite Organization provides the accountability structure. Promise Theory provides the commitment model. Cybernetic regulation provides the control architecture. Policy deployment provides the alignment mechanism. These are proven foundations that serious organizations already operate under. In our new paper, "Promise Agents: Governing Humans and Machines Through Lines of Regulation," we introduce the Promise Agent — an agent, human or machine, that must formally declare its commitments, agree to keep them, and self-regulate to ensure that it does. Self-regulation within the existing governance architecture is a condition of entry into the enterprise workforce. Not human-in-the-loop. Agent-in-the-loop. The question is not whether these practices work. The question is whether the broader market will adopt them — or learn the hard way why they exist. Link to the full paper below.