The invoice arrives before the strategy does. In mid-2026 Microsoft, the company with the deepest AI distribution advantage in enterprise software, terminated its internal Claude Code licences after per-engineer bills reached 500 to 2,000 dollars a month, and redirected those engineers to its own tooling. Uber capped agentic coding spend at 1,500 dollars per employee per month. These are two of the most sophisticated technology buyers on earth, and both discovered the same thing at the same time: the price of the AI they had built into daily work was set by someone else, and it moved.

If that is happening to Microsoft, it is happening to you, and the difference is that Microsoft can build its own model and you cannot. Menlo Ventures’ December 2025 enterprise survey, as analysed by Brookings, found that three providers, Anthropic at roughly 40%, OpenAI at 27%, and Google at 21%, together control almost 90% of the 37 billion dollar enterprise LLM market. Brookings did not hedge the description. It called the market an oligopoly. The capability you spent two years embedding into customer support, code, underwriting, and document work now rests on a supplier base of three, and the terms are theirs to change.

The previous posts in this series looked inward: selecting use cases, capturing ROI, scaling agents, redesigning the org chart, the seniority cliff. This post looks at the supply side. Not what AI can do for you, but who you are now structurally dependent on to keep doing it, and what happens when that dependency meets a price rise, a deprecated model, or a European supervisor.

📊 The Numbers: Three providers control close to 90% of the 37 billion dollar enterprise LLM market (Menlo Ventures, via Brookings). Yet in Zapier’s 2026 enterprise survey, while 81% of leaders are concerned about vendor dependency, only 6% believe they could switch their primary provider without material operational disruption.

This is not the vendor risk your procurement team already manages

Enterprises have managed software vendor dependency for decades. This is a different animal, and treating it like the old one is the first mistake.

Classic vendor lock-in was contractual and data-format based. You could, with effort and a migration budget, move from one ERP to another. AI concentration operates across five layers at once and they compound: the model, the orchestration layer that coordinates agents, the data your workflows have accumulated inside the vendor’s environment, the governance evidence a European regulator will one day ask for, and the organisational knowledge your people have built around one provider’s quirks. An organisation that is 60% locked in at the model layer, 70% at orchestration, and 80% at data does not have an average switching cost. It has one that reflects all three dependencies intersecting at once. Lock-in here is multiplicative, not additive.

Underneath the concentration sits a harder economic fact. The binding constraint at the AI frontier is no longer capability. It is compute supply. The 2026 foundation model landscape from Information Matters found three top-tier vendors signalling compute-constrained operations in the first quarter of 2026, and noted that frontier pricing has stopped declining, with open-weight models now doing the price-decline work instead. When supply is scarce and demand is inelastic, because you have already rebuilt your workflows around the product, the pricing power sits entirely with the seller. Most enterprises walked into that position without naming it.

The switching cost you cannot see until you try to move

The gap between knowing this and doing anything about it is the real story, and it is stark.

Zapier’s 2026 enterprise survey found that 81% of leaders are concerned about AI vendor dependency, and 47% say a key business function would stop working if their primary vendor suffered an outage or changed its pricing. Only 6% believe they could switch their primary provider without material operational disruption. Read the three bars together and the awareness is nearly universal while the capacity to act is almost nonexistent. Enterprises have deployed AI far faster than they have built the architecture to exit it.

Two things make the exposure worse than the numbers suggest. The first is hidden concentration: a team that believes it runs a diversified multi-vendor estate often finds several nominally independent SaaS tools all running on the same underlying cloud, so one provider disruption takes down what looked like three separate systems. The second is model deprecation. Providers retire and replace model versions on their schedule, not yours, and a version change can silently alter a workflow you validated against the old one. The collapse of Builder.ai, once valued at 1.3 billion dollars and backed by Microsoft, showed the extreme case: customers tightly coupled to the single vendor were stranded when it disappeared, unable to access critical functions or data.

💡 Key Insight: The vendor does not have to fail to hurt you. A price change is enough, and 47% of enterprises say a key function would stop if it came. You did not buy a tool. You bought a dependency, and a dependency is priced by whoever holds the other end of it.

The vendor is quietly moving into your business

Concentration would be manageable if the concentrated suppliers stayed in their lane. They are not.

Brookings framed the deeper risk precisely in its 2026 analysis of what happens when AI companies compete with their customers. The providers you depend on for infrastructure are also building applications, agents, and products that overlap with what their enterprise customers sell. Post 9 in this series documented the AI-native competitor entering your market from outside. This is the same threat arriving from inside your own supply chain: the vendor whose model powers your product has both the capability and the usage data to build a version of it itself.

This is why the concentration matters strategically, not only operationally. The durable moat is shifting from the systems of record that SaaS incumbents owned to the systems of action that AI agents now execute. When your agents run on a provider’s proprietary orchestration layer, that provider accumulates the logic of how your business actually runs. You are not just a customer. You are a training signal, handing over the one asset, your operational know-how, that was supposed to be yours.

In Europe, concentration is no longer a preference. It is supervised.

Everywhere in the world, vendor concentration is a commercial judgment. In Europe, for a large and growing set of enterprises, it has become a legal obligation with a supervisor attached. This is the part US-written analysis almost entirely misses, and it is where the European lens stops being a differentiator and becomes the whole argument.

The Digital Operational Resilience Act, DORA, has applied across the EU since 17 January 2025. It requires financial entities to assess and manage concentration risk in their ICT supply, document a credible exit strategy for any provider supporting a critical or important function, and test that exit at least annually. Article 28 demands the concentration assessment and the ability to exit without undue disruption, Article 29 a pre-contract concentration assessment before signing, and Article 30 the exit and transition clauses that make the right to leave actually executable. A right-to-exit clause that no one could ever exercise is exactly what supervisors now probe.

The dependency this addresses is already documented. The European Banking Authority’s 2024 risk dashboard found over 70% of significant banks rely on at least one of the three hyperscalers, AWS, Microsoft Azure, or Google Cloud, for at least one critical function, with over 65% using at least two. On 18 November 2025 the European Supervisory Authorities designated the first 19 critical ICT third-party providers, a list including AWS, Microsoft Azure, Google Cloud, Oracle, IBM, SAP, and Deutsche Telekom, and the DORA Joint Oversight Forum began its first examinations across 2026 with binding recommendations expected. Since almost every production AI workload runs on precisely these designated hyperscalers, your AI vendor concentration and your regulated ICT concentration are now the same problem, viewed by the same supervisor.

⚠️ Watch Out: Your multi-vendor AI strategy may be three vendors running on one cloud. Under DORA that is not diversification, it is undocumented concentration, and an untested exit plan is what an examiner assumes is fiction. If your firm is in scope and your AI estate is not in your Register of Information with a tested exit, you are exposed on both the operational and the regulatory axis at once.

The sovereignty option is real, and it is oversold

The instinctive European answer is to buy European, and sovereignty has moved from ambition to procurement criterion faster than most incumbents realise. ISG’s 2026 research found European enterprises reclassifying sovereign cloud from a compliance safeguard to core infrastructure for AI workloads under EU jurisdiction. Mistral has become the most production-ready European model option and saw revenue surge simply for being an alternative to the US labs, with SAP and Mistral announcing a sovereign AI stack on SAP’s Business Technology Platform in November 2025. In April 2026 the Cohere and Aleph Alpha merger, backed by the German and Canadian governments and a Schwarz Group investment, set out to build a transatlantic sovereign alternative for regulated and public-sector buyers.

That is the genuine opportunity. Now the honest counterweight, because a consultant who sells only the upside is not worth hiring. Forrester’s 2026 European predictions concluded plainly that no European enterprise will shift entirely from the US hyperscalers in 2026, and that a wholesale move to local suppliers is impractical in the short to medium term. Sovereignty reduces one dependency by creating another, and a European provider under compute constraint has the same pricing power a US one does. The point is not to swap a US monoculture for a European one. It is to end the monoculture.

What the organisations getting this right do differently

The ones handling this well are not the ones who picked the perfect vendor. They are the ones who refused to depend absolutely on any single one, and built the option to move before they needed it.

• Build the abstraction layer before the second vendor, not after. An abstraction layer separates your workflow logic from any one provider’s API, so a switch means changing the interface rather than rewriting every integration. Enterprises that build it into the first deployment add or switch providers with far less migration effort than those who wired everything directly to a single API. It has a small upfront cost and a large retroactive one.

• Run a portfolio, not a marriage. Route the workload to the model that fits it, keep at least one credible secondary provider live in production rather than on a slide, and treat open-weight models as the pricing-discipline benchmark that stops a frontier vendor’s increases from being uncontestable.

• Make the exit plan real by testing it. A fallback that has never been activated is not a fallback. Run the switch on a non-critical workload on a schedule, so that when a price rise or deprecation arrives, the migration is a rehearsed procedure and not a crisis. In DORA scope, this is not optional. It is the annual test.

• Put concentration on the enterprise risk register with a named owner. Not in an architecture document. On the risk register, alongside supply-chain concentration and key-person dependency, with a reported metric: the share of critical AI workload resting on any single provider, and the tested time to switch it. Risks that are not owned and not measured do not get managed.

• Negotiate from optionality. Every move above is also commercial leverage. A vendor that knows you can leave prices differently from one that knows you cannot, and the 6% who could switch are the only ones with real bargaining power at renewal.

✅ Leadership Action: Before the next renewal, commission a real exit test on your single highest-value AI workload. Not a clause, not a slide, an actual migration to an alternative provider on a non-critical instance. The exercise produces three things at once: the true switching cost, a rehearsed procedure, and, in DORA scope, the evidence a supervisor will ask for. If it cannot be done, that is the finding.

The leader’s 30-day move

A concrete sequence before the next AI contract renewal is signed.

• Week 1. Map the true concentration. For every production AI workload, record the model provider, the orchestration platform, and the underlying cloud. Collapse the nominal vendor count to the real one. Most leaders discover their diversification is thinner than the procurement list suggests.

• Week 2. For the three highest-value workloads, cost the exit. What would it actually take, in time and money, to move each to an alternative provider? The honest number is your switching cost, and it is almost always higher than assumed.

• Week 3. Stand up one abstraction layer and bring one credible secondary provider into live production on a non-critical workload. One workflow, genuinely portable, tested end to end.

• Week 4. Add AI vendor concentration to the enterprise risk register with a named executive owner and two reported metrics: single-provider share of critical workload, and tested time to switch. If your firm is in DORA scope, cross-reference your AI estate against your Register of Information and confirm each critical dependency has an exit that has actually been tested.

The consultant’s takeaway

Every enterprise that scaled AI in the last two years made a rational decision at each step: pick the best model, integrate it deeply, move fast, ship value. The sum of those steps is a position almost nobody chose deliberately: a business-critical capability resting on three suppliers, priced by them, deepening by the quarter, with an exit that 94% of leaders admit they could not execute cleanly. The efficiency was real and immediate. The dependency is real and compounding, and it was never priced into any business case.

For European leaders this is sharper than for most, and for once the regulation is an asset rather than a burden. DORA has already forced the financial sector to name its concentration, document its exits, and test them, which is precisely the discipline the economics demanded anyway. The firms treating that as a compliance chore will produce a binder. The firms treating it as an operating-model decision will end up with something more valuable: a genuine ability to move, and therefore a genuine ability to negotiate.

The next renewal will not turn on which model is best. It will turn on whether you could walk away from the one you have. The vendor already knows the answer to that question, and has been pricing you against it. The only thing left to decide is whether you know it too.

The restructuring numbers that dominate boardroom discussion are the wrong ones. What matters is not how many roles came out of the organisation. It is which rung of the ladder they came from.

A Harvard working paper by Seyed Hosseini and Guy Lichtinger, covering résumé and job posting data for more than 60 million workers across over 280,000 firms between 2015 and 2025, found that firms adopting generative AI cut junior employment by roughly 9% within six quarters, while senior employment at the same firms showed no comparable break and continued to rise. The researchers named the pattern seniority-biased technological change. The Stanford Digital Economy Lab, analysing payroll records in its Canaries in the Coal Mine study, found a 13% relative employment decline for workers aged 22 to 25 in the most AI-exposed occupations since late 2022, with older workers in the same occupations holding steady or growing.

The mechanism matters more than the magnitude. This was not a wave of redundancies. Separation rates for juniors barely moved. It happened almost entirely through hiring that quietly stopped, and it started before the automation actually arrived. Firms adjusted their intake for the productivity they expected rather than the productivity they had. The previous posts in this series dealt with restructuring sequence, with the verification bottleneck, and with why training programmes fail to change behaviour. This post deals with the second-order effect none of those cover: what happens to the supply of experienced judgment when the work that produced it is the first thing you automate.

📊 The Numbers: Junior employment fell around 9% at generative-AI-adopting firms within six quarters, while senior employment at the same firms kept rising (Hosseini and Lichtinger, Harvard 2026). Employment for 22 to 25 year olds in the most AI-exposed occupations declined 13% relative to peers since late 2022 (Stanford Digital Economy Lab).

The data has stopped being ambiguous

For most of 2024 and 2025, the entry-level story was contested. It could plausibly be read as post-pandemic correction, interest rate pressure, or the ordinary cyclical thinning of graduate intake. That reading no longer survives contact with the evidence, because the effect is now visible within firms rather than across the economy. The comparison is between companies that adopted generative AI and companies that did not, in the same sectors, over the same period.

The shape of that chart is the entire argument. If AI were simply reducing headcount, the bars would move together. They do not. The decline is concentrated precisely where codified, checkable, textbook-learnable work sits, and that is the definition of an entry-level role. Pay data points the same direction: analysis of AI-exposed firms found starting wages fell around 4.5% after ChatGPT’s launch, with a steeper 6.3% drop for junior positions and stable or rising pay for senior hires. The market is repricing experience upward at exactly the moment it stops manufacturing any.

💡 Key Insight: The tasks AI absorbed first were never valuable for their output. They were valuable because they were the tuition. Nobody was paying a graduate analyst for the reconciliation itself. They were paying for the twenty-fourth reconciliation, where the analyst finally sees why the number is wrong before the model does.

Four things break when the bottom rung disappears

1. The work that taught judgment was the most automatable work. Early-career roles were built from research, first drafts, documentation, reconciliation, and routine analysis. These tasks are unglamorous, high volume, and structured, which is exactly the profile this series has repeatedly identified as the highest-yield AI target. That was correct advice and remains correct. What almost no business case captured is that these same tasks carried the context, repetition, and feedback through which a professional learns how decisions actually get made, when to escalate, and what a wrong answer looks like before anyone else notices.

2. Review-first work inverts the learning sequence. The common response is to redefine the junior role as reviewing AI output. This sounds like an upgrade and is closer to the opposite. Reviewing asks someone to detect error before they have ever produced the thing well enough to know what error feels like. You cannot audit a forecast you have never built, and you cannot spot a flawed argument in a structure you have never had to construct yourself. Review is a downstream skill presented as an entry-level one.

3. Verification is a senior capability, and the pipeline that produced it is the one being cut. An earlier post in this series argued that human oversight, not model capability, is the binding constraint on scaling AI. That argument assumed a supply of people qualified to verify. A CHI 2026 study found AI assistance is weakest exactly where tacit, specialist knowledge matters, in settings where output cannot be easily checked because the expertise lives in people’s heads. It is a single small study and should be treated as directional, but it names the trap precisely. The more autonomous the systems become, the more verification capacity the enterprise needs, and the fewer people it is training to supply it.

4. The cost lands two CEOs later, so nobody owns it. A thinner bench does not show up in this year’s EBIT or next year’s. It shows up in seven to ten years as unfilled senior roles, longer time to competence, expensive external hires for positions that used to be filled internally, and a management layer that has never done the work it now supervises. No current executive is measured on it, no business case models it, and no restructuring deck contains a line for it. That is why it is happening at scale without anyone deciding to do it.

⚠️ Watch Out: If your workforce plan treats entry-level roles purely as a cost line, you will automate them on schedule and discover the consequence long after the executives who approved it have moved on. The efficiency is real and immediate. The liability is real and deferred, which is precisely why it goes unpriced.

Europe has already written the oversight requirement into law

For European leaders this is not only a talent question. It is a compliance question with a date attached.

Under Article 26 of the EU AI Act, deployers of high-risk AI systems must assign human oversight to natural persons who have the necessary competence, training and authority, together with the necessary support. Article 14 sets the standard for what that oversight must be capable of doing, and for certain systems requires separate confirmation by two qualified persons. The Article 4 AI literacy obligation has applied since February 2025, and the deployer obligations under Article 26 become applicable on 2 August 2026. The regulation is explicit that oversight competence is a higher bar than general AI literacy. The overseer needs specialised knowledge of the system in question.

Read that alongside the hiring data and the problem states itself. The AI Act assumes a standing population of people qualified to exercise judgment over automated decisions in your domain. Competence of that kind is accumulated, not appointed. An organisation that has spent three years thinning the roles where domain judgment was built is going to find the named-person requirement considerably harder to satisfy than it looks on a compliance checklist.

The German picture sharpens this further. The Institute for Employment Research projects that the number of economically active people in Germany will fall from 47.1 million in 2023 to around 46 million by 2040, with the baby boomer cohort retiring through to 2035. German industrials are therefore constricting the entry pipeline at precisely the moment the exit pipeline opens widest. The dual training system that made German engineering depth possible was never primarily a recruitment channel. It was a judgment transfer mechanism, and it is being quietly disinvested in by firms that would never describe the decision that way.

What the organisations getting this right do differently

The ones handling this well are not hiring more juniors out of sentiment. They are separating two things that entry-level work had always bundled together, and being deliberate about which one they automate.

• Distinguish output-producing tasks from judgment-producing tasks. Run this at role level, not function level. For each early-career role, list the tasks and mark which ones exist because the work needs doing and which ones exist because that is where someone learns to see. Automate the first category aggressively. Treat the second as developmental infrastructure with a protected budget line. Most organisations have never made this distinction explicitly, which is why it gets resolved by default.

• Redesign entry-level roles around supervised production, not review. Juniors should still produce, at lower volume and higher scrutiny, on work where AI could have done it faster. The inefficiency is the point, in the same way a flight simulator is deliberately inefficient. Then have them compare their output against the model’s and defend the difference. That exercise builds the discriminating judgment that review-only roles never develop.

• Make coaching a measured obligation of the manager. Deloitte’s 2026 Human Capital Trends research argues AI is reshaping how workers learn in the flow of work, which makes manager-led learning more important rather than less, because tools accelerate output while leaving people unclear on how expert decisions are reached. This series has made the same point twice about training and activation. Managers determine whether individual capability becomes organisational capability. Put decision walkthroughs and work reviews into the manager’s objectives, with a stated cadence, or they will lose to delivery pressure every quarter.

• Put bench depth on the risk register with a named owner. Not in the HR strategy deck. On the enterprise risk register, alongside supply chain concentration and key person dependency, with a named executive accountable and a reported metric: internal fill rate for senior roles, and time to competence for critical positions. Risks that are not owned and not measured do not get managed, and this one has a decade-long fuse.

✅ Leadership Action: McKinsey’s State of Organizations 2026, surveying over 10,000 leaders, concludes that for every dollar spent on AI technology, organisations should invest five in people. Before your next AI business case is approved, ask what share of its total budget is allocated to building the capability that will supervise the system in five years. If the answer is nothing, the case is incomplete rather than efficient.

The leader’s 30-day move

A concrete sequence before the next workforce planning cycle is signed off.

• Week 1. Pull the last three years of hiring by seniority band, split by function. Compare the trend in functions with heavy AI deployment against those without. Most organisations have never looked at this cut, and it is usually available in 48 hours. The pattern is either there or it is not, and you should know which.

• Week 2. Pick the two functions where domain judgment takes longest to build, typically engineering, underwriting, quality, or regulated operations. Map the developmental path in each: what does someone do in year one, year three, year five that makes them capable in year ten? Mark every step on that path that AI has already absorbed or is scheduled to absorb.

• Week 3. For those functions, redesign the entry-level role around supervised production with explicit judgment checkpoints, and name the manager accountable for coaching cadence. One role, one function, documented.

• Week 4. Add bench depth to the enterprise risk register with a named owner and two reported metrics. In parallel, cross-reference your EU AI Act high-risk inventory against your named oversight persons and ask a blunt question for each one: where does the next qualified overseer come from, and are we still producing them?

The consultant’s takeaway

Every enterprise in Europe is currently running an unpriced trade. It is exchanging a visible five-year cost reduction for an invisible ten-year capability reduction, and it is doing so without a decision ever being made, because no single business case contains both sides of the ledger.

The uncomfortable question underneath the data is simple. How does anyone become senior if they can no longer be junior? Organisations do not answer that question by hiring more graduates or by slowing AI adoption. Neither is realistic and neither is right. They answer it by working out which of the work they are automating was training in disguise, and rebuilding that specific function deliberately, rather than assuming it will survive the removal of the tasks that carried it.

For German and European industrials this is more urgent than for most, and the reason is arithmetic rather than culture. The retirement wave is already scheduled, the workforce is already contracting, the AI Act already requires named humans with demonstrable competence to oversee high-risk systems from August, and the pipeline that would have supplied those humans is being thinned right now for reasons that look entirely rational quarter by quarter. The firms that look well run in a decade will not be the ones that automated entry-level work fastest. They will be the ones that understood what that work was actually for before they removed it.

Ask a European industrial group where its AI programme sits and the answer is almost always the same. In IT, or in a transformation office reporting to IT, measured in licences deployed and hours returned to the business. Ask the same group where its profit comes from and you get a different answer entirely. McKinsey’s May 2026 aftermarket research found that at one elevator and escalator company, services accounted for nearly three quarters of the margins. Its analysis of more than fifty industrial organisations across fifteen years found those with a high service focus delivered 1.7 times the total shareholder return of those focused mainly on products.

Two answers, two halves of the company, almost no overlap. The AI programme is pointed at the half that carries the cost. The margin sits in the half it has no mandate over.

The previous posts in this series worked exclusively on the first half. Use case selection, the ROI that leaks, scaling agents, activating licences, shadow AI, the org chart, the verification bottleneck, the data foundation under all of it. Every one assumed AI is something the enterprise uses. For a machine builder, a medical device maker, or a vehicle manufacturer, that assumption quietly writes off the more valuable half of the business. This post is about the other half: the AI you sell rather than the AI you use, and why in Europe that distinction is now a legal one.

📊 The Numbers: Deloitte’s 2026 State of AI in the Enterprise found 74% of organisations hope AI will drive revenue growth and about 20% have achieved it. Revenue does not live in the workflow your AI programme is pointed at. It lives in the offering, which almost no AI programme is allowed near.

The series has been writing about half the company

Deloitte’s 2026 State of AI in the Enterprise, based on 3,235 senior leaders across 24 countries, splits organisations into three roughly equal groups: 34% using AI to create new products and services or reinvent business models, 30% redesigning key processes around it, and 37% applying it at a surface level. The same research found 74% hope AI will drive revenue growth and about 20% have achieved it.

Post 5 treated that revenue gap as a measurement and absorption problem, and at the workflow level it is. But there is a blunter explanation the measurement framing obscures. An AI programme aimed exclusively at internal workflows can only produce cost outcomes, and will always struggle to explain itself in the revenue column no matter how well instrumented it is. The 20% growing revenue are largely the 34% who put AI into what they sell.

For an industrial group this is not a philosophical distinction. It is the difference between a programme reporting to the CIO and one reporting to the business unit head who owns the product roadmap. Almost every European industrial has the first. Very few have the second.

The multiple is in the service business

The financial case for pointing AI outward is stronger than the case for pointing it inward, and it has been visible in the data for some time.

Three multiples, one direction. McKinsey’s Putting AI to work research, surveying 1,000 executives across 696 manufacturing and service businesses, found that companies embedding AI across many functions generate nearly double the profit margins of peers using it in only a few, with three-year return on invested capital more than five times higher. The same research found roughly 90% of organisations at least experimenting with AI and only about 7% scaling it across the enterprise.

The uncomfortable reading is that the returns come from breadth and from the service P&L, and a copilot rollout delivers neither. It delivers depth in one function, in the half of the company that does not carry the margin.

The word that changes everything is “provider”

Here is where the European lens stops being a differentiator and becomes the whole argument.

The EU AI Act does not assign obligations by company. It assigns them by role. A deployer uses an AI system under its own authority. A provider develops an AI system, or has one developed, and places it on the market under its own name or trademark. Every post in this series so far has been written for deployers, because that is what an enterprise using Copilot is.

The moment you put an AI system into a product you sell, you are the provider, and the obligation set is a different order of magnitude. Article 16 pulls in a risk management system, data governance, technical documentation, automatic record keeping, instructions for use to your deployers, human oversight designed in rather than bolted on, accuracy and cybersecurity, and a quality management system. On top of that sit conformity assessment, an EU declaration of conformity, CE marking, registration in the EU database before the product reaches the market, and post-market monitoring for the life of the system. The Article 26 deployer obligations most European compliance functions have spent a year preparing for are, by comparison, a short list.

Article 25 is the trap. Put your name on a high-risk AI system already on the market and you become its provider. Substantially modify one, including changing its intended purpose, and you become its provider. Fine-tuning a supplier’s model on your own field data or extending what the system may act on sit close to that line. A great deal of what an engineering team would call ordinary product work is, under this regulation, the act of becoming a manufacturer of AI.

⚠️ Watch Out: Your compliance function has probably scoped the AI Act as a deployer exercise, because that is what the enterprise IT estate required. If any business unit is embedding AI into a shipped product, the company is a provider, and nobody has scoped that. Contractual language pushing responsibility back to the model vendor does not change the classification. The Act assigns roles functionally, not contractually.

The date on your compliance slide is the wrong date

Every European AI compliance deck written in the last eighteen months, including the analysis in earlier posts of this series, carried 2 August 2026 as the hard date for high-risk obligations. That date has moved, and the movement is not the relief it appears to be.

Following the political agreement of 7 May 2026 on the proposal to simplify the AI Act, the Commission has set a revised timeline. Rules for systems used in certain high-risk areas, including biometrics, critical infrastructure, education, and employment, now apply from 2 December 2027. Rules for AI integrated into products already covered by EU product safety legislation, such as lifts, toys, and machinery, apply from 2 August 2028. The agreement also clarifies the interplay between the AI Act and the Machinery Regulation, precisely the seam every machine builder in Germany has been asking about. Everything else, including the transparency rules, remains applicable from 2 August 2026.

Read that as a leader rather than as a lawyer. Two clocks are now running and they belong to two different parts of your company. The 2026 clock is your IT estate’s. The 2028 clock is your product’s, and it is the tighter of the two, because industrial product programmes run on three to five year cycles. The machine whose architecture is being frozen in specification reviews this quarter is the machine that has to satisfy the 2028 regime. There is no version of that programme where compliance is retrofitted in 2027 without reopening the design.

💡 Key Insight: August 2026 is your deployer deadline and your compliance function is already on it. August 2028 is your product deadline and almost nobody has started, because the product organisation was never told the AI Act applied to them. Of the two, 2028 is the one you are already late for, since the product that must comply is the one being designed now.

The moat under the service business is being dismantled

While the AI Act determines what you must document about the intelligence in your product, a second regulation is rewriting who owns the data that intelligence runs on.

The EU Data Act has applied since 12 September 2025. Its logic is simple and, for an industrial incumbent, brutal. Data generated by a connected product belongs, in commercial terms, to the person using it. Users can demand access in a structured, machine-readable format, in real time where technically feasible, and can direct the manufacturer to share it with a third party of their choosing, including an independent maintenance provider. Under Article 4(13), a data holder may no longer use non-personal data generated by the product without a contractual agreement with the user, even for its own product development.

The dates matter for the same reason the AI Act dates matter. Access and sharing obligations are live now. Design obligations, requiring products to be built so the data is accessible by default, apply to connected products placed on the market from 12 September 2026. The unfair contractual terms rules reach into long-term contracts concluded on or before 12 September 2025 from 12 September 2027, putting an expiry date on the legacy service agreements currently protecting the installed base.

There are safeguards. Designated gatekeepers under the Digital Markets Act cannot receive the data, recipients may not use it to build a competing product, and trade secrets retain protection. But the Commission is explicit that the Data Act does not prohibit competition in aftermarket services, which is the entire point of it. It estimates roughly 80% of industrial data in Europe goes unused, and expects the Act to add around 273 billion euros to EU GDP by 2028 largely by unlocking the service competition incumbents have been fencing off.

Put the two regulations side by side and they converge on one demand. You must be able to say what the AI in your product does, on which data, under whose accountability, and you must be able to hand that data to your customer’s chosen competitor. That is not a compliance project. It is a product governance capability, and it does not exist in the function currently running your AI programme.

The defensive instinct is to slow the roadmap, bolt AI on as a feature at the end, and let legal manage the exposure. Post 9 documented what happens to incumbents who take that route: they pay the retrofit tax, ship the same capability months later, and lose the deal anyway. McKinsey’s April 2026 work on where AI will and will not create value makes the point from the other end. Foundation models are commoditising, so durable differentiation comes not from access to them but from redesigning offerings, economics, and ecosystems around them. The capability is table stakes. The product built around it is the asset.

The leader’s 30-day move

A concrete sequence for a leader who suspects their AI strategy is really an IT strategy.

• Week 1. Split the AI portfolio in two. Every initiative into one of two columns: AI we use, and AI we sell. If the second column is empty or holds only a pilot, that is your finding. Ask each business unit head, not the CIO, which products on their roadmap will contain an AI system when they ship. Most will not know, because nobody has put the question to them that way.

• Week 2. Run the role classification. For every product in the second column, establish whether the company is provider or deployer, and whether Article 25 pulls you into provider status through branding, resale, or substantial modification of a supplier’s model. Fine-tuning on your own data is not a technical detail. It is a legal event. Assign a named owner per product, not a committee.

• Week 3. Put both clocks on one page. 2 August 2026 for the IT estate. 2 December 2027 for Annex III systems. 2 August 2028 for AI embedded in regulated products. 12 September 2026 for Data Act design obligations. 12 September 2027 for legacy service contracts. Map your product release calendar against it. The overlaps are where the surprises are.

• Week 4. Decide who owns the intelligence in the product. Not the model, not the compliance file. The roadmap, the P&L, and the accountability for what the system does in a customer’s plant. If the answer is the CIO, the answer is wrong. If there is no answer, that is the largest gap on this list, and it is an org design decision, not a technology one.

✅ Leadership Action: Before the next product portfolio review, require one page per product line answering four questions. Will this product ship with an AI system inside it. Are we the provider or the deployer of that system. Which regulatory clock does it run on. And who, by name, owns the outcome. A product line that cannot answer all four is not ready for the 2028 regime, and it is being designed right now.

The consultant’s takeaway

The most consequential decision a European industrial leader will make about AI in the next two years is not which model to standardise on, how many Copilot seats to buy, or whether the governance framework is mature. It is whether the AI programme is allowed anywhere near the product.

That decision is currently being made by default, by an org chart that put AI in IT because in 2023 AI looked like an IT topic. It no longer is. In the half of the company that carries the margin, AI is a product capability, governed by product safety law, running on data the customer now controls, on a clock that runs to 2028 and a design freeze that runs to this quarter. None of that sits inside the CIO’s mandate, and none of it is on the AI programme’s dashboard.

For a European industrial this is not the disadvantage it is usually framed as. Being a provider under the AI Act is a burden, but it is a burden that produces an auditable, documented, human-overseen product at exactly the moment that becomes a procurement criterion. Being forced open by the Data Act threatens a closed installed base, but the interfaces that let a competitor in let you out, into fleets you never built. Compliance and expansion are one engineering programme, executed once. The regulation is doing to the product business what the oversight requirements did to the org chart in post 10: forcing a sequence the good operators would have chosen anyway.

The question for the next portfolio review is not how much AI your company is using. It is how much of it your customers are paying for.

Every stalled AI programme gets the same autopsy. The model was not good enough. The use case was wrong. Adoption was poor. Change management failed. I have sat through enough of these post-mortems to notice a pattern: the diagnosis almost always stops one layer too high. Underneath the model, the use case, and the copilot nobody opens, there is usually a data foundation that was never built for what the organisation is now asking of it.

The number that should end the debate arrived in March 2026. A Cloudera and Harvard Business Review Analytic Services survey of 1,574 enterprise IT leaders found that only 7% say their data is completely ready for AI. Gartner expects enterprises to abandon 60% of AI projects through 2026 specifically because they lack AI-ready data foundations. The two figures describe the same problem from opposite ends. Almost nobody has built the foundation, and the projects built without it are the ones being quietly scrapped.

The previous posts in this series worked on the visible layers of enterprise AI: selecting use cases that matter, capturing the ROI that leaks, scaling agents, activating licences, redesigning the org chart, and most recently the verification bottleneck that caps how fast oversight can scale. This post goes underneath all of them. It is about the substrate every one of those layers silently depends on, and the reason it keeps failing is not technical. It is that almost no one owns it as an operating capability.

📊 The Numbers: Only 7% of enterprises say their data is completely AI-ready (Cloudera / HBR, March 2026), while Gartner expects 60% of AI projects to be abandoned through 2026 for lack of an AI-ready data foundation.

The failure everyone diagnoses one layer too high

Ask a leadership team why an AI initiative stalled and you get a familiar list. Wrong model. Immature vendor. Weak adoption. Insufficient training. Each of these is sometimes true. None of them is usually the binding constraint.

Post 2 in this series put a number on where the money actually goes. Data preparation alone consumes a large share of AI project budgets, and integration with legacy systems consumes more. Post 4 turned data readiness into a greenlight test: verify the data exists in usable form before committing to scale, because assuming it will be cleaned during the project is how the 95% end up underwater. What both posts pointed at, without naming it directly, is that the data layer is where most enterprise AI quietly dies. Gartner’s cost work is blunt about it. Up to 40% of AI project costs come from fixing data issues that were only discovered after deployment. That is not a modelling failure. It is a foundation nobody inspected.

The reason this keeps happening is structural, not careless. Data readiness is invisible in a demo. A copilot that answers three curated questions beautifully tells you nothing about whether the underlying estate can answer the fourth. So the foundation stays unexamined until scale exposes it, at which point the integration bill and the rework arrive together.

💡 Key Insight: A demo proves the model works. It proves nothing about whether your data can answer the next question, which is the only question that matters at scale.

“AI-ready” is not the data-quality problem you already know

Here is where most leaders get the scope wrong. They hear “AI-ready data” and reach for the familiar playbook: master data management, a data lake, a quality dashboard. Useful, and a decade out of date for what generative and agentic AI actually demand.

McKinsey’s technology practice, in work published only weeks ago, described the shift precisely. As AI leans on unstructured data (contracts, transcripts, emails, internal documents), that content no longer stays whole. It gets extracted, chunked, embedded, and recombined across systems, and each transformation alters the context of the original. The consequence is a new class of risk. When a single AI answer is assembled from fragments of many documents, the organisation often cannot reproduce which source, which version, or which transformation logic produced it. McKinsey’s phrase for the result is worth sitting with: the outputs become indefensible. In a regulatory audit or in legal discovery, that gap is not academic. It is material.

This is the real bar for 2026. AI-ready data is data that is discoverable, accessible in real time, governed by a single identity and policy model, high in quality with traceable lineage, and provisioned as reusable products that agents and copilots can consume across the estate. Most enterprise data estates fail at least three of those five tests. That is why the 7% figure is not an outlier. It is the honest number.

The five tests are a useful filter because they reframe the work. This is not a cleaning exercise you finish once. It is a set of properties your data has to hold continuously while agents pull it apart and put it back together thousands of times a day.

Why this is an operating-model problem, not a platform purchase

The instinct, once leaders accept the foundation is weak, is to buy a platform. Databricks, Snowflake, Microsoft Fabric, pick one and the problem is solved. It is not, and the reason is the most important point in this post.

The bars capture the trap. Almost no one has the foundation, a mature governance model, or a strategy anyone would honestly call mature, yet a clear majority of projects will be scrapped for exactly that reason. A platform licence does not move a single one of those bars on its own.

McKinsey’s point about platform maturity is the one to internalise. If two business units each build their own extraction logic, chunking strategy, embedding model, and retrieval configuration for the same underlying data, you do not get one AI-ready estate. You get two, and they disagree. The same question, asked in two parts of the company, returns two different answers, and neither is auditable. Duplication multiplies cost while destroying the one thing AI at scale requires, which is a consistent version of truth.

Platform maturity in an AI context therefore means something organisational: reusable extraction pipelines, shared embedding and indexing infrastructure, a common retrieval layer, and standardised guardrails that every application draws on. Tooling does not replace governance. It has to be governed centrally and consumed locally. This is the same shape Post 10 identified for the operating model as a whole. IBM’s 2025 research found that organisations running centralised or hub-and-spoke AI operating models see roughly 36% higher AI ROI than those where every team fends for itself. Data is the layer where that finding bites first.

In practice, the enterprises I see pulling ahead made one unglamorous decision early. They named an owner for AI-ready data as a governed product, with the authority to set shared standards, before they scaled a single agent. The ones still stuck treat data readiness as something each project fixes for itself, which guarantees they fix it five times and trust it zero.

⚠️ Watch Out: Buying a data platform without an owner and shared standards does not give you AI-ready data. It gives every team a faster way to build its own incompatible version of the truth.

Where the European lens changes the math

Everything above is true in every market. In Europe, it stops being optional.

From 2 August 2026, the EU AI Act’s obligations for high-risk AI systems are enforceable. Those obligations include logging, traceability, and a human-oversight architecture, all of which assume you can reconstruct how a given output was produced. Read that against McKinsey’s warning about indefensible outputs and the two collide directly. An AI system whose data lineage you cannot reconstruct is no longer only a quality problem or an ROI problem. It is a compliance exposure, with penalties that scale into the millions of euros or a share of global turnover.

This is the part US-centric AI strategy tends to skip, and it is a genuine advantage for European incumbents willing to use it. The 7% who have built lineage-traced, governed data are the ones who will be auditable when the deadline lands. Their competitors will be reconstructing provenance they never captured. For once, the regulatory environment rewards the organisations that did the boring foundational work first. In Frankfurt, I no longer treat data lineage as a data-team concern. It is a board-level readiness question with a date attached to it.

✅ Leadership Action: Treat data lineage as an EU AI Act deliverable, not a data-team preference. Any high-risk system whose outputs you cannot trace to source is a regulatory exposure before it is anything else.

The leader’s 30-day move

A concrete sequence, before the next platform invoice or the next stalled-pilot post-mortem.

• Week 1. Trace one answer end to end. Take one high-value or one stalled use case and follow a single AI output back to its sources. If you cannot reproduce which document, which version, and which transformation produced it, you have found your real constraint, and it is not the model.
• Week 2. Count the pipelines. Inventory how many separate extraction and embedding pipelines already exist for the same underlying data. Duplication is the clearest evidence that no operating model exists. Every duplicate is a divergent answer waiting to happen.
• Week 3. Name one owner. Assign a single accountable owner for AI-ready data as a governed product, with authority to set shared standards across business units, and decide the shape (centralised or hub-and-spoke). This is one name on one slide, not another governance committee.
• Week 4. Map lineage to the Act. Classify your AI systems against the EU AI Act high-risk criteria and check each one’s data lineage. Any high-risk system whose provenance you cannot reconstruct goes on the risk register now, not in August.

Do only these four things and you will already be operating ahead of the roughly nine in ten enterprises still treating data readiness as something a platform purchase will quietly resolve.

The consultant’s takeaway

Every layer of enterprise AI that leaders enjoy discussing (the models, the agents, the copilots, the org redesign) rests on a layer they prefer not to. The data foundation does not demo well, does not photograph well on a board slide, and does not generate a launch announcement. It simply determines whether everything above it works. The 7% who have built it will spend 2026 scaling. The 93% who have not will spend it running post-mortems that keep stopping one layer too high.

The uncomfortable reframe is that most AI strategies are data strategies that have not admitted it yet. The use-case portfolio, the agent architecture, the governance framework, all of it is downstream of whether the organisation can produce a consistent, traceable, reusable version of its own data. That is an operating-model decision about ownership and standards, not a procurement decision about platforms.

In Europe, the clock makes the point for me. When the EU AI Act’s high-risk obligations go live in August, the difference between the organisations that built a traceable data foundation and the ones that did not stops being a matter of AI performance and becomes a matter of who is auditable. In Frankfurt that is no longer a technical preference. It is the difference between a programme that scales and one that has to explain itself to a regulator it was never built to answer. The foundation was always the strategy. The only question is whether you build it deliberately, or discover it the hard way when the layer above it fails.

The same report contains a second number that most boardrooms have not connected to the first. Documented AI incidents rose to 362 in 2025, up from 233 the year before, a roughly 55% increase recorded in the AI Incident Database. More capable agents are producing more output, and more of that output is going wrong in ways that reach the real world. Every one of those failures had to be caught by a human, or it was not caught at all.

This is the part of the agent story that the capability charts hide. The previous posts in this series dealt with selecting agentic use cases, scaling the architecture behind them, and redesigning the org chart around them. This one deals with the constraint that surfaces the moment those agents start working at volume. Not whether the agent can do the task, but whether your organisation can check that it did it correctly. That capacity is finite, it is expensive, and almost nobody has budgeted for it.

📊 The Numbers: Agent success on the OSWorld benchmark rose from roughly 12% to 66.3% in a single year (Stanford 2026 AI Index). Over the same period, documented AI incidents climbed to 362, up from 233. Capability scaled. The capacity to verify it did not.

Execution scaled. Verification did not.

For most of the last decade, the scarce resource in automation was the automation itself. Building the model and getting it to perform was the hard part, and the human in the loop was a rounding error on top. Agents invert this. The marginal cost of an agent doing one more task is approaching zero. The marginal cost of a qualified human verifying that task is not.

The chart shows the capability half of the story. It cannot show the other axis, because almost no enterprise measures it: how many agent outputs a single qualified reviewer can meaningfully check in a day. That number is roughly fixed by human attention, and it is the real ceiling on how much autonomy an organisation can safely run. When agent volume rises and review capacity stays flat, the gap does not disappear. It becomes a queue, a rubber stamp, or an unchecked failure. All three destroy the business case.

💡 Key Insight: The bottleneck in scaling agents is no longer model capability. It is the human capacity to verify what the models produce, and that capacity does not scale with compute.

The error rate nobody staffs for

An agent that succeeds 77% of the time is genuinely impressive and operationally dangerous at the same time. The 77% is what gets demonstrated to the board. The 23% is what determines whether the deployment makes or loses money, because every failure that escapes review carries a downstream cost almost always larger than the task itself. A mispriced quote, a wrong clinical summary, a payment sent to the wrong account.

An earlier post in this series called this the labour paradox, where human review burden quietly consumes the productivity AI appears to create. At agent scale it sharpens. The question is no longer how much time the agent saved, but how many of its outputs you can afford to check, and what happens to the ones you cannot. Most enterprises never answer either question. They count the speed of the 77% and discover the cost of the 23% later, in production.

⚠️ Watch Out: A high success rate is not a low oversight cost. The higher the volume an agent handles, the more absolute failures it produces, even as the percentage improves. Throughput without proportional review capacity is how a successful pilot becomes an expensive incident.

Span of control for agent bosses

Microsoft’s 2025 Work Trend Index, based on 31,000 workers across 31 countries, gave the emerging role a name. The agent boss, an employee who directs and supervises a team of agents rather than doing the work directly. The framing is useful, but it hides the hard question every operating model now has to answer. How many agents can one human actually supervise before oversight becomes fiction.

This is a span-of-control problem, and it is solved the way span of control has always been solved. By designing what reaches a human and what does not. The organisations getting this right are not reviewing every agent output, which is impossible, nor trusting every output, which is reckless. They are building tiered escalation, where the agent proceeds autonomously inside defined boundaries and routes to a human only when a confidence threshold, a financial threshold, or a sensitivity threshold is crossed. The design of those thresholds, not the capability of the agent, is what determines whether the system holds at scale.

The apprenticeship problem hiding underneath

There is a slower, more dangerous version of this constraint. The work AI agents now do well, drafting, summarising, first-pass analysis, is precisely the work junior employees used to do, and through which they became the senior reviewers who can verify an agent. Research from Stanford’s Digital Economy Lab found that employment for early-career workers in the most AI-exposed occupations has already declined measurably since generative AI became widely available, with the sharpest drops among the youngest cohorts.

The implication is uncomfortable. An organisation can automate away its junior roles, hit this year’s productivity target, and quietly dismantle the pipeline that produces the experienced people who catch an agent’s mistakes. The verifier is a senior role, and seniority is manufactured by doing junior work. Remove the junior work entirely and the supply of future verifiers stops, exactly as demand for verification rises. This is not a problem for next quarter. It is one leaders are deciding right now, without framing it as a decision.

In Europe, oversight is now an operating requirement

Everywhere in the world, verification capacity is an economic question. In Europe, it is also a legal one. The EU AI Act’s obligations for high-risk systems become enforceable on 2 August 2026, and Article 14 requires that high-risk AI systems be designed so they can be effectively overseen by humans, with named people able to understand the output, intervene, and stop the system. A Digital Omnibus package under discussion in 2026 may adjust some timelines, which is worth tracking, but the direction of travel is fixed.

Read alongside the capability data, this is not a compliance footnote. For any regulated, high-stakes workflow, the human oversight layer is no longer optional, and no longer something to bolt on after deployment. It is a design and staffing requirement that European enterprises have to build in from the start. Firms treating Article 14 as a box to tick after go-live are building exactly the rubber-stamp oversight the regulation exists to prevent. Firms treating it as an operating-model decision are sizing their verification capacity before they scale, which is what the economics demanded anyway.

✅ Leadership Action: For every high-risk agent deployment, define the human oversight design before approving the build. Who reviews what, under which thresholds, with what capacity, and how that scales as volume grows. In Europe, treat this as an Article 14 obligation, not an afterthought.

The leader’s 30-day move

A concrete sequence before the next agent deployment is signed off.

• Week 1. Measure the real ratio. For every agent already in production, calculate outputs generated per week against qualified human reviews actually performed. The gap between them is your current unmanaged risk. Most leaders have never seen this number.
• Week 2. Tier the escalation. For each agent, define what it may do autonomously and the confidence, financial, and sensitivity thresholds that route an output to a human. No agent runs without an explicit escalation design.
• Week 3. Name and size the oversight layer. Assign accountable human reviewers to each high-risk workflow and size that capacity against projected volume, not current volume. If the plan is to scale the agent tenfold, the review model has to survive that.
• Week 4. Protect the verifier pipeline. Before automating a junior role away, identify how your organisation will keep producing the experienced people who can supervise agents. If the answer is that it will not, reconsider the cut.

The consultant’s takeaway

The capability of AI agents is now the easy part. It improved faster last year than almost anyone forecast, and it will keep improving. What does not improve on the same curve is the human capacity to verify, govern, and recover from what those agents do, and that capacity is becoming the real constraint on how much value an enterprise can safely capture.

The leaders who navigate the next eighteen months well will not be the ones who deployed the most agents or automated the most aggressively. They will be the ones who treated verification as a first-class part of the operating model. Measured it, designed for it, staffed it, and protected the pipeline that produces the people who do it. In Frankfurt, with the EU AI Act’s high-risk obligations live from August, this is no longer only good practice. It is the difference between an agent programme that scales and one that becomes the incident the regulator asks about.

AI agents will do more and more of the work. The enduring advantage belongs to the organisations that can still tell, reliably and at scale, when they have got it wrong.

The meeting is happening in boardrooms across Europe right now. A consulting deck lands on the table showing competitors running leaner. The CFO points to the headcount line. The CEO, who according to WRITER’s 2026 enterprise survey has a 73% chance of reporting stress or anxiety about the company’s AI strategy, asks the obvious question: if AI makes everyone more productive, why are we still carrying this structure? Within a quarter, a restructuring is announced, framed as “becoming AI-native.” Twelve months later, the same broken processes are running with fewer people to catch the errors.

This is the org-chart trap, and in 2026 it is the most expensive mistake in enterprise AI. The previous posts in this series dealt with selecting use cases, capturing ROI, scaling agents, and activating the licences you already bought. This one deals with what happens when leaders point AI at the organisation itself. The pattern is the same failure that kills AI pilots, only now it is being applied to people’s jobs and the company’s risk surface at the same time.

📊 The Numbers: 69% of enterprises are planning layoffs because of AI. Only 23% have a documented AI governance framework, and roughly 21% have redesigned a workflow end-to-end. The action is running three times ahead of the foundations.

The restructuring wave is real, and it is not the cycle you remember

The cuts are not hypothetical. PayPal announced in May 2026 a workforce reduction of roughly 20%, around 4,760 roles over two to three years, with the CEO framing it around removing duplication and layers and accelerating AI adoption. Cloudflare cut about 1,100 jobs, nearly 20% of its people, the same week it beat revenue expectations, explicitly to rebuild around an agentic AI-first operating model. Meta began cutting around 8,000 roles and reorganised thousands of engineers into AI-focused “pods.” Accenture is running an AI-focused restructuring affecting at least 11,000 people. Tata Consultancy Services is removing roughly 12,000 roles, concentrated in middle and senior management. Amazon has confirmed tens of thousands of corporate cuts justified explicitly by the need for fewer layers and more ownership.

The European list is shorter but more strategically loaded. Commerzbank is cutting thousands of roles while committing a multi-year AI investment programme, partly as a case for standalone independence against a takeover bid. Porsche plans to reduce positions in Germany through to the end of the decade. SAP has moved from one-off cuts to what its leadership describes as a continuous repositioning of roles around Business AI.

Here is what makes this different from 2022 and 2023. Those cuts were openly described as correcting pandemic over-hiring. The 2026 cuts are described as permanent structural decisions about which functions still require humans at all. That distinction matters, because a correction can be reversed when conditions improve. A capability-driven restructuring is a bet that the work itself has changed. If that bet is placed before the work has actually been redesigned, it is not a strategy. It is a hope with a severance cost attached.

Why most of this restructuring will fail its own thesis

The evidence on sequencing is unusually clear, and it points the opposite way from how most companies are acting.

McKinsey’s State of AI, published in November 2025, found that while 88% of organisations now use AI somewhere, only about 6% are genuine high performers capturing material EBIT impact. The single behaviour that separates them is not how much they spend or how many people they cut. It is that they have fundamentally redesigned workflows. High performers are nearly three times as likely to have done this end-to-end work. The redesign, not the headcount reduction, is what produces the value.

Set that against what happens when companies move in the wrong order. S&P Global Market Intelligence found that the share of organisations abandoning the majority of their AI initiatives before they reached production jumped from 17% to 42% in a single year. Gartner expects 60% of AI projects unsupported by AI-ready data to be scrapped through 2026. Cutting the organisation faster does nothing to fix the data fragmentation, unclear decision rights, and un-redesigned processes that caused those pilots to fail. It simply removes the people who were absorbing the friction those failures created.

The chart below is the whole argument on one page. It contrasts what enterprises are doing with what they have actually built underneath.

Sixty-nine percent of enterprises are planning layoffs because of AI. Twenty-three percent have a documented AI governance framework. Roughly a fifth have redesigned a workflow end-to-end. Fewer than half have controls specific to generative AI. The action is running three times ahead of the foundations. That gap is the failure, and it is entirely self-inflicted.

Four things that break when you cut before you redesign

Across the restructurings playing out now, the same four failures appear repeatedly.

1. You delayer the people who were doing the oversight. The middle-management layer everyone is racing to cut was doing three jobs at once: coordinating work, developing people, and acting as the last human check on what flowed up and down the chain. The coordination is genuinely automatable. The last-human-check is the operational definition of human-in-the-loop. Gartner has predicted that through 2026, a fifth of organisations will use AI to eliminate more than half of current middle-management positions. When you remove that layer without putting the oversight somewhere else, you have not become efficient. You have removed your second line of defence.

2. Accountability becomes diffuse exactly as the risk concentrates. At the moment companies are thinning the human layer, the machine layer is acting more autonomously. Okta’s 2026 research found that 88% of organisations report suspected or confirmed AI agent security incidents, while only about a fifth treat those agents as identity-bearing entities they actually govern. Microsoft’s 2026 Data Security Index reports generative AI is now implicated in around a third of data security incidents, yet under half of organisations have GenAI-specific controls. IBM’s 2025 breach research put a number on the consequence: shadow AI adds roughly 670,000 dollars to the average breach cost. Cut the humans who owned exception handling, and that residual risk does not disappear. It lands on the executive who signed the restructuring.

3. The same broken process now runs faster with fewer people to fix it. If the workflow underneath was never redesigned, AI does not eliminate the work. It accelerates the parts that were already fast and leaves the bottlenecks untouched, now with a thinner team. This is the productivity paradox from earlier in this series, scaled up to the level of the whole organisation. A leaner org running an un-redesigned process is not a transformation. It is the old company with more stress and less slack.

4. You restructure ahead of a regulator who is about to ask who is in charge. For European leaders this is not a soft risk. The EU AI Act’s high-risk obligations become enforceable on 2 August 2026. From that date, deployers of high-risk AI systems must have named responsible persons for risk monitoring and incident handling, a quality-management system, and a human-oversight architecture built into the design, with penalties scaling to 15 million euros or 3% of global turnover. A company that has just delayered the very people who would have owned that oversight, without naming who now does, is walking into both operational and regulatory exposure at once.

⚠️ Watch Out: The middle layer you are cutting was doing the second-line review no AI agent has yet earned the right to do alone. Remove it without relocating the oversight, and the residual risk lands directly on the executive who signed the restructuring.

What the companies getting this right do differently

The organisations capturing real value are not the ones cutting deepest. They are the ones sequencing governance and operating model before headcount. Four moves separate them.

• Stand up the operating model before you touch the structure. IBM’s 2025 research on Chief AI Officers found that organisations running hub-and-spoke or centralised AI operating models see around 36% higher AI ROI than those running decentralised, every-team-for-itself models. The shape of how AI is governed and delivered is itself a driver of return. Decide that shape, with shared standards and architecture at the centre and execution in the business units, before you start removing layers from the chart.
• Give one executive real authority, not a compliance title. More than half of CAIOs now report directly to the CEO or board. But the role fails in a predictable way, especially in Europe, when it becomes a highly paid compliance anchor: a figurehead with no budget, no cross-functional authority, and KPIs measured in documents produced rather than outcomes moved. Appoint someone with a pilot budget, authority across at least three business units, and a direct line to the top. Measure them on production deployments and EBIT, not on policy pages.
• Build the EU AI Act spine into the org design, not alongside it. Inventory every AI system, classify each against the high-risk criteria, assign a named risk owner to each high-risk system, and adopt a recognised management-system standard such as ISO 42001 as the backbone. With only around a quarter of European mid-market firms holding a documented governance framework today, doing this early is not just compliance. It is a competitive position: you will be auditable when your competitors are scrambling.
• Redesign the workflow first, then size the workforce to it. This is the move that mirrors the high performers in the McKinsey data. Pick three to five value streams. Redesign them end-to-end with AI as the default path, not a feature bolted onto the old process. Measure the new cycle time. Then, and only then, size the team to the redesigned operation. The workforce reduction becomes the output of the redesign, not its starting assumption.

💡 Key Insight: The companies that look smart in eighteen months will not be the ones with the deepest cuts. They will be the ones that redesigned the work, governed it, and then sized the workforce to the operation they had actually rebuilt. The order is the strategy.

The leader’s 30-day move

A concrete sequence before the next restructuring decision is signed.

• Week 1. Before approving any AI-driven restructuring above a token threshold, demand a one-page answer per affected function to four questions: which workflows have we actually redesigned, who now owns AI output review and incident response, what is the EU AI Act risk classification of the systems replacing these roles, and what oversight capacity are we adding to absorb what the cut managers were doing. If a function cannot answer all four, it is not ready to be cut.
• Week 2. Decide the AI operating model. Centralised or hub-and-spoke, with standards and architecture at the centre and delivery in the business units. Name the single executive accountable for it, with budget and cross-unit authority. This is one name on one slide, not a steering committee.
• Week 3. Run the EU AI Act inventory. Every AI system classified, every high-risk system assigned a named human owner, the human-oversight design documented. Treat 2 August 2026 as a hard date, because for high-risk systems it is.
• Week 4. Select the three to five workflows you will redesign end-to-end this quarter. Set a cycle-time baseline now. Make clear to the organisation that the structure will follow the redesign, not precede it.

✅ Leadership Action: Put a rule on the next restructuring proposal: no function gets cut until it can name the redesigned workflow, the human owner of AI oversight, and the EU AI Act classification of what is replacing the roles. If it cannot, it is a pilot, not a production decision.

Companies that sequence in this order do not cut less in the end. They cut more precisely, they keep the oversight they need, and they do not spend the following year discovering what the delayered managers were quietly holding together.

The consultant’s takeaway

Most leaders are running the AI restructuring playbook in the wrong order. They cut the org chart first, then discover that the workflows underneath were never redesigned, that the governance the regulator and their own board now expect does not exist, and that the management layer they removed was performing the second-line oversight no AI agent has yet earned the right to do alone.

The companies that will look smart in eighteen months will not be the ones with the deepest cuts. They will be the ones that redesigned the work, stood up an operating model with someone genuinely accountable for it, built EU AI Act compliance into the structure before August 2026, and then sized the workforce to the operation they had actually rebuilt. The order is the strategy.

AI is going to reshape the org chart. That is not in question. The only question is whether you redesign the organisation deliberately, in the right sequence, or let a quarter of layoff announcements and a regulator’s deadline write the structure for you. In Frankfurt, that is no longer a matter of strategic taste. With the high-risk obligations live in August, it is a matter of getting the sequence right while there is still time to choose it.

In October, Sierra — a customer support AI company founded in 2023 — crossed $100 million in annual recurring revenue. By January 2026 it had passed $150 million, with a $10 billion valuation. Its customers include Weight Watchers, SiriusXM, Sonos, ADT, and Redfin. It charges roughly $1.50 per resolved customer interaction — about 10% of the human equivalent.

In the same window, Decagon, an AI-native customer support competitor founded in the same year, tripled its valuation in six months — to $4.5 billion in January 2026 — after adding more than 100 enterprise customers including Deutsche Telekom, Avis Budget, Block, and Chime. Chime reports a 60%+ reduction in its contact centre costs. 53% of Decagon’s customers replaced an existing IVR, ticketing, or CRM-based agent system to move to it.

In legal, Harvey reached an $11 billion valuation in March 2026 and is now embedded in roughly half of the Am Law 100. In Europe, Stockholm-based Legora has raised over €500 million in a single Series D round and is taking direct aim at LexisNexis, Thomson Reuters, and Harvey itself.

The pattern is not isolated. Menlo Ventures’ 2025 State of Generative AI in the Enterprise found that at the AI application layer, AI-native startups have moved from 36% market share in 2024 to 63% in 2025 — capturing nearly $2 in revenue for every $1 earned by incumbents. That is not the early-warning data. That is the result.

📊 The Numbers: AI-native startups captured 36% market share in 2024. By 2025, they captured 63% — nearly $2 in revenue for every $1 earned by incumbents.

The previous posts in this series have been about how to run AI well inside the enterprise — selection, ROI, scaling, training, governance, activation. This post pivots outward. It addresses the question that most C-suite leaders are starting to ask in early 2026 but few are answering rigorously: are we the disruptor or the disrupted in our category, and how would we know before the P&L tells us?

The line has already been crossed — but unevenly

The most important pattern in the 2025–2026 data is not that AI-native startups are winning. It is that they are winning very unevenly across enterprise functions.

The map above, drawn from Menlo Ventures’ enterprise spend data, is the single most useful diagnostic for any incumbent leadership team in 2026. It says three things.

First, in finance and operations, AI-native startups already hold 91% of net new spend. This is the function where regulated incumbents like Intuit move slowest — accuracy demands, audit requirements, and integration complexity slow their AI roadmap, and AI-first ERPs like Rillet, Campfire, and Numeric have walked into the gap. Total dollars are still small, but the trajectory is decisive.

Second, in product and engineering — code generation in particular — startups hold 71% share. Cursor (Anysphere) is the canonical case: GitHub Copilot was the first mover with every structural advantage, and Cursor still captured significant share by shipping repo-level context, multi-file editing, and natural-language commands faster than Microsoft could. The lesson generalises. In categories where the rate of feature delivery is the moat, AI-native companies will win.

Third, incumbents still hold the line in infrastructure, IT, and data platforms. Databricks, Snowflake, MongoDB, and Datadog each saw AI-driven re-acceleration in 2025. Even AI-native application builders are choosing existing infrastructure platforms to manage their data and orchestrate workflows. Where reliability, integration depth, and existing system dependencies matter more than raw iteration speed, incumbents are not just defending — they are growing.

This is the strategic picture every leader needs on a single page: where you sit on this map determines almost everything about how you should respond.

What “AI-native” actually means — and why it matters

The term is now used loosely enough to be almost meaningless. The distinction that matters is structural, not stylistic.

An AI-enhanced enterprise uses AI internally — to draft faster, summarise faster, code faster. The product itself, however, still assumes a human user, and the workflows still reflect pre-AI design assumptions. This is the model most incumbents are running.

An AI-native competitor builds the product so that AI is the primary user, the primary execution layer, or both. Sierra’s agents don’t just answer questions; they take actions inside customer systems — issuing refunds, updating CRMs, processing returns. Harvey’s product is not a chatbot bolted onto Westlaw; it is a system that produces work product the lawyer reviews. Decagon’s Agent Operating Procedures translate plain-English service rules into code-level agent behaviour without engineering intermediation.

This structural difference compounds. AI-native architectures avoid the agent overlay tax — the cost of retrofitting AI onto workflows designed for humans. They charge per outcome rather than per seat, which aligns vendor incentives with customer results in ways legacy SaaS contracts cannot. And critically, they accumulate workflow data that incumbents never see.

⚠️ Watch Out: Outcome-based pricing aligns vendor incentives with customer results in ways legacy SaaS contracts cannot. If you’re still selling by the seat, you’re at a structural disadvantage.

Sapphire Ventures’ 2026 outlook captures the implication bluntly: at least 50 AI-native businesses are expected to reach $250 million in ARR by end of 2026, with several crossing the billion-dollar mark. By their count, more than 60 AI-native products had already passed $100 million ARR by end of 2025. This is not a wave forming. It is a wave that has already broken.

The European picture matters more than US-centric coverage suggests

Most coverage of AI-native disruption is written from San Francisco. For European leaders, the picture is genuinely different — and increasingly material.

European venture funding hit $17.6 billion in Q1 2026, up nearly 30% year-over-year, with the four largest rounds all going to AI-native companies. France’s Mistral has raised over €2 billion. Stockholm’s Legora is now Harvey’s most credible global challenger. UK-based Wayve is at an $8.6 billion valuation in autonomous driving; Synthesia has crossed $100 million ARR in generative video. Black Forest Labs (image), Lovable (development), and Nscale (infrastructure) round out a credible European AI-native cohort.

Three things make the European picture distinctive for an incumbent leader. First, the EU AI Act enters live enforcement on 2 August 2026, which changes the compliance burden for general-purpose model providers and creates a competitive variable that US-only AI strategy decks largely ignore. Second, sovereignty has become a real procurement criterion in DAX, CAC, and FTSE accounts — European incumbents now have an asymmetric advantage in regulated and public-sector deals if they choose to use it. Third, the European AI-native cohort is concentrated in vertical applications and infrastructure rather than horizontal foundation models, which means the threat profile for a European incumbent is more about being out-iterated in your category than about a global platform shift.

The “European AI is dead” narrative has aged badly. The more useful question is whether your specific market is being entered by a European AI-native player, a US-based one, or both.

Why the incumbent playbook fails here

Most incumbent responses to AI-native competition are versions of the same playbook: appoint a Chief AI Officer, launch an AI feature in the existing product, sign a partnership with a foundation model provider, announce it on the earnings call. This playbook has worked before. It is not working now, and the reasons are structural.

Iteration speed. AI-native startups release weekly. Most enterprise software releases quarterly. In categories where the rate of capability improvement is the buying criterion — code generation, customer support, legal research — quarterly is already losing.

Architectural debt. A retrofitted AI feature inside a legacy product carries the cost of every workflow, integration, and UI assumption built before the feature existed. An AI-native competitor built on a clean schema does not. This is why incumbents routinely ship “the same” feature months later and lose deals anyway.

Pricing model. Most incumbents sell AI by the seat. AI-native vendors increasingly sell by outcome — per resolution, per submission, per generated artefact. When the buyer is a CFO under pressure to show AI ROI, outcome pricing wins almost every time. Gartner now expects more than half of enterprises to move to outcome-based AI contracts by 2028.

Distribution data. SaaS incumbents won the last decade by owning systems of record. AI-native agents own systems of action — the logic of how the business actually runs. As ServiceNow’s January 2026 partnership with OpenAI quietly acknowledged, the next moat is not the data the customer puts into the system; it is the workflows the system executes on the customer’s behalf.

The incumbent response that works is not “add AI to our product.” It is to decide, deliberately and quickly, which of three strategies fits your situation.

The three responses — and the conditions under which each works

Across the cases that have played out in the last 24 months, three credible strategic responses have emerged for incumbents whose category is being entered.

Defend. Make the integration and switching costs of leaving you so high that even a faster, cheaper AI-native competitor cannot dislodge customers. This works when you own the system of record, when your data is genuinely proprietary, and when your customers are large and risk-averse. Salesforce and Microsoft are running versions of this play. It is expensive and slow, and it works only if you can hold the line for the three to five years it takes for AI-native pricing pressure to compress.

Partner. Bring an AI-native capability inside your distribution rather than trying to build it. ServiceNow + OpenAI is the archetype. The bet is that the AI-native company values your distribution more than its own brand, and that you can integrate fast enough not to lose your customers in the meantime. This works in categories where the AI-native cohort is fragmented and capital-intensive enough that distribution still matters.

Rebuild. Take the most exposed product line, isolate it, and rebuild it AI-natively from a clean schema, with separate teams, separate metrics, and explicit permission to cannibalise the legacy product. This is the hardest move organisationally and the only one that works if your category is fundamentally being re-architected. Bessemer and others now expect a wave of incumbent M&A through 2026 because most large enterprises will conclude they cannot rebuild fast enough internally — which makes acquisition the rebuild path.

The wrong move in 2026 is not picking the wrong response. It is failing to choose at all and running a generic AI strategy that is none of the three.

💡 Key Insight: The wrong move is not picking the wrong response. It is failing to choose, and running a generic AI strategy that is none of the three.

The leader’s 30-day diagnostic

Five questions, applied honestly to your category, will tell you which response fits.

• Has an AI-native competitor entered your market? Search by function, not by company name. If you cannot list the three best-funded AI-native players targeting your segment by name, your competitive intelligence is already behind.
• Where do you sit on the function-by-function map? Finance, ops, customer support, code, legal, marketing — these are exposed. IT, data science, infrastructure — less so. Your position determines urgency.
• Are you selling by seat while competitors are selling by outcome? If so, your pricing model is now a strategic liability. The CFO conversation about AI ROI is being won by whoever can quote a per-outcome number.
• Does your product require legacy workflows to function? If a competitor’s customer can switch without re-architecting their internal processes, your switching-cost moat is thinner than you think.
• Who in your organisation is accountable for naming the response? If “compete with AI-native players” is in three executives’ OKRs and no one’s mandate, you do not yet have a response. You have a meeting.

If your answers point to exposure, the next step is not another AI strategy review. It is to commit, this quarter, to one of the three responses — defend, partner, or rebuild — and fund it accordingly.

✅ Leadership Action: If your answers point to exposure, commit this quarter to one response — defend, partner, or rebuild — and fund it accordingly. Ambiguity is the fastest path to disruption.

The consultant’s takeaway

The most dangerous position for an incumbent in 2026 is not being disrupted. It is being disrupted slowly enough not to notice. Sierra’s growth from $26 million to $150 million ARR in twelve months is what fast disruption looks like; the equivalent in your category may be quieter, but the structural advantages are the same.

The leaders who navigate this well in the next eighteen months will not be the ones who ran the most AI pilots, hired the most data scientists, or signed the most foundation-model partnerships. They will be the ones who looked honestly at the function-by-function map, identified where their category sat on it, and made an explicit choice — defend, partner, or rebuild — before the choice was made for them.

The question is no longer whether AI-native competition is coming. It is whether your organisation is structured to recognise it before the next earnings call.

The meeting usually happens sometime in the fourth quarter. The CFO opens the invoice, multiplies thirty dollars a month by the number of seats, and asks the CIO the question that should have been asked eighteen months ago: “What are we actually getting from this?”

In a 5,000-seat enterprise, a full Microsoft 365 Copilot deployment runs roughly $1.8 million a year before training, change management, or integration costs. Comparable numbers apply to Salesforce Einstein, Adobe Firefly, ServiceNow AI, and the growing stack of AI add-ons that every major SaaS vendor now sells. The licences are deployed. The dashboards show healthy provisioning. And yet when the CFO asks what measurable business outcome has shifted, the CIO usually cannot answer cleanly.

This is the activation problem — and in 2026, it is the single largest source of invisible AI waste in the enterprise. A July 2025 Morgan Stanley / RSM AI Adopter Survey found that 79% of enterprises have deployed Microsoft Copilot, but 74% of companies using AI tools still cannot show tangible business value. The gap between buying AI and absorbing it is where most AI budgets are quietly being burnt.

📊 Leadership Signal: The gap between buying AI and absorbing it is where most AI budgets are quietly being burnt.

The shelfware is real, and the numbers now exist

Until recently, AI shelfware was hard to measure. In 2026, the data is hardening. Morgan Stanley and RSM’s research across large enterprises shows a consistent pattern: among organisations with more than 1,000 employees, only around 55% of deployed AI licences are actively used on a weekly basis. Roughly half the AI spend produces roughly zero of the AI activity. The variation across industries is striking:

Technology firms reach nearly 80% active weekly use. Professional services sit in the seventies. Financial services land in the mid-sixties. Healthcare, weighed down by regulatory friction, legacy workflow complexity, and cautious clinical adoption, comes in under 60%. For a regulated enterprise with 20,000 Copilot seats, the activation gap alone can account for three to four million dollars a year of pure shelfware.

Microsoft’s own disclosures tell a similar story at the macro level. As of the end of 2025, Microsoft reported 16.1 million paid Copilot seats against roughly 12 million daily active users — impressive absolute growth, but a reminder that even with the largest distribution advantage in enterprise software, the gap between provisioned and actively used is material.

⚠️ Watch Out: Roughly half the AI spend produces roughly zero of the AI activity.

Why licence deployment is not adoption

Four patterns explain almost every activation gap I see inside large enterprises:

1. The tool was procured, not chosen. A large share of enterprise Copilot deployments happened because Microsoft made the commercial case easy to the CIO, not because employees asked for it. When users have a real choice between AI tools, a recent enterprise survey found that three-quarters of them pick ChatGPT as their primary tool; Copilot receives around 18%. Employees route to what works, not what is licensed.

2. The licence was deployed without a workflow behind it. A Copilot seat is not a use case. A seat is permission to access a tool. Without an explicit workflow the tool is meant to change — draft customer emails in Outlook, summarise meetings in Teams, analyse variances in Excel — employees have no anchor. They log in once, don’t know what to do, and stop coming back.

3. Managers were skipped. The front-line manager is the layer that turns individual tool access into team behaviour. When the manager doesn’t use the tool, can’t describe what good use looks like, and doesn’t reward AI-assisted output, the team drifts back to whatever worked before. BCG’s 2025 workforce survey found that only around a quarter of frontline workers say their leaders give them sufficient guidance on AI. That is an adoption killer at scale.

4. Nobody owns activation. Procurement owned the contract. IT owned the deployment. L&D owned the training. Nobody owned the outcome. When activation is everybody’s responsibility, it is nobody’s, and the licence quietly idles.

The activation funnel

It helps to visualise what actually happens after an AI contract is signed:

Of 100 licences purchased, perhaps 80 users log in at least once. Around 60 receive any form of training. Roughly 40 become weekly active users. And only about 15 ever see a workflow redesigned around the tool — which is the only point in the funnel where measurable business value actually lands. The rest is activity without impact.

The striking thing about this funnel is that most of the leakage is fixable. Each stage has a known fix. Almost no enterprise applies them systematically, because no single executive owns the whole chain.

A playbook for turning seats into behaviour

Four moves consistently separate enterprises that convert AI spend into business outcomes from those that don’t:

💡 Key Insight: The striking thing about this funnel is that most of the leakage is fixable.

• Appoint a single activation owner. One executive, named, accountable, with the authority to pull on IT, L&D, line management, and procurement. Without a single throat to choke, the funnel leaks at every stage. This is not a governance committee — it is one name on one slide.

• Tie every licence cohort to a workflow. Before any seats are deployed to a team, define the two or three specific workflows the tool is meant to change. Draft first-response customer emails. Summarise weekly sales calls. Pre-populate month-end variance commentary. No workflow, no seats. This one rule eliminates the largest category of shelfware at source.

• Train managers before teams. For every hundred employees trained on an AI tool, the manager has to be trained first — and expected to coach, model, and reward the tool’s use in weekly cadence. Teams drift toward what their managers recognise. Until managers recognise AI-assisted output, adoption will always lag.

• Put activation metrics on the executive dashboard. Weekly active users as a percentage of deployed seats. Workflows redesigned per quarter. Business KPI shifts attributable to the tool. If these numbers aren’t reported at the executive table, the activation problem will never be fixed — because no one in the room will feel the cost of it.

The leader’s 30-day move

A concrete sequence before the next renewal cycle:

• Week 1. Pull the utilisation data for every AI licence in the enterprise. Active weekly users as a percentage of deployed seats, by tool, by function. Most CIOs can produce this in 48 hours. Most CFOs have never seen it.

• Week 2. Identify the three functions with the largest gap between seats deployed and active use. These are your priority interventions. Kill or reclaim licences where activation has been under 30% for more than a quarter.

• Week 3. For the prioritised functions, define two or three specific workflows the tool will change. Assign a workflow owner and set a behaviour baseline.

• Week 4. Put activation metrics on the next executive review. Make the CIO, CFO, and functional leaders accountable to the same number.

Enterprises that apply this discipline consistently report activation gains of 15–25 percentage points within two quarters — which on a seven-figure licence spend is not a rounding error.

✅ Leadership Action: The question on your next AI renewal is not whether to buy more licences.

The consultant’s takeaway

Gartner is now predicting that by 2028, over half of enterprises will stop paying for assistive AI tools altogether and move to outcome-based, workflow-embedded AI — paying for results rather than seats. That shift is coming. The enterprises that arrive at that transition with a disciplined view of which licences drive behaviour, and which don’t, will be the ones best positioned to restructure their spend intelligently.

The question on your next AI renewal is not whether to buy more licences. It is whether the licences you already own are actually doing any work. The answer, for most enterprises, is a very expensive “no.” Fixing it doesn’t require new technology. It requires accountability, workflow design, and the willingness to measure something most leaders have so far preferred not to look at.

Why enterprise AI training programmes are failing — and what senior leaders need to do differently. A consultant’s guide.

Every Chief Human Resources Officer I speak with in 2026 has sat through a version of the same meeting. L&D presents the year’s AI training numbers: courses deployed, completions logged, certifications issued. The slide looks excellent. Then someone in the room — usually the CFO — asks the awkward question: what has actually changed in how people work?

In most enterprises, the honest answer is: very little.

This is one of the most expensive open secrets in enterprise AI. Deloitte’s 2026 State of AI in the Enterprise, based on 3,235 senior leaders across 24 countries, found that education was the number-one way companies adjusted their talent strategy for AI — ahead of role redesign, ahead of workflow change, ahead of hiring. ManpowerGroup’s 2026 Global Talent Barometer found that while regular AI use among workers rose 13% during 2025, confidence in the technology fell by 18%. People are using the tools more and trusting them less. That is not a training success story.

The starkest data point comes from Docebo’s 2026 AI Readiness Gap research: 85% of employees say they cannot apply the AI training they have received to their day-to-day jobs. This is not a marginal skills gap. It is the collapse of the training-to-behaviour bridge at enterprise scale.

The previous post in this series looked at why individual time savings from AI don’t add up to enterprise productivity. This post takes on the single biggest lever most leaders are pulling to fix that — training — and shows why the way it is being used is making the problem worse, not better.

📊 Leadership Signal: If completion rates are high but workflow behaviour is flat, the programme is optimising for reporting optics, not operating change.

The scale of the failure

Four numbers, all drawn from 2026 enterprise research, describe what is actually happening inside most AI training programmes:

The first bar is the one every L&D team presents proudly. The other four are the bars nobody presents at all. Among employees who complete AI training, only around 15% can apply what they learned to their work. Only about 22% say their training happens in the tools they actually use day-to-day — Slack, Salesforce, the CRM, the ticketing system — rather than in a separate learning platform. Only 40% say the training was designed for people in roles like theirs. And more than half report they are so buried in pre-AI manual work that they don’t have time to learn the tools that are supposed to replace that work.

Taken together, these numbers explain why training spend keeps rising and measurable behaviour change keeps not showing up. The problem is not that employees can’t learn. The problem is that most enterprise AI training is designed in a way that makes transfer almost impossible.

⚠️ Watch Out: Training outside daily tools creates a predictable transfer gap. If learning is not embedded in where work happens, adoption will stall.

Four structural reasons most AI training fails

Across the 2026 enterprise research, four failure modes appear consistently:

1. Generic literacy instead of role-specific capability. Most AI training teaches what a large language model is, how prompting works, and what hallucination means. That is useful background; it is not a capability. A claims assessor doesn’t need to know how transformer attention works. They need to know what “good AI use” looks like on their next thirty claims. DataCamp’s 2026 survey of over 500 enterprise leaders found that the most common complaint about third-party AI training is that the learning paths aren’t tailored to specific roles.

2. Learning separated from the tools of work. The employee logs into the LMS, watches a 45-minute video, passes a quiz, logs out, and goes back to Salesforce — where nothing has changed. Docebo’s research found that 78% of respondents say training happens outside the tools they actually use. The cognitive distance between “where I learned this” and “where I would apply this” is where transfer dies.

3. Managers are skipped entirely. Front-line managers are the layer that turns individual learning into team behaviour. If the manager doesn’t know what good AI use looks like in their function, they can’t model it, coach it, or reward it. BCG’s 2025 global workforce survey found only around a quarter of frontline workers say their leaders give them sufficient guidance on AI. That is not a training-content problem. It is a training-audience problem: we are teaching the wrong people first.

4. Success is measured in completions, not behaviour. Most enterprise L&D dashboards report completion rates, assessment scores, and Net Promoter Scores. Almost none report whether the trained employee actually changed how they work. Without a behaviour metric, the programme is flying blind — and, crucially, has no way to improve itself.

What the “AI-fluent 5%” actually had

A recent analysis of AI usage across the knowledge workforce identified roughly 5% of workers as “AI-fluent” — those who had redesigned significant portions of their work around the technology. They save a median of 8 hours per week. Casual users of the same tools save 3.

The variable that separated them was not intelligence, not tenure, not technical background. It was two things working together: training that was specific to their role, and explicit organisational permission to change how they worked. Training alone did not produce fluency. Permission alone did not produce fluency. The combination did.

This is the uncomfortable implication for senior leaders. You cannot train your way out of this problem. You have to train and redesign simultaneously — or the training dollars are wasted.

💡 Key Insight: Role-specific training plus managerial permission is the conversion point from AI literacy to measurable behavioural change.

A playbook for training that actually changes behaviour

Five principles consistently separate AI training programmes that change behaviour from the ones that don’t:

• Design by role, not by topic. A recruiter, a claims handler, a field engineer, and a finance analyst need four different AI training programmes — not the same “Introduction to Generative AI”. Generic content is what most vendors sell. Specific content is what actually transfers.

• Embed learning in the tool of work. If sales uses Salesforce, AI training for sales needs to live in Salesforce. If developers live in GitHub and VS Code, that is where the learning goes. In-context guidance closes the transfer gap that standalone LMS content cannot.

• Train the manager before the team. The manager’s job is to define what good AI use looks like in their function, reinforce it in one-to-ones, and recognise it in performance reviews. Teams drift toward what their manager rewards. Until the manager knows what to reward, no amount of team training will stick.

• Require a workflow redesign as the training output. The goal of the training is not completion. It is a concrete change in how the team works: one workflow, redesigned, documented, deployed. If the training ends and no workflow has changed, the training failed — regardless of the assessment score.

• Measure behaviour change, not completion. For each trained cohort, track one behaviour metric and one business metric before and after. Time to first draft. Number of tickets resolved per hour. Cycle time to close. The metric is the evidence that the training landed.

✅ Leadership Action: Make one behaviour metric and one business metric mandatory for every training cohort before approving rollout.

The leader’s 30-day move

A concrete sequence for a senior leader who wants to stop burning training spend:

• Week 1. Pull the current AI training portfolio. For each programme, ask two questions: which specific role is this for, and which workflow is expected to change as a result? Kill or redesign anything that cannot answer both.

• Week 2. Pick one high-leverage role — customer support, sales, underwriting, claims — and commit to building a role-specific, tool-embedded training pilot around it. One role, one workflow, one tool.

• Week 3. Train the managers of that role first. Before any employee sits through training, the manager should be able to articulate what good AI use looks like in their team.

• Week 4. Set the baseline. Pick one behaviour metric and one business metric, measure them now, and commit to reporting them 60 and 90 days after the training rolls out.

The consultant’s takeaway

Training, by itself, doesn’t change how people work. It never has. The enterprises that are extracting real productivity from AI are not the ones with the most completions or the most certificates. They are the ones that treated training as one input into a broader redesign — the others being workflow change, manager reinforcement, and disciplined measurement.

If your organisation is preparing to spend again on AI training in the next budget cycle, the question to put on the table is not how many people to train. It is: what workflow will have measurably changed, in which role, by when, as a result? If the training programme cannot answer that question, it is not an investment. It is an expense.

The next generation of high-performing enterprises will not be defined by how many people they trained on AI. They will be defined by how many workflows they redesigned around it — and by the discipline of the leaders who refused to confuse the two.

✅ Leadership Action: In the next 30 days, select one role, one workflow, and one embedded tool context, then prove behaviour change with pre/post metrics before scaling training further.

Every senior leader I speak with in 2026 has a version of the same conversation. The CIO says the organisation has paused its formal AI rollout “until governance is in place.” The CMO mentions, almost in passing, that the content team has been using ChatGPT for months. The CFO asks, slightly too casually, whether the free-tier models are “safe to use on unpublished forecasts.” Meanwhile, the official AI policy is still in draft.

This is shadow AI: the use of unsanctioned AI tools inside the enterprise, on enterprise data, without IT visibility or leadership oversight. It is not a fringe behaviour. A 2025 Gartner analysis of more than 500 enterprises found that 68% of employees regularly use AI tools their organisation has not formally approved. Deloitte’s 2026 State of AI in the Enterprise found that worker access to AI rose by roughly 50% during 2025 — while only one in five organisations has a mature governance model. Other industry surveys now put the share of enterprises with some level of unsanctioned AI use at close to 98%.

The uncomfortable truth for senior leaders: your AI policy is already being written. It is being written by each individual employee, on each personal account, with every paragraph of customer data, financial forecast, or source code pasted into a free-tier chatbot. Unless you actively choose otherwise, your policy is going to be whatever those thousands of individual decisions happen to add up to.

The previous posts in this series dealt with the AI you deliberately deploy. This one deals with the AI your organisation is already using — whether you authorised it or not.

📊 Leadership Signal: If formal rollout is paused but teams are already using public AI tools, governance delay is now creating unmanaged exposure, not preventing it.

The problem is not your employees

It is tempting to treat shadow AI as an employee discipline issue. It is not. The people using unsanctioned AI tools are not rogue actors. They are productive, well-intentioned employees trying to meet the expectations their leaders have set for them. A 2025 study by the National Cybersecurity Alliance found that 43% of employees have shared sensitive work information with AI tools without their employer’s permission — and the same workers report that AI makes their work faster, better, and more responsive. When the approved tool is six months behind the free one, when IT approval takes three weeks and the deadline is Friday, employees do what employees always do: they find a path.

Shadow AI is a symptom of three gaps:

• A capability gap — the approved tool is worse than the free one employees can access from their phones.

• A clarity gap — employees don’t know what is encouraged, what is conditional, and what is off-limits.

• A speed gap — the pace of approval inside the enterprise is slower than the pace of expectation outside it.

Close those gaps and shadow AI shrinks. Leave them open and no amount of policy documentation will matter.

✅ Leadership Action: Close one gap per month: capability first, clarity second, speed third. Sequenced intervention outperforms blanket restrictions.

The leadership paradox: the C-suite is modelling the behaviour

Here is the part most governance discussions quietly skip. Microsoft’s 2026 Data Security Index found that nearly 70% of presidents and C-suite executives openly prioritise speed over data privacy when adopting new AI tools. Leaders are not just failing to stop shadow AI — in many organisations, they are the power users. The senior partner drafting the board deck through ChatGPT on their iPad. The regional CFO summarising confidential deal terms through Claude before an investor call. None of them considers themselves reckless. They are moving fast because their calendars demand it.

The signal this sends is unambiguous. When leaders behave this way and then ask their teams to wait for policy, the policy is dead on arrival. BCG’s 2025 workforce survey found that only around a quarter of frontline workers say their leaders provide sufficient guidance on AI. The gap is not because leaders are absent. It is because leaders are doing the same thing their employees are doing — just with bigger stakes attached.

What shadow AI actually costs

Until recently, shadow AI risk was described mostly in hypothetical terms — “imagine if your customer data ended up in a training set.” In 2025 and 2026, the numbers arrived.

IBM’s 2025 Cost of a Data Breach Report — one of the most widely referenced security benchmarks in the industry — found that breaches involving high levels of shadow AI cost enterprises on average $670,000 more per incident than comparable breaches without it. Roughly one in five organisations surveyed reported a breach directly tied to shadow AI usage, and 97% of organisations that experienced an AI-related security incident lacked appropriate AI access controls. Containment for shadow AI breaches also takes approximately one week longer than average — because the security team cannot immediately identify who used which tool, when, and with what data.

The cost stack extends beyond the direct breach:

For a large enterprise, the aggregate exposure is no longer a compliance footnote. It is a board-level liability that most cyber insurance policies written before 2024 do not explicitly cover.

Why bans don’t work

The instinctive leadership response to shadow AI is familiar: block it. Put ChatGPT on the firewall blocklist, issue a policy memo, run a training module. This approach was famously attempted early by Samsung in 2023, after internal engineers pasted proprietary semiconductor source code into ChatGPT during debugging. Samsung banned the tool company-wide. The data was already gone.

Bans fail for two reasons. First, they don’t change the underlying demand — the work still needs to be done, the deadlines are still there, and employees route around the block through personal devices, personal accounts, or the roughly 70% of AI interactions that by 2026 will happen inside SaaS products employees already legitimately use. Second, bans push usage further into the shadows. Once employees understand their AI use is officially forbidden but operationally necessary, they stop reporting incidents and flagging risky edge cases to IT. The organisation loses the one thing it needs most: visibility.

Every governance framework that has actually worked in the last two years starts from the same premise: you cannot govern what you are pretending doesn’t exist.

⚠️ Watch Out: Blocking tools without creating a better approved path pushes AI use underground and makes incidents harder to detect and contain.

A governance playbook that actually works

The enterprises that are handling shadow AI well are not the ones with the thickest policy binders. They are the ones that have done three things in sequence.

1. Surface usage before sanctioning it. Before writing any policy, invest in visibility. Run an anonymous internal survey on AI usage. Deploy network and endpoint monitoring that identifies AI traffic without punishing users. Ask managers in each function to candidly list which tools are being used and for what. The goal is not to catch people — it is to size the problem honestly. Leaders who skip this step invariably write policies for a workforce that does not exist.

2. Provide a safe default that is actually better than the shadow option. One study of healthcare enterprises found that when approved, enterprise-grade AI tools were provided, unsanctioned use dropped by nearly 90%. The lesson scales to every industry. If the approved tool is slower, clunkier, or six months behind the public model, employees will keep routing around it. Procurement and security need to optimise for the user experience as aggressively as they optimise for risk, or the governance model will never take hold.

3. Publish a one-page permission framework, per function. Not a 40-page policy. A single page, per team, that answers three questions: where is AI encouraged, where is it conditional (and on what), and where is it off-limits? Examples help more than rules. “Yes to drafting customer emails; no to pasting customer PII. Yes to brainstorming pricing scenarios; no to uploading unpublished financials.” Signed by the function head. Visible on the intranet. Revisited quarterly.

These three moves, done together, compress the shadow AI problem faster than any ban ever has. They also produce something no policy document can: a living map of how AI actually flows through the organisation.

💡 Key Insight: Visibility plus a better default plus clear boundaries is the minimum viable governance stack for shadow AI. Remove any one layer and risk returns.

The leader’s 30-day plan

A concrete sequence for a senior leader who wants to get in front of this in the next month:

• Week 1 — Commission a cross-functional shadow AI audit. Include IT, security, legal, HR, and a senior line-of-business representative. Make clear to employees that the purpose is visibility, not enforcement.

• Week 2 — Identify the top three functions with the highest shadow AI usage and the highest data sensitivity. These are your intervention priorities.

• Week 3 — Commit to an approved enterprise-grade tool for each of those functions, with a deployment date inside 60 days. Ruthless on user experience — if it’s worse than the free version, it will fail.

• Week 4 — Publish the one-page permission framework for each function, signed by the function head. Pair it with a short, non-punitive communication that acknowledges the reality of current usage and names the path forward.

Inside 90 days, revisit. The organisations that do this consistently report that declared AI usage goes up (because employees stop hiding it) and shadow AI risk goes down (because the approved path is now genuinely faster). That is the shape of governance working.

The consultant’s takeaway

Shadow AI is not a compliance problem waiting for a compliance fix. It is a leadership test. The AI your organisation is already using is a reflection of where the capability gap, the clarity gap, and the speed gap sit inside your operating model. Closing those gaps is the work.

The leaders who will come out of 2026 with a governed, productive AI estate are not the ones who banned the tools or bought the most licences. They are the ones who looked honestly at what was already happening inside their organisation, built a credible alternative, and were clear with their people about where the lines actually are.

The question is not whether your organisation has a shadow AI problem. It does. The question is whether you are going to write the policy — or whether your employees already have.

✅ Leadership Action: In the next 30 days, run a cross-functional shadow AI audit, name the top three high-risk functions, and publish one-page usage boundaries with an approved enterprise-grade alternative.