If your exco is still treating routine AI automation with the same friction as a core-platform replacement, former Sasol group CIO Lungile Mginqi outlines how to fix your decision design.
Technology change has always outpaced enterprise governance. AI has dramatically widened this gap. Decisions now arrive continuously, while boards still operate periodically. The predictable response is to demand faster governance: shorter packs, more meetings, earlier alignment between CTO/ CIO and CFO. I think that is the wrong diagnosis.
Most organisations I work with do not have a governance-speed problem. They have a decision-design problem. A reversible workflow change, an uncertain AI experiment and a multimillion-rand platform commitment are routinely pushed through the same approval machinery, regardless of consequence. Leaders conclude that governance is too slow, and that misdiagnosis keeps producing more committees instead of better classification.
The fix is not uniform speed but deliberate variation in decision speed: some decisions should move faster, others should face more friction. That requires three lanes: operate, explore and commit, deciding which decisions management may take, which may be tested within limits and which must escalate. AI belongs in all three: routine uses should Operate, uncertain uses should Explore, and consequential or dependency-creating AI should Commit. Amazon’s one-way-door distinction supports differentiated treatment of reversible and irreversible decisions; NIST supports iterative, risk-based governance; King V holds the governing body accountable for an effective technology governance system. None prescribes the lanes, but together they support governance proportional to consequence.
Escalation is not control
When a decision feels unfamiliar, organisations push it upward; when an initiative fails, another approval gate appears. Leaders believe this builds control; in practice, it industrialises permission-seeking. Managers learn that escalation is safer than judgement and the decisions that deserve scrutiny compete with noise.
Delegation is not abdication and oversight is not approval. If every technology decision needs senior sign-off, governance has produced management dependency, not control. That points straight at the real bottleneck: organisations are not classifying decisions badly. Most are not classifying them at all.
Governance design starts with classification
The first task of governance design is deciding which decisions deserve which level of authority and scrutiny. Most route decisions by project size or sponsor seniority, proxies that miss the question that matters most: can this be reversed quickly and affordably? Easy-to-reverse decisions should not carry the governance burden of decisions that constrain the organisation’s future options.
Ignore that distinction and three failures compound: delegation stays unclear because managers cannot say what they may decide without escalating, funding turns dishonest because experiments must manufacture certainty they lack, and visibility erodes because small decisions accumulate into exposure no single forum can see. The result is a paradox worth naming plainly: governance becomes heavy at transaction level and weak at system level.
Classification has to earn its keep. It fails the moment it costs more than the decision it simplifies, and just as badly if trusted blindly: any system that lets people classify their own decisions invites a hard commitment split into smaller ones, or delivery relabelled as experimentation. The proof point is retrospective review and real consequences for under-classification, not a scoring matrix. The lanes are the architecture through which technology and AI flow, with authority, funding and escalation matched to consequence.
Operate: autonomy inside guardrails
Operate covers reversible, lower-risk decisions inside approved budget, data, architecture and security boundaries. For AI, that includes approved copilots, coding assistants, internal search and productivity automation with human review. These uses should not return to a senior forum merely because they involve AI. Control comes from embedded guardrails and aggregated evidence, not another approval.
The pragmatist’s objection is fair: a decision can be reversible in isolation while irreversible in accumulation. Escalating everything again is not the answer; treating the portfolio, not the transaction, as the unit of governance is. The guardrails need scepticism too: automating a weak rule does not create strong governance, only faster weak governance, which is why exception data must redesign the rule, not enforce it.
Explore: bounded uncertainty, not open-ended experimentation
Explore is where many new AI use cases should begin, provided the downside can be contained. A limited agentic workflow, customer assistant or forecasting model can be tested with a hypothesis, capped funding, approved data, human oversight and a fixed evidence date. The FCA sandbox and NIST reinforce the principle that uncertainty can be governed iteratively.
But uncertainty alone does not earn a decision, a place in Explore; it is the home of uncertainty whose downside can be bounded. Safety-critical AI, unsupervised customer-facing agents or consequential decisions at scale belong in Commit, or should not proceed. At the timebox’s end, the call is Scale, Fix or Stop. A pilot that gains users, sensitive data or operational dependency can become a Commit decision. Lane membership is a state, not a permanent identity.
Commit: where the evidence burden should rise
Once the downside cannot be contained easily, the decision moves to Commit. This includes AI making credit, insurance, employment or eligibility decisions, autonomous agents at scale, AI in critical operations, strategic model dependency, core-platform replacement and material cyber-risk acceptance. These cross a one-way door, so the case must show the dependencies created and how the organisation could exit.
The objective is not a thicker business case; thick documents still hide weak decisions. It is an inspectable commitment: what must be true, what remains uncertain, what would change the recommendation. Cost of delay belongs in that evidence, but it must be demonstrated, not asserted. Urgency changes the clock, not the risk.
The governance compact that makes the lanes real
The lanes become real only when translated into decision rights, capital rules and escalation triggers. The CIO or CTO and CFO should lead that design, with risk, legal, cyber and architecture shaping the boundaries rather than reviewing decisions afterwards. Operate draws from agreed budgets; Explore receives capped learning capital tied to a hypothesis and evidence gate; Commit receives staged investment as the case matures.
This carries its own failure mode: a compact built on the language of discipline can quietly become Finance controlling technology choices rather than capital. The CFO governs how capital is released and whether the evidence is credible, not which architecture or vendor is right.
Prove it on one portfolio before redesigning the whole system
Do not start with a year-long redesign. Take one live AI portfolio for 90 days. Month one: classify every use case and record disputes. Month two: let low-risk AI Operate, run uncertain use cases in Explore, and route consequential AI through Commit. Month three: review what moved, what was under-classified and what changed lanes, then adjust the thresholds.
The proof is evidence that useful AI moved faster, uncertain AI was bounded, and consequential AI surfaced before becoming difficult to reverse.
Governance must design the architecture, not manage the approval queue
Effective governance does not prove control by approving more technology work. It proves control by showing that authority was deliberately allocated, experiments were bounded, material commitments escalated, and exceptions produced consequences.
This is consistent with King V’s outcomes-based approach: the governing body is accountable for the effectiveness of technology governance, not for approving every technology decision. The board owns the effectiveness of that design; it may delegate decisions, but not accountability for whether the decision system works.
None of this removes the need for judgement, and I am not claiming that it does. The model cannot eliminate politics, weak leadership or bad risk appetite. What it does is surface the consequences faster, at the level where they belong.
So start here. Pull the last 10 AI and technology decisions that reached your exco or board. Which low-risk uses should management have approved? Which were experiments dressed up as investments? Which consequential uses arrived only after scale or dependency made them difficult to reverse?
If most still travelled upward, your governance system is not protecting speed or accountability. It is protecting indecision: heavy where it should be light, light where it should be heavy, and silent on the pattern building underneath both.
That silence is the real cost, not the slow meeting. Governance cannot move at the speed of technology disruption, and it should not try. Its purpose is to create the decision architecture that allows the organisation to move at that speed without losing control.
