KI-Strategie · 23. Mai 2026 · 24 Min. Lesezeit · Mohsen Ghulami, GTM Engineer, Amplifa

KI-Strategie: Build vs. Buy im Mittelstand

KI-Strategie im Mittelstand: Entscheiden Sie Build vs. Buy mit Zahlen, Fällen und klaren Kriterien, bevor Ihr PoC Budget frisst.

Vor drei Wochen stehe ich in Gütersloh in einem Besprechungsraum, der nach Filterkaffee und warmem Kunststoff riecht. Thomas, CTO eines Maschinenbauers mit 280 Leuten, schiebt mir sein iPad hin und sagt: „Wir bauen jetzt unsere eigene KI-Plattform.“ Auf dem Hof piept ein rückwärtsfahrender Stapler, drinnen flackert eine PowerPoint-Folie mit Azure-Logo, Python-Schlange und einem Budgetblock von 1,2 Millionen Euro. Meine erste Frage war nicht technisch, sondern brutal simpel: Ist das wirklich KI-Strategie — oder nur ein teurer Umweg zur nächsten Standardsoftware?

Ich schreibe seit 1998 über Industrie. Ich habe bei Trumpf in Ditzingen gesehen, wie Daten aus Laserschneidanlagen zum Servicegeschäft werden. Ich habe bei kleineren Lohnfertigern auf der Schwäbischen Alb erlebt, wie ein einziger fehlender MES-Export ein ganzes KI-Projekt stoppt. Und ich habe genug CFOs gesehen, die bei dem Wort „Eigenentwicklung“ die Lippen zusammenpressen, als hätten sie in eine Zitrone gebissen.

Build vs. Buy bei KI ist deshalb keine Glaubensfrage. Es ist eine Kapitalallokationsfrage. Wer als Mittelständler mit 50 bis 500 Mitarbeitern jedes Forecasting-Modell selbst bauen will, verbrennt Zeit, Gehälter und Nerven. Wer aber jede KI-Funktion zukauft, obwohl sie im eigenen Produkt den Unterschied macht, verschenkt Marge an Anbieter, die das Geschäft nicht verstehen. Beides habe ich gesehen. Beides tut weh.

Warum KI-Strategie jetzt zur Chefsache wird

Im März 2025 saß ich bei einem Zulieferer in der Nähe von Heilbronn, 410 Mitarbeiter, viel Zerspanung, wenig Geduld. Andrea, Head of Operations, zeigte mir eine Linie mit sechs Bearbeitungszentren von DMG Mori. Das Geräusch war dieses harte, metallische Singen, das man aus Hallen kennt, in denen niemand über Zukunft redet, weil der Auftrag bis Freitag raus muss. „Wir haben vier KI-PoCs“, sagte Andrea. „Keiner läuft produktiv.“

Genau da steht der Mittelstand. Nicht am Anfang der KI-Debatte, sondern nach der ersten Ernüchterung. ChatGPT hat 2023 die Tür aufgestoßen, Microsoft Copilot ist in vielen Firmen angekommen, SAP schiebt KI-Funktionen in die Suite, und jeder zweite Softwareanbieter klebt inzwischen ein KI-Etikett auf seine Roadmap. Nur: In der Halle, im Vertrieb, im Service passiert weniger, als die Konferenzbühnen behaupten.

Die Zahlen passen zu dieser Beobachtung. Laut Bitkom-Studie 2024 setzen rund 15 bis 20 Prozent der deutschen Unternehmen KI produktiv ein; bei Unternehmen zwischen 100 und 499 Mitarbeitern liegt die Quote eher im unteren Bereich, grob 10 bis 15 Prozent. BCG und VDMA kamen 2023 im Maschinenbau zu einem Muster, das ich in Gesprächen ständig höre: Mehr als 60 Prozent experimentieren mit KI-PoCs, aber weniger als 15 Prozent haben skalierte Anwendungen im Unternehmen. Also: viel Pilot, wenig Betrieb.

Das ist kein deutsches Naturgesetz. Es ist oft schlechtes Entscheiden. Der Mittelstand behandelt KI zu oft wie eine Technologieanschaffung und zu selten wie eine Frage der Wertschöpfung. In einem Betrieb mit 180 Mitarbeitern aus Augsburg sagte mir Jens, kaufmännischer Leiter, im Januar 2025: „Wir können uns keinen Fehler leisten.“ Stimmt. Aber Nicht-Entscheiden ist auch ein Fehler. Nur leiser.

KI-Strategie im Mittelstand: Was Build vs. Buy wirklich bedeutet

Build heißt nicht, dass drei Data Scientists im Keller ein Foundation Model trainieren. Naja, fast nie. Build bedeutet im Mittelstand meist: eigene Datenpipelines, eigene Modelle oder zumindest eigene Domänenlogik, eigene MLOps-Prozesse, eigenes Monitoring, eigene Verantwortung. Der Anbieter liefert vielleicht Cloud-Infrastruktur, aber die Firma trägt Produkt- und Betriebsrisiko.

Buy heißt nicht, dass man eine Software kauft und am Montag 15 Prozent Ausschuss spart. Wer das glaubt, hat noch nie eine Schnittstelle zwischen altem ERP, Excel-Export und Maschinensteuerung gesehen. Buy heißt: Standardsoftware, SaaS oder Plattformbausteine einkaufen, konfigurieren, integrieren, schulen, messen. Das ist Arbeit. Aber es ist eine andere Arbeit als Modellbau.

Die schärfste Grenze verläuft nicht zwischen Cloud und On-Prem. Sie verläuft zwischen Commodity und Differenzierung. Forecasting, Standard-NLP, Bildklassifikation, Routenoptimierung, Angebotsassistenz, einfache Recommendation Engines — dafür gibt es brauchbare Produkte. KI im Produktkern, etwa intelligente Sensorik, autonome Navigation, proprietäre Prozesssteuerung oder ein Servicealgorithmus, der aus 15 Jahren Maschinendaten lernt — da kann Build sinnvoll sein. Kann. Nicht muss.

PwC und Roland Berger beschreiben seit 2023 ein Muster, das auch in meinen Gesprächen auftaucht: kleinere und mittlere Mittelständler fahren überwiegend Buy oder Configure, größere Mittelständler wählen häufiger Hybrid. Der 300-Mann-Betrieb kauft eher Microsoft, SAP, Cognex, Celonis, o9, PTC oder einen spezialisierten Anbieter. Der 3.000-Mann-Zulieferer baut vielleicht ein Analytics Competence Center und entwickelt dort, wo die Wertschöpfung sitzt. Das klingt banal. Es wird trotzdem dauernd ignoriert.

Die harten Zahlen: Kosten, Timelines, Erfolgsquoten

Ich habe in den vergangenen zwei Jahren in München, Stuttgart, Bielefeld und Linz mit Digitalverantwortlichen gesprochen, die ihre KI-Budgets nicht in Pressemitteilungen, sondern in Excel pflegen. Die Spannen sind erstaunlich stabil. Ein Build-PoC liegt im Mittelstand meist bei 100.000 bis 300.000 Euro für drei bis sechs Monate. Bis ein MVP produktiv läuft, sind 300.000 bis 800.000 Euro realistisch, interne Personalkosten nicht immer sauber gerechnet. Und genau dort beginnt die Selbsttäuschung.

Denn der Data Scientist ist nicht kostenlos, nur weil er schon auf der Payroll steht. Der Produktionsingenieur, der jede Woche acht Stunden Labels prüft, auch nicht. Die IT-Architektin, die Sicherheitsfreigaben klärt, erst recht nicht. In einem Werk bei Ulm roch es im Februar 2025 nach Kühlschmierstoff, während mir Martin, IT-Leiter, sagte: „Extern haben wir nur 180.000 Euro ausgegeben.“ Zwei Stunden später zeigte er mir die interne Aufwandsschätzung. Mit Eigenleistung lag das Projekt bei 520.000 Euro.

Buy oder Configure startet niedriger. Pilotlizenz plus Integration: häufig 50.000 bis 250.000 Euro. Rollout über mehrere Werke oder Bereiche: 150.000 bis 800.000 Euro. Laufende Lizenzkosten liegen für viele mittelständische Szenarien bei 50.000 bis 200.000 Euro pro Jahr, abhängig von Nutzern, Datenvolumen und Anbieterlaune. Ja, Anbieterlaune. Wer schon einmal im dritten Vertragsjahr eine SaaS-Verlängerung verhandelt hat, weiß, was ich meine.

Die Erfolgsquoten sind der eigentliche Schlag ins Kontor. McKinsey berichtete im State of AI 2023, dass nur etwa 20 bis 30 Prozent der Unternehmen signifikante finanzielle Vorteile aus KI-Projekten erzielen. In Fertigung und Industriegütern sterben nach meiner Erfahrung und nach Beraterbenchmarks 50 bis 70 Prozent der PoCs, bevor sie echten Betrieb sehen. Bei Build schaffen oft nur 30 bis 40 Prozent den Sprung in Produktion. Bei Buy oder Configure eher 50 bis 70 Prozent. Nicht weil Anbieter zaubern. Sondern weil weniger Grundrisiko im Modell steckt.

Build lohnt sich — aber seltener, als Gründerfolien behaupten

Ich mag Eigenentwicklung. Wirklich. Es gibt diesen Moment, wenn ein Team ein Modell nicht nur trainiert, sondern in einen Prozess einbettet, die Nutzer es anfassen, die Kennzahl sich bewegt und der Werkleiter nicht mehr von „dem KI-Ding“ spricht, sondern von seinem neuen Werkzeug. Das ist stark. Nur passiert es nicht, weil jemand PyTorch installiert hat.

Trumpf ist ein gutes Beispiel, aber auch eine Warnung. Das Familienunternehmen aus Ditzingen hat rund 16.500 Mitarbeiter, tiefe Maschinendaten, eigene Plattformhistorie mit AXOOM und ein Ökosystem rund um TruConnect. Seit etwa 2017 investiert Trumpf kontinuierlich in digitale Services, Predictive Maintenance und Smart-Factory-Funktionen. In öffentlichen Darstellungen spricht Trumpf bei bestimmten Anlagen von bis zu 20 bis 30 Prozent weniger Stillstandzeiten durch vorausschauende Wartung. Das ist kein Nebenprojekt aus der IT. Das ist Produkt- und Servicegeschäft.

Kärcher aus Winnenden ist ähnlich interessant. Der KIRA B 50, ein autonomer Reinigungsroboter, braucht Computer Vision, Navigation, Sensorfusion und robuste Software im physischen Produkt. Ein Standard-Recommender aus der Cloud hilft da wenig. Kärcher hat seit etwa 2018 digitale Kompetenzen aufgebaut, unter anderem im Digital Hub, und verbindet eigene Entwicklung mit Cloud-Bausteinen. Hier ist Build kein Prestige. Die KI steckt im Gerät, im Preis, im Servicevertrag.

Das ist der Punkt: Build lohnt, wenn KI den Kundennutzen verändert oder einen Prozess abbildet, den Wettbewerber nicht einfach kopieren können. Ein Werkzeugmaschinenhersteller mit Milliarden historischer Sensordaten hat eine andere Ausgangslage als ein 220-Mann-Großhändler, der Cross-Selling im Webshop verbessern will. Wer diese Unterschiede verwischt, zäumt das Pferd von hinten auf.

Wir entwickeln nur dort selbst, wo wir einen klaren Wettbewerbsvorteil sehen und unser Prozess- oder Produktwissen einzigartig ist. Standard-Analytics und Sprachmodelle kaufen wir zu.

— sinngemäß nach einem CDO eines deutschen Maschinenbauers, Handelsblatt-Gespräch 2024

Nicole Büttner von Merantix Momentum hat in EY-Formaten zu „Zukunft Deutschland“ sinngemäß etwas Ähnliches betont: Der Mittelstand hat mit eigenen Daten einen Vorteil, sollte aber Modelle und Plattformen oft zukaufen und die Domänenlogik selbst beherrschen. Ich unterschreibe das. Daten allein sind noch kein Burggraben. Erst wenn Daten, Prozesswissen und Verteilungskanal zusammenkommen, wird Build interessant.

Buy-first ist keine Kapitulation, sondern Disziplin

In Münster traf ich im November 2024 einen Logistikmanager, Ralf, der bei Fiege früher an Prognoseprojekten beteiligt war. Wir saßen in einer Kantine, es roch nach Bratensoße, und aus dem Lager kam dieses dumpfe Rollen von Fördertechnik. „Wir hätten alles selbst bauen können“, sagte er. „Aber wofür?“ Fiege nutzt in verschiedenen Bereichen Cloud-Services, Azure-Bausteine und Partnerlösungen, etwa für Prognosen und Optimierung. Die veröffentlichten Use Cases sprechen von 2 bis 5 Prozent Bestandsreduktion und 3 bis 8 Prozent besserer Forecast Accuracy, je nach Feld.

Das ist Mittelstandsrealität, nur eine Nummer größer. Ein Forecast ist selten einzigartig. Eine Routenoptimierung auch nicht. Eine bildbasierte Qualitätsprüfung mit definierter Fehlerklasse ist technisch anspruchsvoll, aber oft kein Grund, ein eigenes Vision-Team aufzubauen. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx oder spezialisierte Anbieter haben ihre Macken. Natürlich. Aber sie starten nicht bei null.

Ein anonymisierter Fall aus Süddeutschland zeigt die Logik sauber. Maschinenbauer, 800 Mitarbeiter, manuelle Sichtprüfung, Personalmangel, hoher Nacharbeitsdruck. Das Unternehmen kaufte ein kommerzielles Vision-AI-System statt eigener Entwicklung. Initialinvestition: rund 350.000 Euro für Hardware, Lizenzen, Integrator und Schulung. Vier Monate PoC, drei Monate Rollout auf zwei Linien. Nach zwölf Monaten lag die Fehlerquote etwa 30 Prozent niedriger, Amortisation unter 18 Monaten. Kein Innovationspreis. Aber Geld.

Ich weiß, Buy klingt manchen CTOs zu klein. Man will nicht bloß „konfigurieren“. Man will gestalten. Verständlich. Nur zahlt der Kunde nicht für den Stolz der IT-Abteilung. Er zahlt für Lieferfähigkeit, Qualität, Service, Preisstabilität. Wenn Standardsoftware 80 Prozent des Nutzens in einem Drittel der Zeit bringt, dann ist Eigenentwicklung oft Eitelkeit mit Sprint-Planung.

Die zweite Wahrheit: Buy kann teuer, träge und gefährlich werden

Jetzt die Selbstkorrektur. Buy-first heißt nicht Vendor-first. Ich habe SaaS-Projekte gesehen, die nach zwei Jahren aussahen wie eine Mietwohnung nach zehn Untermietern: überall Adapter, keiner weiß mehr, wem der Schlüssel gehört. Ein 260-Mann-Zulieferer aus Niederbayern zahlte 2024 für drei KI-nahe Tools im Vertrieb, im Service und in der Planung jeweils moderate Lizenzen. Zusammen mit Schnittstellen, Beratung und internen Admins lagen die Jahreskosten plötzlich bei 310.000 Euro. Nutzen? Schwer messbar. „Wir haben jetzt Dashboards“, sagte der Vertriebschef. Ich hatte Mitleid mit ihm.

Der größte Buy-Fehler ist blinder Funktionsglaube. Eine Softwaredemo zeigt immer saubere Daten. Immer. Im echten Betrieb kommen doppelte Kundenstämme, fehlende Artikelhierarchien, abweichende Schichtmodelle und ein ERP-Feld namens „Sonstiges“, das seit 2009 alles enthält, was niemand einordnen wollte. SAP, Microsoft, Siemens oder PTC können viel abfedern. Aber sie reparieren keine Organisation, die ihre Stammdaten verachtet.

Der zweite Fehler ist Lock-in ohne Gegenwert. Wenn ein Anbieter die gesamte Datenhaltung, Modelllogik, Benutzeroberfläche und Prozessintegration kontrolliert, wird die Firma abhängig. Das kann akzeptabel sein, wenn der Use Case Commodity ist und der Anbieter stabil liefert. Bei kritischen Kernprozessen sollte man vorsichtiger sein. Datenexport, Auditfähigkeit, Kosten bei Skalierung, Exit-Szenario — langweilige Themen, ja. Genau deshalb werden sie zu spät gelesen.

Wo Build-Projekte im Mittelstand sterben

Es gibt eine Szene, die sich wiederholt. Besprechungsraum, grauer Teppich, Whiteboard mit Resten eines Workshops, irgendwo steht noch „Use Case Priorisierung“. Im Raum sitzen IT, Fachbereich und ein externer Berater. Nach 14 Monaten Projektzeit fragt jemand: „Wer ist eigentlich Product Owner?“ Dann wird es still. Ich habe das in Köln, Nürnberg und St. Gallen erlebt.

Der erste Todesgrund heißt Datenqualität. Nicht sexy, aber tödlich. Ein Automotive-Zulieferer mit etwa 3.000 Mitarbeitern startete über drei Jahre mehrere Predictive-Maintenance-PoCs, gemeinsam mit einem Forschungsinstitut. Aufwand: über eine Million Euro, interne Zeit eingerechnet. Alle Piloten blieben in einzelnen Anlagen hängen. OT und IT waren getrennt, es gab kein zentrales Lakehouse, die Instandhaltung war spät eingebunden, und die Datenhistorie passte nicht zur Ausfalllogik. Nach Wechsel in der IT-Leitung wurde auf eine Standardplattform umgestellt. Neun Monate später liefen erste produktive Use Cases, nach 18 Monaten wurden auf ausgewählten Anlagen rund 15 Prozent weniger ungeplante Ausfälle gemeldet.

Der zweite Todesgrund heißt falscher Stolz. Ein B2B-Händler aus der DACH-Region mit rund 1.200 Mitarbeitern wollte eine eigene Recommendation Engine bauen, auch um Abhängigkeit von US-Cloud-Plattformen zu reduzieren. Fünfköpfiges Data-Science-Team, Python, Scikit-Learn, später TensorFlow. Achtzehn Monate Entwicklungszeit, grob 1 bis 1,5 Millionen Euro. Am Ende lag die Performance nach internen Tests nur bei 60 bis 70 Prozent eines Standard-Cloud-Recommenders. Das Projekt wurde gestoppt, die SaaS-Lösung kam trotzdem. Nur später und teurer.

Der dritte Todesgrund ist fehlendes Produktdenken. KI wird als Projekt gestartet, nicht als Produkt betrieben. Es gibt einen PoC, einen Abschlussbericht, Applaus im Lenkungskreis. Danach driftet das Modell, niemand misst die Nutzerquote, niemand plant Retraining, niemand fühlt sich für Fehlalarme verantwortlich. Nach sechs Monaten sagt der Schichtleiter: „Das Ding spinnt.“ Und schon ist die Akzeptanz weg.

MLOps ist hier kein Buzzword, sondern Hausmeisterarbeit für Modelle. Monitoring, Datenversionierung, Freigabeprozesse, Rollback, Verantwortlichkeiten, Auditspur. Klingt trocken. Ist es auch. Aber ohne diese Routinen wird KI zur Einwegsoftware. Man baut, zeigt, vergisst.

Die Build-vs.-Buy-Matrix für eine belastbare KI-Strategie

Ich nutze in Gesprächen gern eine einfache 2×2-Matrix. Keine Magie. Auf der X-Achse steht Differenzierungspotenzial: Macht diese KI-Funktion uns am Markt schwerer kopierbar? Auf der Y-Achse steht Standardisierbarkeit: Gibt es reife Software, die 70 bis 80 Prozent der Aufgabe abdeckt? Wenn beide Achsen ehrlich bewertet werden, fallen viele Lieblingsprojekte durch.

Quadrant eins: hohes Differenzierungspotenzial, niedrige Standardisierbarkeit. Hier darf man Build oder Co-Build ernsthaft prüfen. Beispiele: KI in einem medizinischen Gerät mit spezieller Sensorik, autonome Funktionen in einer Reinigungsmaschine, Prozesssteuerung bei einem eigenen Produktionsverfahren. Kärcher, Trumpf, Wittenstein oder Festo denken in solchen Kategorien. Da steckt KI nah am Produkt oder am Prozessgeheimnis.

Quadrant zwei: niedriges Differenzierungspotenzial, hohe Standardisierbarkeit. Kaufen. Punkt. Standard-Forecasting, Textklassifikation im Kundendienst, einfache Chatbots, Spesenprüfung, Lead Scoring, Bildprüfung mit bekannten Fehlerbildern. Wer hier Build predigt, sollte die Opportunitätskosten auf den Tisch legen. Nicht als Folie. Als Eurobetrag.

Quadrant drei: hohes Differenzierungspotenzial, hohe Standardisierbarkeit. Das ist der spannende Hybridbereich. Ein LLM kann Angebotsentwürfe erzeugen, aber die eigene Produktlogik, Rabattregeln, Lieferfähigkeit und Haftungsklauseln müssen aus dem Unternehmen kommen. Microsoft Copilot oder SAP Joule können Oberflächen liefern, aber das Geschäftsgehirn liegt im eigenen Datenmodell. Genau dort sollten Mittelständler Kompetenz aufbauen.

Quadrant vier: niedriges Differenzierungspotenzial, niedrige Standardisierbarkeit. Meist ein Warnsignal. Wenn etwas weder strategisch wichtig noch leicht kaufbar ist, warum sollte man es tun? Weil ein Bereichsleiter es will? Weil ein Förderprogramm winkt? Fördergeld ist kein Business Case. Da beißt die Maus keinen Faden ab.

ROI-Rechnung: Warum der billigere Start teuer enden kann

Im Juni 2025 rief mich ein Geschäftsführer aus Ravensburg an. 120 Mitarbeiter, Sondermaschinenbau, ordentliches EBIT, aber dünne IT. Er fragte: „Was kostet uns eine KI für Angebotsautomatisierung?“ Ich fragte zurück: „Was kostet ein Angebot heute?“ Stille. Dann Blättern. Dann die Zahl: ungefähr 1.800 Euro interner Aufwand bei komplexen Maschinen, wenn Vertrieb, Konstruktion und Einkauf beteiligt sind.

Erst mit solchen Zahlen wird Build vs. Buy greifbar. Wenn ein Unternehmen 900 komplexe Angebote pro Jahr schreibt und ein KI-Assistenzsystem die Durchlaufzeit um 25 Prozent senkt, reden wir nicht über Spielerei. Wir reden über Kapazität, schnellere Reaktion, weniger Fehler in Stücklisten, bessere Nachverfolgung. Ob die Lösung gekauft, gebaut oder hybrid ist, entscheidet sich dann am Payback, nicht am Bauchgefühl des CTO.

Branchenvergleich: Maschinenbau, Handel, Logistik, Automotive

Maschinenbau ist Build-verführerisch. Die Firmen haben technisches Selbstbewusstsein, viele Ingenieure, gute Produktdaten und oft eine Kultur des Selbermachens. Bei DMG Mori, Trumpf, Wittenstein oder Festo ergibt diese Haltung in produktnahen KI-Funktionen Sinn. Bei einem 180-Mann-Anlagenbauer aus Oberfranken, der eine eigene Text-KI für Serviceberichte bauen will, eher nicht. Der Geruch von Hydrauliköl macht ein NLP-Modell nicht proprietär.

Handel und B2B-Distribution sollten fast immer Buy-first denken. Recommendation, Pricing, Bestandsprognose, Kundencluster, Kampagnensteuerung — das sind Felder mit vielen Anbietern und viel Erfahrung. Die Differenzierung liegt dort weniger im Algorithmus als in Datenqualität, Sortimentslogik, Einkaufskonditionen und Vertriebsausführung. Ein Händler aus Essen sagte mir im April 2025: „Wir wollten die Amazon-Logik selbst nachbauen.“ Ich fragte: „Warum nicht erst verkaufen wie Amazon?“ Er lachte nicht.

Logistik ist pragmatischer. Vielleicht, weil dort jeder Prozentpunkt sofort in Paletten, Kilometer und Schichtpläne fällt. Fiege, Dachser oder Rhenus arbeiten mit Plattformen, Partnern und eigenen Teams dort, wo es passt. Buy für Standardoptimierung, Build oder Co-Build bei speziellen Netzwerkdaten und kundenspezifischer Planung. Der Hallenboden entscheidet. Nicht die Strategieabteilung.

Automotive-Zulieferer sitzen zwischen den Stühlen. Sie haben Volumen, Qualitätsdruck, Traceability-Anforderungen und OEM-Vorgaben. Predictive Quality, Maintenance, Sichtprüfung und Planungs-KI sind attraktiv. Aber viele Werke sind historisch gewachsen, OT-Daten liegen fragmentiert, und der Betriebsrat will früh gefragt werden. Wer dort Build ohne Datenplattform startet, landet im PoC-Sumpf. Ich habe es zu oft gesehen.

Praxisbeispiel: 320 Mitarbeiter, 14 Monate, ein ehrlicher Hybrid

Ein Fall, den ich anonymisiert erzählen kann: Komponentenhersteller aus Baden-Württemberg, 320 Mitarbeiter, Umsatz knapp 75 Millionen Euro, Kunden aus Maschinenbau und Medizintechnik. Ich war im Oktober 2024 dort. In der QS roch es nach Alkoholreiniger, unter einer LED-Leuchte lagen gefräste Teile in grauen Trays. Sabine, Qualitätsleiterin, sagte: „Wir verlieren Zeit, weil wir Fehler zu spät sehen.“

Das Unternehmen hatte drei KI-Ideen: Vision AI für Qualitätsprüfung, Forecasting im Einkauf, Angebotsassistenz für Sonderteile. Früher hätte man wahrscheinlich drei PoCs gestartet. Diesmal nicht. Der Geschäftsführer ließ jede Idee durch die Matrix laufen. Vision AI: Buy. Forecasting: Buy/Configure. Angebotsassistenz: Hybrid, weil die technische Machbarkeitslogik und Variantenregeln wirklich unternehmenseigen waren.

Die Zahlen nach 14 Monaten: Vision-AI-Pilot für zwei Teilefamilien kostete rund 210.000 Euro inklusive Kamera, Beleuchtung, Integrator und Schulung. Fehlerdurchschlupf sank um 28 Prozent, Nacharbeit um 11 Prozent. Forecasting wurde über ein Modul des bestehenden ERP-Partners plus externe Datenpipeline eingeführt, Kosten etwa 95.000 Euro; die Forecast Accuracy stieg in den A-Teilen um 6 Prozentpunkte. Die Angebotsassistenz kostete mehr: rund 380.000 Euro, weil CPQ, CAD-nahe Regeln und Preishistorien integriert wurden. Dafür sank die durchschnittliche Durchlaufzeit komplexer Angebote von 9,5 auf 6,8 Arbeitstage.

Wichtiger als die Einzelzahlen war die Governance. Es gab einen Product Owner je Use Case, monatliche KPI-Sicht, klare Abbruchkriterien und einen kleinen Datenkern: ein Data Engineer, eine Analytics Engineerin, ein externer Architekt für sechs Monate. Kein KI-Labor mit Sitzsäcken. Kein Innovationszirkus. Nur Arbeit.

Amplifa ICP Playbook — Praktisches Playbook, um Zielkunden, Datenquellen und Prioritäten sauber zu definieren, bevor KI im Vertrieb oder in der Lead-Generierung Geld verbrennt.

FAQ: Wann sollte ein Mittelständler KI selbst bauen?

Ein Mittelständler sollte KI selbst bauen, wenn drei Bedingungen gleichzeitig erfüllt sind: Die Funktion schafft Differenzierung beim Kunden, die nötigen Daten sind proprietär und belastbar, und das Unternehmen kann Betrieb, Monitoring und Weiterentwicklung finanzieren. Fehlt eine dieser Bedingungen, würde ich Build nur mit Partner und harter Stopplinie zulassen. Ein Beispiel: intelligente Zustandsdiagnose für eigene Maschinen mit exklusiven Sensordaten kann Build rechtfertigen. Ein Standard-Chatbot für Serviceanfragen nicht.

FAQ: Was ist die beste KI-Strategie für 50 bis 500 Mitarbeiter?

Für Firmen zwischen 50 und 500 Mitarbeitern ist meist eine Buy-first-Hybridstrategie die beste Wahl. Standardsoftware für Commodity-Use-Cases, eigene Domänenlogik für differenzierende Prozesse, kleines internes Kernteam für Daten und Produktverantwortung. Das klingt weniger heroisch als „wir bauen unsere eigene Plattform“. Es funktioniert häufiger. Laut Bitkom 2024 ist produktive KI-Nutzung im deutschen Mittelstand noch niedrig; genau deshalb zählt Time-to-Value mehr als technischer Stolz.

FAQ: Wie vermeidet man die PoC-Falle bei KI?

Man vermeidet sie mit Kill-Kriterien, bevor der erste Workshop beginnt. Beispiel: Wenn eine Vision-AI-Lösung nach zwölf Wochen keine mindestens 10 Prozent bessere Erkennung gegenüber manueller Stichprobe zeigt, wird sie gestoppt oder neu zugeschnitten. Wenn eine Angebotsassistenz nach sechs Monaten keine messbare Zeitersparnis bringt, fliegt sie aus dem Portfolio. Klingt hart. Ist aber billiger als 18 Monate Hoffnung.

Handlungsempfehlungen: 7 Schritte zur Build-vs.-Buy-Entscheidung

Ich würde als Geschäftsführer, CTO oder Digitalverantwortlicher nicht mit Toolauswahl starten. Auch nicht mit einem KI-Workshop, bei dem am Ende 47 Use Cases auf Post-its kleben und keiner weiß, wer sie bezahlt. Ich würde sieben Dinge tun. In genau dieser Reihenfolge.

1. Inventarisieren Sie mögliche KI-Use-Cases in Produktion, Vertrieb, Service und Backoffice. Schreiben Sie pro Use Case eine Kennzahl daneben: Ausschuss, Stillstand, Angebotsdauer, Conversion, Bestand, Reklamationskosten. Ohne Kennzahl kein Use Case.
2. Bewerten Sie jeden Use Case mit der 2×2-Matrix: Differenzierungspotenzial gegen Standardisierbarkeit. Machen Sie die Bewertung im kleinen Kreis mit Geschäftsführung, Fachbereich und IT. Nicht im 18-Personen-Workshop.
3. Definieren Sie eine Buy-first-Regel für Commodity-Themen. Forecasting, Standard-Textanalyse, einfache Vision Inspection, CRM-Automation und Recommendation sollten nur dann Build werden, wenn ein schriftlicher Business-Grund vorliegt.
4. Legen Sie Kill-Kriterien fest. Zeitlimit, Mindest-KPI, Datenverfügbarkeit, Nutzerakzeptanz. Ein PoC ohne Stopplinie ist kein Experiment, sondern ein Kostenrisiko mit freundlichem Namen.
5. Bauen Sie ein kleines Kernteam auf. Für 50 bis 500 Mitarbeiter reicht oft: ein Data Engineer oder Analytics Engineer, ein starker Product Owner pro Use Case, ein IT-Architekt anteilig, externe Spezialisten für begrenzte Phasen.
6. Integrieren Sie KI in bestehende Systeme. Keine isolierten KI-Portale, wenn Nutzer im ERP, CRM, MES, CPQ oder Ticketsystem arbeiten. KI muss dort auftauchen, wo die Arbeit sowieso passiert.
7. Berichten Sie quartalsweise über produktive KI-Anwendungen, nicht über PoCs. Zeigen Sie Business-Impact, Nutzerquote, Kosten, offene Risiken. Der CFO sollte die Tabelle verstehen, ohne „Embedding“ googeln zu müssen.

Amplifa Produkt — KI-gestützte Vertriebsautomatisierung für B2B-Teams, die Lead-Generierung, ICP-Schärfung und Outreach nicht als Bastelprojekt aufsetzen wollen.

Governance: Wer entscheidet, wer haftet, wer stoppt?

KI-Governance klingt nach Konzern. Stimmt nicht ganz. Gerade der Mittelstand braucht sie, weil die Wege kurz sind und Fehler schnell persönlich werden. Wenn eine KI falsche Qualitätsfreigaben empfiehlt, landet das Thema nicht in einem anonymen Risikoausschuss. Es landet bei Sabine in der QS, bei Thomas im Engineering und beim Geschäftsführer, wenn der Kunde reklamiert.

Eine brauchbare Governance für 50 bis 500 Mitarbeiter muss nicht dick sein. Sie braucht vier Rollen: Business Owner, Product Owner, technischer Verantwortlicher, Risiko- oder Compliance-Prüfer. Der Business Owner verantwortet den Nutzen. Der Product Owner verantwortet Nutzung und Roadmap. Die Technik hält Betrieb, Sicherheit und Datenfluss sauber. Compliance prüft Datenschutz, Betriebsratsthemen, EU-AI-Act-Relevanz und Auditfähigkeit. Vier Namen. Nicht „die IT“.

Der EU AI Act wird ab 2025 und 2026 stufenweise spürbarer, besonders bei Hochrisiko-Anwendungen. Viele mittelständische Use Cases fallen nicht in die höchste Risikoklasse, aber Dokumentation, Transparenz und Verantwortlichkeit werden wichtiger. Wer heute eine KI in Qualitätsentscheidungen, Personalprozessen oder sicherheitsnahen Produktionsschritten einführt, sollte nicht warten, bis der Auditor im Foyer steht.

Governance entscheidet auch Build vs. Buy. Bei Buy müssen Sie den Anbieter prüfen: Datenverarbeitung, Modelltransparenz, Hosting, Löschkonzepte, Zugriff, Audit-Logs. Bei Build müssen Sie all das selbst können. Ehrlich? Viele 200-Mann-Firmen können es nicht. Das ist kein Vorwurf. Es ist ein Entscheidungskriterium.

Technikstack: Was Mittelständler wirklich brauchen

Wenn Build oder Hybrid sinnvoll ist, braucht man keinen Technikzoo. Ich sehe zu oft Architekturbilder mit Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes und fünf weiteren Logos, obwohl das Unternehmen noch CSV-Dateien aus dem ERP per Mail verschickt. Das ist nicht Strategie. Das ist Logo-Sammeln.

Für viele Mittelständler reicht ein klarer Stack: zentrale Datenablage oder Lakehouse, stabile Schnittstellen zu ERP/CRM/MES, ein MLOps-Werkzeug für Modellversionierung und Monitoring, Rechtekonzept, Reporting. Azure ist im DACH-Mittelstand stark, oft wegen Microsoft-365-Verträgen und bestehender IT-Kompetenz. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core oder Siemens Industrial Edge können passen. Die Frage ist nicht, welches Logo moderner klingt. Die Frage ist, wer es betreibt.

Open Source ist kein Gratisessen. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — alles gute Werkzeuge. Aber jemand muss Abhängigkeiten pflegen, Sicherheitsupdates prüfen, Modelle überwachen, Drift erkennen, Pipelines reparieren. In einer Spätschicht interessiert niemanden, ob der Fehler aus dem Feature Store oder aus der SPS-Schnittstelle kommt. Die Linie steht.

Bei Buy/Configure sieht der Stack anders aus. Siemens Industrial Edge oder Insights Hub für industrielle Daten, PTC ThingWorx für IoT-nahe Szenarien, SAP AI Core und Joule im ERP-Umfeld, Microsoft Dynamics 365 mit Copilot für CRM-Prozesse, Celonis für Process Mining, o9 oder SAS für Planung, Cognex oder Landing AI für Vision. Diese Produkte lösen nicht jedes Problem, aber sie geben Struktur. Für viele Mittelständler ist Struktur schon der halbe ROI.

Amplifa für KI-Vertriebsstrategie — Für mittelständische B2B-Unternehmen, die KI im Vertrieb produktiv nutzen wollen, ohne erst eine eigene Outreach- und Datenplattform zu bauen.

Change Management: Die Halle entscheidet mit

Im Dezember 2024 war ich bei einem Betrieb in der Nähe von Pforzheim. 160 Mitarbeiter, Präzisionsteile, viel Handarbeit in der Prüfung. Ein junger Projektleiter erklärte auf einem Monitor eine KI-gestützte Fehlererkennung. Neben mir stand ein Prüfer, vielleicht Ende fünfzig, die Hände schwarz an den Fingerrändern. Er sagte leise: „Wenn die Kiste falsch liegt, bin ich schuld.“ Das war der wichtigste Satz des Tages.

KI-Einführung scheitert selten nur an Technik. Sie scheitert an Verantwortung. Wenn Menschen glauben, dass die KI ihnen Arbeit wegnimmt, Fehler zuschiebt oder ihr Erfahrungswissen entwertet, nutzen sie sie nicht. Dann wird das System umgangen, Warnungen werden ignoriert, Daten werden schlecht gepflegt. Change Management heißt nicht, Plakate aufzuhängen. Es heißt, Rollen, Haftung und Nutzen sauber zu klären.

Bei Vision AI in der Qualitätssicherung muss klar sein: Gibt die KI frei oder empfiehlt sie? Wer entscheidet bei Grenzfällen? Wie werden falsche Negative behandelt? Wie fließt Feedback der Prüfer ins Modell? Bei Angebotsassistenz im Vertrieb muss klar sein: Darf die KI Preise vorschlagen? Wer prüft Rabatte? Welche Aussagen an Kunden sind tabu? Diese Fragen sind nicht Bremsen. Sie sind Betriebsvoraussetzungen.

Der Betriebsrat gehört früh dazu, nicht nach dem Pilot. Besonders bei KI in Leistungsmessung, Schichtplanung, HR oder Assistenzsystemen mit Nutzungsdaten. Ich kenne Firmen, die drei Monate verloren haben, weil sie glaubten, Beteiligung sei ein Formalakt. War sie nicht. Sie war der eigentliche Rollout.

Was ich 2026 erwarte: weniger PoC-Theater, mehr harte Auswahl

Meine Prognose ist kantig: Bis Ende 2026 werden viele Mittelständler ihre KI-Portfolios halbieren. Nicht, weil KI enttäuscht. Sondern weil die Projektlisten aus 2023 und 2024 zu breit, zu technisch und zu schlecht gerechnet waren. Der CFO wird fragen, welche Anwendungen produktiv laufen. Der Vertrieb wird fragen, warum der Angebotsassistent noch nicht im CRM ist. Die Produktion wird fragen, warum der Pilot nur auf Linie 3 funktioniert. Dann wird aussortiert.

Gleichzeitig werden die guten Firmen schneller. Sie werden keine 30 Use Cases verfolgen, sondern fünf. Sie werden Standardsoftware dort nehmen, wo sie reicht, und eigenes Know-how dort aufbauen, wo es weh tut, wenn der Wettbewerber es auch hat. Sie werden nicht „KI machen“. Sie werden Ausschuss senken, Angebote beschleunigen, Serviceumsätze erhöhen, Bestände reduzieren. Das ist ein anderer Ton.

SAP-CTO Jürgen Müller hat öffentlich mehrfach die Integration generativer KI in die Business Suite betont. Die Botschaft für den Mittelstand ist klar: Nicht jeder Kunde soll eigene Foundation Models bauen. Viele sollen KI konsumieren, einbetten, kontrollieren. Ich halte das für gesund. Wer 2026 noch glaubt, ein 250-Mann-Unternehmen müsse erst ein eigenes KI-Lab gründen, bevor es Nutzen sieht, verwechselt Mittelstand mit Forschungsinstitut.

Am Ende bleibt die Szene aus Gütersloh. Thomas, der CTO mit dem 1,2-Millionen-Euro-Plan, rief mich zwei Wochen nach unserem Gespräch an. Sie hatten die Plattformidee gestoppt, zwei Buy-Piloten gestartet und einen einzigen Hybrid-Use-Case für ihre Maschinenlogik behalten. „Fühlt sich weniger visionär an“, sagte er. Im Hintergrund hörte ich wieder den Stapler piepen. Vielleicht war genau das der Fortschritt.