KI im Mittelstand: Build, Buy oder Integrate

KI-Strategie · 14. Oktober 2026 · Anthony Filipiak

KI im Mittelstand: Entscheiden Sie Build vs. Buy nicht pauschal. Lesen Sie, welche Use Cases Sie kaufen, integrieren oder bauen sollten mit TCO und 7 Schritten.

Die meisten Mittelständler sollten 2026 keine eigene KI bauen. Ja, ich meine das ernst — und ich weiß, dass jetzt einige CTOs innerlich die Arme verschränken. KI im Mittelstand wird gerade zu oft wie ein Stolzprojekt behandelt, nicht wie eine Investitionsentscheidung. Das ist teuer. Und manchmal sogar gefährlich, weil sechs Monate Eigenentwicklung schnell wie Strategie aussehen, obwohl man nur ein Problem löst, das Microsoft, OpenAI, SAP oder ein guter API-Anbieter längst besser gelöst hat.

Meine Prognose für die nächsten zwei bis drei Jahre: Die Gewinner im europäischen Mittelstand werden nicht die Unternehmen sein, die am meisten selbst entwickeln. Es werden die Unternehmen sein, die am härtesten entscheiden, was sie nicht selbst bauen. Buy-or-Integrate-first wird zur Grundhaltung — Eigenentwicklung bleibt die Ausnahme für Prozesse, die tatsächlich Marge, Lieferfähigkeit oder Kundenerlebnis verteidigen.

Das klingt defensiv. Ist es nicht. Es ist Kapitaldisziplin. Ein Geschäftsführer aus Ulm sagte mir im Januar 2026 nach einer Budgetrunde: „Ich habe keine Lust, 180.000 Euro auszugeben, damit ein Chatbot PDFs durchsucht.“ Recht hat er. Wenn der Use Case generisch ist, kaufe ich generische Intelligenz. Wenn der Use Case mein Unternehmen einzigartig macht, dann rede ich über eigene Daten, eigene Logik und manchmal auch eigene Modelle. Naja, fast. Meistens rede ich zuerst über Integration.

KI im Mittelstand: Status quo 2026

Wo stehen wir heute? Nicht bei Science-Fiction. Eher bei Excel, ERP und einer wachsenden Zahl von Teams, die ChatGPT, Microsoft Copilot, Salesforce Einstein, SAP Joule oder spezialisierte Agenten schon nutzen, aber selten sauber in den Prozess eingebettet haben. Ich sehe bei Geschäftsführern zwischen 50 und 500 Mitarbeitenden gerade vier Lager: die Abwartenden, die Tool-Sammler, die Pilot-Sammler und die wenigen, die Use Cases wie ein Portfolio führen. Die letzte Gruppe ist klein. Sie wird gewinnen.

Die Zahlen aus dem Markt geben die Richtung vor. Für abgegrenzte KI-Piloten werden in deutschen Marktübersichten häufig 18.000 bis 35.000 Euro genannt; produktive, tief integrierte Lösungen können 120.000 Euro und mehr kosten, so eine Kostenübersicht von Melexsoft aus 2025. Space-O Technologies nennt für individuelle KI-Software je nach Integrationsgrad, Datenlage und Betrieb oft 50.000 bis über 500.000 Euro. Ein einfacher Workflow-Pilot kann dagegen deutlich niedriger starten: AIWorx nennt 2.500 Euro einmalig plus 250 Euro monatlich, zuzüglich Modellkosten und interner Aufwände. Diese Spannbreite ist kein Preischaos. Sie ist ein Signal.

Das Signal lautet: Wer die Build-or-Buy-Frage pauschal stellt, hat die Kostenstruktur nicht verstanden. Eine Meeting-Zusammenfassung ist nicht dasselbe wie visuelle Qualitätsprüfung an einem kundenspezifischen Bauteil von Trumpf, DMG Mori oder einem Werkzeugbauer in Remscheid. Eine interne Wissenssuche ist nicht dasselbe wie eine KI-gestützte Produktionsplanung mit Restriktionen aus MES, ERP, Schichtmodell, Lieferterminen, Maschinenverfügbarkeit und Erfahrungswissen aus der Fertigungsleitung. Das eine ist Softwarebeschaffung. Das andere ist operative Architektur.

Im März 2025 habe ich in mehreren Gesprächen mit Vertriebsleitern und Digitalverantwortlichen gemerkt, wie sehr das Wort Eigenentwicklung emotional aufgeladen ist. Eigenentwicklung klingt nach Kontrolle. Nach IP. Nach „wir lassen uns nicht abhängig machen“. Stimmt nicht ganz. Eine schlecht betriebene Eigenentwicklung macht genauso abhängig — nur eben von zwei internen Entwicklern, einer unvollständigen Dokumentation und einem Prompt, den niemand mehr anfassen will, weil er irgendwie funktioniert. Das riecht nicht nach Innovation. Das riecht nach Serverraum um 22 Uhr, wenn ein Cronjob hängt.

Trend 1: KI im Mittelstand wird zur Portfolioentscheidung

Der erste Trend ist banal und wird trotzdem unterschätzt: Build versus Buy stirbt als Grundsatzfrage. Es wird ersetzt durch eine Portfolioentscheidung pro Use Case. Kaufen. Kaufen und konfigurieren. Per API integrieren. Mit eigenen Daten erweitern. Vollständig selbst entwickeln und betreiben. Das sind fünf verschiedene Investitionslogiken, keine religiösen Lager.

Ich frage in Strategieworkshops fast immer dieselbe Sache: Würde ein Wettbewerber mit derselben Standardsoftware praktisch denselben Nutzen erzielen? Wenn die Antwort ja lautet, dann ist Eigenentwicklung meistens Eitelkeit. Wenn die Antwort teilweise lautet, dann reden wir über Integration, Retrieval-Augmented Generation, Rollenrechte, Datenqualität und Prozessführung. Wenn die Antwort nein lautet, wird es interessant. Dann geht es um proprietäre Daten, Prozesslogik, Latenz, Auditierbarkeit oder eine Kundenerfahrung, die nicht kopierbar sein soll.

Ein Beispiel. Serviceticket-Klassifikation bei einem Maschinenbauer? Kaufen oder integrieren. Automatische Angebotserstellung für Ersatzteile mit historischen Margen, kundenspezifischen Rabattlogiken, Lieferfähigkeit aus SAP und technischen Zeichnungen aus dem DMS? Integrate first. Eine KI, die bei Webasto-ähnlichen Produktvarianten thermische Auslegungen unterstützt und interne Erfahrungswerte nutzt? Da kann Eigenentwicklung Sinn ergeben. Nicht als eigenes Basismodell. Als eigene Logikschicht, eigener Evaluationssatz, eigene Systemintegration.

Diese Entwicklung ist nicht nur technisch. Sie verändert Budgetgespräche. Früher hat ein Digitalprojekt gern mit der Frage begonnen: Welche Plattform nehmen wir? Heute muss es beginnen mit: Wo entsteht Wert, wer ist Prozessverantwortlicher, wie messen wir Erfolg und was passiert, wenn das Modell falsch liegt? Ein CFO aus Köln, Thomas, sagte mir im Dezember 2025: „Ich unterschreibe gern einen KI-Piloten. Aber ich unterschreibe keinen Lernurlaub für die Organisation.“ Hart. Aber fair.

Der Mittelstand hat kein KI-Problem. Er hat ein Priorisierungsproblem. Wir sehen zu viele Use Cases mit ähnlicher Technik, aber völlig unterschiedlichem wirtschaftlichem Gewicht.

— Andrea, Head of Digital Sales bei einem Hidden Champion in Bielefeld

Andrea hat den Satz in einem Workshop gesagt, nachdem ihr Team 27 KI-Ideen gesammelt hatte. 27. Von automatischer Lead-Recherche über Angebotsmail-Entwürfe bis hin zu Ersatzteilprognosen. Der Raum war begeistert, bis wir die Ideen nach Marge, Datenzugang, Prozessvolumen und Risiko sortiert haben. Danach blieben sechs übrig. Zwei Buy. Drei Integrate. Eine mögliche Eigenentwicklung. Genau so muss das laufen. Nicht romantisch. Wirksam.

Trend 2: Buy-or-Integrate-first wird der Standard

Der zweite Trend ist der wichtigste für Geschäftsführer: Kaufen ist nicht Kapitulation. Integrieren ist oft die intelligenteste Form von Eigenständigkeit. Wer eine Standard-KI per API mit ERP, CRM, DMS, PIM oder Kundenportal verbindet, baut nicht weniger strategisch. Er baut nur nicht an der falschen Stelle. Die Basismodelle sind teuer, schnelllebig und operativ anspruchsvoll. Der Wettbewerbsvorteil liegt für viele Mittelständler nicht im Modellkern, sondern in Datenzugriff, Prozessführung, Freigabelogik und Nutzerakzeptanz.

Nehmen wir Vertrieb. Die generische Aufgabe „Fasse ein Meeting zusammen“ gehört gekauft. Die Aufgabe „Erstelle aus CRM-Historie, Website-Signalen, Branchenereignissen, vorhandenen Kontakten und Angebotsmustern eine priorisierte Account-Liste für den Außendienst“ gehört integriert. Die Aufgabe „Berechne die technische Machbarkeit eines Sonderprodukts mit 14 firmenspezifischen Restriktionen“ kann eigene Komponenten brauchen. Drei Use Cases. Drei Architekturentscheidungen. Ein Budgettopf wäre Unsinn.

Bei Amplifa sprechen wir oft mit Unternehmen, die schon Microsoft 365, HubSpot, Salesforce, SAP Business One, Microsoft Dynamics oder ein DMS wie ELO im Haus haben. Der Reflex lautet dann: Wir brauchen eine neue KI-Plattform. Manchmal ja. Oft nein. Häufig fehlt zuerst eine dünne, saubere Integrationsschicht: Rollenrechte, Datenquellen, Prompt-Templates, Logging, Monitoring, Evaluationsdaten und ein Weg zurück in den Prozess. Klingt trocken. Ist es auch. Aber genau dort entscheidet sich, ob KI im Alltag arbeitet oder nur im Demo-Video glänzt.

Aus unseren Implementierungen wissen wir: Bei mittelständischen B2B-Teams mit 50 bis 500 Mitarbeitenden entstehen die ersten messbaren Effekte selten durch ein eigenes Modell, sondern durch drei Muster. Erstens: KI greift auf vier bis sieben definierte Datenquellen zu, nicht auf „alles“. Zweitens: Jede Antwort endet in einer konkreten Aktion im System — CRM-Notiz, Ticket-Vorschlag, Angebotsentwurf, Prüfhinweis. Drittens: Die Qualität steigt erst ab etwa 80 bis 120 echten Bewertungsfällen pro Use Case stabil, weil dann die schlechten Kanten sichtbar werden: veraltete Preislisten, doppelte Firmen in CRM, PDFs ohne Metadaten, unterschiedliche Bezeichnungen für dieselbe Produktlinie. Das erzählt dir kein Lizenzrechner.

Der Buy-or-Integrate-first-Ansatz passt auch zur Regulierung. Der EU AI Act ist seit 2024 beschlossen, zentrale Pflichten greifen gestaffelt. Für den Mittelstand bedeutet das nicht Panik, sondern Dokumentation: Zweck, Datenquellen, Risiken, menschliche Kontrolle, Protokollierung. Standardanbieter übernehmen Teile dieser Last. Aber sobald ich ein Modell in einen kritischen Prozess integriere, bleibt Verantwortung im Unternehmen. Wer glaubt, ein SaaS-Vertrag ersetze Governance, sollte einmal mit einem Datenschutzbeauftragten aus Baden-Württemberg essen gehen. Danach ist die Illusion weg.

Ich mag kleine Piloten, wenn sie ehrlich sind. Ein Pilot für 2.500 Euro, der neun Stunden pro Woche spart, kann ein guter Einstieg sein. AIWorx rechnet in einem Beispiel neun Stunden mal 45 Euro mal 46 Arbeitswochen — 18.630 Euro theoretischer Bruttonutzen pro Jahr. Aber bitte sauber bleiben: Zeitersparnis ist nur dann Wert, wenn daraus Kapazität, weniger Überstunden, vermiedene Einstellungen oder mehr Durchsatz entsteht. Wenn Mitarbeitende die gesparte Stunde mit internen Abstimmungen füllen, hat niemand Geld verdient. Das ist unbequem. Naja, fast. Es ist nötig.

Der häufigste Fehler im Buy-Modus ist Vendor Lock-in ohne Exit-Plan. Können Daten exportiert werden? Sind Prompts, Embeddings und Konfigurationen portierbar? Kann der Modellanbieter gewechselt werden? Werden Daten in der EU verarbeitet? Was passiert bei Preisänderungen? Ich habe diese Fragen in Ausschreibungen zu selten gesehen. Dafür sehe ich viele schöne Folien mit „AI Ready“. Eine Folie verarbeitet keine Kundenanfrage.

Trend 3: Eigenentwicklung wandert in Kernprozesse

Der dritte Trend: Eigenentwicklung verschwindet nicht. Sie wird ernster. Weniger Chatbot, mehr Fertigung. Weniger „wir trainieren unser eigenes LLM“, mehr Prozessintelligenz an Stellen, an denen Standardsoftware nicht weiß, wie Ihr Geschäft wirklich funktioniert. Bei Festo, Schaeffler, Phoenix Contact, Wittenstein oder Brose gibt es Prozesse, Daten und Produkte, die nicht einfach in eine generische Maske passen. Der Mittelständler mit 180 Mitarbeitenden hat dieselbe Logik kleiner: Maschinenparameter, historische Reklamationen, Zeichnungen, Kalkulationswissen, Lieferantenverhalten, Sonderfälle aus 20 Jahren.

Eigenentwicklung lohnt sich vor allem, wenn mehrere Bedingungen zusammenkommen. KI ist Bestandteil des Kernprodukts oder der zentralen Wertschöpfung. Es gibt einzigartige Trainings- oder Prozessdaten. Standardprodukte bilden den Ablauf nicht ab. Das Ergebnis wirkt auf Marge, Qualität, Lieferfähigkeit oder Kundenerlebnis. Es gibt Anforderungen an Latenz, Offline-Fähigkeit, Datenhoheit oder Auditierbarkeit. Und — das wird gern vergessen — es gibt eine Organisation, die Betrieb, Monitoring, Updates und Fehlerbehandlung leisten kann.

Ein Beispiel aus Gesprächen mit einem Produktionsleiter in Süddeutschland: visuelle Qualitätsprüfung für ein Bauteil mit wechselnden Oberflächen, Reflexionen und engen Toleranzen. Standard-Vision-Systeme liefern eine Basis. Aber die entscheidenden Daten liegen in Rückläufern, Prüfplänen, Grenzmustern und Erfahrungswissen der Schichtführer. Hier kann ein eigenes System wirtschaftlich sein, weil jeder falsch ausgesonderte Artikel Geld kostet und jeder durchgerutschte Fehler Reklamationen auslöst. Das ist nicht „KI-Spielerei“. Das ist Stückkostenrechnung mit Kameras.

Ein anderes Beispiel: Finanzabschluss in einer mittelständischen Unternehmensgruppe. Ein dokumentierter Fall beschreibt einen KI-Agenten, der vor dem Monatsabschluss tausende Buchungen auf Plausibilität prüft, fehlende wiederkehrende Buchungen erkennt, Kostenstellen mit historischen Mustern abgleicht und auffällige Beträge markiert. Die Prüfzeit sinkt laut Fallbeschreibung von mehreren Stunden pro Gesellschaft auf wenige Minuten. Meine Einordnung: kein eigenes Basismodell. Integrate. Der Wert entsteht aus Finanzdaten, Regeln, Ausnahmen und menschlicher Freigabe.

Die Analysten und Anbieter sind sich nicht in allem einig. Müssen sie auch nicht. Die Richtung ist trotzdem klar: GenAI wird Infrastruktur, Differenzierung entsteht an den Rändern. In Daten. In Workflows. In Bewertungssystemen. In Branchenlogik. Wer 2026 ein eigenes Modell trainiert, bevor er Retrieval, API-Orchestrierung, Rollenrechte und saubere Evaluation ausgereizt hat, verbrennt wahrscheinlich Geld. Nicht immer. Aber oft genug, dass ich es einem 200-Mitarbeiter-Unternehmen nicht als ersten Schritt empfehlen würde.

Amplifa ICP Playbook Ein praktisches Playbook, um Zielkunden, Datenquellen und Vertriebslogik zu strukturieren — sinnvoll, bevor KI in Lead-Generierung oder Account-Priorisierung integriert wird.

Was Build, Buy und Integrate wirtschaftlich bedeuten

Die Business-Auswirkung liegt nicht im Label. Sie liegt in Kapitalbindung, Geschwindigkeit, Risiko und Lernkurve. Buy gibt schnelle Nutzung, aber begrenzte Anpassung. Integrate gibt Flexibilität mit vertretbarer Time-to-Value. Build gibt Kontrolle, aber auch Betriebslast. Hybrid mischt alles — und macht Architektur komplexer. Wer das nicht sauber trennt, vergleicht Lizenzkosten mit Entwicklungsbudgets und wundert sich später über Nachträge.

Ich rechne mit Kunden nicht nur Einführungskosten. Ich rechne drei Jahre. Einführung, Integration, interne Aufwände, Betrieb, Governance, Weiterentwicklung. Diese Formel wirkt simpel, aber sie verändert Entscheidungen. Plötzlich ist die günstige Eigenentwicklung nicht mehr günstig, weil die Fachabteilung 80 Stunden Daten bereinigt, die IT Schnittstellen baut, der Datenschutz prüft, der Betriebsrat eingebunden wird und jemand monatlich Qualität, Latenz und Kosten kontrollieren muss. Das ist kein Kleingedrucktes. Das ist der eigentliche Preis.

Besonders gern unterschätzt werden Inferenzkosten. Ein Prototyp mit 300 Anfragen im Monat ist niedlich. Ein produktiver Assistent mit 40.000 Anfragen, langen Dokumenten, mehreren Retrieval-Schritten und Qualitätschecks ist ein anderes Tier. Dann zählen Token, Caching, Modellwahl, Antwortlänge, Rate Limits und Monitoring. Der Geruch von verbranntem Budget ist nicht sinnlich, aber sehr real. Man merkt ihn spätestens, wenn die erste Cloud-Rechnung kommt.

Wann Standardsoftware bei KI im Mittelstand überlegen ist

Standardsoftware gewinnt, wenn der Prozess branchenübergreifend ähnlich ist. Meeting-Protokolle. Übersetzungen. interne Wissenssuche. Serviceticket-Klassifikation. Rechnungs- und Belegverarbeitung. einfache Vertriebsassistenz. E-Mail-Entwürfe. Dokumentenzusammenfassungen. Hier ist der Nutzen meistens Zeitersparnis, nicht Differenzierung. Wenn Kärcher, ein Händler aus Münster und ein Anlagenbauer aus Österreich denselben Prozess ähnlich lösen würden, dann sollte niemand ein eigenes System bauen, nur weil das Wort KI im Projektantrag steht.

Der Vorteil von Standardsoftware liegt nicht nur in der Lizenz. Der Anbieter übernimmt Produktentwicklung, Modellpflege, Sicherheitsupdates, Support, Skalierung und teilweise Compliance-Dokumentation. Ein Implementierungspartner wie AI Heroes nennt bei klar abgegrenzten Projekten Startphasen von etwa sechs Arbeitstagen und Gesamtumsetzungen von zwei bis zwölf Wochen. Das ist für viele mittelständische Teams genau richtig, wenn ein Fachbereich endlich spürbare Entlastung braucht und nicht ein Forschungsvorhaben.

Aber Standardsoftware hat Grenzen. Sie kennt Ihre Rabattlogik nicht. Sie kennt nicht die Excel-Liste, die seit 2017 von einer Kollegin gepflegt wird und eigentlich der wahre Produktkonfigurator ist. Sie versteht keine stillen Regeln aus der Fertigung, wenn sie nicht dokumentiert sind. Sie weiß auch nicht, warum ein Kunde aus der Schweiz immer eine andere Verpackung braucht, obwohl das im ERP wie derselbe Artikel aussieht. Genau an diesen Stellen beginnt Integration. Nicht zwangsläufig Eigenentwicklung.

Wann Eigenentwicklung wirklich gerechtfertigt ist

Eigenentwicklung ist gerechtfertigt, wenn der Use Case eine der zentralen wirtschaftlichen Achsen berührt: Qualität, Durchsatz, Lieferfähigkeit, Marge, Produktfunktion oder Kundenzugang. Nicht, wenn jemand sagt: „Unsere Prozesse sind speziell.“ Das sagen alle. Die Frage ist: Sind sie speziell genug, dass Standardsoftware keinen vergleichbaren Nutzen liefern kann? Und ist der Vorteil groß genug, um Entwicklung, Betrieb, Governance und Personalrisiko zu tragen?

Ich sehe plausible Build-Fälle im industriellen Mittelstand vor allem in sechs Bereichen: visuelle Qualitätsprüfung für spezifische Bauteile, Predictive Maintenance mit proprietären Maschinendaten, Produktionsplanung mit individuellen Restriktionen, automatische Auslegung kundenspezifischer Produkte, technische Assistenz mit internen Normen und Zeichnungen, KI-Funktionen im eigenen Maschinen- oder Softwareprodukt. Das sind keine Spielwiesen. Dort hängen Fehlentscheidungen an Ausschuss, Lieferterminen, Gewährleistung oder Umsatz.

Ein CTO aus Nürnberg, Markus, sagte mir im Herbst 2025: „Das funktioniert bei uns nicht, wenn die Daten das Haus verlassen.“ Er meinte keine PowerPoint-Angst. Sein Unternehmen verarbeitet kundenspezifische Konstruktionsdaten mit engen Geheimhaltungsvereinbarungen. Für ihn waren Offline-Fähigkeit, On-Premises-Betrieb und Audit-Logs keine Nice-to-haves. Genau dort kippt die Entscheidung. Vielleicht kein vollständiger Eigenbau. Aber sicher keine unkontrollierte SaaS-Lösung mit unklarem Datenpfad.

Trotzdem rate ich auch in solchen Fällen selten zum eigenen Foundation Model. Warum? Weil die Wertschöpfung meist nicht im Sprachmodell selbst liegt. Sie liegt in der Datenpipeline, den Evaluationsfällen, der Zugriffskontrolle, den Prüfregeln, der Integration in MES oder ERP und im Mensch-in-der-Schleife-Prozess. Ein leistungsfähiges Standardmodell, sauber eingebettet, schlägt oft ein schwaches eigenes Modell mit großem Ego.

FAQ: Sollte ein Mittelständler ein eigenes KI-Modell trainieren?

Meistens nein. Ein eigenes Modelltraining sollte erst geprüft werden, wenn Standardmodelle plus Retrieval-Augmented Generation, gute Prompts, klare Datenaufbereitung, domänenspezifische Evaluation und regelbasierte Validierung nicht ausreichen. Wenn ein Unternehmen keine 100 belastbaren Testfälle für einen Use Case zusammenbekommt, ist eigenes Training fast immer zu früh. Ehrlich? Ich weiß es nicht in jedem Einzelfall. Aber ich weiß, dass viele Teams Training sagen, wenn sie eigentlich Datenstruktur meinen.

Was das für Geschäftsführer, CTOs und Digitalverantwortliche bedeutet

Für Geschäftsführer bedeutet es: KI-Budgets müssen wie Investitionsportfolios geführt werden. Nicht wie Innovationsspielgeld. Jeder Use Case bekommt eine These, eine Zielkennzahl, eine Architekturvariante und eine Exit-Regel. Wenn nach acht Wochen keine belastbaren Daten zu Genauigkeit, Nutzungsrate, Latenz, Kosten und Prozesswirkung vorliegen, wird nicht weiterromantisiert. Dann wird angepasst oder gestoppt.

Für CTOs bedeutet es: Architekturentscheidungen müssen reversibel bleiben. Modellanbieter wechseln können. Daten exportieren können. Prompts versionieren. Logs schreiben. Rechte sauber abbilden. Kosten messen. Wenn ein Anbieter nur eine hübsche Oberfläche liefert, aber keine tragfähige Integrations- und Governance-Geschichte, dann kaufen Sie keine KI. Dann kaufen Sie Abhängigkeit mit Login-Seite.

Für Digitalverantwortliche bedeutet es: Der Fachbereich muss liefern. Prozessbeschreibung. Testfälle. Datenzugang. Akzeptanzkriterien. Zeit der Key User. Ich habe zu viele Piloten gesehen, in denen die IT den schwarzen Peter bekam, obwohl Vertrieb, Service oder Finance keine klaren Erfolgswerte definiert hatten. „Die KI soll uns entlasten“ ist kein Ziel. „Bearbeitungszeit technischer Kundenanfragen um 30 Prozent senken, bei maximal 5 Prozent Eskalationsfehlern“ ist ein Ziel.

Ein gutes Beispiel ist Vertriebspriorisierung. Viele Teams wollen mehr Leads. Stimmt nicht ganz. Sie wollen bessere Verkaufszeit. Wenn ein System 500 Firmen findet, aber der Außendienst 480 ignoriert, ist nichts gewonnen. Wenn ein integrierter Agent aus CRM-Historie, Website-Signalen, Branchenclustern und vorhandenen Referenzen 40 Accounts priorisiert und zehn davon echte Gespräche werden, reden wir über Pipeline. Nicht über Datenmenge.

Amplifa Produkt Amplifa hilft B2B-Teams, Zielkunden zu identifizieren, Signale zu nutzen und Vertriebsprozesse mit KI zu operationalisieren — ohne unnötige Eigenentwicklung.

Sieben Vorbereitungsschritte für Ihre KI-Strategie

1. Use-Case-Inventar erstellen: Sammeln Sie nicht nur Ideen, sondern Prozesse mit Volumen, Kosten, Fehlern, Durchlaufzeit und Prozessverantwortlichem. Eine Liste mit 30 Ideen ist wertlos, wenn keine davon einen messbaren Engpass adressiert.
2. Differenzierungsgrad bewerten: Fragen Sie brutal ehrlich, ob ein Wettbewerber mit derselben Standardsoftware denselben Nutzen hätte. Bei ja: Buy. Bei teilweise: Integrate. Bei nein: Build prüfen, aber erst nach Datencheck.
3. Datenzugang prüfen: Klären Sie, welche Datenquellen benötigt werden, wem sie gehören, wie aktuell sie sind, welche Rechte gelten und ob historische Beispiele vorhanden sind. Ohne Datenreife wird Eigenentwicklung zum Nebelprojekt.
4. Drei-Jahres-TCO rechnen: Erfassen Sie Einführung, Integration, interne Aufwände, Betrieb, Governance und Weiterentwicklung. Lizenzpreise sind nur ein Teil. Fachbereichszeit ist kein Gratisgut.
5. Pilotkriterien vor Start festlegen: Definieren Sie Mindestwerte für Genauigkeit, Latenz, Nutzungsrate, Fehlerquote, Kosten pro Vorgang und Amortisation. Eine Demo ohne Abbruchkriterium ist Verkaufsunterhaltung.
6. Governance klein, aber echt aufsetzen: Benennen Sie Product Owner, Datenverantwortlichen, IT-Security-Ansprechpartner, Freigabeprozess, Logging, Eskalation und regelmäßige Qualitätskontrolle. Nicht nach dem Rollout. Vorher.
7. Architektur mit Exit planen: Verlangen Sie Exportmöglichkeiten, Modellwechsel, Dokumentation, Versionierung und klare Vertragsregeln zu Datenverarbeitung und Preisänderungen. Vendor Lock-in ist leichter zu verhindern als zu reparieren.

Diese sieben Schritte klingen nach Arbeit. Sind sie auch. Aber sie sparen die falsche Arbeit. Ein vier- bis achtwöchiger Pilot ist realistisch, wenn Use Case, Datenzugriff und Verantwortlichkeiten geklärt sind. Wenn nicht, dauern schon die ersten zwei Wochen nur deshalb, weil niemand weiß, wer auf welche Tabelle zugreifen darf. Dann ist nicht die KI langsam. Dann ist die Organisation unvorbereitet.

Die harte Budgetlogik: Unter 10.000 Euro, 50.000 Euro, 150.000 Euro

Für die meisten DACH-Mittelständler nutze ich eine einfache Budgetlogik. Bis etwa 10.000 Euro: Standardsoftware oder kleiner Workflow-Pilot. Etwa 10.000 bis 50.000 Euro: API-Integration, interner Wissensassistent oder einzelner Fachprozess. Etwa 50.000 bis 150.000 Euro: produktive, systemübergreifende Lösung mit Governance und Monitoring. Über 150.000 Euro: nur bei hoher Prozessrelevanz, klarer Skalierung und belastbarem ROI. Eigene Modelle oder vollständige Plattformen? Nur bei strategischer Differenzierung, proprietären Daten und vorhandener Betriebsorganisation.

Diese Schwellen sind keine Naturgesetze. Ein Phoenix-Contact-naher Elektronikzulieferer mit hoher Stückzahl und klaren Qualitätskosten kann einen höheren Betrag früher rechtfertigen als ein 70-Personen-Handelsunternehmen mit generischer Dokumentenverarbeitung. Aber die Schwellen zwingen zur Frage: Was muss wahr sein, damit sich dieses Projekt lohnt? Wenn niemand diese Frage beantworten kann, sollte das Projekt nicht starten.

Ich habe eine Abneigung gegen KI-Roadmaps, die aus Toolnamen bestehen. Q1 Copilot, Q2 Chatbot, Q3 Agent, Q4 Automatisierung. Das ist keine Strategie. Eine Strategie sagt, welche Fähigkeiten das Unternehmen aufbaut: Datenzugang, Evaluation, Prozessintegration, Governance, Anbietersteuerung, Nutzerführung. Tools kommen und gehen. Fähigkeiten bleiben. Zumindest, wenn jemand sie pflegt.

FAQ: Wie messe ich Erfolg bei KI-Piloten im Mittelstand?

Ich trenne drei Stufen. Technischer Pilot: Die Lösung funktioniert mit Echtdaten. Messgrößen sind Genauigkeit, Latenz und Fehlerrate. Operativer Pilot: Mitarbeitende verwenden sie im Prozess. Messgrößen sind Nutzungsrate, Bearbeitungszeit, Eskalationen und Akzeptanz. Wirtschaftlicher Erfolg: Der Nutzen ist nachweisbar. Messgrößen sind Kosten pro Vorgang, Durchlaufzeit, Umsatzwirkung, Fehlerkosten oder vermiedene Neueinstellungen. Ein Pilot kann technisch funktionieren und wirtschaftlich trotzdem egal sein.

Mindestwerte helfen. 90 Prozent korrekte Dokumentklassifikation. Weniger als 5 Prozent unbehandelte Fehlentscheidungen. Antwortzeit unter drei Sekunden, wenn Nutzer im Prozess warten. Mindestens 30 Prozent Zeitersparnis, wenn der Business Case auf Produktivität basiert. Mindestens 60 Prozent aktive Nutzung nach drei Monaten. Amortisation innerhalb von 12 bis 24 Monaten. Nicht jeder Use Case braucht dieselben Werte, aber jeder braucht vorab definierte Werte.

Der unterschätzte Teil: Change Management und Betriebsrealität

KI-Projekte scheitern selten an einer einzigen technischen Wand. Sie scheitern an Reibung. Ein Sachbearbeiter vertraut der Klassifikation nicht. Ein Vertriebsleiter will keine neuen CRM-Felder. Die IT will keine weiteren Schatten-Integrationen. Datenschutz verlangt eine Prüfung. Der Betriebsrat fragt nach Leistungsüberwachung. Die Fachabteilung hat keine Zeit für Testfälle. Jede dieser Reibungen ist lösbar. Keine löst sich von selbst.

Ich mag deshalb Piloten, die klein genug sind, um zu starten, aber echt genug, um weh zu tun. Echtdaten. Echter Prozess. Echte Nutzer. Ein Test mit fünf perfekten PDFs aus dem Marketingordner ist wertlos. Im Alltag kommen gescannte Dokumente, Tippfehler, alte Vorlagen, fehlende Anhänge, doppelte Kundennummern und eine Kollegin, die „wie immer“ etwas anders macht. Wenn die Lösung damit nicht umgehen kann, ist sie Demo-Material. Kein Betrieb.

Bei einem Serviceprozess eines Maschinenbauers aus Ostwestfalen haben wir in der Analyse gesehen, dass nicht die KI-Klassifikation der Engpass war. Die war nach einigen Iterationen gut genug. Der Engpass war, dass die Eskalationsregeln je nach Produktlinie unterschiedlich gelebt wurden und niemand sie vollständig dokumentiert hatte. Die Werkhalle roch nach Öl und warmem Metall, die Whiteboards waren voll, und am Ende war die wichtigste KI-Arbeit ein Prozessgespräch mit drei Teamleitern. So sieht Realität aus.

KI-Governance: klein anfangen, aber nicht naiv

Governance muss nicht mit einem 90-seitigen Handbuch starten. Aber sie muss starten. Jeder produktive Use Case braucht einen fachlichen Product Owner, einen Datenverantwortlichen, einen IT- und Security-Verantwortlichen, dokumentierte Qualitätsmetriken, Eskalations- und Fallback-Prozess, regelmäßige Kosten- und Qualitätskontrolle. Das ist der Mindeststandard. Wer KI in Kundenkommunikation, Finanzprozesse oder Produktionsentscheidungen bringt, braucht Nachvollziehbarkeit. Sonst wird aus Automatisierung ein Haftungsthema.

Der EU AI Act wird diese Disziplin verstärken. Nicht jeder Mittelstands-Use-Case ist Hochrisiko. Aber die Fragen werden normal: Welche Daten wurden genutzt? Wer darf was sehen? Wie wird ein Ergebnis freigegeben? Was passiert bei Fehlern? Wie werden Versionen dokumentiert? Wenn ein Anbieter darauf nur mit „unsere KI ist sicher“ antwortet, reicht mir das nicht. Ein Audit-Log ist langweiliger als ein Demo-Video. Genau deshalb ist es wertvoll.

Amplifa KI-Strategie Gespräch Für Mittelständler, die konkrete Use Cases nach Build, Buy und Integrate priorisieren wollen — mit Fokus auf Vertrieb, Datenquellen, Governance und messbare Umsetzung.

Meine persönliche Prognose für 2026 bis 2028

Erstens: Reine Inbound-Strategien werden im B2B-Mittelstand weiter an Wirkung verlieren. Wer 2026 noch glaubt, dass ein paar Whitepaper und Messekontakte die Pipeline der nächsten fünf Jahre tragen, bekommt ein Problem. KI-gestützte Markt- und Account-Intelligenz wird Standard. Nicht als Spam-Maschine. Als System, das Zielkunden, Timing, Bedarfssignale und Gesprächsanlässe besser verbindet.

Zweitens: Die meisten Unternehmen werden ihre ersten KI-Fehlinvestitionen nicht bereuen, weil sie zu teuer waren. Sie werden sie bereuen, weil niemand gelernt hat. Kein sauberer Evaluationssatz. Keine Nutzungsdaten. Keine Dokumentation. Kein Vergleich zwischen Buy, Integrate und Build. Dann bleibt nur ein diffuses Gefühl: KI hat bei uns nicht funktioniert. Das ist die gefährlichste Erzählung, weil sie falsch und bequem ist.

Drittens: Die beste KI-Strategie im Mittelstand wird unspektakulär aussehen. Standardsoftware für generische Aufgaben. APIs für Prozessintegration. Eigene Daten als Differenzierungsstufe. Eigenentwicklung nur dort, wo sie wirtschaftlich verteidigbar ist. Ich weiß, das verkauft sich schlechter als „wir bauen unsere eigene KI“. Aber Geschäftsführer bezahlen nicht für Schlagzeilen. Sie bezahlen für Marge, Durchsatz, Pipeline und weniger Blindflug.

Wenn ich in zwei Jahren auf diesen Trend-Report schaue, erwarte ich weniger Diskussionen über Modellnamen und mehr über Prozessmetriken. Weniger Stolz auf Eigenentwicklung. Mehr Stolz auf saubere Entscheidungskriterien. Vielleicht ist das der eigentliche Reifegrad: nicht zu bauen, was man bauen kann. Sondern nur das, was das Unternehmen wirklich stärker macht.