You Are Deploying AI. Your Competitor Is Shipping It.

Almost every enterprise AI programme in Europe is pointed inward: copilots, back-office workflows, the cost line. For companies that sell physical products, the profit pool sits somewhere else entirely, and three European regulations are rewriting the rules around it while the AI programme summarises meetings. A consultant’s guide for leaders whose AI strategy is really an IT strategy.

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.