Crossing the AI chasm,
one business function at a time

Executive summary

Artificial intelligence (AI) is becoming ordinary software faster than it is becoming an ordinary organisational capability.

That distinction matters because most measures of AI adoption tell us very little about how deeply an organisation has changed. A company can buy licences, encourage employees to use assistants, run dozens of pilots and even deploy agents without changing the underlying operating model very much. At the other extreme, a single business function can reorganise its work, decision rights, systems and accountability around AI while the rest of the enterprise remains largely untouched.

The useful unit of analysis is therefore often not "the enterprise" and certainly not "AI" as one market. It is the function or workflow.

A concrete example helps. Workwear Group did not simply add an AI assistant to an existing contact centre. In the provider-published account, customer journeys were mapped, a fragmented stack was replaced with an integrated service environment, conversational AI was combined with contextual human hand-off and automated quality assurance, and ongoing managed service became part of the operating model.⁹ The outcome evidence is still short-term and commercially interested. But the shape of the change is the point: the function changed around the technology rather than merely adding the technology at its edge.

Geoffrey Moore's adoption framework provides a useful conceptual lens. In a February 2026 discussion of agentic AI, Moore argued that a meaningful chasm crossing becomes visible when a function re-engineers itself around a technology and a sufficiently complete "Whole Product" forms around it. He also points to serious operating constraints and trapped value as the places where a technology has the strongest reason to displace the old way of working.¹

This paper does not use Moore's framework as proof that AI, generative AI or agentic AI has crossed the chasm. The evidence does not support such a broad claim. Gartner reported in September 2026 that only 22% of surveyed organisations had successfully scaled AI across multiple business units or adopted an AI-first approach, even as 85% of functional leaders planned to increase AI spending.² ServiceNow's 2026 research similarly reported 27% of organisations automating or optimising workflows with AI, but only 16% streamlining workflows across functions and just 9% in each of the autonomous-multistep and completely-new-workflow categories.³

Those figures describe a market in which access, spending and local use can look mature while organisational redesign remains relatively shallow.

At the same time, the evidence is no longer limited to experiments. Named customer-service cases are appearing in which AI is combined with workflow redesign, systems integration, managed services, contextual hand-off, human escalation and measurable production outcomes. Procurement and third-party risk management show similar mechanisms, although the available evidence is less independently referenceable. Mainstream advisers, risk firms, managed service providers and specialist consultancies are also packaging AI readiness, governance and implementation preparation into bounded products designed for more pragmatic buyers.

The less celebrated evidence matters too. Oversight bodies and courts have stopped systems that were technically usable or locally supported but lacked the authority, legal basis, controls or evidence required for dependable operation.^20212425 South Wales Police later resumed live facial-recognition deployments after further trial deployments, testing and evaluation, including independent National Physical Laboratory work.²⁶ The practical point is not that governance is anti-innovation. It is that a credible route to scale must include a credible route to stop - and, where conditions change, to re-enter.

Taken together, the evidence supports a narrower and more useful conclusion:

The Whole Product is central to that proposition. It is not merely the model, agent or application. It is the complete organisational proposition required for dependable production use: data, integration, systems of record, controls, workflow, decision rights, governance, procurement route, implementation, support, monitoring, exception handling and a credible way to recover when something goes wrong.

That changes both the economics and the risk of adoption. The software price is only one line in the business case; integration, governance, organisational redesign, transition and management attention may matter as much or more. It also makes the implementation partner part of the technology decision. Buyers need to judge not only whether a provider can build the system, but whether it can support the organisational dependency being created and be replaced if necessary.

Andrew's Intel therefore proposes a seven-part Functional Chasm Test:

1. Is there a serious operating constraint or pool of trapped value?

2. Is a sufficiently complete Whole Product present?

3. Has the end-to-end workflow changed?

4. Are authority, accountability and human judgement explicit?

5. Is the system in repeatable production use?

6. Is organisational value actually being released?

7. Is the evidence credible and referenceable enough for a pragmatic peer?

Passing some of these tests is not the same as crossing. Strong technical performance with weak integration, governance or operating redesign should remain a trial or integration project, not be promoted rhetorically into transformation.

The practical management question therefore changes. It is no longer simply: "How much AI are we using?"

It becomes:

Where is the serious constraint? What complete system would be required to change it? What would the function itself have to become? And what evidence would justify moving to the next stage?

1. Stop asking whether "AI" has crossed

There is an appealing simplicity to asking whether AI has crossed the chasm into the mainstream. It gives the impression that we can locate an enormous family of technologies on one curve and then decide whether an organisation is early, late or roughly on time.

The problem is that the question collapses unlike things into one category.

An employee using a general-purpose AI assistant to rewrite an email is not in the same adoption state as a customer-service operation that has redesigned its workflow around AI-assisted self-service, contextual hand-off, automated quality analysis and managed human escalation. A finance team running a pilot is not in the same state as a function in which AI is embedded in ordinary decision-making. A company may simultaneously contain all of these states.

That is why enterprise-wide usage rates can be misleading. They tell us something about access and activity. They tell us much less about organisational absorption.

A more useful hierarchy is:

This extends the measurement logic developed in the earlier Andrew's Intel piece AI Adoption Is Becoming a Terrible Measure of AI Progress. A companion piece, AI Adoption Is Earlier Than It Looks - and Later Than It Looks, makes a related distinction between awareness, institutionalisation and operationalisation. This paper takes the next step: it asks what evidence would justify saying that a function has reorganised itself around AI rather than merely accumulated more AI activity.

Each step is harder than the one before it. More importantly, each step asks a different management question.

At the access stage, the question is whether people can use the technology. At the activity stage, it is whether they do. At the useful-task stage, it is whether AI improves something real. Repeatable workflow asks whether the improvement survives outside an individual's personal method. Functional redesign asks whether the work itself has changed. Organisational outcome asks whether the change affects cost, quality, service, revenue, risk, cycle time or capacity. The final stage asks whether management is confident enough in the change to alter budgets, roles, staffing, outsourcing, service levels or investment.

These are not semantic differences. They explain why adoption can look both earlier and later than it really is.

Gartner's September 2026 survey is a useful counterweight to optimistic usage narratives. Among 1,303 respondents from organisations with at least $50 million in annual revenue, only 22% said they had successfully scaled AI across multiple business units or adopted an AI-first approach. Yet 85% of functional leaders planned to increase AI spending in 2026 after allocating an average of 12% of their functional budgets to AI in 2025.²

Spending is therefore not the same as scaling.

ServiceNow's global Enterprise AI Maturity Index provides another view. Its 2026 data reports 27% of organisations automating or optimising workflows with AI, 16% streamlining and integrating workflows across business functions, 9% using agentic AI for autonomous multistep workflows and 9% creating completely new workflows that were previously not possible.³

The shape matters more than any single percentage. The deeper the operating-model change, the smaller the group.

Singapore makes the distinction particularly visible. ServiceNow reported that agentic AI adoption among surveyed Singapore enterprises rose from 22% in 2025 to 51% in 2026. Yet only 10% were using it in redesigned end-to-end processes. The largest group, 33%, was using AI to assist individual employees with day-to-day tasks.⁴

It is perfectly possible, then, for agent adoption to become common while functional redesign remains unusual.

That is not failure. It is what we should expect from a technology diffusing through organisations with different functions, risk tolerances, systems, data, economics and management capacity.

The mistake is to describe all of those states with one adoption number.

The crossing is local before it is universal

An enterprise is not one social system. Sales, finance, procurement, customer service, legal, human resources, operations and research can have different incentives, different data, different regulatory exposure and very different consequences of error.

This is consistent with Everett Rogers' diffusion work: adoption occurs inside social systems, and different groups can experience the same innovation through different norms, risks, communication channels and perceived advantages.¹⁹ The modest implication here is enough: one enterprise can contain several rationally different adoption curves at the same time.

Organisational research supports this multi-stage view. Wang, Zhong, Huang and Liang organise interviews with 27 providers, adopters and advisers around Rogers's five-stage innovation-decision process - agenda-setting, matching, redefining and restructuring, clarifying, and routinising - and identify ten socio-technical contradictions across those stages.⁶ The value of that work is not that every company must follow exactly five steps. It is that implementation is shown as a socio-technical process rather than a binary deployment event.

MIT Center for Information Systems Research (MIT CISR) reaches a similar conclusion from a different direction. Its four-stage Enterprise AI Maturity Model moves from experimentation and preparation, through pilots and capability building, into scaled AI ways of working and finally AI embedded in processes and decisions. Its 2025 update found the largest financial shift between the pilot stage and the stage in which organisations scale platforms and change how work is done.⁵

This is the first central proposition of the paper:

2. What Moore's chasm actually gives us

Geoffrey Moore's original chasm framework is a market-adoption model, not a measurement system for enterprise AI maturity. That distinction should be preserved.

Moore's chasm is the gap between enthusiastic early adopters and pragmatic mainstream buyers who require proven, complete, low-risk solutions.

Its value here is conceptual.

The early adopter is willing to tolerate uncertainty. The pragmatic buyer is less interested in being first and more interested in whether a solution is complete enough, safe enough, referenceable enough and economically credible enough to become ordinary operating infrastructure.

Moore's February 2026 discussion of agentic AI makes that practical. He argues that a chasm crossing becomes meaningful when a function "completely re-engineers itself" and when a Whole Product forms around a serious operating constraint. He also stresses the role of trapped value: the value an organisation cannot reliably capture because some part of its existing operating model prevents it.¹

Those ideas give us three useful tests.

First, look for a serious constraint rather than generic enthusiasm. If the problem is mildly irritating, the organisation has little reason to absorb the disruption of redesigning work around a new technology. The best targets are bottlenecks, delays, error burdens, capacity limits, inaccessible knowledge, regulatory friction, service failures or commercial opportunities large enough to justify changing the system.

Second, look for a complete enough solution rather than an impressive capability. Pragmatic buyers do not want to invent the missing parts of an operational system themselves.

Third, look for changed work. If the technology is simply helping people do the old process faster, it may be useful without representing a deeper transition.

This does not mean every valuable AI use case needs to cross a chasm. An employee saving twenty minutes a day with an assistant can be worthwhile. A team automating a narrow administrative step can be worthwhile. The chasm lens matters when we are trying to identify the point at which AI moves from an optional tool towards operating-model infrastructure.

That point is more demanding.

3. What the Whole Product actually means

The term "Whole Product" can sound more abstract than it is.

At its simplest, the core AI product answers:

Can the technology do this?

The Whole Product answers the harder question:

Can this organisation depend on it to do this as part of normal business?

That second question is much larger.

Consider a procurement agent capable of analysing supplier information, comparing offers and proposing negotiation positions. The agent may perform brilliantly in a demonstration. That does not make it a procurement system.

For ordinary production use, the organisation may also need:

• access to the enterprise resource planning (ERP) system and relevant supplier records;
• reliable data and clear definitions of what data can be used;
• identity, permissions and cybersecurity controls;
• rules governing purchasing authority and financial limits;
• human approval and escalation for judgement-bearing decisions;
• audit trails and reconstructable decision records;
• exception handling for incomplete, contradictory or unusual cases;
• workflow integration with buyers, finance, legal and operational stakeholders;
• training and role redesign;
• monitoring, testing and change control;
• support arrangements and incident response;
• commercial terms, service levels and responsibility when something fails;
• an exit route if a model, supplier or implementation partner changes.

The model or agent may be the visible technology. The Whole Product is the operating system around it.

Three layers of the adoption proposition

A useful way to think about the Whole Product is to separate three layers.

Layer 1: Core AI capability

This is the technological component: model, agent, application, inference, tools and direct software licence or usage cost.

It is usually the easiest layer to demonstrate and compare. It is also the layer most likely to dominate product marketing.

Layer 2: Whole Product infrastructure

This is what makes the capability usable in the organisation: integration, data, identity, permissions, workflow, governance, implementation, support, monitoring, exception handling and operational ownership.

This layer turns possibility into a service that ordinary people can rely on.

Layer 3: Organisational absorption

This is what the buyer itself must change: roles, decision rights, management routines, incentives, training, process design, capacity allocation, budgets, accountability and sometimes organisational structure.

This layer is easy to underprice because much of it is internal. Management attention does not arrive with an invoice. Neither does the cost of running old and new processes in parallel, maintaining extra review during transition, resolving ownership disputes or discovering that a role has changed faster than the job architecture around it.

This leads to a practical economic observation:

The inverse is also true:

That is one reason the licence fee can become a relatively small part of the decision.

Benefits of the Whole Product

The Whole Product reduces the amount of invention the customer must do.

That can produce several benefits.

Lower integration risk. The organisation is not left to connect a demonstration to systems, data and live workflow on its own.

Clearer authority. Decision rights, human intervention and escalation can be designed before the system becomes consequential.

More predictable operations. Monitoring, exception handling and support reduce dependence on heroic individuals who understand hidden workarounds.

Faster organisational learning. A repeatable operating system produces evidence that can be compared, reviewed and improved.

Better economics. Reliable workflow change creates a stronger route than isolated task improvement to releasing capacity or improving commercial outcomes.

Greater referenceability. Pragmatic buyers can evaluate something recognisable rather than a set of components and promises.

Drawbacks and new risks

Completeness does not make the Whole Product harmless.

The first risk is cost migration. A low software price can sit beside expensive integration, consulting, governance and transition work.

The second is organisational coupling. The deeper the system is embedded, the more serious a failure becomes. A broken optional assistant inconveniences users. A broken system participating in procurement, service, finance or risk decisions can interrupt the function itself.

The third is lock-in. Data structures, workflows, controls, training and organisational roles can become shaped around a particular vendor or architecture even when the underlying model is replaceable.

The fourth is process rigidity. Organisations can over-design around today's capability and make future changes harder.

The fifth is transition burden. Parallel running, review, retraining and temporary duplication can absorb substantial management and staff capacity.

The sixth is false completeness. A vendor can sell a broad-looking package whose weakest parts only become visible after production use.

This is why Whole Product should not be read as "more components are always better". The objective is not maximal architecture. It is a sufficiently complete system for the job.

The governing design principle is therefore:

4. The Functional Chasm Test

The Functional Chasm Test is designed to make the missing pieces visible.

It is deliberately harder to pass than a technology evaluation.

1. Serious operating constraint

Is there a material bottleneck, delay, cost, risk, capacity limit or inaccessible value pool worth reorganising around?

The first question is not "Where can we use AI?" It is "What is stopping this function from performing materially better?"

This protects against use-case tourism - collecting clever applications without establishing why the organisation should absorb the change.

A serious constraint need not be cost. It might be service capacity, speed, risk exposure, inconsistent decisions, inability to process available information, supplier complexity or a commercial opportunity that the current operating model cannot capture.

2. Whole Product

Does the usable solution include the integration, data, systems of record, controls, workflow, governance, procurement route, implementation, support and exception handling required for ordinary operation?

A missing element does not automatically make the project bad. It tells management what is still experimental.

If the model performs well but the organisation cannot reliably connect it to live data, the system is not ready. If integration works but authority is unclear, it is not ready. If the workflow functions only while a project team manually rescues exceptions, it is not ready.

3. Workflow redesign

Has end-to-end work changed, or are people simply performing familiar tasks faster?

Task productivity matters, but it is not the same as redesign.

The most valuable changes often require removing or combining steps, changing hand-offs, shifting work between people and machines, altering when decisions happen or eliminating work that existed only because the old process was slow.

4. Authority and accountability change

Are decision rights, human judgement, escalation, role boundaries and ownership explicit in the redesigned workflow?

This becomes increasingly important as AI systems act rather than advise.

"Human in the loop" is not enough. Which human? Reviewing what? With what information? Under what time pressure? With authority to stop the action? What happens if the human disagrees? Who owns the result after approval?

A ceremonial human checkpoint is not control.

Authority also has a vertical dimension. A project team, vendor sponsor or local governance group may have permission to experiment without having authority to put the organisation into production. The question is not only who reviews an AI output, but who is entitled to create the operational dependency in the first place.²⁰

5. Repeatable production use

Is this normal operating work rather than a pilot, demonstration, innovation project or unusually supported exception?

Pilots are designed to learn under bounded conditions. Production systems must survive normal variation, staff turnover, unusual cases, changing data, system upgrades and the ordinary messiness of the business.

This is one reason production evidence carries more weight than a successful proof of concept.

6. Released value

Is there credible evidence of movement in an organisational outcome such as cycle time, quality, cost, service, revenue, risk or deployable capacity?

Time saved is not automatically value released.

If AI frees three hours but the organisation cannot redeploy those hours, the benefit may remain local. If a pilot makes a task faster but the downstream approval process is unchanged, the function may capture little economic value.

Research from Boston Consulting Group (BCG) provides a useful example. An automotive manufacturer's early tender-assistant tools produced local productivity gains. BCG reports that after the procurement lifecycle was redesigned around AI, commercial outcomes such as negotiation uplift and earnings before interest and taxes (EBIT) contribution were worth more than ten times the internal efficiency value.¹² The buyer is anonymous and the case comes through a consultancy, so it should not be treated as independent proof. But the mechanism is important: capacity becomes commercially valuable only when the surrounding system can use it.

7. Peer referenceability

Is the case named, repeatable or independently credible enough that a pragmatic peer could treat it as reassurance rather than an interesting anecdote?

This is the deliberately conservative part of the test.

A provider case can still be useful evidence, but the reader should know that it is provider-published. An anonymous buyer case can reveal mechanism without giving a peer much reassurance about repeatability. A survey can show prevalence without proving that one implementation works.

The evidence class matters.

Interpretation rule

Passing some elements does not establish a crossing.

A technically strong deployment with weak governance may deserve Trial or Integrate. A well-governed system with no released value may deserve Hold. A function with a serious problem but no dependable Whole Product may be Not Yet.

The test is not designed to reward progress. It is designed to improve the decision.

5. What crossing begins to look like in practice

The current evidence is not strong enough to declare that customer service, procurement or third-party risk as entire markets have crossed the chasm. It is strong enough to identify specimens of the pattern.

Customer service: Workwear Group

Workwear Group's customer-service redesign is one of the clearest named examples in the current evidence set.

According to Innovior, the programme replaced a fragmented contact-centre environment with an integrated model combining Salesforce Service Cloud, Amazon Connect, conversational AI, analytics, automated quality assurance (QA), managed services and contextual hand-off across five brands. Innovior reports that customer journeys were mapped before implementation and that the solution was delivered under one commercial model. After just over four weeks, the provider reported self-service resolution increasing from 14.48% to 51.12%, chat average handle time falling by 16.05%, resolved cases rising by 16.85% and QA performance improving by 3.3%.⁹

This is unusually useful because the surrounding system is visible. It is not simply "we added a chatbot". Integration, operating design, hand-off, analytics, service management and commercial responsibility are part of the proposition.

The limitations are equally important. The outcome window is short, and the principal evidence is provider-published. That makes the case a strong emerging specimen, not final proof of a mature category.

Put through the Functional Chasm Test, the case becomes more revealing. Whole Product: integration, journey mapping, contextual human hand-off, automated quality assurance and managed service are all visible in the provider account, while authority detail and longer-term durability remain unclear. Partner and operating responsibility: ongoing managed service sits inside the proposition rather than being an implementation afterthought, which is commercially significant but also helps explain why the principal evidence is provider-published. Released value: self-service resolution, handle time and resolved-case volume moved within just over four weeks. Workwear Group's customer-service lead also says automation freed people to focus on more complex interactions, but the evidence does not quantify how much capacity was redeployed or show whether that shift produced sustained cost, service or commercial value.⁹

Customer support: Smarsh

Smarsh provides a second named example.

The company reports using two AI agents in support. Archie is customer-facing and handles routine support, while Emmy supports internal representatives with account context and resolution guidance. Smarsh reported in September 2026 that Archie had reached a 72% self-service deflection rate across 405 interactions in the second quarter of 2026, and that the company was expanding its use of Salesforce Agentforce after roughly a year of operating experience.¹⁰

Again, the important feature is not the percentage alone. It is the division of labour between customer-facing automation, internal assistance and human handling of more complex work.

The limitation is provenance. Smarsh is reporting its own results in a release connected to a technology platform. It is credible operational evidence of what the organisation says it is doing, but not independent evaluation.

Third-party risk management: strong mechanism, weak referenceability

ProcessUnity's September 2026 launch of AI agents for third-party risk management (TPRM) describes agents spanning intake, due diligence and monitoring while routing judgement calls to human subject-matter experts. The company reports that one large global technology and consulting firm reduced incomplete inherent-risk questionnaires by 75%, cut initial intake cycle time by 54% and increased assessment throughput by 43%.¹¹

The design pattern is close to the Whole Product logic: structured workflow, automation of manual work, human judgement where required and explicit attention to auditability.

The weakness is that the buyer is anonymous and the evidence is supplier-published. That makes it useful for understanding mechanism but much weaker as peer reassurance.

Procurement: redesign creates the value

Boston Consulting Group's 2026 research is especially useful because it separates pilot productivity from commercial value.

Its study of more than 200 chief information officers (CIOs), procurement leaders and technology buyers found three recurring patterns. Internal operational benefits tend to appear before external supplier-facing benefits; production deployments outperform pilots; and organisations combining technology deployment with capability building, process redesign and governance report stronger outcomes.¹²

BCG also reports four recurring constraints: inconsistent data, integration with legacy systems, the difficulty of transforming while running business as usual, and governance. Nearly half of respondents cited difficulty integrating AI with legacy systems such as ERP and procure-to-pay platforms. Governance concerns included trust in autonomous decision-making, security and intellectual-property risk, regulatory uncertainty, accountability and auditability.¹²

This is important because it moves the discussion away from model performance.

The barrier is increasingly the enterprise's ability to absorb the capability.

Evidence matrix: what the current specimens actually establish

On a narrow screen, each row is shown as a separate card.

What these cases do - and do not - prove

They do not prove that an entire function has crossed a market chasm.

They do show several characteristics we would expect to see if a crossing were beginning:

• the technology is connected to live operational systems;
• work is redesigned rather than merely accelerated;
• human and machine roles are made explicit;
• production use replaces isolated pilots;
• outcomes are measured in operational or commercial terms;
• implementation and support become part of the product.

That is enough to justify watching the function, not enough to declare victory.

6. The product around the AI product is becoming visible

If the early majority wants reduced uncertainty, a market should form around reducing uncertainty.

That is now visible.

PricewaterhouseCoopers (PwC) offers a United States Enterprise AI Readiness Assessment that scores organisations across 12 enterprise domains using more than 285 questions, benchmarks them against more than 500 organisations and produces prioritised recommendations and a sequenced roadmap.¹³ PwC's United Kingdom offer similarly packages transformation, trust and data readiness around the transition from proof of concept to scalable, responsible implementation.¹⁴

Deloitte has published an agentic-AI capability assessment for digital channels organised around embedded capability, agent operability and trustworthiness.¹⁵

Marsh offers AI system risk analysis that classifies system risk, assesses controls against regulatory requirements, identifies gaps and suggests remediation.¹⁶

For smaller organisations, ISS IT now includes an AI Readiness Assessment and Automation Roadmap within its Protect & AI managed service, alongside AI policy, approved-tool controls, data-readiness work, platform administration, training and reporting.¹⁷

Advisor Labs sells a three-week fixed-price readiness assessment for $18,000 to $35,000. It explicitly states that the deliverable is a first project and roadmap, and says roughly two-thirds of assessment clients hire it for the recommended follow-on project.¹⁸

These offers vary enormously in scope, depth, price and commercial model. That is not the point.

The market signal is that AI judgement itself is becoming productised.

Pragmatic buyers can now purchase help with questions such as:

• Are we ready?
• Which use case deserves capital?
• What has to change first?
• What risks or governance gaps block production?
• What should we not build?
• What is the sequence from experiment to normal operation?

The product being sold is not always AI. Sometimes it is a safer decision about AI.

That is consistent with the kind of infrastructure we would expect to appear as a market moves beyond pioneers.

7. But much of this infrastructure is also a sales funnel

The same development should make buyers more cautious, not less.

A readiness assessment can genuinely reduce ambiguity and still be a lead-generation product. Those two things are not mutually exclusive.

ISS IT is unusually transparent: its current offer embeds the readiness assessment and roadmap in a recurring managed-service package, with AI licences purchased separately.¹⁷ Advisor Labs states that around two-thirds of assessment customers subsequently hire it for the first project.¹⁸ PwC's assessment naturally sits beside a much larger transformation and advisory capability.¹³

None of this invalidates the service.

The useful management question is: What incentive structure sits behind the diagnosis?

If the organisation providing the assessment also sells implementation, cloud migration, data platforms, managed services or a preferred technology stack, its incentives matter. The buyer should ask whether the assessment genuinely allows "do nothing", "not yet", "use somebody else" or "solve the problem without AI" as credible outcomes.

This becomes particularly important because Whole Product thinking expands the commercial surface around the software.

For the buyer, integration, governance, workflow redesign, training and support are adoption costs.

For a capable adviser or implementation partner, the same items are potential revenue streams.

That is not a criticism. Someone has to do the work. The economic opportunity exists precisely because pragmatic buyers do not want to build every missing component themselves.

The danger appears when the commercial proposition matures faster than delivery capability.

A firm can learn to sell AI transformation before it has learned to deliver one.

8. Choosing the implementation partner becomes part of the technology decision

Once a buyer is adopting a Whole Product rather than a point tool, partner selection becomes much more consequential.

An established relationship is not enough.

A long-standing ERP consultancy may understand the client's systems and procurement processes but have limited experience with AI evaluation, agent architecture, machine authority, continuous monitoring or the governance of probabilistic systems.

A managed service provider may have excellent security and infrastructure disciplines but little experience redesigning a business function.

A specialist AI consultancy may understand models, tools and orchestration but lack enterprise integration depth, regulated-industry knowledge, support capacity or the financial durability to remain responsible for a deeply embedded system.

A large global consultancy may have all of those capabilities somewhere in the firm but still assemble the wrong team for the actual engagement.

The point is not that one category is safer. It is that the required competence is composite.

The implementation-partner test

A pragmatic buyer should examine at least ten things.

1. Relevant production evidence

What comparable Whole Product has the partner actually implemented and supported in production? A successful prototype is not enough.

2. Systems competence

Can it integrate the AI with the systems of record, data platforms, identity systems and workflows on which the function really depends?

3. Operating-model competence

Can it redesign work, roles and decision rights, or only configure technology?

4. Governance competence

Does it understand authority, accountability, auditability, escalation, model change, human intervention and regulatory constraints?

5. Evaluation competence

Can it establish whether the system is actually improving the outcome rather than merely increasing activity or automation?

6. Delivery depth

Which capabilities are genuinely internal? Which are subcontracted? Who is responsible when the integration crosses organisational boundaries?

7. Support capability

Who monitors and supports the system after the transformation team leaves? What happens at 02:00 when the workflow fails?

8. Commercial incentives

Is the partner capable of recommending a smaller solution, a different provider, a delay or no AI at all?

9. Continuity and durability

Will the provider still be capable of supporting the system in three or five years? What happens if it is acquired, loses key staff or changes strategy?

10. Replaceability and exit

Can another competent provider take over without rebuilding the whole organisational system? Are data, controls, documentation and interfaces portable enough to support an orderly exit?

Continuity and replaceability deserve unusual weight in a fast-changing implementation market. Established firms are adding AI services while new specialists appear rapidly; some will become durable providers, while others may pivot, be acquired or disappear. A buyer embedding AI into the operating model therefore has to evaluate not only whether the partner can build the system, but whether the organisation can survive the partner.

A private design observation

In one private procurement-system design exercise, the surrounding implementation problem quickly became larger than the software problem. Once the design was followed far enough, the critical questions were integration, infrastructure, security, auditability, decision authority, support, organisational structure and long-term operating responsibility.

That observation is not market evidence and should not be treated as such. Its value is diagnostic: serious implementation work tends to reveal the missing Whole Product around the model.

It also shows why the economics can look different from either side of the table. To the buyer, integration and organisational redesign are costs and risks. To a capable partner, the same work is consulting, implementation and support value. The same Whole Product complexity can therefore be a burden on one side of the transaction and part of the commercial opportunity on the other.

9. Why broad organisational redesign is still a minority state

A paper about emerging chasm crossings needs strong counter-evidence, otherwise every encouraging case begins to look like confirmation.

The broad evidence remains cautious.

Scaling is still a minority state

Gartner's 22% figure is the clearest current signal that scaling across multiple business units remains limited.²

ServiceNow's workflow data points in the same direction. Only 16% of organisations in its 2026 global research had streamlined and integrated workflows across functions with AI, while only 9% reported autonomous multistep workflows and 9% completely new workflows.³

Those are not trivial numbers. They are simply not evidence of broad organisational redesign.

Personal use can deepen without organisational diffusion

Christos Makridis's 2026 analysis of more than 30,000 United States employees in the Gallup Workforce Panel adds another important qualification. Frequent AI use rose from under 10% to more than 27% between 2023 and the first quarter of 2026, but later growth was driven substantially by existing occasional users becoming frequent users rather than by large expansion at the extensive margin. Use also remained strongly uneven by hierarchy, occupation and industry.⁷

This means individual use can become much more intense without telling us that the organisation has redesigned around it.

Makridis reports that the association between AI use and worker outcomes varies with perceived strategic clarity and trust. Employees who said their organisation had a clear AI strategy were much more likely to be frequent users, while the association between frequent use, engagement and burnout differed by organisational context.⁷

The implication is not that strategy documents cause productivity. It is that management context is part of the adoption mechanism.

Pilot success is not the same as scale

In Asana's February 2025 survey of 3,182 United States and United Kingdom knowledge workers, 67% reported that their organisations struggled to scale AI beyond pilots. The wider report separately analyses product-usage data from more than 112,000 employees across more than 350 companies; Asana is commercially interested in the market it describes.⁸

The useful point is consistent with the other evidence: isolated use does not naturally turn into organisational transformation. Team workflows, context, management practice and infrastructure have to change around it.

Maturity is moving, but the transition is organisational

MIT CISR's 2025 update is particularly useful here because it revisits a model originally grounded in 2022 data with a smaller 2025 survey conducted during widespread generative-AI adoption and experimentation with agentic AI. The research found the largest financial impact in moving from stage 2 - pilots and capability building - to stage 3 - scaled AI ways of working.⁵

The authors identify four challenges in that transition: strategy, systems, synchronisation and stewardship. In practical terms: align investments with value; build interoperable systems and data; redesign people, roles and work; and embed monitoring and responsible governance.⁵

That list looks remarkably like the Whole Product problem.

So the counter-evidence does not weaken the paper's thesis. It defines its boundary.

AI can be mainstream as a tool before it is mainstream as an organisational system.

10. The early majority arrives function by function

The phrase "early majority" is tempting because it suggests a large group moving together.

Inside organisations, the movement will often be uneven.

Customer service may redesign early because the work is high-volume, digitally mediated, measurable and constrained by queueing, service capacity and repetitive demand.

Procurement may move differently because commercial judgement, supplier relationships, fragmented data, authority limits and systems integration are central to the work.

Risk functions may move cautiously because the value of automation is high but the cost of a wrong judgement can also be high.

Finance may find some workflows highly automatable while retaining tighter control around reporting, treasury or material decisions.

Human resources may be able to automate administration while treating hiring, performance or employee-relations decisions differently because of fairness, legal and reputational concerns.

The same organisation can therefore contain several rational adoption curves.

A multi-curve map

For each function, management can ask where it currently sits:

Not AI → Not Yet → Hold → Trial → Integrate → Re-engineer → Scale

These are decision states, not maturity trophies.

Not AI means the problem is better solved another way.

Not Yet means the use case may be valid but the technology, data, economics, regulation or organisational capability is not ready.

Hold means the organisation has learned enough to pause deliberately while a specific uncertainty is resolved.

Not Yet and Hold should name the missing condition, the evidence required, the decision owner and the trigger for review. Without those fields, delay is drift rather than governance.

Trial means test the capability in a bounded environment.

Integrate means connect it to the real systems, data and workflow required for production.

Re-engineer means redesign the function or end-to-end process around what the combined human-machine system can now do.

Scale means repeat and expand the operating model where evidence supports doing so.

An organisation should expect different functions to occupy different states at the same time.

That is not inconsistency. It is disciplined adoption.

11. Benchmark the decision, not the crowd

The emergence of peer cases creates a new management risk: adopting because the market appears to be moving.

Peer evidence matters. It reduces uncertainty, shows what is feasible and helps pragmatic buyers distinguish a functioning category from a collection of demonstrations.

But peer behaviour is not the decision rule.

A competitor may have different data, systems, labour economics, regulation, customer expectations, risk tolerance or management capacity. It may also be making a mistake.

Benchmarking is therefore useful for identifying possibilities, not for surrendering judgement.

The governing principle should be:

This is why Not AI and Not Yet need to remain legitimate outcomes.

When "not AI", "not yet" or "hold" is a sign of maturity

A function should choose Not AI when a simpler deterministic system is cheaper, safer or easier to govern, or when the underlying problem is bad process design rather than insufficient intelligence.

It should choose Not Yet or Hold when the use case may be sound but an important condition remains unresolved. That may be the data, the available controls, the economics, the provider's ability to support the dependency being created, or the organisation's own capacity to absorb the change without damaging something more important.

Maturity is not measured by the proportion of work touched by AI.

It is measured partly by the quality of the decisions about where AI belongs - including the decision to wait or decline.

The negative evidence is quieter

Approval decisions are marketed. Stop decisions tend to survive in regulator rulings, court judgments, audit reports, annual accounts and post-mortems. That evidence is harder to find, but it matters because it shows that Not AI, Not Yet and Hold are not theoretical options.

Not every example below is generative AI. AMAS and SyRI are algorithmic decision systems. They are included as governance precedents because the decision concerned production authority, legal basis and human consequence - not as evidence about current model capability.

New Zealand Police: local permission was not organisational authority

New Zealand Police trialled Clearview AI facial recognition between February and March 2020. An internal governance group had approved the trial, but it proceeded without Police Executive approval or consultation with the Privacy Commissioner or Government Chief Data Steward. The software was judged not operationally viable. The subsequent review led to central governance reporting to the executive and a policy for emerging-technology trials.²⁰

This was a bounded trial, not a major production programme. Its value is narrower: it shows that project-level approval and organisational authority are not the same thing.

Austria's employment service: a national deployment stopped at the legal boundary

Austria's Public Employment Service intended to introduce its Labour Market Opportunities Assistance System (AMAS) nationwide in January 2021. In August 2020, the Austrian Data Protection Authority prohibited the processing. It treated the system as profiling under the General Data Protection Regulation and found no sufficiently clear statutory basis for data processing of that scale and effect.²¹ The litigation later changed the legal reading: in September 2025, the Federal Administrative Court held that advisers retained sufficient decision authority for the system to comply.²² By then, however, the data and development had been deleted, and the service said the project would not be revived.²³

That sequence is important. A stop can be rational even when part of the underlying proposition is later vindicated. Timing, evidence and authority are part of the Whole Product; they are not paperwork outside it.

The Netherlands' SyRI: public value did not override an inadequate legal basis

The Hague District Court held in February 2020 that the legislation governing the System Risk Indication (SyRI) welfare-fraud system failed to strike a fair balance under Article 8 of the European Convention on Human Rights. The court emphasised the state's special responsibility when applying new technologies and found the system insufficiently transparent and verifiable.²⁴

SyRI was already operating, so this was not an early project gate. It is nevertheless a clear example of external authority removing production permission after enthusiasm and implementation had already occurred.

South Wales Police: Not Yet, then governed re-entry

In August 2020, the Court of Appeal found South Wales Police's ongoing use of live automated facial recognition unlawful: the legal framework left excessive discretion over watchlists and deployment, the data-protection impact assessment was deficient, and the public-sector equality duty had not been met.²⁵ Deployment did not proceed unchanged.

South Wales Police later carried out further trial deployments, testing and evaluation, and relied on independent National Physical Laboratory work. It says it resumed use on 5 April 2023.²⁶ Whatever one's view of facial recognition, the governance pattern is useful: Not Yet became a later Yes only after the authority, evidence and operating conditions changed.

Not Yet needs a route back

Not Yet is not indecision when the conditions for Yes have been stated.

A useful Not Yet or Hold decision should record five things:

• the missing condition - legal authority, data quality, control, economics, provider capability, organisational capacity or evidence;
• the evidence or change required to close it;
• the person or body authorised to reopen the decision;
• the permitted scope while the condition remains open - research, sandbox, trial, parallel running or none;
• the review trigger - a date, an external decision or the production of specified evidence.

This converts delay from passive drift into managed option value. It also prevents a project from being quietly reintroduced under a new label without resolving the reason it stopped.

12. What adoption means to the organisation

The deepest implication of Whole Product adoption is that the technology decision becomes an organisation-design decision.

Once AI participates in ordinary work, five things begin to change.

Work changes

The sequence of activities can change rather than merely accelerate.

Steps may disappear. Handoffs may move. Information may be assembled before a person asks for it. AI may handle routine cases and concentrate human attention on exceptions. A process that was designed around scarce analysis can become inefficient when analysis becomes abundant.

Roles change

People may move from producing every unit of work to supervising, handling exceptions, exercising judgement, managing relationships or improving the system. That does not automatically mean fewer people; it means the work content changes.

It also creates a training problem. If junior staff no longer perform the tasks through which expertise was traditionally learned, the organisation has to design another route to competence. People may struggle to supervise work they have never learned to judge.

Authority changes

An AI system that can recommend is different from one that can act.

The organisation must decide which actions can occur automatically, which require review, what thresholds apply, who can override, how exceptions escalate and who remains accountable.

This is governance becoming operational rather than documentary.

Systems become coupled

The AI ceases to sit beside the organisation and begins to depend on its live systems, data and identity infrastructure.

That can create value because context and action become connected. It also increases dependency. Changes to an ERP system, data definition, application programming interface (API), vendor model or permission structure can now affect the AI-enabled workflow.

Economics change

Reliable productivity gains can affect staffing, outsourcing, service levels, pricing, capacity investment and the allocation of management attention.

But the economic gain is not automatic.

Freed capacity has to go somewhere useful. Faster work has to improve an outcome that matters. Lower unit effort can be offset by increased supervision, integration or exception cost. A system that saves time but increases operational risk may not create value at all.

This is why the Whole Product business case should include three ledgers:

1. Core capability cost - licence, usage, model and direct technology cost.

2. Whole Product cost - integration, data, implementation, governance, support and monitoring.

3. Organisational absorption cost - management attention, training, role redesign, parallel running, disruption, temporary duplication and stranded capability.

The third ledger is especially easy to miss because much of it never appears on an external invoice.

13. The management question changes

When a technology is immature, leaders ask what it can do.

When it begins to mature, the better questions move outward.

Where is the serious operating constraint?

What value is trapped by the current operating model?

Is AI actually the right intervention?

What Whole Product would be required for ordinary operation?

Which parts already exist and which would have to be built?

What must change in the workflow?

Which decisions can the machine make, which must remain human, and why?

Who is accountable when the two disagree?

Who is authorised to approve production - and who can stop it?

What will implementation cost beyond the licence?

Can the organisation absorb the transition?

Is the proposed implementation partner competent across technology, integration, operating design and governance?

Can that partner be replaced?

What evidence will establish that the system is releasing value rather than merely generating activity?

Which condition, if satisfied, would justify advancing to the next state?

These are ordinary management questions.

That is itself a sign of maturation.

The more AI becomes part of the operating model, the less useful it is to treat AI as a separate programme with its own exceptional logic. Finance still has to finance it. Operations still has to operate it. Risk still has to understand it. Technology still has to integrate it. Human resources still has to deal with changed roles and skills. Management still has to decide what outcome matters and who owns it.

The technology may be novel.

The obligation to manage the system is not.

How this paper connects to the wider Andrew's Intel work

The earlier adoption pieces supply the measurement foundation; this paper supplies the function-level test and evidence architecture. The Functional AI Readiness Diagnostic is the practical application layer for this paper. It applies the same logic to a nominated function or workflow, identifies missing evidence, controls and authority, and supports a defensible next decision: Proceed, Not Yet, Hold or Stop. It is a decision aid, not a competitive league table. Supporting articles can go deeper into Whole Product design, implementation-partner selection and organisational absorption, but they extend this paper rather than being required to understand it.

Conclusion: the chasm is moving up the stack

Artificial intelligence does not cross one chasm once.

Different technologies, workflows, functions and organisations can occupy different adoption states at the same time.

The current evidence is consistent with a market in which AI is becoming ordinary at the level of access and individual use while deeper organisational redesign remains much less common. That is why enterprise adoption can look both advanced and immature depending on what is measured.

The more useful signal is the emergence of function-level systems in which AI is no longer an isolated tool. It is connected to live workflow, systems of record, governance, human judgement, implementation, support and measurable outcomes.

That is the Whole Product transition.

It also explains why the market around AI is changing. Readiness assessments, risk analysis, implementation services, managed support and governance products are becoming part of what pragmatic buyers purchase. The surrounding market reduces ambiguity - while also creating new sales incentives, dependency and partner-selection risk.

None of this justifies a universal "adopt faster" message.

A function should move when the decision case supports moving. It should wait when important conditions are missing. It should reject AI when a better solution exists.

The important crossing is not the moment when most employees have access to an AI tool.

It is the point at which a function can reorganise around a complete enough system, operate it repeatedly, govern it, recover from failure and release value that the previous operating model could not reliably capture.

That is a much harder standard than adoption.

It is also a much more useful one.

Executive artefact: Functional Chasm Test

Use this sheet for one nominated function or workflow. Do not score the organisation against competitors. Record what is true now and what would have to become true next.

On a narrow screen, each row is shown as a separate card.

Current decision state

Choose one:

Then answer the most important question on the page:

For Not Yet or Hold, also record: missing condition / required evidence or change / decision owner / permitted interim scope / review trigger. If those fields are empty, the decision is not yet governable.