The Governance Lag

AI becomes infrastructure before boards notice

Apr 30, 2026

We still talk about AI adoption as though it were a decision waiting to be made. In many large organisations, that decision has already been made elsewhere. AI arrives inside customer-service platforms, analytics suites, security tools, coding assistants, document flows, and fraud controls. It enters through contracts, updates, bundled features, and ordinary workflow changes long before a paper called “AI strategy” reaches the board.

Institutions usually realise what AI has become only after it has become difficult to remove. By then it is no longer a pilot or a slide in a strategy deck. It is part of the operating environment. Business units lean on it. Control functions begin to assume it. Directors are then asked to oversee systems they did not choose, cannot fully inspect, and would struggle to replace.

The governance problem starts there. Seen from that angle, this is an operational-resilience story first. APRA’s posture before April 30, 2026 already pointed in that direction. The March 2025 governance review found weaknesses in director capability, board performance assessment, and fit-and-proper processes across regulated entities. Its 2025-26 corporate plan put AI-related risk monitoring beside cyber resilience, CPS 230 implementation, and single points of failure. CPS 510, CPS 220, CPS 230, and CPS 234 complete the picture. Taken together, they ask for competent governance, control of material risk, continuity of critical operations during stress, and security proportionate to threat. None of this was drafted as an AI manifesto. It assumes management understands the systems the institution relies on and can act when those systems change shape. That assumption breaks down when critical capability arrives through fast-moving external services.

That does not mean every sector inherits the same risk profile, or that every AI feature becomes infrastructure. It does show a mechanism that travels well. Large enterprises buy software, outsource operations, and embed managed services into daily work. In each route, capability can arrive as dependence before governance catches up. Finance makes the pattern easiest to see because the control obligations are explicit. The same structure appears elsewhere whenever hospitals, manufacturers, or logistics firms inherit model capability through ordinary software updates rather than a declared AI programme. The underlying organisational problem is broader than finance.

The clearest frame for that dependence is a control loop. In that frame, the system being controlled is the institution’s operating environment: workflows, decisions, data flows, customer interactions, code changes, and attack surfaces. AI accelerates that system. Outputs change more often. Error finds more routes. Behaviour becomes less stable from one update to the next. The loop is everything the institution uses to keep operations inside tolerance: inventory, monitoring, escalation, validation, board reporting, policy, audit, and incident response. When sampling is slow, telemetry is partial, or no one has authority to intervene, the loop cannot stabilise what it claims to supervise.

A control loop that notices drift only after a workflow has been reorganised around a model is not much of a brake. By the time the risk paper lands, response time has already been spent. Recovery gets harder because the process, the people around it, and the service commitments have already adapted to the new dependency.

A risk committee that discovers a business-critical AI dependency only after the business has organised itself around it has arrived too late. What remains is drift recorded after the fact.

The live question is simpler and harsher: can the institution keep critical operations running, preserve decision quality, meet accountability duties, and recover when a model changes, degrades, is attacked, or disappears behind a vendor boundary?

That framing clarifies what boards do and do not need to know. Directors do not need transformer internals any more than they need to derive credit models by hand. They need a current map of model-shaped operations, the upstream components that can change without local approval, the providers shared across critical services, and the failure modes that default to unsafe. An institution that cannot produce that map is already carrying a resilience weakness. It just has not met the stress that reveals it.

Here the governance lag becomes concrete. Traditional inventories assume the organisation knows where important software starts and ends. Procurement assumes material features can be assessed at purchase. Audit assumes functions own bounded systems. Those assumptions fail when model capability appears in a platform update, sits behind an API layer, or gets woven into a workflow by a business unit chasing speed. Shadow AI matters, but hidden AI matters more. Shadow AI is a deliberate workaround: staff reach for tools outside the approved stack. Hidden AI sits inside the approved stack itself, which means the institution can inherit model dependence without ever treating it as a discrete decision.

Once that hidden dependence takes hold, concentration risk stops looking like routine vendor management and starts looking like shared-cause fragility. The Financial Stability Board has been moving toward that conclusion for years. Its cloud work warned that concentration creates oversight problems before it creates obvious systemic events. The 2023 third-party risk toolkit sharpened the focus on critical providers and correlated reliance. A 2024 paper on AI and financial stability added the missing layer. In paraphrase, the FSB’s point was that AI brings new forms of service-provider concentration, data dependence, model risk, and correlated behaviour. By late 2025 the FSB was tracking how control over the AI supply chain was consolidating among global technology firms.

The exact topology will vary by firm. That variation is the point. The same upstream dependency can be sold under different product labels and enter through different budgets. A single vendor stack, or a tightly coupled cloud-and-model pairing, can sit beneath customer support tooling, internal coding assistance, fraud triage, document handling, analytics, and parts of cyber defence simultaneously. The FSB’s concentration work points to the pattern: separate owners at the surface, correlated reliance underneath.

The same pattern of hidden correlation appears in cyber risk. In early 2024 the UK’s NCSC assessed that AI would intensify the threat by lowering barriers for less-skilled attackers and increasing the volume and impact of malicious activity. Defenders can gain automation, triage support, and improved detection. Attackers gain reconnaissance, phishing variation, code assistance, malware adaptation, and faster exploitation of ordinary weaknesses. This is not a symmetric tempo race. Attackers need one workable path. Defenders have to cover a wider surface, sort signal from noise, and respond before the next cycle begins.

Under AI conditions, time becomes a governance variable. Detection windows, escalation latency, intervention authority, and recovery time now determine whether governance is real or ceremonial. AI shortens the gap between vulnerability and exploitation. It also compresses the distance from configuration error to operational consequence, and from model update to downstream behaviour change. A cadence built for quarterly papers and annual policy review was already under strain in cloud-heavy environments. Under AI conditions it becomes a lagging instrument, able to sound diligent on the old timetable while missing the actual moment of change.

The lag is easy to hide behind healthy dashboards. Handling times fall, analysts clear more work, and code ships faster. Tickets close and documents move. Some of those gains are real and worth keeping. Teams do succeed with bounded uses: an internal drafting assistant, a call-summary tool, or a low-risk coding copilot can be governed adequately when outputs are reviewed, substitution is easy, and the manual fallback is still practiced rather than theoretical. But performance telemetry is not control telemetry. A workflow can become commercially useful at the same time it becomes harder to explain, harder to challenge, and harder to recover from.

That is the dangerous phase. Output quality improves, adoption spreads, and the surrounding process is quietly rewritten around the new tool. Meanwhile the oversight layer often samples less often than the tool changes. The vendor updates the model, product teams expand the automation, business leaders drop a review step because the results look better, and no one re-runs the original challenge at the speed the system is evolving. The business feels smarter because the local output improved. Its line of sight narrows because the mechanism producing that output is changing faster than anyone is watching.

Classic model-risk discipline still helps because it treats models as governed artefacts that require bounded use, validation, effective challenge, and aggregate oversight. In SR 11-7 terms, effective challenge means informed scrutiny with enough authority and independence to matter. SR 11-7 was written for more stable and inspectable systems than today’s vendor-managed generative tools. The older failure modes still look familiar: overreliance, shallow understanding, weak implementation, ignored limits. But there is also a qualitative break from the SR 11-7 world. With generative systems, validation is harder in practice, and the customer sees less still. Those weaknesses now spread through products many users do not even recognise as models.

Figure: NIST’s AI RMF Core treats governance as the cross-cutting function that informs mapping, measurement, and management. Source: NIST AI Risk Management Framework, Figure 5, published January 26, 2023, U.S. government/NIST public reuse basis.

The practical response is less glamorous than a separate AI bureaucracy and harder to fake than an AI principles document. Institutions need one dependency view shared across procurement, cyber, model risk, operational risk, and internal audit. They need a clear boundary between experimentation and production reliance. High-consequence uses need exit rights, manual fallbacks, or both.

Assurance fails when privacy reviews one slice, cyber another, procurement the contract, legal the liability, and model teams only what has been formally designated a model. Each function sees part of the system, while the loop as a whole has no owner. That is how institutions end up with plenty of governance activity and very little governance grip.

The board test is operational. Management should be able to identify the AI-enabled processes that now matter to service delivery or control effectiveness. It must trace the shared providers beneath them, state what can change upstream without explicit local approval, and show how the institution would continue if a critical system became unavailable, untrustworthy, or insecure. Knowing where the contracts sit is not enough. Management has to know where operational reliance sits. The standard is visibility that is current and clear: enough to recognise what matters, early enough to act before drift hardens into dependence, and practical enough to keep the organisation running when a critical service changes shape.

Not every AI use case demands the same intensity of scrutiny. A summarisation aid used in a reversible internal workflow is not the same thing as a model embedded in fraud controls, customer decisions, or cyber response. Scope, blast radius, and substitutability all matter. The problem begins when a helpful feature quietly becomes infrastructure. At that point the institution depends on something it has not named and supervises something it cannot easily pause.

As AI capability sinks deeper into ordinary enterprise tooling, adoption will look less like a series of deployments and more like a shift in the background conditions of operations. Governance built around project approval will keep missing that shift. The real movement happens through updates, dependencies, and delegated infrastructure. Governance built around dependence, control cadence, and resilience thresholds is built for the system that now exists.

We like to think progress arrives as a tool we can choose to adopt. Often it arrives as a condition we must learn to govern. First the system speeds up. Dependence thickens after that. Only later do we ask whether the people charged with oversight can still describe what the organisation now runs on, how quickly it can change, and who can slow it down. That is the real lag beneath AI adoption. In complex systems, power matters less than the ability to see drift and intervene before it hardens into dependence. What endures is the control loop that still lets us see the change and act before the dependency hardens.

Discussion about this post

Ready for more?

The Governance Lag

AI becomes infrastructure before boards notice

Further Reading, Background and Resources

Discussion about this post

Ready for more?