When we talk about AI adoption, most people mean efficiency. Making existing processes faster. Swapping one process stack for another. Here's the thing. With what has been borrowed against AI, efficiency does not come close to settling the account. Because that is what this is. A debt. We have directed much of the world's capital into a single technology and away from everything else it could have funded. That capital was not free. It was borrowed against a promise. And capital is only part of what was drawn down. The data centres behind AI run on staggering amounts of energy and water. Their electricity demand is on track to double by 2030 — to roughly 945 terawatt-hours a year, more than all of Japan consumes. Power that could light homes and run hospitals. Fresh water, by the millions of litres, poured through cooling systems to keep the servers cold. Water that could grow food and fill reservoirs. Every model trained, every query answered, draws down resources that are already scarce — and not available to people who need them. So the account is large, and it is still open. Against it stands the promise. One day, we were told, AI would help cure cancer, reduce hunger, clean up pollution, make life more viable for everyone. That was the note we signed. That was the collateral we put up. So where is the payment going? Not toward those problems. Toward compute centres, power generation, GPUs, memory. The machinery of something its builders call AGI. Here is why that was never going to end any other way. Cybernetics has a law for it: the law of inevitable ethical inadequacy. Stated plainly — if you do not require a system to be ethical, you will not get one. You get a system that optimizes for the goals you specified, at the expense of the ones you did not. The ethical. The human. The good. And those goals are set by us. Not by the machine — by the people who build it and fund it. The system does what it is told. We are the ones doing the telling. So the inadequacy is not the machine's failing. It is ours. Look at what we made a requirement. Capability. Scale. AGI. Then look at what we left as a promise. Cancer. Hunger. Pollution. A better life for everyone. A promise is not a requirement. And a system built to hit the goals we set will spend every borrowed dollar, every watt, every litre on hitting them harder — not on the good we never required of it. So the default was built in from the start. In both senses of the word. The outcome defaults to what we specified, and the debt defaults unpaid — because repayment was never written into the terms. What is being built looks like a future without us. Not one where we do better. That is not a betrayal of the goal. It is the goal, working exactly as specified. The bill does not disappear because we spent it elsewhere. If AI is going to cost us this much — our capital, our power, our water, the things we need to live and grow our society — then the good cannot stay a promise. It has to become a requirement. Written into the terms. Measured in what we were told AI would deliver. Cancer. Hunger. Not process cycle times. That is what is owed. Specify the good, or it will not come. That is the only way AI ever delivers the goods.

Audit Will Not Make AI Safe Ask almost anyone in compliance where the field ought to be heading and the answer comes back the same. Compliance should become proactive. It should anticipate risk rather than react to it. It should build the capability to meet obligations, not merely the paperwork to prove them. The obligations themselves have already moved. Regulation and standards have shifted toward risk-based and outcome-based designs, and they now ask organizations to contend with uncertainty and achieve results rather than follow prescription alone. There is broad agreement on the destination. What is remarkable is how little the practice of compliance has moved, even as the obligations already have. I wrote a few years ago that compliance needs to change, and that the reactive model most companies still run has been quietly working against the very outcomes they are trying to achieve. That is still true. What I did not name clearly enough at the time was the reason the reactive model persists. It persists because the audit regime holds it in place. Audit is not a neutral check on compliance. Audit is the mechanism that keeps compliance reactive. Reactive by Design Consider what an audit actually does. It samples evidence after the fact. It compares that evidence against documented procedure. It produces findings, and those findings are closed through corrective action. Every part of that sequence looks backward. An audit can tell you what already happened. It cannot tell you what is about to. I made a related point in the earlier paper. There is an important difference between verifying what has already happened and preventing what has not yet happened. Financial audit was built for the former. Safety, quality, and risk live in the latter. When we borrow the financial audit model and apply it to outcomes that have not yet occurred, we are using an instrument built to look back as though it could look forward. It cannot. The reactivity is not a flaw in how audit is practised. It is what audit is. The Vicious Cycle A reactive instrument is a problem on its own. What makes it worse is that the burden does not stay fixed. It grows with every cycle. Each finding is closed by adding something: a control, a checkpoint, a document. More procedure creates more surface to audit. More surface produces more findings. More findings produce more procedure. The apparatus grows on its own momentum, and every increment of complexity introduces new ways to fail and new things to inspect. The mechanism meant to correct the system is the same mechanism that inflates it. This is the pattern behind the misuses I described before. When audit findings are treated as requirements, the ratchet turns, and the auditor's interpretation becomes the obligation the program must now grow to satisfy. When companies run pre-audits to prepare for internal audits to prepare for external audits, the parallel apparatus has already taken over. An entire second system now exists whose only purpose is to prove compliance to someone else's uncertain benchmark. What I once catalogued as four common misuses are not accidents of poor practice. They are what a reactive instrument produces when a company relies on it. Two forces make the cycle worse. The first is that people begin to manage the measure instead of the outcome. Because the audit scores what can be documented, effort migrates toward looking compliant, and a company can become very good at passing audits while becoming no safer at all. The second is that the work of feeding the audit crowds out the work of building capability. The busier a company is closing findings, the less time it has to prevent the next one, and so it stays perpetually behind. Assurance Does Not Come From Audit Here is the point we keep getting wrong. Compliance does need assurance. Regulators, boards, and stakeholders are right to want confidence that obligations will be met, and not only that they were met once. That confidence does not come from an audit. It comes from capability. Assurance is the confidence that a company can keep its promises today, tomorrow, and every day after. No inspection can manufacture that. An audit can attest to a moment already past. The capacity to meet an obligation in the future is a property of how the work is designed, resourced, and operated. It is built into the organization, or it is not there at all. A certificate on the wall says a sample looked acceptable on the day it was taken. It says nothing about whether the capability exists to keep the promise tomorrow. This is the mistake compliance has made for decades. We have treated assurance as something an auditor confers rather than something an organization possesses. We are now about to make the same mistake, at scale, with AI. The Same Mistake, Now Applied to AI New regulation for AI is arriving, and the predictable response is already taking shape. The audit regime will stand up to meet it. Certification schemes, conformity assessments, and audit checklists are being assembled to answer the new obligations in the only language the existing apparatus knows, which is documented conformance verified after the fact. We should see where this leads, because we have watched it before. Most businesses will not build safety into their AI systems. They will hire external auditors to certify that they have the appearance of being safe. The certificate will attest to a snapshot. The behaviour of the system in the world, which is precisely the thing that matters and precisely the thing that changes, will go unaddressed. The vicious cycle will reassert itself, the same misuses will follow, and organizations will feel more protected while becoming less safe, at a moment when the distance between appearing safe and being safe carries far greater consequences than it ever did before. AI does not tolerate a reactive compliance model. Its behaviour is variable, fast, and often novel. An instrument that samples the past cannot regulate a system whose risks are still forming. The range of what can go wrong outruns anything an audit checklist can hold. Applying the audit regime to AI is not a partial solution that time will improve. It is a category error, and it will give companies confidence in exactly the wrong thing. But We Still Need Independent Assessment The most common objection to all of this is that organizations still need independent assessment. They do. Independence has real value, and nothing here argues against it. The objection skips over the only question that matters, which is what the independent assessor is actually assessing. Asking this plainly. Does the auditor assess the level of safety a system has achieved? Does the auditor assess the organization's capacity to remain safe as conditions change? In almost every case the answer is no. The auditor checks whether the documentation is in order and whether procedure was followed. That is an assessment of the appearance of safety. It can be independent, rigorous, and still beside the point. Independent assessment is worth keeping. What has to change is what it assesses. An assessor should be asking whether the organization is safe and whether it can stay that way. That is a question about real capability, not about whether the documents are in order. Point independent assessment at the capacity to be safe rather than the appearance of it, and independence becomes an asset again instead of a ritual. What This Requires It comes down to one question. Where does assurance come from? Assurance has to be built. It cannot be inspected into existence. It belongs in the first line, where managerial accountability exists. The people who do the work produce the assurance, because no one else can. That means designing compliance into the work, not bolting an audit on at the end. It means measuring capability, not just documents. It means moving the feedback ahead of the harm, so a company knows it can meet an obligation before it is tested. Verification still belongs inside this system. What changes is that it serves capability instead of standing in for it. Audit can tell us what happened. Only capability can assure us of what will. That difference has always mattered, and with AI it becomes decisive. A system whose behaviour is fast, variable, and still forming will not be made safe by a certificate that attests to a moment already past. It will be made safe by building the capability to stay safe, and by assessing whether that capability is real. Every organization adopting AI now faces the same choice. Build safety in, or buy the appearance of it. Only one of them makes you safe. Building safety in has a name. I call it Forward Assurance. It builds the capability to be safe into how an AI system is designed and run, and it gives the organization ongoing evidence that the capability is real and working. It shows whether you can meet your AI obligations today and keep meeting them, not whether you passed an audit last quarter.

Investing in the Opportunity to Succeed Every business creates value under uncertainty. Some of that uncertainty can be reduced. It comes from what the organization does not yet know. About its processes. Its risks. Its obligations. The conditions it works in. Learning reduces it. So does capability. This is uncertainty you buy down. Some of it cannot be reduced. Variation is part of real conditions, and no amount of learning removes it. This is uncertainty you contend with by creating margin. Businesses succeed when they do both. They buy down what can be known. They hold margin against what cannot. Where compliance fits Compliance programs are how organizations buy down uncertainty. Uncertainty about their obligations, and uncertainty about the outcomes of those obligations. Every obligation carries the risk that it will not be met. A regulation. A commitment. A promise to a stakeholder. Until the organization has the capability to deliver on it, whether it gets met is an open question. A compliance program closes that question. Not by documenting the obligation, but by building what it takes to meet it. The outcomes carry uncertainty too. Safety is not produced by meeting safety obligations alone. Neither is security, or quality, or sustainability. Each one is something the organization is working toward in conditions it does not fully control. The compliance program is what reduces the uncertainty of getting there. Margin is the other half. Where uncertainty cannot be reduced, the response is buffer, tolerance, and reserve. Enough room that variation does not become failure. This is why compliance measured against profit alone misses most of what it produces. What Total Value accounts for Businesses create more than profit. Reputation. Integrity. Quality. Safety. Security. Sustainability. And underneath all of them, stakeholder trust. These are outcomes the organization has committed to and stakeholders rely on. They are also the outcomes most exposed to uncertainty, because each one depends on something going right that could have gone otherwise. Total Value accounts for all of it. What a business earns, and what it protects and ensures. The third advantage Michael Porter identified two sources of competitive advantage through value chain analysis. Cost and differentiation. Compete on price, or compete on what the product does. There is a third. An organization that reliably delivers on what it has committed to earns something competitors cannot easily copy. It stays between the lines, ahead of risk, and on mission. Stakeholders come to rely on it. That reliance is difficult to build and slow to lose. We call this the Total Value Advantage. It does not come from managing compliance more efficiently. It comes from building the capability to meet obligations, and from contending well with the uncertainty between an obligation and its outcome. Is your compliance ready for the age of intelligence? The Compliance Readiness Scorecard gives you an honest picture of where your program stands — and a strategic conversation about what to do next. https://www.leancompliance.ca/compliance-readiness-scorecard

Forward Assurance for AI Systems Audit looks backward. It verifies that something was done. Forward assurance is confidence that a system will keep its promises in operation — and that confidence cannot be inspected in after the fact. It is engineered in, by design. The gap AI is adopted when it can be trusted with the work that matters. We trust a mission critical system because we trust the people who design and build it, and the discipline they follow. That is what has to be established, and mostly it isn't. Most of what is offered to close this gap checks the output, attests to it, or reports on it. None of it establishes that the work itself was done to engineering and regulatory standards. Engineering is how the gap closes We provide consulting services to help you establish engineering practice that meets professional standards — applying the methods, technical standards, and disciplines that govern how AI systems should be engineered, such as ISO/IEC 5338 and others that apply. The result is a practice that creates trust because AI systems are engineered by competent and trustworthy practitioners, following proven engineering methods to professional and regulatory standards. Three disciplines, working together → Engineering Methodology — how AI systems are engineered for the enterprise: architecture, capability requirements, risk-based phasing, and separation of concerns. → Project Assurance — independent engineering judgment over the build: stage-gating, acceptance criteria, and design review that keep each phase sound enough to support the next. → AI Compliance — compliance engineered into the system from the design stage: obligations, controls, and the regulator structure built into the architecture, not bolted on after. Who this is for Data, software, and IT solutions firms putting AI into client work. Organizations pursuing licensed engineering practice or a Certificate of Authorization. Engineering and delivery teams standing up AI capabilities to professional and regulatory standards. Organizations bidding into regulated or public work, where engineering assurance is the basis they compete on. If you are working to put real engineering practice behind your AI, reach out. https://www.leancompliance.ca/forward-assurance

Up until now, we created, stored, and moved data to where it was needed to drive our businesses. This was the world of Information Technology (IT) — and the foundation of Enterprise Architecture. That era is ending. AI has already absorbed virtually all the unstructured data available in the world. Large language models didn't just process that data — they internalized it. Now we need to build AI for the business — harnessing operational data, engaging the system of record, and deploying autonomous agents to do what could not be done before. Enterprise Architecture will no longer be designed to manage information. It will be designed to create and harness the power of artificial intelligence. This is the shift from Information Technology to Intelligence Technology — from IT to I²T. And it demands a new kind of compliance — not procedural, but operational. Real-time, adaptive, and capable of regulating AI at the speed AI operates. ⚡ Is your compliance ready for intelligence technology? Let's find out. Take our Compliance Program Scorecards and see where you stand before the shift leaves you behind.

Governance is a form of regulation. Cybernetics is the study of regulation in machines and living systems. It gives us two rules that matter here. First, the regulator must model the system it regulates. This is the Conant-Ashby theorem. Every good regulator of a system must be a model of that system. Second, the regulator must hold at least as much variety as the system it controls. This is Ashby's Law of Requisite Variety. Only variety can absorb variety. A set of finite controls cannot govern a system of near-infinite variability. The controls run out of responses. The system reaches states the controls never anticipated. This is why frontier labs place AI inside their own control architecture. They need adaptive regulation. Rule-based controls cannot generate enough variety to keep pace. The approach functions, but it is neither sufficient nor reliable on its own. So how do you regulate a system whose variety you can never match? You stop trying to match it. Requisite variety is not reached by stacking controls until they equal the system. That path has no end. You balance the variety equation from both sides. Attenuate the system. Constrain the operating envelope. Bound the states the AI can reach. Reduce the variety you are required to absorb. Amplify the regulator. Use adaptive, recursive, and self-regulating controls. Let each level regulate itself. Variety is best absorbed close to where it arises. AI in the loop only amplifies. On its own it becomes an arms race you will lose. Paired with attenuation, the two meet at a point you can actually hold. The real work is engineering that balance. That is the discipline of cybernetic regulation. A necessary practice in meeting obligations in the age of intelligence.

Elevate Compliance Huddle · Session 100 THE FUTURE OF LEAN COMPLIANCE Elevate Compliance Huddle · Session 100 Monday, September 14 · Noon ET · Live on Zoom In our last webinar we explored what the future of compliance might look like in the age of intelligence. Obligations moving from rules to outcomes. AI arriving in the value chain, in the products organisations make, in their suppliers' processes, and in the compliance function itself. The message was this: compliance must now adapt. On September 14 we take the next step: what compliance needs to do to prepare for AI, and what that means for Lean Compliance. Along with our client engagements, we have now held 99 huddles for our community. Two years working through the shift from procedural to operational compliance. Obligations and promises. Uncertainty and risk. Governance, programs, systems, and processes. Assurance that looks forward instead of back. Continuous compliance. We called this Compliance 2. That work anticipated exactly what AI now demands. Real-time regulation. Promises kept by systems. Accountability that is owned, not transferred. Capability rather than documentation. Together we have worked through the foundations over the last several years. That is what creates the opportunity now — to apply them to a world with AI. Session 100 is where that conversation starts. Save the date and join us on September 14 at noon on Zoom. Open to everyone, so bring a colleague if they are interested in how to prepare compliance for AI. Links will be sent out as we get closer. 👉 Subscribe to stay informed → leancompliance.ca/subscribe Raimund Laqua, PMP, P.Eng. Founder, Chief Compliance Engineer Lean Compliance Meeting Obligations in the Age of Intelligence

I have used the same Compliance Program Scorecard for ten years. No one has ever disagreed with their score. That tells me the scorecard is reliable at evaluating compliance. People see where their compliance stands and they recognize it. What the scorecard gives them is where and how to improve. The reason that matters more now is AI. It does not change what compliance is. It changes what it takes to produce it. Obligations do not disappear when work moves to machines. They multiply, and the agents keeping your promises now include systems, not only people. Meeting that demand is not a matter of doubling down on what you already do. It means building the capabilities, capacity, competency, and culture that compliance depends on. That is a different kind of ask, and it is where the scorecard tests more than your program. Some organizations take on the work. Many don't. Not because they disagree with what the scorecard showed them, but because they discover something else: leadership is not behind the change. So they stay where they started, doing the same reactive, procedural compliance they always have. Improving compliance is hard work, but it is not what stops people. What stops them is that they are not ready to address what the scorecard reveals. If you want to know where your compliance stands, and what it would take to improve it, take the scorecard. The findings are worth having either way. 👉 https://www.leancompliance.ca/compliance-program-scorecard

Most conversations about AI and compliance go one of two ways. Either they are about technology, which tools to buy and what to monitor with them. Or they are about regulations, which rules now apply and how to map controls to them. Both are worth having. Neither is the one I think we are missing. Buying the right tools and knowing the right rules will not be enough, because underneath both is a culture and capability problem that AI is exposing rather than creating. AI adoption is already overwhelming traditional compliance practices, and it is doing so from two directions at once. New obligations and new risk are arriving faster than most compliance programs can absorb. And AI is entering the compliance function itself. This is landing on top of shifts already in motion: from static, structural compliance toward dynamic, operational compliance. From assurance by inspection toward assurance by design. From asserted trust toward demonstrated trust. The methods most organizations rely on were already under strain before AI arrived. AI is what pushes them past what they can carry. The future of compliance now depends on its capability, competency, and capacity to continually adapt. That is a hard sentence for compliance to hear, because adapting is not what compliance was built to do. Why compliance struggles to adapt Most compliance programs run on a bounded-set culture. The question is simple: are we in or out of compliance? You build fences, monitor for gaps, and close them when you find them. Once you are inside the line, there is nothing further to pursue, nothing to improve, nothing to get better at. This is not wrong. For rules-based obligations, it works. That is why it has lasted this long. But someone else drew those lines. A regulator, a standards body, a court. Which means compliance becomes a destination you arrive at rather than a direction you travel. You cannot raise a standard that was never yours to set. That is the trap. A program that only corrects never practices getting better. So when the line moves, and AI is moving it right now, you suddenly need a capability you never had any reason to build. What AI actually asks of you AI does not just add obligations to your list. It brings a kind of obligation no fence can hold. Promises kept by non-human agents. You cannot audit an agent into keeping a promise. Agents must be regulated in real time. System controls, not internal controls. Closed-loop, not open-loop control systems. Continuous assurance across the operational lifecycle. Not a point in time. Not once a year. Requisite capability for real-time oversight. If the system moves faster than you can respond, you are not regulating it. That is just Ashby's Law showing up in your compliance program. Accountability that cannot be delegated, no matter how far the value chain extends or how autonomous the system becomes. Every one of these needs a purpose, a goal, a centre to align to. None of them can be met by staying inside a line, because for AI there is no line. Nobody has drawn one yet, and by the time somebody does, the system will already have changed. The predictable response, and why it will not work Faced with this, most organizations do the obvious thing. They build a bigger moat. More audits. More attestations. More controls. More documentation. More governance oversight. More monitoring. More reporting. This is where the two default conversations lead. Better tools make the moat wider. Better regulatory mapping makes it deeper. Neither changes what the moat is for. Same behaviour, same practices, just more of them. That is not adaptation. That is doubling down on the thing that already got you here. From boundary to alignment There is another way for compliance to move forward. Stop minding the boundary. Start minding your direction. A centred-set culture asks a different question: is our work aligned toward our mission, our promises, our values, or away from them? The work is not building a bigger fence. It is aligning what the organization actually does with the outcomes it exists to produce. And because the centre is yours, so is the standard. Your values, your mission outcomes, your commitments become the bar you raise to get better. Nobody has to hand it to you, and nobody has to approve it. Wherever a program stands today, that work can begin. Raising that bar is also how you get ahead of risk. When you set it above where you are performing today, things that used to pass now register as excursions. Weak signals surface while they are still small, still cheap, and still far from causing harm. Wait at the boundary instead and you only learn when something crosses it, which is the moment risk stops being a prediction and becomes an event. From there the rest follows. You measure capability as a whole, not the holes in it. Governance guides and adapts instead of just watching. This is the culture that can respond to AI. The bounded-set culture cannot. How you build the capacity to adapt The real work is building the capability, competency, and capacity to adapt. This is often called continuous improvement, and you will find some version of it in every serious transformation program. Here is what most people miss about it. It is not the specific change that matters most. It is the practice of changing. The discipline of making changes continuously is what builds the capacity to adapt. But that is only half of it. The other half is guidance: improvement toward a bar that keeps rising. Safety researcher David Woods has written on this, calling it Guided Adaptability, a way of resolving what he frames as the command-adapt paradox in complex systems. You will recognize the same pattern if you have worked in Lean, Toyota Kata, Lean Six Sigma, Theory of Constraints, or systemic safety. Different tools, same pattern. Raise the standard. Adapt to meet it. Raise it again. Problems, issues, and gaps are not failures in this model. They are what make you stronger and more capable of confronting your challenges. Deciding to run a marathon is easy. Being able to run one is not. You train, over longer and longer distances, until you become the kind of runner who can run marathons. Your compliance future works the same way. It is about who you are becoming, more than who you are right now. Where this leaves compliance The path forward has already been walked by others. Lean walked it. Theory of Constraints walked it. Compliance, for the most part, has not. Do not wait for the next obligation, or the next AI system, to breach the fence before you start. The fence was never going to hold on its own. Build the capability now: closed-loop controls instead of open-loop ones, programs that steer instead of just watch, capacity to handle risk and uncertainty before they show up at the edge. That is not something you assemble after the breach, and not something a higher fence gives you. Start now, on the road of continuous improvement and Guided Adaptability. That is the future of compliance in the age of intelligence. This is a summary of "The Future of Compliance in the Age of Intelligence," presented at the Elevate Compliance Huddle, session 99. If this resonates with what you are seeing in your own program, I would like to hear about it in the comments. About the author Raimund Laqua, P.Eng., PMP, is the Founder and Principal Engineer at Lean Compliance. He works with organizations across safety, security, sustainability, quality, and regulatory compliance, applying engineering discipline and systems thinking to a practice that has long relied on audit and inspection. His focus is helping companies stay between the lines, ahead of risk, and on mission. He hosts the Elevate Compliance Huddle, a series that takes on a critical aspect of modern compliance each session. Huddles run weekly for members and open to everyone about once a month. Registration details are on the Lean Compliance website.

Structural governance asks: are we inside the line? Directional governance asks: are we going to make it? Nearly every governance instrument we have answers the first question. The risk register. The control matrix. The attestation. The RAG dashboard. The assurance map. Not one of them answers the second. A ship inside its shipping lane is not thereby on course. Four years ago I wrote about bounded-set and centred-set compliance. A bounded set is defined by a boundary and your relation to it — in or out. A centred set is defined by a centre and your direction of movement relative to it — towards or away. I have been applying that distinction to compliance ever since. Lately I have applied it to governance, and it splits the same way. Structural governance keeps us within the boundaries. Directional governance steers us towards the centre. Most organizations assume they are doing both. Three questions will tell you which one you are actually running: Can it tell you its heading, or only its position? Does it correct after deviation appears, or before? Is anyone accountable for the centre — or only for the lines? The word itself carries the answer. Governance comes from kybernētēs — the steersman. Not the fence. The tiller. And safety science has been telling us for thirty years that organizations drift into failure even when everyone complies with the rules. Which means inside the lines was never the same thing as on mission. The original article is below. I would be interested in where you think the distinction holds — and where it breaks down. Bounded-set Versus Centred-set Compliance Keeping you on-mission, between the lines, and ahead of risk.

The revised standard is close. ISO/TC 176/SC 2 has completed the technical revision and submitted the Final Draft, with publication expected in September 2026. Organizations then have a three-year transition period, to September 2029. The revision is an evolution rather than a rewrite — the process approach, the harmonized structure, and the core requirements stay. What's new is context. Among the themes carried through the drafts is digitalization, with reliable data treated as essential to how information, machines, and processes are actually worked with. What ISO 9001:2026 requires The standard treats reliable data and connected information as essential to how work is done. Meeting that means being clear about three stages, which are easily confused. Digitization puts existing information into digital form. Procedures become PDFs, records become database rows. Digitalization connects that information and its tooling so the work itself is done better. Digital transformation changes the practice — the model becomes the authoritative basis of the work. An eQMS puts quality records where they can be found. That is digitization, and it is worth doing. What it does not change is operational. Whether processes are performing as intended. Whether risks are being controlled while the work is happening. Whether nonconformity is caught early enough to matter. Quality obligations are met in operation, not in the document that describes them. Digitalization connects the quality system to the work it governs, so those obligations can be seen, managed, and met as operations run. The requirements are model-shaped Look at what ISO 9001 has always been built on: the process approach, risk-based thinking, control of change, organizational knowledge, and evidence that requirements have been met — by the product or service, and by the system meant to deliver it. Every one of those is model-shaped. A process approach is a model of how work flows and where it can fail. Change control is impact analysis. Organizational knowledge is a maintained model of how the organization actually operates. A management system is a regulator. And a regulator can only be as good as its model of the thing it regulates. What digital engineering supplies In practice that means a system model of the management system — objectives, processes, obligations, risks, controls, and the information connecting them — coupled to the systems that execute the work, so it reflects what runs rather than what was written. Evidence traced to the requirements it satisfies. Change assessed against the model before it's made. Conformity demonstrated continuously rather than reconstructed before an audit. That coupling is the work of the digital twin and the digital thread — the twin keeping the model faithful to the organization as it operates, fed by what actually happens; the thread carrying traceability from obligation through process to evidence. The result is a management system that stays true to the organization rather than a description that drifts from it. Use the transition window Three years — from publication in September 2026 to the September 2029 deadline — is long enough to model the system rather than re-document it. Organizations that treat this as a re-papering exercise will arrive in 2029 with the same management system in newer software. Those that treat it as an engineering exercise will arrive with something that actually regulates the business. Reach out to us at Lean Compliance to learn how digital engineering supports the digitalization strategies that transform a quality program — and meet the requirements of ISO 9001:2026. Raimund Laqua, P.Eng., PMP, is founder of Lean Compliance, where his work includes engineering assurance — the practice of showing that systems and the obligations attached to them are actually being met. Through E4P (Engineers for the Profession) and OSPE, he is working to define digital engineering as a recognized engineering discipline and professional practice, and advocates for federal licensure of digital engineers.

PDCA Applied to Obligation/Promise Cycle An obligation is a requirement the organization must fulfil. It may be mandatory or voluntary, external or internal, and it stays active for as long as it is imposed or adopted. A promise is a voluntary commitment made by an agent about its own behaviour. Obligations give rise to promises. That is how an obligation becomes operational. The cycle runs between them. Obligations produce promises, promises are kept through operational capability, and what that capability delivers is assessed back against the obligation. PDCA belongs on this cycle. Where you place it determines whether you get a management ritual or a working regulator. Why PDCA belongs here at all Lean and compliance are separate disciplines working on the same problem. Variation that escapes control produces waste, creates risk, and results in non-compliance. Those are three expressions of one condition. PDCA came out of that same problem. Shewhart built it for variation. Deming taught it as a way to learn about a system. PDCA gives you four questions. What are we promising. What will produce it. How will we know when it drifts. What will we do about it. You answer them once, when you design how a level regulates itself. Answering is a sequence. The four functions the answers describe are concurrent. They run at the same time, at different speeds, for as long as the work continues. Plan and the positive prior You cannot detect what is missing until you have defined what should be present. Every compliance failure is an absence, and an absence only makes sense against a stated presence. Plan is where the presence gets stated. The obligation gives the requirement. The promise states what the organization will do about it, written so someone else can assess it, with an obligation owner named, a stakeholder entitled to judge it, and a date it took effect. How much and what work this takes depends on the regulatory design of the obligation. A rules-based obligation arrives nearly specified. Store personal data in encrypted format. The promise adds little beyond scope and ownership. A practice-based obligation names a body of practice and leaves interpretation to you. Implement process safety management. The promise has to say which elements, to what depth, and how competence is established. A performance-based obligation gives a measurable target and leaves the means open. The promise states the path to it, with reference points close enough together to detect drift. An outcome-based obligation gives an end result and nothing else. Ensure process safety. Achieve net zero. Nearly all the specification work is yours, and this is where obligation debt accumulates fastest. Most registers cover rules well and thin out toward outcomes. Voluntary obligations mostly sit at the outcome end, which is why ESG targets and community commitments are so often unmanaged. The four functions on a single obligation Take a commitment to reduce carbon footprint by thirty per cent within three years. Plan sets the reference. The thirty per cent is the requirement. It states an endpoint and nothing else. The promise states the path. Which sources are in scope, what will be done to each, and what the footprint will be at the end of each year. Without those interim points there is nothing to compare against until the deadline has passed. Do produces the behaviour. Equipment replacement, fuel switching, procurement terms, changes to how work is scheduled. Operability is the question here. Whether the budget, the people and the authority exist to deliver the reductions the promise depends on. Check detects deviation. Measure the footprint against this year's point on the path, often enough that a shortfall can still be recovered. Reporting once a year on a three year commitment gives you two chances to correct. Act changes the means. Bring projects forward, add capital, change suppliers. When the range of responses runs out, the level escalates. The failure to watch for is the target moving instead. A rebaselined starting year, a narrowed scope, offsets bought to close the gap in the report. Every obligation in the register can be walked this way. Where the walk stops is the finding. Most stop at Plan, with a target and no path. What Check has to reach Adherence and conformance are where most measurement stops. Are we doing what we said we would do, and does our approach meet the accepted standard of practice. Both are necessary and neither tells you whether the promise is being kept. Performance asks whether the targets are being met. Effectiveness asks whether the work is producing the outcome the obligation exists for. Integrity asks whether stakeholders can trust the organization to keep delivering on their obligations. The effectiveness gap opens between effort expended and outcomes achieved, and it stays invisible to a measurement system that stops at conformance. Audit tells you what happened. Assurance tells you whether the promise will keep being kept, and it is built from operational capability and continuous monitoring rather than periodic inspection. The same functions at every level Level Primary behaviour What its loop regulates Speed Governance Sets direction The promises the organization makes Years Programs Introduces change Capability being built Months to two years Systems Resists change Variation around control limits Weeks to months Processes Does the work Accuracy, timeliness, completeness Hours to weeks The tension between programs and systems is designed. Programs are the engines of adaptive control, introducing change to build capability. Systems are stabilizers, damping variation to hold what has been built. Both run the four functions and their loops pull against each other, which is healthy while each stays inside its own mandate. Requisite variety applies at each level. The range of responses available has to match the disturbances arriving at that level's speed. When everything escalates to governance, the lower levels were never given a range. When nothing escalates, the signals generated by processes are not reaching the levels above them. Reading your register Obligation debt is the volume of obligations left unaccounted and unmanaged. You can see it in the column headings. Most registers carry the obligation, its source, applicability, an owner and a status. The missing column is the promise. Add it, sort by it, and the blanks are your obligation debt. Then look at what status measures. Status is usually implementation. The procedure was written, the training was run, the control was installed. That is a project measure, and it says nothing about whether the thing operates under the conditions you face. A register built on implementation status will show a mature program on the morning the control stops working. Who promises Every obligation has an obligation owner, a named individual with delegated authority and accountability for fulfilment. Promises are made by autonomous (but supervised) agents, and an agent may be a person, a team, or a system able to declare what it will do within its own capability and monitor its own fulfilment. Accountability does not transfer to the system. When a promise in the register has no person behind it, the review after a failure ends with a description of what the equipment did. Try this Pick one obligation. Walk it. What does it require, and is it rules, practice, performance or outcome based. What have you promised, and who owns it. Can the organization operate that promise today. What does Check measure, and does it reach past conformance. What is this management level allowed to change when the promise is missed. Documentation shows intent. Only operations deliver outcomes.