Speed by design

The cost of deploying without design

The cases are instructive and increasingly specific.

In February 2024, Air Canada became the first major organisation to have legal liability established for a chatbot's incorrect advice. A customer who received erroneous information about bereavement fare eligibility was awarded compensation after the British Columbia Civil Resolution Tribunal ruled that Air Canada was responsible for all information on its website, regardless of how it was generated. The financial exposure was modest—$812 in compensation. The governance precedent was not: organisations cannot disclaim responsibility for the outputs of systems they have deployed.

IBM's Watson for Oncology, into which more than $4 billion was invested over a decade, was discontinued after independent validation studies found its treatment recommendations conflicted with clinical judgement, in some cases unsafely. The system had been trained on hypothetical synthetic cases rather than real patient data—a foundational design error that was invisible until the system was tested against clinical reality at scale.

Amazon's recruiting AI, deployed to accelerate hiring across its technology division, was discontinued after it was found to systematically downrank female candidates. The system had been trained on a decade of historical data that reflected a predominantly male workforce. The bias was not an error in the model. It was an error in the architecture—specifically, in the failure to define fairness criteria before training began.

In each case, the common factor was not the technology. It was the absence of design before deployment. Data standards, accountability frameworks and risk thresholds were either undefined or applied after consequences had already emerged. Remediation was costly, visible and in some cases irreversible.

The cost of designing too long

The opposite risk is equally consequential, and less often acknowledged.

Extended diagnostic phases, sequential approval cycles and blueprint processes that produce documentation rather than decisions create the appearance of rigour while eroding the conditions for it. Meanwhile, local experimentation proliferates. Functions adopt tools independently. Shadow technology embeds. Informal practices harden into de facto standards—and by the time formal governance arrives, it is governing a landscape that has already formed without it.

Seventy-two per cent of business leaders report suffering from analysis paralysis in the context of AI adoption. Organisations that stall on governance design do not achieve governance. They achieve fragmentation at a slower pace.

The governing challenge is precise: design sufficiently to steer, but not so extensively that the enterprise stalls.

Upfront design is not delay

This requires a clear distinction between decisions that must be made before material deployment—data ownership, decision rights, risk thresholds, integration principles—and decisions that can and should be made iteratively, as deployment reveals what the organisation actually needs. Getting that distinction wrong in either direction is expensive. The risk in one direction is structural fragmentation. The risk in the other is competitive irrelevance.

What proactive governance requires is not a comprehensive blueprint. It is a reference architecture: explicit definition of a small number of foundational decisions before material exposure is committed.

Those decisions are not optional and cannot be deferred:

• •Enterprise data ownership and stewardship. Who is accountable for the quality, consistency and access of data that AI systems will depend on. This is an executive decision, not a technical one— the people whose choices shape what data exists, in what form, with what governance, are business unit leaders, CFOs and COOs.
• •Decision rights across functions and platforms. Which capabilities can be deployed at business- unit level, which require central approval and which require board-level oversight. Ambiguity here does not slow decisions; it means decisions happen without accountability.
• •Risk thresholds and escalation logic. What constitutes acceptable exposure in each deployment context and what triggers escalation to senior governance. Without these, risk appetite exists only in principle.
• •Integration principles. What must connect to the enterprise core before an AI capability can progress from contained pilot to production, and what can remain isolated while learning continues.
• •Stability constraints. What must not change as other elements evolve—the fixed reference points against which adaptation is deliberately evaluated rather than reactively managed.

When this baseline architecture exists, changes can be evaluated against enterprise logic rather than negotiated case by case. Adjustments become deliberate recalibrations. Governance becomes directional rather than obstructive.

JPMorgan Chase illustrates the compound return on proactive design. Before scaling AI across 60,000 employees, the organisation built four foundational pillars: a top-down mandate with significant investment, proprietary data and technology infrastructure, a managed portfolio of use cases, and a rigorous governance and talent architecture. The outcome included a 95 per cent reduction in anti-money laundering false positives and a projected $2 billion in AI-generated value. The result was not despite the architecture. It was because of it.

Iteration within guardrails

Once the reference architecture exists, transformation must proceed iteratively—but within defined boundaries.

Pilots imply reversibility. Structural AI integration does not. The distinction matters practically: testing in a contained domain with explicit exit criteria is fundamentally different from deploying into core operational workflows without defined governance for progression. The first generates learning that can inform the next decision. The second generates capability that the organisation cannot reliably observe, correct or account for.

Iterative integration—learning within guardrails, with defined criteria for progression from contained domain to production—is what separates organisations that build compounding capability from those that accumulate tools.

McKinsey's research on transformation success rates is consistent on this point: organisations that pursue a rigorous approach across governance, culture and leadership visibility see success rates more than double, from 26 per cent to 58 per cent. The technology components matter. But they are consistently not the differentiating factor between success and failure. Design discipline and leadership clarity are.

The Learning Loop

Design-led governance establishes the architecture—the principles, thresholds and decision rights that shape how AI is deployed. But architecture without feedback becomes obsolete. The third leadership behaviour that this model demands is not driving or demonstrating: it is learning—visibly, structurally, and at pace.

Traditional governance operated on periodic review cycles. AI programmes do not. They surface learning continuously: through deployment data, user adoption signals, edge-case failures and unexpected performance gains. If that intelligence is not captured and fed back into design, the framework governing deployment is always catching up with the reality it is meant to govern.

The organisations closing this gap are building what might be called a learning loop—a structured mechanism through which operational experience informs design, and design governs the next iteration. It operates through three practices:

• •Structured feedback from edge to centre. Frontline teams encountering AI performance issues, workarounds and unexpected outcomes have the mechanisms to surface those signals—not informally, but as designed inputs to the governance framework.
• •Shared learning infrastructure. Individual and collective learning are not left to happen by chance. Teams that have navigated a deployment challenge share that knowledge explicitly, through after-action reviews, shared playbooks and cross-functional learning sessions that build institutional capability.
• •Governance as living design. The framework is not fixed. It is reviewed and updated in response to what the organisation is learning—adjusting thresholds, revising principles, updating decision rights as the reality of deployment evolves.

This is the distinction between iterative integration and exploratory proliferation. Both move fast. But iterative integration moves fast within a learning system—one where pace is informed by evidence, governed by design, and continuously improved through shared experience. This is what makes speed sustainable, and what transforms governance from a constraint into a competitive capability.

Governing risk velocity

The AI enterprise introduces a category of risk that conventional governance frameworks were not designed to manage: velocity.

In August 2012, Knight Capital Group deployed a new algorithmic trading system with a residual configuration error. Within 45 minutes the error had generated more than 4 million unintended trades and produced losses of $440 million—equivalent to four years of the company's earnings. Knight Capital ceased to exist within days. There were no humans in the loop capable of intervening at the speed the system was operating.

That event predated the current generation of AI by more than a decade. The risk profile it illustrates— automated decisions compounding at machine speed, outpacing the governance mechanisms designed to manage them—is precisely the dynamic that AI integration is now introducing into operational workflows across industries, at far greater breadth.

Boards and executive teams are structurally underprepared. PwC's 2025 research found that nearly half of executives consider AI a major risk to their organisations—but only 10 per cent of board directors agree. That gap is not a difference of opinion. It is a structural blind spot. Deloitte's 2025 boardroom survey found that 66 per cent of board members report limited to no knowledge or experience with AI—a significant deficit in a risk environment that is accelerating, not stabilising.

Governance calibrated to manage risk velocity requires specific mechanisms that most governance frameworks do not yet have: clear architectural ownership at enterprise level; decision forums whose cadence matches the pace of deployment; defined authority thresholds below which deployment can proceed without escalation; and pre-agreed routes for when those thresholds are exceeded.

Governance that reacts after deployment is insufficient for this environment. Governance that precedes deployment and is calibrated to the operating speed of what is being governed, is stabilising.

What this asks of leaders

For CEOs, the implication is clarity of architectural intent. The foundational design decisions—data ownership, accountability frameworks, risk thresholds, decision rights—are not questions for the technology function. They are questions about how the enterprise is structured. Delegating them to IT is the most reliable mechanism for ensuring they are answered too narrowly and too late.

For COOs, it demands governance models built for throughput, not obstruction. A governance structure designed for quarterly review cycles cannot effectively govern AI deployments operating on daily or hourly iteration loops. Decision cadence must match capability velocity. The question is not whether to approve, but whether the approval architecture can keep pace with what it is approving.

For CFOs and risk leaders, AI integration reframes what financial control means. Exposure now sits inside workflow design, not downstream from it. A model that automates a procurement decision, a credit approval or a customer resolution carries financial consequence at the moment of deployment—not at the moment of audit. The control question must move upstream accordingly.

For Boards, the structural oversight question is whether speed is being absorbed within defined guardrails—or informally, in the gap between governance frameworks and operational reality. PwC found that nearly 80 per cent of technology, media and telecoms board directors believe AI receives insufficient boardroom attention—the highest of any industry sector and nearly double from 2024. The implication is that AI risk is accumulating faster than board oversight is developing.

Four disciplines are decisive:

• •Design before material exposure. Commit capital and operational risk only after defining the reference architecture. This is not a full blueprint; it is the foundational decision set that makes every subsequent decision coherent rather than isolated.
• •Separate experimentation from integration. Contained learning domains require flexibility. Core integration requires governance. Conflating the two is how informal practices become structural— and how learning that should inform design instead bypasses it.
• •Make decision rights explicit. Ambiguity accelerates fragmentation. Where it is unclear who approves a deployment, the effective answer is that no one does—or that everyone does independently, which produces the same outcome.
• •Measure coherence as well as progress. The metrics most organisations track—tools deployed, pilots completed, efficiency targets—measure momentum, not alignment. The measures that matter are whether the enterprise is converging toward architectural coherence or diverging from it.

AI-enabled transformation will not wait for perfect readiness. Move too slowly and experimentation escapes governance. Move without architectural clarity and risk compounds faster than the organisation can detect it.

The balance is not instinctive. It is designed.

Governance is not the constraint on pace. Poorly designed governance is. Well-designed governance— explicit architecture, clear decision rights, risk thresholds calibrated to velocity—is what allows complex organisations to move quickly without destabilising themselves.

In the AI enterprise, that distinction is no longer academic. It is the difference between transformation that compounds value and transformation that compounds risk.