AI in SMEs: Build, Buy, or Integrate

KI-Strategie · 14. Oktober 2026 · Anthony Filipiak

AI in SMEs: Don't make a blanket decision on Build vs. Buy. Read which use cases you should buy, integrate, or build, considering TCO and 7 steps.

Most SMEs shouldn't build their own AI in 2026. Yes, I'm serious — and I know some CTOs are inwardly crossing their arms right now. AI in SMEs is too often treated as a vanity project, not an investment decision. That's expensive. And sometimes even dangerous, because six months of in-house development can quickly look like strategy, even though you're just solving a problem that Microsoft, OpenAI, SAP, or a good API provider has long since solved better.

My prognosis for the next two to three years: The winners among European SMEs will not be the companies that develop the most themselves. They will be the companies that decide most rigorously what they *don't* build themselves. Buy-or-Integrate-first will become the default mindset — in-house development will remain the exception for processes that genuinely defend margin, delivery capability, or customer experience.

That sounds defensive. It's not. It's capital discipline. A managing director from Ulm told me in January 2026 after a budget round: "I don't feel like spending 180,000 Euros just so a chatbot can search PDFs." He's right. If the use case is generic, I buy generic intelligence. If the use case makes my company unique, then I'm talking about proprietary data, proprietary logic, and sometimes even proprietary models. Well, almost. Mostly, I'm talking about integration first.

AI in SMEs: Status Quo 2026

Where are we today? Not in science fiction. More like Excel, ERP, and a growing number of teams already using ChatGPT, Microsoft Copilot, Salesforce Einstein, SAP Joule, or specialized agents, but rarely cleanly embedded in the process. I currently see four camps among managing directors of companies with 50 to 500 employees: the wait-and-sees, the tool collectors, the pilot collectors, and the few who manage use cases like a portfolio. The last group is small. They will win.

Market figures dictate the direction. For clearly defined AI pilots, German market overviews often cite 18,000 to 35,000 Euros; productive, deeply integrated solutions can cost 120,000 Euros and more, according to a cost overview from Melexsoft in 2025. Space-O Technologies often quotes 50,000 to over 500,000 Euros for individual AI software, depending on the degree of integration, data availability, and operation. A simple workflow pilot, however, can start significantly lower: AIWorx quotes 2,500 Euros one-time plus 250 Euros monthly, plus model costs and internal expenses. This range is not price chaos. It's a signal.

The signal is: Anyone who asks the build-or-buy question as a blanket statement has not understood the cost structure. A meeting summary is not the same as visual quality inspection of a customer-specific component from Trumpf, DMG Mori, or a toolmaker in Remscheid. Internal knowledge search is not the same as AI-supported production planning with restrictions from MES, ERP, shift models, delivery dates, machine availability, and experiential knowledge from production management. One is software procurement. The other is operational architecture.

In March 2025, in several discussions with sales managers and digital officers, I noticed how emotionally charged the term 'in-house development' is. In-house development sounds like control. Like IP. Like "we won't let ourselves become dependent." Not quite. Poorly managed in-house development makes you just as dependent — only on two internal developers, incomplete documentation, and a prompt that no one wants to touch anymore because it somehow works. That doesn't smell like innovation. That smells like a server room at 10 PM when a cron job hangs.

Trend 1: AI in SMEs becomes a portfolio decision

The first trend is trivial yet underestimated: Build versus Buy is dying as a fundamental question. It is being replaced by a portfolio decision per use case. Buy. Buy and configure. Integrate via API. Extend with proprietary data. Develop and operate entirely in-house. These are five different investment logics, not religious camps.

In strategy workshops, I almost always ask the same thing: Would a competitor achieve practically the same benefit with the same standard software? If the answer is yes, then in-house development is usually vanity. If the answer is partially, then we're talking about integration, Retrieval-Augmented Generation, role permissions, data quality, and process management. If the answer is no, it gets interesting. Then it's about proprietary data, process logic, latency, auditability, or a customer experience that shouldn't be copyable.

An example. Service ticket classification for a machine manufacturer? Buy or integrate. Automatic quote generation for spare parts with historical margins, customer-specific discount logic, delivery capability from SAP, and technical drawings from the DMS? Integrate first. An AI that supports thermal design for Webasto-like product variants and uses internal experience? In-house development can make sense there. Not as a proprietary base model. As a proprietary logic layer, proprietary evaluation set, proprietary system integration.

This development is not just technical. It changes budget discussions. Previously, a digital project often started with the question: Which platform should we use? Today, it must begin with: Where is value created, who is responsible for the process, how do we measure success, and what happens if the model is wrong? A CFO from Cologne, Thomas, told me in December 2025: "I'm happy to sign off on an AI pilot. But I won't sign off on a learning vacation for the organization." Harsh. But fair.

SMEs don't have an AI problem. They have a prioritization problem. We see too many use cases with similar technology but completely different economic weight.

— Andrea, Head of Digital Sales at a Hidden Champion in Bielefeld

Andrea said that in a workshop after her team had collected 27 AI ideas. 27. From automatic lead research to draft offer emails to spare parts forecasts. The room was enthusiastic until we sorted the ideas by margin, data access, process volume, and risk. After that, six remained. Two Buy. Three Integrate. One possible in-house development. That's exactly how it needs to run. Not romantic. Effective.

Trend 2: Buy-or-Integrate-first becomes the standard

The second trend is the most important for managing directors: Buying is not capitulation. Integrating is often the most intelligent form of independence. Anyone who connects a standard AI via API with ERP, CRM, DMS, PIM, or a customer portal is building no less strategically. They are just not building in the wrong place. Base models are expensive, fast-moving, and operationally demanding. For many SMEs, the competitive advantage lies not in the model core, but in data access, process control, approval logic, and user acceptance.

Let's take sales. The generic task "summarize a meeting" should be bought. The task "create a prioritized account list for the field sales team from CRM history, website signals, industry events, existing contacts, and offer patterns" should be integrated. The task "calculate the technical feasibility of a special product with 14 company-specific restrictions" may require proprietary components. Three use cases. Three architectural decisions. One budget pot would be nonsense.

At Amplifa, we often talk to companies that already have Microsoft 365, HubSpot, Salesforce, SAP Business One, Microsoft Dynamics, or a DMS like ELO in-house. The reflex is then: We need a new AI platform. Sometimes yes. Often no. Often, a thin, clean integration layer is missing first: role permissions, data sources, prompt templates, logging, monitoring, evaluation data, and a way back into the process. Sounds dry. It is. But that's exactly where it's decided whether AI works in everyday life or only shines in a demo video.

From our implementations, we know: For medium-sized B2B teams with 50 to 500 employees, the first measurable effects rarely come from a proprietary model, but from three patterns. First: AI accesses four to seven defined data sources, not "everything." Second: Every answer ends in a concrete action in the system — CRM note, ticket suggestion, offer draft, inspection note. Third: Quality only stabilizes after about 80 to 120 real evaluation cases per use case, because then the rough edges become visible: outdated price lists, duplicate companies in CRM, PDFs without metadata, different names for the same product line. No license calculator tells you that.

The Buy-or-Integrate-first approach also fits regulation. The EU AI Act has been passed since 2024, with key obligations phased in. For SMEs, this means not panic, but documentation: purpose, data sources, risks, human control, logging. Standard providers take on parts of this burden. But as soon as I integrate a model into a critical process, responsibility remains with the company. Anyone who believes a SaaS contract replaces governance should have dinner with a data protection officer from Baden-Württemberg. The illusion will be gone afterwards.

I like small pilots if they are honest. A pilot for 2,500 Euros that saves nine hours a week can be a good entry point. AIWorx calculates in one example nine hours times 45 Euros times 46 working weeks — 18,630 Euros theoretical gross benefit per year. But please keep it clean: Time savings are only valuable if they result in capacity, fewer overtime hours, avoided hires, or increased throughput. If employees fill the saved hour with internal coordination, no one has earned money. That's uncomfortable. Well, almost. It's necessary.

The most common mistake in buy mode is vendor lock-in without an exit plan. Can data be exported? Are prompts, embeddings, and configurations portable? Can the model provider be changed? Is data processed in the EU? What happens with price changes? I've seen these questions too rarely in tenders. Instead, I see many beautiful slides with "AI Ready." A slide doesn't process a customer inquiry.

Trend 3: In-house development shifts to core processes

The third trend: In-house development isn't disappearing. It's becoming more serious. Less chatbot, more manufacturing. Less "we train our own LLM," more process intelligence in areas where standard software doesn't know how your business really works. At Festo, Schaeffler, Phoenix Contact, Wittenstein, or Brose, there are processes, data, and products that don't simply fit into a generic mold. The SME with 180 employees has the same logic on a smaller scale: machine parameters, historical complaints, drawings, calculation knowledge, supplier behavior, special cases from 20 years.

In-house development is particularly worthwhile when several conditions come together. AI is part of the core product or central value creation. There are unique training or process data. Standard products do not map the process. The result impacts margin, quality, delivery capability, or customer experience. There are requirements for latency, offline capability, data sovereignty, or auditability. And — this is often forgotten — there is an organization that can handle operation, monitoring, updates, and error handling.

An example from discussions with a production manager in Southern Germany: visual quality inspection for a component with changing surfaces, reflections, and tight tolerances. Standard vision systems provide a basis. But the crucial data lies in returns, inspection plans, limit samples, and the experience of shift supervisors. Here, a proprietary system can be economical, because every incorrectly sorted item costs money and every missed error leads to complaints. This is not "AI tinkering." This is unit cost accounting with cameras.

Another example: financial closing in a medium-sized corporate group. A documented case describes an AI agent that checks thousands of bookings for plausibility before month-end closing, identifies missing recurring bookings, reconciles cost centers with historical patterns, and flags conspicuous amounts. According to the case description, the inspection time drops from several hours per company to a few minutes. My assessment: no proprietary base model. Integrate. The value arises from financial data, rules, exceptions, and human approval.

Analysts and providers don't agree on everything. Nor do they have to. The direction is clear nonetheless: GenAI becomes infrastructure, differentiation arises at the edges. In data. In workflows. In evaluation systems. In industry logic. Anyone who trains their own model in 2026 before exhausting retrieval, API orchestration, role permissions, and clean evaluation is probably burning money. Not always. But often enough that I wouldn't recommend it as a first step for a 200-employee company.

Amplifa ICP Playbook A practical playbook to structure target customers, data sources, and sales logic — useful before integrating AI into lead generation or account prioritization.

What Build, Buy, and Integrate mean economically

The business impact is not in the label. It lies in capital commitment, speed, risk, and learning curve. Buy offers quick use but limited customization. Integrate offers flexibility with reasonable time-to-value. Build offers control but also operational burden. Hybrid mixes everything — and makes architecture more complex. Anyone who doesn't cleanly separate this compares license costs with development budgets and later wonders about additional charges.

I don't just calculate implementation costs with clients. I calculate three years. Implementation, integration, internal expenses, operation, governance, further development. This formula seems simple, but it changes decisions. Suddenly, the cheap in-house development is no longer cheap because the department spends 80 hours cleaning data, IT builds interfaces, data protection checks, the works council is involved, and someone has to monitor quality, latency, and costs monthly. This is not fine print. This is the real price.

Inference costs are particularly underestimated. A prototype with 300 requests per month is cute. A productive assistant with 40,000 requests, long documents, multiple retrieval steps, and quality checks is a different beast. Then tokens, caching, model selection, response length, rate limits, and monitoring matter. The smell of burned budget is not sensual, but very real. You notice it at the latest when the first cloud bill arrives.

When standard software is superior for AI in SMEs

Standard software wins when the process is similar across industries. Meeting minutes. Translations. Internal knowledge search. Service ticket classification. Invoice and document processing. Simple sales assistance. Email drafts. Document summaries. Here, the benefit is usually time savings, not differentiation. If Kärcher, a dealer from Münster, and a plant manufacturer from Austria would solve the same process similarly, then no one should build a proprietary system just because the word AI is in the project proposal.

The advantage of standard software is not just in the license. The provider handles product development, model maintenance, security updates, support, scaling, and partly compliance documentation. An implementation partner like AI Heroes names starting phases of about six working days and total implementations of two to twelve weeks for clearly defined projects. This is exactly right for many medium-sized teams when a department finally needs noticeable relief and not a research project.

But standard software has limits. It doesn't know your discount logic. It doesn't know the Excel list that a colleague has maintained since 2017 and is actually the true product configurator. It doesn't understand unspoken rules from manufacturing if they are not documented. It also doesn't know why a customer from Switzerland always needs different packaging, even though it looks like the same item in the ERP. Exactly at these points, integration begins. Not necessarily in-house development.

When in-house development is truly justified

In-house development is justified when the use case touches one of the central economic axes: quality, throughput, delivery capability, margin, product function, or customer access. Not when someone says: "Our processes are special." Everyone says that. The question is: Are they special enough that standard software cannot deliver comparable benefits? And is the benefit large enough to bear the development, operation, governance, and personnel risk?

I see plausible build cases in industrial SMEs primarily in six areas: visual quality inspection for specific components, predictive maintenance with proprietary machine data, production planning with individual restrictions, automatic design of customer-specific products, technical assistance with internal standards and drawings, AI functions in proprietary machine or software products. These are not playgrounds. There, wrong decisions depend on scrap, delivery dates, warranty, or revenue.

A CTO from Nuremberg, Markus, told me in autumn 2025: "It won't work for us if the data leaves the house." He didn't mean PowerPoint anxiety. His company processes customer-specific design data with strict confidentiality agreements. For him, offline capability, on-premises operation, and audit logs were not nice-to-haves. That's exactly where the decision tips. Perhaps not a complete in-house build. But certainly not an uncontrolled SaaS solution with an unclear data path.

Nevertheless, even in such cases, I rarely advise a proprietary Foundation Model. Why? Because the value creation usually doesn't lie in the language model itself. It lies in the data pipeline, the evaluation cases, access control, inspection rules, integration into MES or ERP, and the human-in-the-loop process. A powerful standard model, cleanly embedded, often beats a weak proprietary model with a big ego.

FAQ: Should an SME train its own AI model?

Mostly no. Proprietary model training should only be considered if standard models plus Retrieval-Augmented Generation, good prompts, clear data preparation, domain-specific evaluation, and rule-based validation are insufficient. If a company cannot gather 100 reliable test cases for a use case, proprietary training is almost always too early. Honestly? I don't know in every single case. But I know that many teams say training when they actually mean data structure.

What this means for managing directors, CTOs, and digital officers

For managing directors, it means: AI budgets must be managed like investment portfolios. Not like innovation play money. Each use case gets a thesis, a target metric, an architectural variant, and an exit rule. If no reliable data on accuracy, usage rate, latency, costs, and process impact is available after eight weeks, there will be no more romanticizing. Then it will be adjusted or stopped.

For CTOs, it means: Architectural decisions must remain reversible. Be able to change model providers. Be able to export data. Version prompts. Write logs. Map rights cleanly. Measure costs. If a provider only delivers a pretty interface but no sustainable integration and governance story, then you're not buying AI. You're buying dependency with a login page.

For digital officers, it means: The department must deliver. Process description. Test cases. Data access. Acceptance criteria. Key user time. I've seen too many pilots where IT got the blame, even though sales, service, or finance hadn't defined clear success metrics. "AI should relieve us" is not a goal. "Reduce processing time for technical customer inquiries by 30 percent, with a maximum of 5 percent escalation errors" is a goal.

A good example is sales prioritization. Many teams want more leads. Not quite. They want better sales time. If a system finds 500 companies, but the field sales team ignores 480, nothing is gained. If an integrated agent prioritizes 40 accounts from CRM history, website signals, industry clusters, and existing references, and ten of those become real conversations, we're talking about pipeline. Not about data volume.

Amplifa Product Amplifa helps B2B teams identify target customers, leverage signals, and operationalize sales processes with AI — without unnecessary in-house development.

Seven preparatory steps for your AI strategy

1. Create a use case inventory: Don't just collect ideas, but processes with volume, costs, errors, lead time, and process owner. A list of 30 ideas is worthless if none of them address a measurable bottleneck.
2. Assess degree of differentiation: Ask brutally honestly if a competitor would have the same benefit with the same standard software. If yes: Buy. If partially: Integrate. If no: Consider Build, but only after a data check.
3. Check data access: Clarify which data sources are needed, who owns them, how current they are, which rights apply, and whether historical examples exist. Without data maturity, in-house development becomes a fog project.
4. Calculate three-year TCO: Include implementation, integration, internal expenses, operation, governance, and further development. License prices are only one part. Department time is not a free good.
5. Define pilot criteria before starting: Define minimum values for accuracy, latency, usage rate, error rate, cost per transaction, and amortization. A demo without a stop criterion is sales entertainment.
6. Set up governance small but real: Appoint a product owner, data owner, IT and security contact, approval process, logging, escalation, and regular quality control. Not after rollout. Before.
7. Plan architecture with an exit: Demand export options, model changes, documentation, versioning, and clear contract rules on data processing and price changes. Vendor lock-in is easier to prevent than to fix.

These seven steps sound like work. They are. But they save the wrong kind of work. A four- to eight-week pilot is realistic if the use case, data access, and responsibilities are clarified. If not, the first two weeks alone will take that long just because no one knows who can access which table. Then it's not the AI that's slow. Then the organization is unprepared.

The hard budget logic: Under 10,000 Euros, 50,000 Euros, 150,000 Euros

For most DACH SMEs, I use a simple budget logic. Up to about 10,000 Euros: standard software or small workflow pilot. About 10,000 to 50,000 Euros: API integration, internal knowledge assistant, or single specialized process. About 50,000 to 150,000 Euros: productive, cross-system solution with governance and monitoring. Over 150,000 Euros: only with high process relevance, clear scalability, and reliable ROI. Proprietary models or complete platforms? Only with strategic differentiation, proprietary data, and an existing operating organization.

These thresholds are not laws of nature. An electronics supplier close to Phoenix Contact with high volume and clear quality costs can justify a higher amount earlier than a 70-person trading company with generic document processing. But the thresholds force the question: What must be true for this project to be worthwhile? If no one can answer this question, the project should not start.

I have an aversion to AI roadmaps that consist of tool names. Q1 Copilot, Q2 Chatbot, Q3 Agent, Q4 Automation. That's not a strategy. A strategy states which capabilities the company is building: data access, evaluation, process integration, governance, vendor management, user guidance. Tools come and go. Capabilities remain. At least, if someone maintains them.

FAQ: How do I measure success for AI pilots in SMEs?

I separate three stages. Technical pilot: The solution works with real data. Metrics are accuracy, latency, and error rate. Operational pilot: Employees use it in the process. Metrics are usage rate, processing time, escalations, and acceptance. Economic success: The benefit is demonstrable. Metrics are cost per transaction, lead time, revenue impact, error costs, or avoided new hires. A pilot can work technically and still be economically irrelevant.

Minimum values help. 90 percent correct document classification. Less than 5 percent unaddressed incorrect decisions. Response time under three seconds if users are waiting in the process. At least 30 percent time savings if the business case is based on productivity. At least 60 percent active usage after three months. Amortization within 12 to 24 months. Not every use case needs the same values, but every one needs predefined values.

The underestimated part: Change Management and Operational Reality

AI projects rarely fail due to a single technical wall. They fail due to friction. An employee doesn't trust the classification. A sales manager doesn't want new CRM fields. IT doesn't want more shadow integrations. Data protection demands an audit. The works council asks about performance monitoring. The department has no time for test cases. Each of these frictions is solvable. None solves itself.

That's why I like pilots that are small enough to start, but real enough to hurt. Real data. Real process. Real users. A test with five perfect PDFs from the marketing folder is worthless. In everyday life, scanned documents, typos, old templates, missing attachments, duplicate customer numbers, and a colleague who does something different "as always" appear. If the solution can't handle that, it's demo material. Not operation.

In a service process for a machine manufacturer from East Westphalia, we saw in the analysis that AI classification was not the bottleneck. That was good enough after a few iterations. The bottleneck was that escalation rules were applied differently depending on the product line, and no one had fully documented them. The workshop smelled of oil and warm metal, the whiteboards were full, and in the end, the most important AI work was a process discussion with three team leaders. That's what reality looks like.

AI Governance: Start small, but not naively

Governance doesn't have to start with a 90-page manual. But it has to start. Every productive use case needs a functional product owner, a data owner, an IT and security officer, documented quality metrics, an escalation and fallback process, and regular cost and quality control. That's the minimum standard. Anyone who brings AI into customer communication, financial processes, or production decisions needs traceability. Otherwise, automation becomes a liability issue.

The EU AI Act will reinforce this discipline. Not every SME use case is high-risk. But the questions will become normal: What data was used? Who can see what? How is a result approved? What happens in case of errors? How are versions documented? If a provider only answers with "our AI is secure," that's not enough for me. An audit log is more boring than a demo video. That's exactly why it's valuable.

Amplifa AI Strategy Discussion For SMEs who want to prioritize specific use cases by Build, Buy, and Integrate — with a focus on sales, data sources, governance, and measurable implementation.

My personal forecast for 2026 to 2028

First: Pure inbound strategies will continue to lose effectiveness in B2B SMEs. Anyone who still believes in 2026 that a few whitepapers and trade fair contacts will sustain the pipeline for the next five years will face a problem. AI-supported market and account intelligence will become standard. Not as a spam machine. As a system that better connects target customers, timing, demand signals, and conversation starters.

Second: Most companies will not regret their first AI misinvestments because they were too expensive. They will regret them because no one learned. No clean evaluation set. No usage data. No documentation. No comparison between Buy, Integrate, and Build. Then only a vague feeling remains: AI didn't work for us. This is the most dangerous narrative because it is false and convenient.

Third: The best AI strategy in SMEs will look unspectacular. Standard software for generic tasks. APIs for process integration. Proprietary data as a level of differentiation. In-house development only where it is economically defensible. I know that sells worse than "we're building our own AI." But managing directors don't pay for headlines. They pay for margin, throughput, pipeline, and less flying blind.

When I look at this trend report in two years, I expect fewer discussions about model names and more about process metrics. Less pride in in-house development. More pride in clean decision criteria. Perhaps that is the true level of maturity: not building what you can build. But only what truly makes the company stronger.