AI Strategy: Build vs. Buy in Mid-Sized Companies

KI-Strategie · 23. Mai 2026 · Mohsen Ghulami

AI strategy for mid-sized companies: Decide Build vs. Buy with numbers, cases, and clear criteria before your PoC devours your budget.

Three weeks ago, I was in Gütersloh in a meeting room that smelled of filter coffee and warm plastic. Thomas, CTO of a 280-person mechanical engineering company, pushed his iPad towards me and said, “We’re building our own AI platform now.” Outside, a forklift beeped in reverse, inside a PowerPoint slide flickered with an Azure logo, a Python snake, and a budget block of 1.2 million euros. My first question wasn't technical, but brutally simple: Is this really an AI strategy — or just an expensive detour to the next standard software?

I've been writing about industry since 1998. I've seen at Trumpf in Ditzingen how data from laser cutting machines turns into service business. I've experienced at smaller contract manufacturers in the Swabian Alb how a single missing MES export can halt an entire AI project. And I've seen enough CFOs clench their lips at the word “in-house development” as if they'd bitten into a lemon.

Build vs. Buy in AI is therefore not a matter of faith. It's a question of capital allocation. A mid-sized company with 50 to 500 employees that wants to build every forecasting model itself burns time, salaries, and nerves. But if it buys every AI function, even though it makes the difference in its own product, it gives away margin to providers who don't understand the business. I've seen both. Both hurt.

Why AI Strategy is Now a C-Level Priority

In March 2025, I was at a supplier near Heilbronn, 410 employees, a lot of machining, little patience. Andrea, Head of Operations, showed me a line with six DMG Mori machining centers. The sound was that harsh, metallic singing you know from halls where no one talks about the future because the order has to be out by Friday. “We have four AI PoCs,” Andrea said. “None are running productively.”

That's where mid-sized companies stand. Not at the beginning of the AI debate, but after the initial disillusionment. ChatGPT opened the door in 2023, Microsoft Copilot has arrived in many companies, SAP is pushing AI functions into its suite, and every second software provider is now slapping an AI label on its roadmap. But: In the factory, in sales, in service, less is happening than conference stages claim.

The numbers match this observation. According to the Bitkom study 2024, about 15 to 20 percent of German companies use AI productively; for companies between 100 and 499 employees, the rate is rather in the lower range, roughly 10 to 15 percent. BCG and VDMA found a pattern in mechanical engineering in 2023 that I constantly hear in conversations: More than 60 percent are experimenting with AI PoCs, but less than 15 percent have scaled applications in the company. So: a lot of pilot, little operation.

This is not a German law of nature. It's often bad decision-making. Mid-sized companies too often treat AI as a technology acquisition and too rarely as a question of value creation. In a company with 180 employees from Augsburg, Jens, commercial director, told me in January 2025: “We can't afford a mistake.” True. But not deciding is also a mistake. Just quieter.

AI Strategy in Mid-Sized Companies: What Build vs. Buy Really Means

Build doesn't mean three data scientists training a foundation model in the basement. Well, almost never. In mid-sized companies, Build usually means: own data pipelines, own models or at least own domain logic, own MLOps processes, own monitoring, own responsibility. The provider might supply cloud infrastructure, but the company bears product and operational risk.

Buy doesn't mean buying software and saving 15 percent scrap on Monday. Anyone who believes that has never seen an interface between old ERP, Excel export, and machine control. Buy means: purchasing standard software, SaaS, or platform components, configuring, integrating, training, measuring. That's work. But it's different work than model building.

The sharpest line is not between cloud and on-prem. It's between commodity and differentiation. Forecasting, standard NLP, image classification, route optimization, offer assistance, simple recommendation engines — there are usable products for these. AI at the product core, such as intelligent sensors, autonomous navigation, proprietary process control, or a service algorithm that learns from 15 years of machine data — that's where Build can make sense. Can. Not must.

PwC and Roland Berger have been describing a pattern since 2023 that also appears in my conversations: smaller and medium-sized mid-market companies predominantly choose Buy or Configure, larger mid-market companies more often choose Hybrid. The 300-person company is more likely to buy Microsoft, SAP, Cognex, Celonis, o9, PTC, or a specialized provider. The 3,000-person supplier might build an Analytics Competence Center and develop where the value creation lies. This sounds trivial. Yet it is constantly ignored.

The Hard Numbers: Costs, Timelines, Success Rates

Over the past two years, I've spoken with digital managers in Munich, Stuttgart, Bielefeld, and Linz who manage their AI budgets not in press releases, but in Excel. The ranges are surprisingly stable. A Build PoC in a mid-sized company usually costs 100,000 to 300,000 euros for three to six months. Until an MVP runs productively, 300,000 to 800,000 euros is realistic, internal personnel costs not always cleanly calculated. And that's where self-deception begins.

Because the data scientist isn't free just because they're already on the payroll. Neither is the production engineer who checks labels eight hours a week. And certainly not the IT architect who clarifies security clearances. In a factory near Ulm, it smelled of coolant in February 2025, while Martin, IT manager, told me: “We only spent 180,000 euros externally.” Two hours later, he showed me the internal effort estimate. With in-house work, the project was at 520,000 euros.

Buy or Configure starts lower. Pilot license plus integration: often 50,000 to 250,000 euros. Rollout across multiple plants or areas: 150,000 to 800,000 euros. Ongoing license costs for many mid-sized scenarios are 50,000 to 200,000 euros per year, depending on users, data volume, and vendor mood. Yes, vendor mood. Anyone who has negotiated a SaaS renewal in the third year of a contract knows what I mean.

The success rates are the real blow. McKinsey reported in its State of AI 2023 that only about 20 to 30 percent of companies achieve significant financial benefits from AI projects. In manufacturing and industrial goods, in my experience and according to consultant benchmarks, 50 to 70 percent of PoCs die before they see real operation. With Build, often only 30 to 40 percent make the leap to production. With Buy or Configure, it's more like 50 to 70 percent. Not because providers work magic. But because there's less fundamental risk in the model.

Build is Worthwhile — But Less Often Than Founder Slides Claim

I like in-house development. Really. There's that moment when a team not only trains a model but embeds it into a process, users touch it, the KPI moves, and the plant manager no longer talks about “that AI thing” but about their new tool. That's powerful. But it doesn't happen just because someone installed PyTorch.

Trumpf is a good example, but also a warning. The family business from Ditzingen has around 16,500 employees, deep machine data, its own platform history with AXOOM, and an ecosystem around TruConnect. Since about 2017, Trumpf has continuously invested in digital services, predictive maintenance, and smart factory functions. In public presentations, Trumpf speaks of up to 20 to 30 percent less downtime for certain systems through predictive maintenance. This is not a side project from IT. This is product and service business.

Kärcher from Winnenden is similarly interesting. The KIRA B 50, an autonomous cleaning robot, requires computer vision, navigation, sensor fusion, and robust software in the physical product. A standard recommender from the cloud is of little help there. Kärcher has built up digital competencies since about 2018, including in the Digital Hub, and combines its own development with cloud components. Here, Build is not about prestige. The AI is in the device, in the price, in the service contract.

That's the point: Build is worthwhile if AI changes customer value or maps a process that competitors cannot easily copy. A machine tool manufacturer with billions of historical sensor data has a different starting position than a 220-person wholesaler who wants to improve cross-selling in the webshop. Anyone who blurs these differences is putting the cart before the horse.

We only develop in-house where we see a clear competitive advantage and our process or product knowledge is unique. We buy in standard analytics and language models.

— paraphrased from a CDO of a German mechanical engineering company, Handelsblatt interview 2024

Nicole Büttner of Merantix Momentum emphasized something similar in EY formats on “Future Germany”: Mid-sized companies have an advantage with their own data, but should often buy in models and platforms and master the domain logic themselves. I agree with that. Data alone is not a moat. Only when data, process knowledge, and distribution channel come together does Build become interesting.

Buy-First is Not Capitulation, But Discipline

In Münster in November 2024, I met a logistics manager, Ralf, who used to be involved in forecasting projects at Fiege. We sat in a canteen, it smelled of gravy, and from the warehouse came the dull rumble of conveyor technology. “We could have built everything ourselves,” he said. “But for what?” Fiege uses cloud services, Azure components, and partner solutions in various areas, for example, for forecasts and optimization. The published use cases speak of 2 to 5 percent inventory reduction and 3 to 8 percent better forecast accuracy, depending on the field.

This is mid-sized company reality, just a number bigger. A forecast is rarely unique. Neither is route optimization. Image-based quality inspection with a defined error class is technically demanding, but often no reason to build your own vision team. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx, or specialized providers have their quirks. Of course. But they don't start from scratch.

An anonymized case from Southern Germany clearly illustrates the logic. Mechanical engineering company, 800 employees, manual visual inspection, staff shortage, high rework pressure. The company bought a commercial Vision AI system instead of developing its own. Initial investment: around 350,000 euros for hardware, licenses, integrator, and training. Four months PoC, three months rollout on two lines. After twelve months, the error rate was about 30 percent lower, amortization under 18 months. No innovation prize. But money.

I know, Buy sounds too small to some CTOs. You don't just want to “configure.” You want to create. Understandable. But the customer doesn't pay for the pride of the IT department. They pay for deliverability, quality, service, price stability. If standard software brings 80 percent of the benefit in a third of the time, then in-house development is often vanity with sprint planning.

The Second Truth: Buy Can Become Expensive, Slow, and Dangerous

Now for the self-correction. Buy-first doesn't mean vendor-first. I've seen SaaS projects that after two years looked like a rented apartment after ten subtenants: adapters everywhere, no one knows who owns the key anymore. A 260-person supplier from Lower Bavaria paid moderate licenses in 2024 for three AI-related tools in sales, service, and planning. Together with interfaces, consulting, and internal admins, the annual costs suddenly amounted to 310,000 euros. Benefit? Hard to measure. “We have dashboards now,” said the sales manager. I felt sorry for him.

The biggest Buy mistake is blind faith in functionality. A software demo always shows clean data. Always. In real operation, you encounter duplicate customer bases, missing article hierarchies, differing shift models, and an ERP field called “Miscellaneous” that has contained everything no one wanted to categorize since 2009. SAP, Microsoft, Siemens, or PTC can cushion a lot. But they don't fix an organization that despises its master data.

The second mistake is lock-in without value. If a provider controls all data storage, model logic, user interface, and process integration, the company becomes dependent. This can be acceptable if the use case is a commodity and the provider delivers stably. For critical core processes, one should be more cautious. Data export, auditability, costs at scale, exit scenario — boring topics, yes. That's precisely why they are read too late.

Where Build Projects Die in Mid-Sized Companies

There's a scene that repeats itself. Meeting room, gray carpet, whiteboard with remnants of a workshop, somewhere it still says “Use Case Prioritization.” In the room sit IT, business unit, and an external consultant. After 14 months of project time, someone asks: “Who is the Product Owner, anyway?” Then it gets quiet. I've experienced this in Cologne, Nuremberg, and St. Gallen.

The first cause of death is data quality. Not sexy, but deadly. An automotive supplier with about 3,000 employees started several predictive maintenance PoCs over three years, together with a research institute. Effort: over one million euros, including internal time. All pilots got stuck in individual systems. OT and IT were separate, there was no central lakehouse, maintenance was involved late, and the data history did not match the failure logic. After a change in IT management, they switched to a standard platform. Nine months later, the first productive use cases were running, after 18 months, about 15 percent fewer unplanned outages were reported on selected systems.

The second cause of death is false pride. A B2B dealer in the DACH region with around 1,200 employees wanted to build its own recommendation engine, also to reduce dependence on US cloud platforms. Five-person data science team, Python, Scikit-Learn, later TensorFlow. Eighteen months of development time, roughly 1 to 1.5 million euros. In the end, performance after internal tests was only 60 to 70 percent of a standard cloud recommender. The project was stopped, the SaaS solution still came. Just later and more expensively.

The third cause of death is a lack of product thinking. AI is started as a project, not operated as a product. There's a PoC, a final report, applause in the steering committee. After that, the model drifts, no one measures the user rate, no one plans retraining, no one feels responsible for false alarms. After six months, the shift supervisor says: “That thing is acting up.” And then acceptance is gone.

MLOps is not a buzzword here, but housekeeping for models. Monitoring, data versioning, release processes, rollback, responsibilities, audit trail. Sounds dry. It is. But without these routines, AI becomes disposable software. You build, show, forget.

The Build-vs.-Buy Matrix for a Robust AI Strategy

In conversations, I like to use a simple 2x2 matrix. No magic. On the X-axis is differentiation potential: Does this AI function make us harder to copy in the market? On the Y-axis is standardizability: Is there mature software that covers 70 to 80 percent of the task? If both axes are honestly evaluated, many favorite projects fall through.

Quadrant one: high differentiation potential, low standardizability. Here, Build or Co-Build can be seriously considered. Examples: AI in a medical device with special sensors, autonomous functions in a cleaning machine, process control for a proprietary production method. Kärcher, Trumpf, Wittenstein, or Festo think in such categories. Here, AI is close to the product or the process secret.

Quadrant two: low differentiation potential, high standardizability. Buy. Period. Standard forecasting, text classification in customer service, simple chatbots, expense checking, lead scoring, image inspection with known error patterns. Anyone who preaches Build here should put the opportunity costs on the table. Not as a slide. As a euro amount.

Quadrant three: high differentiation potential, high standardizability. This is the exciting hybrid area. An LLM can generate offer drafts, but the company's own product logic, discount rules, delivery capability, and liability clauses must come from within the company. Microsoft Copilot or SAP Joule can provide interfaces, but the business brain lies in the company's own data model. This is precisely where mid-sized companies should build competence.

Quadrant four: low differentiation potential, low standardizability. Usually a warning sign. If something is neither strategically important nor easily purchasable, why do it? Because a department head wants it? Because a funding program is waving? Funding is not a business case. There's no getting around that.

ROI Calculation: Why a Cheaper Start Can End Expensively

In June 2025, a managing director from Ravensburg called me. 120 employees, special machine construction, decent EBIT, but thin IT. He asked: “What would an AI for offer automation cost us?” I asked back: “What does an offer cost today?” Silence. Then rustling. Then the number: approximately 1,800 euros of internal effort for complex machines, when sales, design, and purchasing are involved.

Only with such numbers does Build vs. Buy become tangible. If a company writes 900 complex offers per year and an AI assistance system reduces the processing time by 25 percent, we're not talking about a gimmick. We're talking about capacity, faster response, fewer errors in bills of material, better tracking. Whether the solution is bought, built, or hybrid is then decided by the payback, not by the CTO's gut feeling.

Industry Comparison: Mechanical Engineering, Trade, Logistics, Automotive

Mechanical engineering is Build-tempting. Companies have technical self-confidence, many engineers, good product data, and often a DIY culture. For DMG Mori, Trumpf, Wittenstein, or Festo, this attitude makes sense for product-related AI functions. For a 180-person plant manufacturer from Upper Franconia who wants to build their own text AI for service reports, probably not. The smell of hydraulic oil doesn't make an NLP model proprietary.

Trade and B2B distribution should almost always think Buy-first. Recommendation, pricing, inventory forecasting, customer clusters, campaign control — these are fields with many providers and much experience. Differentiation here lies less in the algorithm than in data quality, assortment logic, purchasing conditions, and sales execution. A dealer from Essen told me in April 2025: “We wanted to rebuild Amazon's logic ourselves.” I asked: “Why not sell like Amazon first?” He didn't laugh.

Logistics is more pragmatic. Perhaps because every percentage point immediately translates into pallets, kilometers, and shift schedules. Fiege, Dachser, or Rhenus work with platforms, partners, and their own teams where it fits. Buy for standard optimization, Build or Co-Build for special network data and customer-specific planning. The warehouse floor decides. Not the strategy department.

Automotive suppliers are caught between two stools. They have volume, quality pressure, traceability requirements, and OEM specifications. Predictive quality, maintenance, visual inspection, and planning AI are attractive. But many plants have grown historically, OT data is fragmented, and the works council wants to be asked early. Anyone who starts Build there without a data platform ends up in the PoC swamp. I've seen it too often.

Practical Example: 320 Employees, 14 Months, an Honest Hybrid

A case I can tell anonymously: component manufacturer from Baden-Württemberg, 320 employees, turnover just under 75 million euros, customers from mechanical engineering and medical technology. I was there in October 2024. In quality control, it smelled of alcohol cleaner, under an LED light lay milled parts in gray trays. Sabine, head of quality, said: “We lose time because we detect errors too late.”

The company had three AI ideas: Vision AI for quality inspection, forecasting in purchasing, offer assistance for special parts. Previously, they would probably have started three PoCs. Not this time. The managing director ran each idea through the matrix. Vision AI: Buy. Forecasting: Buy/Configure. Offer assistance: Hybrid, because the technical feasibility logic and variant rules were truly proprietary.

The numbers after 14 months: Vision AI pilot for two part families cost around 210,000 euros including camera, lighting, integrator, and training. Defect escape rate decreased by 28 percent, rework by 11 percent. Forecasting was introduced via a module of the existing ERP partner plus external data pipeline, cost about 95,000 euros; forecast accuracy increased by 6 percentage points in the A-parts. Offer assistance cost more: around 380,000 euros, because CPQ, CAD-related rules, and price histories were integrated. In return, the average processing time for complex offers decreased from 9.5 to 6.8 working days.

More important than the individual figures was the governance. There was a Product Owner for each use case, monthly KPI review, clear kill criteria, and a small data core: one data engineer, one analytics engineer, an external architect for six months. No AI lab with beanbags. No innovation circus. Just work.

Amplifa ICP Playbook Practical playbook to clearly define target customers, data sources, and priorities before AI burns money in sales or lead generation.

FAQ: When Should a Mid-Sized Company Build AI Itself?

A mid-sized company should build AI itself if three conditions are met simultaneously: the function creates customer differentiation, the necessary data is proprietary and reliable, and the company can finance operation, monitoring, and further development. If one of these conditions is missing, I would only allow Build with a partner and a hard stop line. An example: intelligent condition monitoring for own machines with exclusive sensor data can justify Build. A standard chatbot for service inquiries cannot.

FAQ: What is the Best AI Strategy for 50 to 500 Employees?

For companies between 50 and 500 employees, a buy-first hybrid strategy is usually the best choice. Standard software for commodity use cases, proprietary domain logic for differentiating processes, a small internal core team for data and product responsibility. This sounds less heroic than “we're building our own platform.” It works more often. According to Bitkom 2024, productive AI use in German mid-sized companies is still low; that's precisely why time-to-value matters more than technical pride.

FAQ: How to Avoid the PoC Trap in AI?

You avoid it with kill criteria before the first workshop begins. Example: If a Vision AI solution does not show at least 10 percent better detection compared to a manual sample after twelve weeks, it is stopped or re-scoped. If offer assistance does not bring measurable time savings after six months, it is removed from the portfolio. Sounds harsh. But it's cheaper than 18 months of hope.

Recommendations for Action: 7 Steps to the Build vs. Buy Decision

As a managing director, CTO, or digital manager, I wouldn't start with tool selection. Nor with an AI workshop where 47 use cases end up on Post-its and no one knows who's paying for them. I would do seven things. In exactly this order.

1. Inventory potential AI use cases in production, sales, service, and back office. For each use case, write a key figure next to it: scrap, downtime, offer duration, conversion, inventory, complaint costs. No key figure, no use case.
2. Evaluate each use case with the 2x2 matrix: differentiation potential vs. standardizability. Do the evaluation in a small circle with management, business unit, and IT. Not in an 18-person workshop.
3. Define a buy-first rule for commodity topics. Forecasting, standard text analysis, simple vision inspection, CRM automation, and recommendation should only become Build if there is a written business reason.
4. Establish kill criteria. Time limit, minimum KPI, data availability, user acceptance. A PoC without a stop line is not an experiment, but a cost risk with a friendly name.
5. Build a small core team. For 50 to 500 employees, often sufficient: one data engineer or analytics engineer, one strong product owner per use case, a part-time IT architect, external specialists for limited phases.
6. Integrate AI into existing systems. No isolated AI portals if users work in ERP, CRM, MES, CPQ, or ticketing systems. AI must appear where the work already happens.
7. Report quarterly on productive AI applications, not on PoCs. Show business impact, user rate, costs, open risks. The CFO should understand the table without having to Google “embedding.”

Amplifa Product AI-powered sales automation for B2B teams that don't want to set up lead generation, ICP sharpening, and outreach as a DIY project.

Governance: Who Decides, Who is Liable, Who Stops?

AI governance sounds like a corporation. Not quite. Mid-sized companies in particular need it because the lines are short and mistakes quickly become personal. If an AI recommends incorrect quality releases, the issue doesn't end up in an anonymous risk committee. It ends up with Sabine in quality control, with Thomas in engineering, and with the managing director when the customer complains.

Usable governance for 50 to 500 employees doesn't have to be thick. It needs four roles: Business Owner, Product Owner, Technical Responsible, Risk or Compliance Reviewer. The Business Owner is responsible for the benefit. The Product Owner is responsible for usage and roadmap. Technology keeps operations, security, and data flow clean. Compliance checks data protection, works council issues, EU AI Act relevance, and auditability. Four names. Not “IT.”

The EU AI Act will become gradually more noticeable from 2025 and 2026, especially for high-risk applications. Many mid-sized use cases do not fall into the highest risk class, but documentation, transparency, and accountability will become more important. Anyone introducing AI into quality decisions, HR processes, or safety-critical production steps today should not wait until the auditor is in the foyer.

Governance also decides Build vs. Buy. With Buy, you have to check the provider: data processing, model transparency, hosting, deletion concepts, access, audit logs. With Build, you have to be able to do all that yourself. Honestly? Many 200-person companies can't. That's not a reproach. It's a decision criterion.

Tech Stack: What Mid-Sized Companies Really Need

If Build or Hybrid makes sense, you don't need a tech zoo. I too often see architecture diagrams with Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes, and five other logos, even though the company still sends CSV files from the ERP via email. That's not strategy. That's logo collecting.

For many mid-sized companies, a clear stack is sufficient: central data storage or lakehouse, stable interfaces to ERP/CRM/MES, an MLOps tool for model versioning and monitoring, rights concept, reporting. Azure is strong in the DACH mid-market, often due to Microsoft 365 contracts and existing IT expertise. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core, or Siemens Industrial Edge can fit. The question is not which logo sounds more modern. The question is who operates it.

Open source is not a free lunch. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — all good tools. But someone has to maintain dependencies, check security updates, monitor models, detect drift, repair pipelines. On a night shift, no one cares whether the error comes from the feature store or the PLC interface. The line is down.

With Buy/Configure, the stack looks different. Siemens Industrial Edge or Insights Hub for industrial data, PTC ThingWorx for IoT-related scenarios, SAP AI Core and Joule in the ERP environment, Microsoft Dynamics 365 with Copilot for CRM processes, Celonis for Process Mining, o9 or SAS for planning, Cognex or Landing AI for Vision. These products don't solve every problem, but they provide structure. For many mid-sized companies, structure is already half the ROI.

Amplifa for AI Sales Strategy For mid-sized B2B companies that want to productively use AI in sales without first building their own outreach and data platform.

Change Management: The Shop Floor Decides Too

In December 2024, I was at a company near Pforzheim. 160 employees, precision parts, a lot of manual work in inspection. A young project manager explained AI-supported defect detection on a monitor. Next to me stood an inspector, perhaps in his late fifties, his hands black at the fingertips. He said quietly: “If the box is wrong, it's my fault.” That was the most important sentence of the day.

AI implementation rarely fails only due to technology. It fails due to responsibility. If people believe that AI takes away their jobs, blames them for errors, or devalues their experiential knowledge, they won't use it. Then the system is bypassed, warnings are ignored, data is poorly maintained. Change management doesn't mean hanging posters. It means clearly clarifying roles, liability, and benefits.

With Vision AI in quality assurance, it must be clear: Does the AI release or recommend? Who decides in borderline cases? How are false negatives handled? How does feedback from inspectors flow into the model? With offer assistance in sales, it must be clear: Can the AI suggest prices? Who checks discounts? Which statements to customers are taboo? These questions are not brakes. They are operational prerequisites.

The works council should be involved early, not after the pilot. Especially with AI in performance measurement, shift planning, HR, or assistance systems with usage data. I know companies that lost three months because they believed participation was a formality. It wasn't. It was the actual rollout.

What I Expect in 2026: Less PoC Theater, More Hard Selection

My prognosis is blunt: By the end of 2026, many mid-sized companies will halve their AI portfolios. Not because AI disappoints. But because the project lists from 2023 and 2024 were too broad, too technical, and too poorly calculated. The CFO will ask which applications are running productively. Sales will ask why the offer assistant isn't in the CRM yet. Production will ask why the pilot only works on line 3. Then there will be a clear-out.

At the same time, good companies will get faster. They won't pursue 30 use cases, but five. They will use standard software where it suffices, and build their own know-how where it hurts if the competitor also has it. They won't “do AI.” They will reduce scrap, accelerate offers, increase service revenues, reduce inventories. That's a different tone.

SAP CTO Jürgen Müller has publicly emphasized the integration of generative AI into the Business Suite multiple times. The message for mid-sized companies is clear: Not every customer should build their own foundation models. Many should consume, embed, and control AI. I think that's healthy. Anyone who still believes in 2026 that a 250-person company must first found its own AI lab before seeing benefits is confusing mid-sized companies with research institutes.

In the end, the scene from Gütersloh remains. Thomas, the CTO with the 1.2 million euro plan, called me two weeks after our conversation. They had stopped the platform idea, started two Buy pilots, and kept a single hybrid use case for their machine logic. “Feels less visionary,” he said. In the background, I heard the forklift beeping again. Perhaps that was precisely the progress.