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.

Every so often I take stock of where compliance actually is as a discipline, compared to where the effort we pour into it says it should be. The honest answer has bothered me for some time, and I want to work through it with you here. Compliance has never had more resources. More frameworks, more software, more staff, more attention from the board than at any point in my career. By almost any measure of activity, the field has grown enormously. And yet, measured the only way that really matters, whether obligations are actually being met and not merely documented, I struggle to see the advance. The activity has multiplied. The outcomes have barely moved. The reason is specific, and I have written about it many times. Most organizations measure conformance, and some measure performance, but almost none measure effectiveness. They can tell you whether the procedure was followed, rarely whether any of it is achieving the outcome the obligation exists to produce. Effectiveness matters most, and it is the measure we most consistently leave on the table. That blind spot is where compliance stalls. This blind spot rests on a handful of assumptions about what compliance is, most of them absorbed rather than chosen. Each sounds reasonable until you hold it up to the light. Conformance is not performance, and neither is it effectiveness Almost every obligation written as a procedure can be read more than one way. One reading asks whether the procedure was followed. That is conformance. Another asks whether it hit its targets. That is performance. A third, the one that matters most, asks whether it produced the outcome the procedure exists to produce. That is effectiveness. An audit tests conformance. It was never built to test effectiveness. This is not a flaw in auditing, it is simply what auditing is. But it means an organization can conform completely, pass every audit, and still not be effective at meeting the obligation. "But we pass our audits" proves something real. It is just not the thing it gets heard as proving. Audit is not a substitute for the act of compliance. Compliance is two kinds of work, and we fund one Meeting an obligation takes two distinct kinds of work, and keeping them separate clarifies almost everything. There is the work that meets the obligation itself: securing the system, keeping the hazard contained, delivering the quality. I call this promise keeping. And there is the work that gives us confidence the promise is being kept: the controls, the audits, the evidence. This is assurance work. Compliance is both. But most programs fund the second and assume the first takes care of itself. If you want to know which half your organization truly values, look at what the budget actually pays for. Even assurance comes in two strengths There is a further distinction inside assurance, and it explains a great deal about why some domains advanced and others did not. Audit based assurance offers an opinion, samples evidence and looks backward, attesting to what the sample showed. An engineering demonstration does something different in kind. It verifies the design, tests the performance, and monitors the operation. It builds a case that the system will keep its promise, rather than an opinion that it probably did. Most compliance functions are staffed and led from the audit tradition, including in industries that plainly need the engineering kind. And so the weaker form of assurance becomes the house standard, not because anyone decided it should, but because it is what the people in the room were trained to produce. We reward the absence of bad news "No findings" is a comfortable phrase. But it only tells us the checking caught nothing. It does not tell us the work is being done, and it certainly does not tell us the work is effective. A clean audit file is cheap, familiar, and reportable this quarter, while real capability is expensive and slow to show its worth. Budgets drift toward what reports well, and then we mistake what reports well for what works. Effort is not the same as results, and compliance of all disciplines should know better than to confuse the two. An obligation accepted is not a promise made Watch how a new obligation usually enters an organization. It gets logged, assigned to a function, and a policy gets written for it. At no point in that sequence did anyone with the capability and the resources to deliver actually commit to it. That is acceptance, not a promise. A real promise has a name attached and a capacity check behind it. Sometimes the name is withheld on purpose, because a clear promise leaves a clear trail if it is not kept. Ask who actually owns the ESG pledge on the website, or the AI principles in the annual report. Where the honest answer is nobody, the obligation was accepted, not promised, and every control built on top of it is standing on nothing. Implementing controls is not the same as meeting the obligation Many treat implementing controls as meeting the obligation. That is true, but only up to a point, and the point matters. The purpose of a control is to deliver a targeted outcome. But most control frameworks in compliance are built from internal controls, not system controls, and the difference is not academic. A system control regulates effort toward an outcome, the way a thermostat regulates temperature or an interlock regulates a hazardous process. It senses, compares against a target, and corrects. An internal control does none of that. It checks that a step occurred, an approval was obtained, a record exists. It is administrative at best, and it regulates nothing. So when we implement a control framework and call the obligation met, we have usually installed a set of administrative checks and left the actual outcome ungoverned. The obligation was to keep the system secure. What we built was a record that someone was supposed to. When the outcome drifts, nothing in the framework steers it back, because nothing in it was regulating the effort in the first place. The confusion underneath all of it The same confusion runs through every one of these. We have let the checking stand in for the keeping, allowed assurance work to become a proxy for the work it was only meant to observe. And because effectiveness is the one thing we rarely measure, the substitution goes unnoticed. Everything looks compliant right up until the obligation is not met. None of these answers were chosen so much as inherited, from audit practice and from the GRC market. They were reasonable for a different kind of work, and they became standard practice without ever being examined. That, more than any budget line, is what holds compliance in place. A path forward What keeps this from being hopeless is that other disciplines have already solved it. Safety and quality faced the same confusion decades ago and worked their way out, not with better paperwork, but by designing the obligation into the facility, the equipment, the systems, and the processes. They made meeting the obligation the point, and treated assurance as evidence that it can rather than a substitute for it. What they did was stop treating compliance as procedural and start treating it as an operational capability, something designed, resourced, and continuously regulated toward an outcome, the way any critical function is. It is not a new idea. It is only new to compliance domains built on the audit tradition. Compliance advances when the work of compliance is effective at meeting obligations, and when we can show, with evidence, that it is. Effectiveness is a property of the program, not the paperwork. Everything else, the frameworks, the software, the audits, earns its place only by making that work more effective. The question I leave you with is the one I keep asking myself. How much of your compliance program produces outcomes, and how much of it only produces evidence?

The information technology era is ending, at least in part. It collected data and moved it to where it was needed. Intelligence technology is different. What that era becomes is not settled. It is being decided now, in procurement decisions and architecture reviews, by the answers being given to questions like these. 🔸 𝗔𝗱𝗼𝗽𝘁𝗶𝗻𝗴 𝗔𝗜 𝘃𝗲𝗿𝘀𝘂𝘀 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗔𝗜 Adoption selects a vendor and measures uptake. Engineering establishes that a system is safe, reliable, and capable of delivering benefits before it is used. We chose adoption, and the engineering phase was declared unnecessary rather than skipped. Whether an application demands engineering is a decision to make before procurement, not after an incident. 🔸 𝗛𝘂𝗺𝗮𝗻 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗜 𝗟𝗼𝗼𝗽 𝘃𝗲𝗿𝘀𝘂𝘀 𝗔𝗜 𝗶𝗻 𝘁𝗵𝗲 𝗛𝘂𝗺𝗮𝗻 𝗟𝗼𝗼𝗽 In one arrangement the person originates the work and the system assists. In the other the system originates and the person approves. The same phrase describes both, and most deployments claim the first while running the second. Name the act the human performs and you will know which loop you are in. 🔸 𝗦𝗽𝗲𝗰𝗶𝗳𝘆𝗶𝗻𝗴 𝗢𝘂𝘁𝗽𝘂𝘁𝘀 𝘃𝗲𝗿𝘀𝘂𝘀 𝗦𝗽𝗲𝗰𝗶𝗳𝘆𝗶𝗻𝗴 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 Outputs say what must be produced. Process says how, and process is where quality, safety, and security are made. Specify only the output and anything optimizing for it will remove the rest. Decide which parts of the process must stay before the work starts, because afterwards there is nothing left to regulate. 🔸 𝗚𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲 𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝘀 𝘃𝗲𝗿𝘀𝘂𝘀 𝗔𝗜 𝗥𝗲𝗴𝘂𝗹𝗮𝘁𝗶𝗼𝗻 Governance controls act once, at a boundary. Regulation acts on a system while it runs and corrects the difference. A guardrail restrains while a regulator steers. Ask what corrects the behaviour while it is happening. If the answer is a report read afterwards, nothing is being regulated. 🔸 𝗥𝗶𝘀𝗸 𝗔𝘀𝘀𝗲𝘀𝘀𝗺𝗲𝗻𝘁 𝘃𝗲𝗿𝘀𝘂𝘀 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗻𝗴 𝗨𝗻𝗰𝗲𝗿𝘁𝗮𝗶𝗻𝘁𝘆 A hazard is a source of uncertainty that creates the opportunity for risk. Risk assessment walks from hazard to failure mode to control, and with these systems that walk breaks at the first step, because how harm arises cannot be enumerated in advance. Evaluating uncertainty is different work: margin, reversibility, containment, and people close enough to notice. 🔸 𝗗𝗮𝘁𝗮 𝗜𝗻𝘀𝗶𝗴𝗵𝘁𝘀 𝘃𝗲𝗿𝘀𝘂𝘀 𝗠𝗮𝗻𝗮𝗴𝗲𝗱 𝗞𝗻𝗼𝘄𝗹𝗲𝗱𝗴𝗲 In the old model, intelligence sits between knowledge and wisdom and operates on what is known. Today's AI is inference over data, used as a proxy for both knowledge and intelligence, with the layers between skipped. A proxy for knowledge is not knowledge. Without managing your own, the inference runs on what it learned from everybody else. 🔸 𝗛𝘂𝗺𝗮𝗻 𝗢𝗻𝘁𝗼𝗹𝗼𝗴𝗶𝗲𝘀 𝘃𝗲𝗿𝘀𝘂𝘀 𝗠𝗮𝗰𝗵𝗶𝗻𝗲 𝗧𝗮𝘅𝗼𝗻𝗼𝗺𝗶𝗲𝘀 We describe these systems in words borrowed from human cognition. This is anthropomorphism, and it points to a category failure. Memory names three unrelated mechanisms. Reasoning names token generation. An ontology of AI comes first, built from what these systems are and do. A proper taxonomy follows from it. Most of these questions already have answers in use, carried over from the information era or supplied by vendors. Those answers were made for a different technology or for someone else's interests, and they are settling into practice unexamined. The model, the platform, and the tooling can be bought. The engineering, the regulation, the organization's own knowledge, and the accountability cannot. They must be built. 𝗛𝗼𝘄 𝗶𝘀 𝘆𝗼𝘂𝗿 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗳𝗿𝗮𝗺𝗶𝗻𝗴 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝗰𝗲 𝘁𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆, 𝗮𝗻𝗱 𝘄𝗵𝗼 𝗰𝗵𝗼𝘀𝗲 𝘁𝗵𝗮𝘁 𝗳𝗿𝗮𝗺𝗶𝗻𝗴? Raimund Laqua, P.Eng., PMP, is the founder of Lean Compliance Consulting and one of Ontario's first licensed software engineers. He works with organizations in highly regulated, high-risk sectors to build the operational capabilities needed to keep their promises, and is a national advocate for licensed professional digital engineering in Canada. He writes about compliance, engineering, and AI at leancompliance.ca.

Which one will you choose? Digital transformation has always been a challenge. Re-engineering a business to use new technology carries real risk, and more so when the benefits aren't easily realized. That is the part the current AI conversation keeps skipping. There are two ways to bring AI into a business, and they are not the same thing. You can adopt it: take the technology as given and fit the business around it. Or you can adapt it: start from the business you already have, with its obligations, standards, and commitments, and make the technology work for you, not the other way around. Start with the claims for adoption. They are familiar. AI will substitute labour. It will improve speed and throughput. It will do it better at scale. These are traditional technology productivity plays. More specifically, they are platform plays. Transfer your workflow from one system to another and call it transformation. We have seen this before. These productivity gains assume a greenfield. No friction, no obligations, no standards of performance already being met, and free of any negative consequences. On that field, substituting labour and adding speed always nets out positive, because there is nothing on the other side of the ledger. No real business is a greenfield. Every one is already meeting obligations, already holding standards, already regulating itself toward results. The benefit of technology has to be real on the field where the business operates, not on a straw man version of it. This is the doorman's fallacy. You cut the doorman to save a salary, then find out he was also deterring theft, greeting regulars, signing for deliveries, and noticing the leak before it became a flood. The line item said "opens door." The job was everything around it. Substitute the visible task and you drop all the value that was created around it. The economics of AI only get worse from there. It is not obvious there is a net benefit, particularly when the cost of AI is more likely to rise than fall. What will your token spend be? What are you giving up to get the claimed benefits? What will it cost to get there? Adoption seldom considers the work needed to adapt. That is the part every adoption pitch leaves out: Change Management. Here is what they get wrong. They treat the organization as the problem, not the technology. Any resistance is read as an obstacle, a sign of not being committed to AI. But change is resisted even when it is good, because we build systems to resist it. We hire people to follow procedures without variation. We build processes to make sure the rules are followed. We use feedback to hold conformance and to course correct when necessary. This is not an organizational design failure. That is the design. Organizations regulate, or govern, effort to advance intended outcomes, within constraints, so that value is generated, usually measured as margin. Resisting change is not a flaw. It is the standard of performance doing its job. The system you are being told to disrupt is the thing keeping the promises you have already made. This is not friction to be eliminated, whatever they call it. Resisting variation is what it takes to reach the goals you want and avoid the ones you don't. AI does not understand this, and neither do many of the people pushing for its adoption. Most of the AI conversation is about adoption. Very little of it is about adaptation. That is the gap, and closing it is where the real benefit lives. So the real work is not adopting AI. It is adapting it to your business, and your business to it. That takes people who understand how business works and how technology works. If that is not who is advising you, you are being sold a platform substitution, not real business benefits. Raimund Laqua, P.Eng., PMP, is the founder and principal of Lean Compliance, an advisory practice serving highly regulated, high-risk sectors. Over more than 30 years he has built compliance and assurance programs across oil and gas, pharmaceuticals, medical devices, manufacturing, and financial services, treating compliance as promise-keeping rather than rule-following. He is one of Ontario's first licensed software engineers, chairs the Digital Engineering Committee for Engineers for the Profession, and advocates for professional digital engineering licensure in Canada. He writes on AI governance, engineering assurance, and why technology should be adapted to the business, not the business to the technology.

ISO 42001 has quickly become a standard organizations reach for when they want to take AI seriously. It is the first international management system standard for artificial intelligence — a framework for governing AI across an organization, built in the same family as ISO 9001 for quality and ISO 27001 for information security. It is a genuine step forward, and for many businesses it can help. But before adding it to the shelf alongside your other management systems, it is worth asking one question: does your organization use AI, or does it develop AI? The answer decides whether 42001 is the right standard for your organization. Start with use. ISO 42001 is a management system standard. It helps you account for the AI you operate, govern how it is used, and assign responsibility for that use. If your business adopts AI built by others, this is exactly the work that needs doing, and 42001 is a reasonable choice. Developing AI is a different kind of work. When you design, build, or substantially modify an AI system, your obligation is no longer to manage its use — it is to engineer it. And engineering is not a set of internal management controls. It is professional practice: a discipline held to a standard outside the organization, carried out by practitioners accountable for the result. This is the line ISO 42001 anticipates but does not cross. It governs the controls an organization runs for itself, and for the engineering it points outward — to ISO 5338. ISO 5338 defines the lifecycle processes for building an AI system: the engineering work of data and model development, verification and validation, deployment, and the ongoing monitoring a system needs once it is operating and continues to change. It builds on the established engineering standards for systems and software, and adds what is particular to AI. This is the engineering standard for AI. It is not part of 42001, and 42001 cannot stand in for it. And this is not only about building from scratch. If you fine-tune a model, add guardrails, chain components, or integrate AI into a larger system, you have made engineering decisions, and the results are yours to stand behind. The discipline applies whether you create a system or assemble it from parts. Regulation is beginning to make this explicit. Under the EU AI Act, AI placed in high-risk settings — including as a safety component in regulated operations — must be designed and developed to achieve accuracy, robustness, and security, and to hold those qualities throughout its life. Those are properties built into a system through engineering. A chemical plant cannot satisfy a safety case by reporting that safety happened; it satisfies it by engineering the system to be safe. When AI carries real hazard, the law is naming what engineering has always required — engineered systems. None of this counts against ISO 42001. It is about matching the standard to the work. Manage the AI you use. Engineer the AI you build. One is internal management. The other is professional practice — held to a standard, carried by people accountable for what they build. Building AI requires the second, and most organizations have only set up the first. Closing that gap is increasingly what I am asked to help with. This work brings together three disciplines: engineering methodology, how AI systems are designed and built for the enterprise; project assurance, independent engineering judgment over the build; and AI compliance, obligations engineered into the system from the design stage rather than bolted on after. If you are developing your own AI systems — from scratch or on procured services — it is worth asking whether that work is being done as engineering, or simply handed to an IT or data team to develop. The two are not the same. The difference decides which standards apply to your work, and whether the system you build can be trusted. If you are not sure which standard to adopt, that is the conversation to have: leancompliance.ca/engineering-assurance

Many organizations are adopting AI in their business, whether as generative AI or as AI agents. In all cases, the AI needs a context to work from, and for the AI to be effective that context must be requisite. An AI model knows nothing about your organization. Everything it produces on your behalf rests on the context supplied at the moment of use. If that context covers what the task requires, the workflow can be trusted. If it doesn't, the model fills the gaps with public defaults and no one is told. Managing requisite context is how organizations keep their AI workflows on the right side of that line. Basic Context The model never learns An LLM's knowledge is fixed when it is trained. Once deployed, it doesn't learn, adapt, or accumulate experience. Its intelligence is applied to whatever is in the context window at the time of inference. Everything you need the model to know must be placed there, every time. Retrieval (RAG) extends what can be placed in context. It doesn't extend what the model knows. A document in the context window is being read, not understood. The model can quote it and summarize it. It can't connect it to everything else it knows, notice that it contradicts a commitment made somewhere else, or apply it to a question that doesn't resemble it. Trained knowledge is integrated into the model. Retrieved knowledge is only consulted. These are different capabilities, even though the output reads the same either way. The model's training works against you Public models are trained on public knowledge. An organization's working knowledge is mostly the opposite: commitments made, obligations held, decisions taken, how the organization actually operates. None of this is in the model. It gets worse. Where your knowledge differs from public consensus, the model's training pushes back. I have spent considerable time teaching AI systems what Lean Compliance means from an operational perspective. They follow the distinctions while the context holds them in view. As soon as the context thins, they fall back to the public default, where compliance means conformance and checklists. The knowledge that makes your organization distinctive is the same knowledge the model resists. Your context has to keep correcting the model, not just inform it. Requisite context Requisite context is the context necessary to properly govern the work. An agent draws on two sources: its training and its context. Context is what shapes inference to align with the organization's objectives, and it is the only source the organization controls. For any task, the requisite context is what the task demands. What must be supplied is that demand, minus what the model's training already covers, plus what it takes to correct the model where its training does not align with your institutional knowledge. This divides work into two classes. For some work, the prompt alone is sufficient context: summarize this document, draft this email. The task carries what it needs, and the model's training covers the rest. Agents do well here, and this is what most demonstrations show. Other work requires institutional knowledge sufficient to govern and shape it. That knowledge is contained in policies, procedures, obligations, and other institutional documents. Some of it can be supplied with the prompt, and some can be pre-filled through retrieval and embeddings. But supplying the organization's entire body of institutional knowledge with every request is not possible within the model's context limits, and would be costly even to attempt. And whatever is supplied, none of it improves the model's inference or teaches it anything. The question is always what exactly is needed for the work, and answering it is where institutional intelligence comes in. Without that judgment, the agent produces output that sounds competent but is shaped by public defaults rather than by the organization. The model will not close this gap for you. It fills every unstated requirement with defaults from its training. Nothing gets flagged. The output looks complete, hiding the fact that no one made those decisions. Organizations must manage requisite context Requisite Context The AI industry calls the technical side of this problem context engineering: designing the retrieval, memory, and pipelines that assemble what a model sees. That tooling delivers context to the model. It cannot decide what the context should contain. Only the organization can determine what its knowledge is, where that knowledge differs from public consensus, which workflows can be safely delegated, and who is accountable when the context falls short. This demands a different kind of knowledge management. Traditional KM served human readers who compensated for gaps, ambiguity, and stale content with their own understanding. AI workflows have no such reader. Where a person fills a gap with institutional knowledge, the model fills it with the public default. Knowledge must now be managed for machine consumption: explicit, complete, current, and marked for authority. Fit for inference, not just searchable. Requisite context does not assemble itself. It is an organizational capability. Organizations that deploy AI workflows without it will get confident answers based on the public average. The essential capabilities for today's Knowledge Management include: Knowledge codification. Institutional knowledge must be made explicit, current, and authoritative before it can be supplied as context. Much of what matters lives in unwritten commitments and operating norms that no retrieval system can fetch. Knowledge that carries obligations must be versioned, attributable, and revocable. Scope determination. For each class of AI workflow, list what a correct output depends on. If the list can't be completed, that tells you something important: requisite context cannot be supplied and the workflow should not be delegated to an agent. Interference assessment. Identify where your organization's knowledge differs from public consensus. These are the points where the model will revert to public defaults, and they need explicit, persistent context. Context provisioning. Assemble and deliver the right context to the right workflow through governed means, not ad hoc prompts and pipelines built by whoever happens to write them. Sufficiency testing. You can't prove context is sufficient, but you can test for when it isn't. Probe deployed workflows with questions where the correct answer depends on your knowledge and the wrong answer is the public default. If you get the public answer, your context isn't enough. Drift monitoring. Sufficiency degrades in operation. Context gets compressed, sessions drift, and the model's training reasserts itself. Requisite context is a variable to be regulated, not a condition established once at deployment. The context an AI agent acts from is the organization's representation of itself. Keeping that representation faithful is a promise the organization makes to everyone who relies on the agent's outputs. That promise must be managed. Raimund Laqua, P.Eng., PMP is the founder of Lean Compliance and chairs the Digital Engineering Committee for Engineers for the Profession (E4P).

There was a time when safety was engineered into the business, the plant, and the operations. It required qualified engineers to ensure harm was avoided, and that risks, when they occurred, were mitigated. Systems were built with instrumentation, controls, and adaptive regulators to keep everything operating within safe limits. This was done so that everyone had the best possible chance of returning home to their families at the end of the day. Then someone threw a stochastic wrench into the works — an organizational hazard that was unregulated, uncontrolled, and did not follow the life-saving rules. They called it AI. They said it would help save lives. But it could not do that without first destroying the very means by which safety was assured. It eliminated the people who knew how things worked. It removed those who had our backs and kept us safe. This was not responsible AI. It was irresponsible adoption. A decision to proceed in the presence of uncertainty where there is the possibility of harm is an ethical choice. This should never be left to algorithmic or stochastic probabilities. This is what makes AI adoption an ethical choice. Choose Wisely. Raimund Laqua, P.Eng., PMP, is the founder of Lean Compliance and one of Ontario's first licensed software engineers. He helps organizations in safety-critical and highly regulated sectors build compliance that keeps its promises. He is a long-standing advocate for professional digital engineering and the accountable adoption of AI.

We just completed the final session in our series on the Golden Thread of Assurance. Assurance is the proactive means of providing confidence that obligations have been met, are being met, and will be met. It runs through everything critical to compliance — and it answers a question many organizations have had to ask: why did we have an incident when we had checked all the boxes? The boxes were checked. The thread was broken. The golden thread connects the spaces in between. It does not do the work of meeting obligations — it closes the gaps between the work that needs to be done. Checking boxes tells you the activities were done. The thread gives you confidence the obligation is actually met. So who is responsible for it? This is the work of compliance. Not preparing for audits, not even conducting them. The real work is assurance — providing confidence that an organization will stay between the lines, ahead of risk, and on mission. Every organization wants this. Most need it. Few have built it. Reach out to me to learn how the Golden Thread of Assurance can close the gaps in your compliance before they find you. — Raimund Laqua, PMP, P.Eng, Founder, Lean Compliance (ray.laqua@leancompliance.ca)

In this blog article we continue to explore the topic of cyber security or more rightly cyber safety. Cyber security mostly refers to protection from hostile forces which is a critical aspect of keeping what we value safe. However, it does not go far enough, cyber security must also protect against failure, breakage, or accidents. It must maintain a state of safety – the condition of being protected from harm or non-desirable outcomes which is what a managed cyber safety program does. A Managed Cyber Safety Program A managed safety program is an implementation of what is referred to as a "Safety II" approach with a focus on outcomes but may also incorporate attention to behaviors and activities as found in "Safety I". A managed cyber safety program will answer the following questions: What do we need to keep safe? What are the effects of uncertainty on safety objectives? What threatens safety? What and how strong do defenses need to be to achieve safety objectives? How do we maintain the performance of your defenses How do we continuously improve effectiveness? Answers to these questions form the context for the implementation of a managed safety system or Cyber SMS. To meet objectives of a managed cyber safety program we need a means of protection which we call "security" when it addresses hostile forces. In general terms, these are risk controls and measures. The level of protection is roughly speaking equal to the safeguards or margins that buffer us from the effects of the threats should they occur. The greater the effects, the greater the margin or buffers needs to be. We call this, "irreducible uncertainty." We can't reduce the threat from occurring, so we are left with creating a wall (safe guard) or at least buying insurance to address its effects. However, there is another kind of uncertainty, "reducible uncertainty", which we can buy down by improving our knowledge, our models, and our measures to prevent threats from occurring in the first place or minimize their effects should they manifest themselves. A managed cyber safety program will effectively address both kinds of uncertainty. It will safeguard against irreducible risk and buy-down reducible risk to provide the necessary total protection needed to keep what we value safe. It does this through a business-like approach that uses a systematic, explicit and comprehensive process for managing safety risk. This is reinforced by a risk-based culture where risk is viewed as something to optimize rather than ignore. Now, how is a managed cyber safety program implemented and managed? It's important to point out that many companies will most likely be doing many of the activities involved to manage cyber safety. Every company has a cybersecurity program, some are more effective than others. A managed cyber safety system will help you to coordinate your efforts more efficiently and effectively to ensure the safety outcomes that you have targeted are achieved and the undesirable outcomes are avoided. And that's a good thing. And that’s what we want. Cyber safety is not only a technical problem; it is a business problem that requires a business solution. A managed cyber safety system will therefore coordinate and manage two kinds of processes. Technical processes - are risk measures used to contend with threats, vulnerabilities, and risk. These are the controls to prevent or recover from threats to safety. Management processes - coordinate these controls, their performance, and their effectiveness at achieving a targeted level of safety. Both of these types of processes are needed to establish effective layers of defense and where any weaknesses in either will create an opportunity for a breach. Many companies invest in traditional cyber security which focuses on technology and equipment such as: firewalls, VPNs,, networks, software and so on. All of these are needed, but how much, and how well do they need to perform, and how effective do they need to be to achieve your cyber safety objectives? It is reported that 75% of companies do not measure the effectiveness of their compliance programs. This means that most companies do not know if their efforts are helping to prevent a breach or increasing the certainty of one happening. Companies that are effective at achieving their cyber safety outcomes will have the essential management processes to ensure safety is achieved, consistently, and that improves over time to address new uncertainties and risks as we are now experiencing with COVID-19. In our next blog article we will look into what a selection of available guidelines, standards, and frameworks available to help organizations realize their cyber safety goals.