The target operating model was only eighteen months old when it stopped fitting. The central team still approved every release although domains had capable owners. A highly contextual experiment had been declared a platform. A vendor incident exposed one invariant that no domain could govern alone.

Nothing was wrong with the original chart. Capability, evidence and exposure had moved around it. Treating the chart as an end state converted once-useful concentration into queue, stable practice into undocumented exception and federation into common-mode risk.

An AI operating model should not be selected once and rolled out as a destination. Early work may need scarce expertise, bounded exposure and rapid learning. Stable interfaces, evaluation and service can later support productisation or federation. Rising consequence, coupling or regulation can move a right back towards enterprise control.

Evolution is reversible and event-driven. Change occurs when evidence shows that current placement of authority, work or controls no longer fits uncertainty, reuse, consequence and local knowledge. The enterprise never receives one stage label because different capabilities and domains need different placements at the same time.

Organisational stability is the strong rival. Frequent redesign can destroy learning, blur accountability and invite political bargaining. Accept stable roles and interfaces until an explicit trigger shows material mismatch. Then evolve the smallest affected decision, service or boundary while preserving useful contracts.

This article’s AI operating-model evolution loop has five reversible moves and six independent evidence dimensions. A migration contract carries decisions, assets and accountability to a ready owner, observes the new placement and preserves a reversal path.

Original synthesisUse five reversible moves, never a maturity ladder

Concentration buys learning and controlled exposure. A small expert group can compare cases, create initial methods and prevent premature replication. Its expiry is visible: queues grow, interfaces stabilise, recipients become capable or context transfer overwhelms the centre.

Codification is not documentation after the fact. It separates the repeatable core from expert judgement, records evaluation populations, automates conformance where useful and names residual discretion. Some work may remain concentrated after codification because exposure is common or recipients are not ready.

Productisation applies when a capability behaves as a persistent reusable service. It receives a named product owner, consumer contract, reliability objectives, change control, operating funding and retirement path. Unstable experiments should not be productised merely to create a platform roadmap.

Federation moves decisions that depend on specific domain knowledge to owners who can govern outcomes in context. Enterprise invariants protect shared exposure and interoperability. Federation fails when it transfers nominal rights without evaluation, incident, data, financial or workforce capability.

Recombination acknowledges that evolution is not one-way. A cross-domain incident may justify recentralising one invariant while leaving other rights local. A platform can split stable core from contextual edge. A capability can be absorbed into a domain product when reuse disappears, or retire when the decision no longer matters.

Dynamic-capability research connects advantage with sensing, seizing and reconfiguring in changing environments.[1] Later work develops the microfoundations of those capabilities.[2] Another view treats dynamic capabilities as identifiable organisational processes whose form and effect depend on market conditions.[3]

The loop translates reconfiguration into bounded operating moves. Sensing is an evidence trigger, seizing is a migration contract, and transforming is an observed placement with reversal. No move is intrinsically more advanced than another.

Move criteriaRead six dimensions separately instead of manufacturing a score

Task and context stability asks whether the decision, population, policy and workflow meaning have settled enough to transfer or standardise. High contextual variation may support federation or domain ownership even when the underlying tool is stable.

Interface and evaluation repeatability asks whether inputs, outputs, configuration, conformance and representative tests can be used by another owner. Tacit expert rescue is evidence that codification remains incomplete.

Operating reliability includes service, change, incident, recovery, evidence preservation and retirement. A strong offline prototype is not ready to productise if ordinary operation still depends on its creators.

Domain absorptive capacity covers the ability to recognise, assimilate and apply relevant knowledge, plus real authority, people, data, operations and risk competence. Absorptive-capacity research describes how prior related knowledge shapes learning and innovation.[4]

Reuse economics compares beneficiary breadth, marginal service cost, avoided duplication, coordination load and switching cost. Reuse aspiration does not make an unstable component economical. A platform can appear cheap by transferring exception work to domains.

Consequence and common-mode exposure considers severity, reversibility, concentration, regulatory duty and cross-domain dependency. Rising common exposure can justify centralising one invariant without recentralising every contextual choice.

No composite score is allowed because dimensions are not interchangeable. High reuse cannot compensate for an unready recipient. Reliable operation cannot erase unacceptable common exposure. Strong domains cannot productise an interface that still changes weekly.

Deliberate learning mechanisms can shape capability evolution.[5] Exploration and exploitation also make different demands on organisation.[6] Ambidextrous designs separate exploratory and mature work where needed.[7] The six dimensions decide which split or connection fits this capability now.

Minimal changeMigrate one bounded decision and its operating assets

The migration contract begins with a trigger event and current failure. A queue, fork, bypass, unstable exception, control gap, incident, vendor shift, new law or expired purpose can demonstrate mismatch. Calendar cadence, leadership fashion and an abstract target chart cannot.

The contract names current placement and target placement at the level of one decision, control, capability element or service boundary. It lists authority, work, data, evaluation assets, controls, runbooks, funding, incidents and evidence that move. Anything retained by the current owner is explicit.

Receiving readiness is demonstrated, not promised. The owner has real authority, competence, service and risk capacity, access to evidence, an incident path and budget. Premature federation is prevented when a domain cannot yet evaluate, release, stop or remediate.

A sending owner has exit duties. The central team stops doing transferred work, removes private queues, hands over relationships and changes its measures. Permanent incubation often persists because recipients inherit accountability while experts keep practical control.

Observation defines population, time, indicators, decision quality, service, queue, exceptions, outcome, risk and coordination cost. A reversal condition states which evidence returns the decision, narrows scope, changes the invariant or retires the capability. Reversal is designed before organisational pride attaches to the move.

Specific knowledge should influence where real decisions are made.[8] Modularity can make change and reuse more manageable through stable design rules.[9] The migration contract joins those principles: move contextual authority with knowledge, and move reusable services only after interfaces stabilise.

Qualify a trigger before moving the boundary

A queue is a trigger only after its cause is known. It may reflect scarce expertise that should remain concentrated, an unclear interface ready for codification, a missing service class, unready consumers or avoidable central approval. Each diagnosis implies a different move. Reorganisation based on queue length alone can put the same delay under a new manager.

A fork or bypass also needs interpretation. A domain may have duplicated capability because the platform was slow, because local context truly differs, or because it avoided a necessary control. The migration review records duplicated operation, lost evidence, local outcome and the condition for rejoining, accepting the local component or stopping unsupported use.

An incident proves common-mode exposure only when several consumers share the failed dependency or invariant. A local policy error is not evidence for enterprise release control. The transition package maps causal path and affected population, then centralises only the object whose scope exceeds local authority.

External triggers can change the evidence boundary quickly. A vendor may remove version control, a law may create a new duty, a strategic decision may end a product, or a workforce constraint may invalidate a human fallback. Urgency can shorten the migration window, but it cannot remove the receiving owner, preservation or reversal requirements.

The no-change counterfactual accompanies every proposal. It estimates what happens if roles and interfaces remain stable while the identified defect is repaired inside the current placement. If that action restores acceptable decisions, service, risk and cost, organisational stability wins. A boundary moves only when local repair cannot address the mismatch or would recreate it repeatedly.

Portfolio topologyLet different capabilities make different moves at the same time

An enterprise stage label erases the evidence that matters. A customer-service summarisation capability can productise after its interface and service stabilise. A specialised scientific workflow can remain concentrated while context is discovered. A mature domain may federate release authority while a new domain consumes a constrained configuration.

The mosaic records capability element, domain, current placement, active move, trigger, key weak dimension and observation state. It allows leaders to see concentration and common dependencies without forcing uniformity. Aggregate exposure can be managed across varied local placements.

Invariants form the grout between mosaic pieces. Identity, provenance semantics, incident identifiers, evidence portability or a prohibited use may remain common. Domain policy, thresholds, workflow and human authority can vary. The invariant is central because common exposure justifies it, not because centrality represents progress.

Funding follows the piece and the shared edge. Persistent services receive lifecycle funding. Domains fund contextual configuration and outcome work. Temporary concentration receives an expiry and knowledge-transfer budget. Recombination funds migration, remediation and dependency removal rather than treating redesign as free.

Portfolio measures include safe time to first use, conformance, reliability, queue, fork, bypass, exceptions, outcome, risk, marginal cost, receiving readiness and reversal. Counting how many capabilities moved to a preferred stage would turn the mechanism into a target and reward organisational motion.

Ownership views cut the mosaic in several ways. A domain leader sees every capability contributing to one outcome. A platform owner sees consumers of a shared service. Enterprise risk sees correlated exposure and invariant breaches. Finance sees persistent and transitional costs. The underlying capability records stay consistent, preventing each function from inventing a different stage narrative.

Cadence follows evidence. Product and domain reviews can examine local placements frequently, while enterprise leaders review cross-capability concentration and external triggers less often. Neither cadence forces a move. A stable record can remain unchanged for several reviews when its evidence still fits, while one material incident can reopen a specific boundary immediately.

The mosaic also reveals orphaned pieces. A capability without an outcome owner, service owner, evidence contract or retirement path cannot be treated as an advanced local innovation. It needs temporary concentration, ownership repair or removal. Visual diversity is acceptable; missing accountability is not.

NIST frames AI risk management as continuous and lifecycle-wide, with review, production monitoring, change and safe decommissioning.[10] Its Playbook offers actions that organisations adapt to context.[11] The mosaic keeps that lifecycle evidence attached to each placement.

OECD, BCG and INSEAD research on AI adoption in firms examines complementary capabilities needed for adoption.[12] The evolution test treats recipient capability as a hard migration condition rather than assuming that decision rights create competence.

Negative controlsDetect movement that creates more mismatch

Premature federation gives domains release or model authority before they can evaluate, observe, stop or remediate. Decision rights move faster than absorptive capacity. The remedy can be continued concentration, facilitated transfer or a narrower configurable service until receiving readiness is demonstrated.

Permanent incubation keeps delivery in a central team after interfaces, evaluation and recipients stabilise. Queues grow and domains never build ownership because experts continue to rescue every release. The sending-owner exit in the migration contract makes retained work and private approvals visible.

Premature platform standardises a highly contextual experimental component. Each domain then needs exceptions, bespoke support and hidden forks. Productisation pauses until stable core, configuration envelope, service evidence and credible beneficiary breadth exist. The component may remain local without being a failure.

Incident overreaction recentralises broad rights after one local failure. Investigators first test whether exposure was common, whether an invariant failed and whether other domains share the path. Recentralise the smallest common object, with an expiry, rather than turning emergency command into permanent organisational control.

Calendar reorganisation changes roles annually although queue, service, outcome and risk evidence show no material mismatch. The rival of stability wins: keep the current design, repair local process defects and preserve learning. An organisation chart should not be a recurring deliverable.

Stage metrics reward movement itself. A leader can claim progress by transferring unready work, labelling an unstable component a platform or eliminating a centre whose decisions remain orphaned. Measures instead compare the before and after decision, service, risk, cost and coordination evidence during observation.

Make transition an operating period, not a chart announcement

The transition begins with a dry run of the receiving contract. The new owner evaluates a representative change, responds to a simulated incident, invokes stop, accesses evidence and demonstrates remediation. The sending owner observes without taking back control at the first difficulty. Gaps become funded transition work rather than reasons to conceal dependence.

Authority and production work move on a declared cutover. Dual ownership is limited to a short comparison window with one final decision rule. Without that rule, the receiving owner may carry formal accountability while the former team continues approving through informal channels. The contract publishes where requests, exceptions and incidents now go.

Knowledge transfer uses artefacts and practice. Runbooks, evaluation packs and service records are necessary, but recipient teams also work real cases with experts and explain the decision back. This tests whether tacit assumptions became usable knowledge. The expert team records recurring rescue because it indicates a missing interface or capability.

Finance moves with accountability. The receiving owner needs budget for operation, service consumption, exceptions, incident response and retirement. The sending owner’s funding declines as retained duties end. Shared platform cost and domain outcome cost remain distinguishable so a transfer does not hide work by moving it into unmeasured local effort.

Observation compares a baseline with the new placement. It includes queue and service, but also decision quality, representative evaluation, adoption, override, incidents, risk, remediation, marginal cost and coordination. Missing evidence is reported rather than treated as a neutral result. A move that shortens queue while making downstream outcomes invisible has not succeeded.

Reversal does not need to recreate the former organisation exactly. A failed federation can return one release right while leaving data and workflow authority local. A product that attracts too many exceptions can split stable core from contextual edge. A temporary incident control can expire after the shared dependency becomes testable. The aim is fit, not restoration of an old chart.

Retirement follows the same discipline. The owner maps decisions formerly made by the capability or forum, transfers any continuing obligations, removes permissions and routes, preserves required evidence and checks for workarounds. Eliminating a committee without moving its decision objects simply turns explicit queue into informal escalation.

Leaders should announce the bounded hypothesis, not a transformation slogan. They state which capability moves, why current evidence shows mismatch, what remains unchanged, when observation ends and what would reverse the decision. That specificity reduces political interpretation and protects stable neighbouring contracts.

Iterative SLO implementation connects service objectives with empowered trade-offs and revision as teams learn.[13] That service discipline supports productisation, but an SLO cannot prove contextual decision readiness or reuse economics on its own.

Machine-learning systems can accumulate technical debt through entanglement, hidden feedback and unstable dependencies.[14] Organisational movement can amplify that debt when a boundary changes before dependencies are understood. The migration package includes the technical and evidence assets needed to preserve continuity.

Worked evolutionMove evaluation from experts to product, then recentralise one invariant

A central expert team initially evaluates AI capabilities for several domains. Uncertainty is high, evaluation populations differ and few people understand failure modes. Concentration is appropriate because it pools learning and limits exposure while the organisation discovers what good evidence means.

Demand grows and the central queue becomes a release bottleneck. Experts repeatedly assemble the same provenance, evaluation harness, segment report and decision receipt. Several domains now have qualified product, data and risk owners. Queue and repeatability evidence trigger codification, not immediate federation.

The team defines common evaluation interfaces, versioned assets, representative-population duties, conformance tests, evidence export, incident identifiers and runbooks. It separates the invariant harness and provenance rules from domain-owned case selection, thresholds, interpretation and outcome acceptance.

Service behaviour stabilises across committed consumers. Marginal operation is lower than duplicated harnesses, support and change obligations are understood, and the capability has an exit path. The reusable core productises under a persistent owner with service objectives, lifecycle funding and consumer contracts.

Domains configure evaluation populations and approve their own releases within enterprise invariants. Federation occurs unevenly. Lending demonstrates evaluation, incident and remediation capacity and receives release authority. A newer domain consumes a constrained configuration while building competence. Both placements are valid.

A vendor-model update later causes a cross-domain provenance failure. Investigation shows that vendor version admission is a common-mode object no one domain can control. The organisation recentralises that invariant into the platform product, including vendor evidence, compatibility and rollback, while leaving domain thresholds and release acceptance local.

The incident does not justify taking all evaluation and release rights back. The migration contract names the failed invariant, affected consumers, enterprise owner, service change, observation window and reversal condition. If vendor interfaces later become independently verifiable, parts of admission can federate again.

The old central approval forum retires after its actual decisions move to typed owners. Platform product owns shared service and vendor invariant. Domains own configuration and outcome acceptance. Independent risk challenges within delegated authority. Records, escalation and aggregate views move before the meeting disappears.

This path is not a prescribed sequence. Another capability may remain concentrated, productise without federation, split into a product core and local edge, or retire during codification when benefits do not justify continuing. The loop describes moves, not an expected journey.

Regulation (EU) 2024/1689 and ISO/IEC 42001 create or inform lifecycle responsibilities, review and management-system evidence for relevant organisations and systems.[15] External change can trigger recombination, but qualified roles still identify the precise obligation and smallest affected boundary.

Decision instrumentTest one capability boundary, not the whole enterprise

The Operating-Model Evolution Test takes a capability and current placement, reads mismatch and receiving evidence, and chooses one reversible move. It rejects maturity scores and calendar-led reorganisation. The output includes a minimal migration contract.

Use it when queue, fork, bypass, exposure, law, vendor, incident, strategic or purpose evidence changes materially. Involve current and proposed owners, domain, platform, risk, workforce and finance. Demonstrate receiving readiness and reversal before changing accountability.

ConclusionEvolve the boundary, not the enterprise label

An AI operating model evolves when a specific placement no longer fits capability, evidence, local knowledge, economics or exposure. Stability remains the default. The response is the smallest reversible move that repairs the mismatch.

Concentrate to learn and limit exposure. Codify to make practice transferable. Productise stable reusable services. Federate contextual decisions to capable owners under invariants. Recombine a failed boundary or retire a capability whose purpose ended. None is a final or superior stage.

The six evidence dimensions prevent a strong condition from hiding a fatal weakness. The migration contract transfers real authority and operating assets, gives the sending owner an exit, observes the new design and defines reversal. The mosaic allows several placements to coexist coherently.

The practical test is whether the current owner remains best placed to make and operate this decision now. If evidence says no, identify the precise mismatch, prove a ready receiver, move the smallest object and watch the consequence. If evidence says yes, resist reorganisation and keep learning inside a stable contract.

This makes evolution legible to boards and teams. They can distinguish capability building from authority transfer, temporary incident control from permanent recentralisation, and platform reuse from imposed uniformity. Each change can be explained through evidence, observed against an explicit baseline and undone without dismantling the rest of the operating system.

The result is disciplined adaptation: stable enough to preserve learning, responsive enough to correct mismatch, and precise enough that every receiving owner knows what changed, what did not and when the decision will be reconsidered.

Source trailReferences

1. Teece, D. J., Pisano, G. and Shuen, A. (1997), ‘Dynamic capabilities and strategic management’, Strategic Management Journal, 18(7), 509–533. DOI.
2. Teece, D. J. (2007), ‘Explicating dynamic capabilities’, Strategic Management Journal, 28(13), 1319–1350. DOI.
3. Eisenhardt, K. M. and Martin, J. A. (2000), ‘Dynamic capabilities: What are they?’, Strategic Management Journal, 21(10–11), 1105–1121. DOI.
4. Cohen, W. M. and Levinthal, D. A. (1990), ‘Absorptive capacity’, Administrative Science Quarterly, 35(1), 128–152. DOI.
5. Zollo, M. and Winter, S. G. (2002), ‘Deliberate learning and the evolution of dynamic capabilities’, Organization Science, 13(3), 339–351. DOI.
6. March, J. G. (1991), ‘Exploration and exploitation in organizational learning’, Organization Science, 2(1), 71–87. DOI.
7. Tushman, M. L. and O’Reilly, C. A. (1996), ‘Ambidextrous organizations’, Harvard Business Review. Publisher record.
8. Jensen, M. C. and Meckling, W. H. (1995), ‘Specific and general knowledge, and organizational structure’, Journal of Applied Corporate Finance, 8(2), 4–18. DOI.
9. Baldwin, C. Y. and Clark, K. B. (2000), Design Rules, Volume 1: The Power of Modularity, MIT Press. Publisher record.
10. NIST (2023), AI Risk Management Framework Core. Official resource.
11. NIST (2023), AI RMF Playbook. Official resource.
12. OECD, BCG and INSEAD (2025), The Adoption of Artificial Intelligence in Firms. DOI.
13. Murphy, N. R. et al. (eds.) (2018), ‘Implementing SLOs’, The Site Reliability Workbook, Google. Online chapter.
14. Sculley, D. et al. (2015), ‘Hidden technical debt in machine learning systems’, Advances in Neural Information Processing Systems 28. Google Research record.
15. European Union (2024), Regulation (EU) 2024/1689; and ISO/IEC (2023), ISO/IEC 42001:2023, AI management systems. EU text; ISO record.