SEARCH

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.

That's the answer I hear when I ask organizations what work they're delegating to AI agents. Don't worry about defining the work. Don't worry about characterizing its complexity. The AI will sort it out. The end by any means. This sounds like progress. It is the abdication of governance. And no amount of forensic auditing will put back accountability for what was not there to begin with. Start with the work This is why I've been drawing on Elliott Jaques' work on Requisite Organization. Jaques spent decades studying how accountability actually functions in organizations — not as policy or org charts, but as the structural relationship between a manager who delegates authority and the outcomes produced under that delegation. His first principle is deceptively simple: start with the work, not the technology. What is the work that needs to be done? At what level of complexity? Over what time horizon? Does the agent have the capability to do it? Most organizations deploying AI agents have not done this. They describe what the agent  does  — summarizes documents, answers queries, writes code — but not the complexity of what is being delegated. A document summary is defined task work: structured inputs, verifiable output. A regulatory landscape analysis with strategic recommendations is qualitatively different work: synthesis across multiple domains, balancing competing factors, over an extended time horizon. The governance requirements for each are completely different. Treating them the same — because the same technology performs both — is where governance fails. Not all AI agents require the same governance. An agent performing defined, verifiable tasks is not fundamentally different from any industrial automation — a robot that learned to pick up boxes has acquired a skill, not agency. Operational controls are sufficient. But an agent that plans, selects among alternatives, delegates to sub-agents, and evaluates outcomes against goals is exercising something that looks like discretion. If a human did that work, it would require managerial oversight, professional judgment, and organizational accountability. Governing it like automation is dangerously inadequate. The hard line Only humans can be held accountable. That is not a limitation of current law that might change. It is a foundational principle of governance. Accountability requires the capacity to bear responsibility, to make restitution, to be answerable. Machines do not have this capacity. They never will, regardless of how capable they become. This means that for every AI agent performing work that involves discretion, a human being must be managerially accountable for the outcome. Not ultimately accountable in some abstract, organizational sense. Directly accountable — because they delegated the authority under which the agent operates, and the agent's output is the product of their delegation. Jaques is precise about what this requires. The manager is accountable for having selected an agent with the capability to do the work. Accountable for having set the context — not just a system prompt, but the organizational understanding of why this work matters and what constraints apply. Accountable for having defined the authority boundaries — what the agent may do, what it may not, when it must escalate. Accountable for maintaining sufficient awareness of the agent's operation. And accountable for the outcome — every decision, every action, every consequence. The manager who says "I didn't review that particular agent decision" is not absolved. Jaques' response: you didn't need to review it if you set the boundaries correctly and maintained adequate monitoring. If you didn't, the failure is yours. Responsibility is not accountability This distinction matters and most frameworks blur it. Jaques separates them precisely. The agent is responsible for the work — for executing within its boundaries, to the standard expected. But the agent cannot be accountable, because accountability is a human relationship: answering to other humans for outcomes produced. The manager is accountable for the outcome. And the manager is responsible for their own managerial work — the work of selecting, context-setting, boundary-defining, and monitoring. That managerial work is not administrative overhead. It is the governance itself. If the manager did it well, the agent operates within appropriate boundaries and the outcomes are governed. If the manager didn't, no amount of policy, committee approval, or compliance documentation compensates. This applies equally to subordinates who use AI agents as tools. When a loan officer uses an AI agent to assess a loan application, the assessment is the loan officer's work product. Their name is on it. Their professional judgment backs it. They are responsible for the work — including their evaluation of the agent's output. Their manager is accountable for the loan officer's output, including the quality of how the loan officer uses AI tools. The manager's work now includes a dimension that didn't exist before: ensuring that subordinates who use AI tools are still performing work at the level their role requires, still exercising the judgment their position demands, and not silently delegating their professional responsibility to an instrument. The danger is not that the person is replaced. It is that the person remains but their judgment is subtracted — hollowed out by an agent that does the processing while the human becomes an accountability placeholder, a name attached to machine output. The doorman problem A consultant walks into a hotel and sees a doorman. He tells the manager: we can replace the doorman with an automatic door opener. Save $30,000 a year. The cost was reduced. So was the value. The doorman didn't just open doors. He recognized guests by name. He read situations — a visitor who didn't belong, a delivery that seemed wrong. He set the tone for the guest experience. He knew the neighborhood. None of this appeared in the cost-benefit analysis because none of it was the task being automated. This is what happens when organizations compress strata with AI. The consultant — now the AI vendor, the transformation advisor — looks at a middle manager and sees information processing: aggregates reports, coordinates teams, relays decisions. That function is automatable. The business case writes itself. But the manager wasn't just processing information. That was the visible task. What the manager actually did was exercise judgment at a level of complexity that included reading organizational dynamics, understanding why a policy exists and when it should bend, maintaining institutional knowledge, translating strategic intent into operational reality through dozens of contextual decisions that never appeared in any report. The AI replaces the information processing. The organization loses the judgment. And the loss is invisible — until the regulatory violation the manager would have flagged, until the risk the manager would have caught, until the strategic misalignment the manager would have detected because they understood both the strategy above and the operations below. Every AI business case is a doorman analysis. It quantifies the cost of the visible function. It cannot quantify the value of the judgment embedded in the same role. The decision to automate is made on incomplete information, every time, structurally. What accelerates the problem The entity you're integrating into your organization is not stable. It is changing faster than your governance can adapt. Foundation models update. Agent frameworks evolve. New capabilities appear — tool use, multi-agent coordination, persistent memory — that didn't exist when you wrote your governance plan. The agent you assessed in January is not the agent you're operating in June. And unlike any previous technology adoption, AI is subtractive, not additive. The internet added a channel. It didn't replace the people doing the work. AI agents replace human judgment, human decision-making, human labor. That's the value proposition. When the agent replaces the human, the institutional knowledge walks out with the person. The organization can't easily reverse the substitution because the human capability no longer exists to reverse to. Dan Davies, in  The UnAccountability Machine , describes the system this produces. An accountability sink — a system that produces outcomes nobody specifically chose and nobody can be held accountable for. Every process was followed. Every policy was in place. Every approval was obtained. And nobody answers for the result, because the accountability was never operationally present. It was procedural. Procedural accountability without operational governance is a filing system, not a governance system. The question The question for every organization deploying AI agents is not whether they have policies, risk assessments, and committee approvals. It is whether a specific human being has done the managerial work — defining the task, assessing capability, setting boundaries, maintaining awareness — that makes accountability meaningful rather than procedural.

The role defines the result. Here's something that doesn't get said often enough: most compliance programs aren't led. They're maintained. And there's a world of difference between the two. The Caretaker Problem In many organizations, the person responsible for compliance isn't leading it. They're caretaking it. Their mandate — spoken or unspoken — is to keep things the same. Don't rock the boat. Don't introduce risk. Make sure we pass the next audit. This isn't a character flaw. It's a role definition. Caretakers exist because the organization has decided that compliance is a holding pattern, not a strategic function. The person in the role is doing exactly what they were hired to do. And when someone comes along with a better way to do compliance — a more effective design, a smarter approach to obligations, a path to genuine operational compliance — the caretaker has no incentive to act on it. Improvement isn't in the job description. Stability is. You Might Trim Costs. You Won't Transform Anything. Can you get a caretaker to accept some changes? Sure. You might reduce costs. Eliminate redundant steps. Streamline a reporting workflow. These are changes that make the status quo cheaper or easier to maintain — and that's precisely why they're accepted. But try to introduce something that changes how compliance actually works — how obligations are owned, how promises are kept, how assurance is built into the operating model — and you'll hit a wall. Not because the idea is wrong, but because the role won't allow it. A caretaker's job is to preserve the system, not redesign it. Usually, it takes something going wrong — a regulatory failure, a material finding, a public incident — before the organization reconsiders whether "keeping things the same" was ever really a strategy at all. Leadership Changes Things. Continuously. Now contrast that with organizations where compliance is led, not just managed. Where the person in the compliance role sees their mandate as delivering outcomes, not preserving routines. Where realizing the benefits of compliance — not just avoiding penalties — is critical to mission success. In these organizations, change isn't a disruption. It's the operating model. Because when your job is to keep the organization between the lines, ahead of risk, and on mission, you can't afford to stand still. The regulatory environment moves. The business evolves. Technology shifts the playing field. Standing still is falling behind. Compliance leaders don't wait for something bad to happen. They design compliance programs that are adaptive by nature — programs built on clear obligations, owned promises, and the operational capability to deliver on both. They close the operability gap between what the program says on paper and what actually happens on the ground. The Question Worth Asking So here's the question: Does your organization have a compliance leader or a compliance caretaker? If it's a caretaker, stop trying to sell them on transformation. It won't work — not because the case isn't compelling, but because the role doesn't reward it. Your energy is better spent helping the organization understand that caretaking isn't leadership, and that compliance without leadership is just waiting for the next failure. If it's a leader — someone who sees compliance as a promise the organization keeps, not a box it checks — then the conversation is entirely different. That's where real design begins. That's where operational compliance becomes possible. That's where you start building something worth keeping.

Operational Compliance Landscape When viewed through an operational lens, governance is not just oversight, accountability structure, or decision authority. Governance is the act of regulating organizational effort towards organizational values. This differentiates traditional approaches — Compliance 1 — focused on procedural compliance. It defines Compliance 2 : Operational Compliance. When it comes to regulatory design, there are four primary types, each requiring its own approach. These cross the spectrum between ENDS and MEANS : ▸ Macro-Ends → Outcomes ▸ Micro-Ends → Targets ▸ Macro-Means → Practices ▸ Micro-Means → Rules These map to obligations associated with outcomes, performance targets, practice standards, and rules. Each type of obligation requires a different means of regulation: ▸ We use processes and procedures to adhere  to rules. ▸ We use management systems to conform  to standard practices. ▸ We use management programs to achieve  performance targets. ▸ We use governance to advance  outcome goals. These do not operate in isolation. Together, these functions regulate the organization — bridging the gap between the ENDS and the MEANS. ▸ Governance regulates Programs ( Measure of Effectiveness ) ▸ Programs regulate Systems ( Measure of Performance ) ▸ Systems regulate Processes ( Measure of Conformance ) ▸ Processes regulate Work ( Measure of Adherence ) This is more than an integrated stack. It is an integrative system of systems. It's what happens in between  that ensures all obligations are met. This is the Measure of Integrity (MoI). If you're not realizing the outcomes of your compliance, now you know why. You haven't made governance operational — and part of how you keep your organization between the lines, ahead of risk, and on mission.