KI-Eigenentwicklung versus Standardlösung: Die Make-or-Buy-Entscheidung im Mittelstand

6. Juli 2026

Artikel teilen

Die Entscheidung zwischen KI-Eigenentwicklung versus Standardlösung gehört zu den folgenreichsten, die Unternehmen bei der Einführung von künstlicher Intelligenz treffen müssen. Anders als bei klassischer Unternehmenssoftware, wo etablierte Beschaffungsprozesse greifen, stehen Geschäftsführer und IT-Verantwortliche bei KI-Projekten vor einem grundsätzlichen Dilemma: Standardlösungen versprechen schnelle Verfügbarkeit und kalkulierbare Kosten, während die Eigenentwicklung maximale Anpassbarkeit und potenzielle Wettbewerbsdifferenzierung bietet. Welcher Weg für ein mittelständisches Unternehmen der richtige ist, hängt nicht von Präferenzen ab, sondern von sechs messbaren Kriterien, die sich systematisch auswerten lassen. Wer diese Kriterien ignoriert und die Entscheidung aus dem Bauch heraus trifft, riskiert entweder millionenschwere Eigenentwicklungsprojekte, die nie in Produktion gehen, oder Standardlösungen, die mit den unternehmensspezifischen Datenstrukturen schlicht nicht kompatibel sind. Dieser Beitrag beschreibt, wie Entscheider den Vergleich strukturieren, welche Kosten auf beiden Wegen realistisch entstehen und welche Fehler sich bei der Umsetzung regelmäßig wiederholen.

Warum KI die klassische Make-or-Buy-Entscheidung verändert

In der Softwarebeschaffung gilt seit Jahrzehnten die Faustregel: Standardprozesse kaufen, Kernprozesse entwickeln. Bei künstlicher Intelligenz greift diese Heuristik nur teilweise. KI-Modelle sind keine abgeschlossenen Funktionsbausteine, die man konfiguriert und einschaltet. Sie erfordern Trainingsdaten, Integrationsschichten, kontinuierliche Pflege und ein Verständnis für modellspezifische Fehlerquellen.

Gleichzeitig hat sich das Angebot an KI-Plattformen und Standardlösungen in den vergangenen Jahren erheblich verbreitert. Für häufig nachgefragte Anwendungsfälle, etwa automatische Dokumentenklassifikation, Absatzprognosen oder E-Mail-Kategorisierung, existieren fertige Produkte, die ohne Data-Science-Expertise betrieben werden können. Der Markt teilt sich grob in KI-Fertigprodukte (SaaS), KI-Plattformen mit Low-Code-Funktionen und branchenspezifische KI-Module in bestehenden ERP- oder CRM-Systemen.

Dennoch ist die Entscheidung komplexer als bei herkömmlicher Unternehmenssoftware. Der Grund: KI-Lösungen sind nur so gut wie die Daten, auf denen sie basieren. Ob ein Standardprodukt mit den internen Datensätzen eines Unternehmens zuverlässig arbeitet, zeigt sich erst im Praxistest. Eigenentwicklungen dagegen können auf unternehmensspezifische Datenstrukturen zugeschnitten werden, binden aber erhebliche Ressourcen. Hinzu kommt, dass KI-Projekte anders als klassische Software-Projekte iterativ verlaufen: Die erste Version eines Modells liefert selten die Zielqualität. Das bedeutet mehr Ungewissheit in der Budgetplanung.

Eigenentwicklung: Stärken, Schwächen und realistische Voraussetzungen

Eine KI-Eigenentwicklung bietet maximale Kontrolle über Modellarchitektur, Trainingsdaten und Weiterentwicklung. Für Unternehmen mit hochspezifischen Anforderungen und ausreichend Datenbasis ist dieser Weg grundsätzlich sinnvoll. Typische Szenarien sind industrielle Qualitätsprüfung mit proprietären Bilddatensätzen, prädiktive Wartungsmodelle auf maschinenspezifischen Sensordaten oder Kreditrisikomodelle mit unternehmensinternen Historien.

Die realistischen Voraussetzungen für eine Eigenentwicklung sind allerdings anspruchsvoller als oft angenommen:

Datenbasis: Für überwachtes Lernen werden in der Regel mehrere Tausend gelabelte Datenpunkte benötigt. Viele mittelständische Unternehmen unterschätzen den Aufwand für Datenaufbereitung und Qualitätssicherung, der erfahrungsgemäß 20 bis 40 Prozent des gesamten Projektaufwands ausmacht.
Fachkompetenz: Eigenentwicklung erfordert Data Scientists oder ML-Engineers. In vielen Unternehmen fehlen diese Rollen; externes Know-how ist teuer und oft schwer zu binden. Ohne interne Kompetenz entsteht eine dauerhafte Abhängigkeit vom externen Dienstleister.
Infrastruktur: Training und Betrieb von KI-Modellen erfordern geeignete Recheninfrastruktur, sei es on-premise mit leistungsstarken GPUs oder Cloud-Ressourcen mit entsprechenden Datenschutzvereinbarungen.
Langfristige Pflege (MLOps): KI-Modelle unterliegen dem sogenannten Model Drift. Wenn sich die Datenlage verändert, nimmt die Modellgenauigkeit ab. Das erfordert kontinuierliches Monitoring, Qualitätsmetriken und regelmäßiges Re-Training. Ohne eine MLOps-Strategie verkommt die Eigenentwicklung zum technischen Schuldenberg.

„Die häufigste Fehleinschätzung bei KI-Eigenentwicklungen ist, dass Unternehmen die initiale Entwicklung als einmaligen Aufwand betrachten. In der Realität sind laufende Modellpflege und Datenqualitätssicherung der größte Kostentreiber.“ (Typische Erfahrung aus mittelständischen KI-Projekten)

Standardlösungen und KI-Plattformen: Kategorien und Auswahlkriterien

Der Markt für KI-Standardlösungen hat sich in drei Hauptkategorien entwickelt, die sich in Anpassungstiefe, Betriebsaufwand und Investitionshöhe unterscheiden:

Kategorie	Typischer Anwendungsfall	Anpassungstiefe	Eignung Mittelstand
KI-Fertigprodukte (SaaS)	Automatische Rechnungsverarbeitung, Kundenservice-Chatbots	Gering (Konfiguration)	Hoch bei standardisierbaren Prozessen
KI-Plattformen (Low-Code/AutoML)	Absatzprognosen, Anomalieerkennung, Klassifikation	Mittel (Daten einbringen, Modell trainieren)	Mittel, erfordert Datenkompetenz intern
KI-Module in ERP/CRM	Nachfrageplanung, Lead-Scoring, Churn-Prognose	Systemgebunden	Hoch bei vorhandenem Kernsystem

Wichtig bei der Evaluierung von Standardlösungen: Anbieter sollten in der Lage sein, Modellgenauigkeiten auf Referenzdaten aus der eigenen Branche nachzuweisen. Marketing-Versprechen über Trefferquoten sind ohne branchenspezifische Validierungsdaten wertlos. Außerdem ist die Datenschutzkonformität zu prüfen: Werden Daten in der EU verarbeitet? Welche Verarbeitungsverträge gemäß DSGVO Art. 28 liegen vor? Und was passiert mit den Daten nach Vertragsende?

Sechs Kriterien für den systematischen Entscheidungsvergleich

Für die Make-or-Buy-Entscheidung bei KI-Projekten hat sich ein strukturierter Kriterienkatalog bewährt. Jedes Kriterium wird auf einer Skala bewertet; das Ergebnis zeigt die Tendenz, ersetzt aber keine Vollkostenrechnung:

Datensouveränität: Wie hoch ist das Risiko, wenn ein Anbieter auf proprietäre Unternehmensdaten zugreift? Bei kritischen Geschäftsdaten oder Betriebsgeheimnissen spricht das für Eigenentwicklung oder On-Premise-Betrieb. Wer die Kontrolle über seine Trainingsdaten verliert, verliert potenziell auch den Wettbewerbsvorteil, den die Daten begründen.
Wettbewerbsdifferenzierung: Ist der Anwendungsfall strategisch differenzierend oder handelt es sich um einen Standardprozess, den viele Unternehmen in ähnlicher Form betreiben? Standardprozesse sollten in der Regel zugekauft werden. Differenzierende Kernprozesse können eine Eigenentwicklung rechtfertigen.
Interne Datenbasis: Sind ausreichend qualitativ hochwertige, strukturierte Daten vorhanden? Ohne fundierte Datenbasis scheitert die Eigenentwicklung häufig. Dieser Faktor ist oft der entscheidende Treiber in Richtung Standardlösung.
Verfügbare Kompetenz: Welche KI-Kompetenz ist intern vorhanden oder realistisch aufbaubar? Die Antwort muss ehrlich sein. Wer externe Dienstleister einplant, muss Abhängigkeit und Wissenstransfer von Beginn an vertraglich sichern.
Time-to-Value: Wie schnell wird eine funktionsfähige Lösung benötigt? Eigenentwicklungen brauchen in der Regel sechs bis achtzehn Monate bis zur Produktionsreife. Standardlösungen können in Wochen bis wenigen Monaten live gehen.
Vollkostenvergleich über fünf Jahre: Inklusive laufender Pflege, Infrastruktur, Lizenzkostensteigerungen und Vendor-Lock-in-Risiko (Details im folgenden Abschnitt).

Kosten und Zeitaufwand: Was Budgetverantwortliche einkalkulieren müssen

Ein verlässlicher Kostenvergleich zwischen Eigenentwicklung und Standardlösung erfordert eine Vollkostenbetrachtung über mindestens drei bis fünf Jahre. Einmalige Investitionen sagen wenig, wenn die laufenden Betriebskosten systematisch unterschätzt werden.

Eigenentwicklung (mittlere Komplexität, typische Größenordnung):

Datenvorbereitung und Datenbereinigung: 20 bis 35 Prozent des Gesamtaufwands
Modellentwicklung, Training und Validierung: 30 bis 40 Prozent
Integration, Deployment und Systemanbindung: 20 bis 25 Prozent
Jährliche Pflege und Re-Training: erfahrungsgemäß 15 bis 30 Prozent der Initialkosten, dauerhaft
Monitoring-Infrastruktur: laufende Cloud- oder Hardware-Kosten

Standardlösung (SaaS, mittlerer Anwendungsfall):

Lizenzkosten: nutzungsabhängig oder als Jahrespauschale, oft mit jährlichen Preissteigerungen in der Vertragslaufzeit
Implementierung und Konfiguration: einmalig, erheblich geringer als Eigenentwicklung, typisch 10 bis 30 Prozent des Jahreslizenzwerts
Datenmigration und initiale Datenkuration: einmalig, abhängig von Qualität der internen Daten
Vendor-Lock-in-Risiko: bei Preiserhöhung oder Produktabkündigung entstehen Migrationskosten

In der Praxis erweisen sich Standardlösungen für Anwendungsfälle mit geringer Differenzierungsrelevanz über drei bis fünf Jahre fast immer als wirtschaftlicher. Die Eigenentwicklung lohnt sich, wenn die KI-Lösung zur strategischen Kernkompetenz werden soll und interne Kompetenz dauerhaft aufgebaut und gehalten werden kann.

Hybride Ansätze: Eigenentwicklung und Standardlösung kombinieren

Die Entscheidung muss nicht immer ein klares Entweder-oder sein. In der Praxis kombinieren viele mittelständische Unternehmen beide Ansätze, indem sie für standardisierbare Teilprozesse Fertigprodukte einsetzen und für hochspezifische Kernfunktionen eigene Modelle trainieren.

Ein typisches Beispiel: Ein Fertigungsunternehmen nutzt ein SaaS-Produkt für die automatische Eingangsrechnungsverarbeitung (standardisierter Prozess mit hohem Anbieterangebot) und entwickelt gleichzeitig ein proprietäres Modell zur Qualitätskontrolle auf Basis eigener Produktionsdaten (differenzierender Kernprozess mit einzigartiger Datenbasis).

Hybride Ansätze erfordern allerdings klare Architekturentscheidungen: Wie kommunizieren Eigenentwicklungen und Standardlösungen? Wie werden Datenpipelines integriert? Wer verantwortet die Gesamtarchitektur? Ohne ein durchgängiges technisches Konzept entstehen Datensilos und Schnittstellenprobleme, die den Effizienzgewinn wieder aufzehren. Eine Architekturverantwortung auf technischer Führungsebene (CTO, IT-Leiter) ist daher bei hybriden KI-Strategien besonders wichtig. Ein regelmäßiges Architecture-Review, in dem die Gesamtstrategie überprüft und neue Angebote am Markt bewertet werden, verhindert außerdem, dass das Unternehmen über Jahre an veralteten Eigenentwicklungen festhält, obwohl längst ausgereifte Standardlösungen am Markt verfügbar sind.

Typische Umsetzungsfehler und wie man sie vermeidet

Unabhängig vom gewählten Ansatz gibt es wiederkehrende Fehler, die KI-Projekte im Mittelstand scheitern lassen.

Bei Eigenentwicklungen unterschätzen Unternehmen regelmäßig den Datenhunger moderner KI-Systeme sowie den Aufwand für das Label-Engineering, also das strukturierte Annotieren der Trainingsdaten. Ein weiteres typisches Muster: Das Unternehmen entwickelt ein Modell, vernachlässigt aber den produktiven Betrieb. Ein Modell, das in der Entwicklungsumgebung funktioniert, muss in Produktionssysteme eingebettet, überwacht und bei Abweichungen nachtrainiert werden. Wer keine MLOps-Strategie hat, sitzt nach der Abnahme auf einem System, das langsam schlechter wird, ohne dass es jemand bemerkt.

Bei Standardlösungen ist der häufigste Fehler die fehlende Pilotphase. Wer eine Lösung ohne Proof-of-Concept auf Basis eigener Daten kauft, kauft eine Blackbox. Außerdem werden Datenhoheitsregelungen mit dem Anbieter oft nicht sorgfältig geprüft. Auch die Annahme, dass eine Standardlösung ohne jede interne Kompetenz betrieben werden kann, ist riskant: Das Unternehmen braucht ausreichend internes Verständnis, um Qualitätsprobleme zu erkennen, Modellentscheidungen zu hinterfragen und Weiterentwicklungsbedarf zu artikulieren.

Auf beiden Wegen gilt: Der größte Erfolgsfaktor ist nicht die Technologiewahl, sondern ein klar definierter Anwendungsfall mit messbarem Geschäftsnutzen, einer realistischen Datenstrategie und einem Sponsor auf Leitungsebene, der das Projekt dauerhaft verantwortet.

Ein weiterer Punkt, der regelmäßig unterschätzt wird: Die Integration in bestehende Systemlandschaften. KI-Lösungen, die nicht sauber an ERP, CRM oder Produktionssysteme angebunden sind, erzeugen Medienbrüche und manuelle Nacharbeit, die den Effizienzgewinn konterkarieren. Bei Standardlösungen muss die Integrationstiefe bereits in der Evaluierungsphase überprüft werden, idealerweise mit einem technischen Proof-of-Concept in der eigenen Systemlandschaft. Bei Eigenentwicklungen ist die Schnittstellenarchitektur von Beginn an Teil des Projektdesigns. Wer diese Integration nachträglich ergänzt, zahlt meist das Doppelte.

Interne Kommunikation und Akzeptanz: Warum der menschliche Faktor entscheidet

Technologische und wirtschaftliche Faktoren bestimmen, ob ein KI-Projekt umsetzbar ist. Ob es tatsächlich den erhofften Mehrwert liefert, entscheidet sich dagegen auf der Ebene der internen Akzeptanz. In vielen mittelständischen Unternehmen scheitern KI-Projekte nicht an der Technologie, sondern daran, dass die betroffenen Mitarbeitenden die neue Lösung nicht nutzen, ihr misstrauen oder aktiv umgehen.

Die häufigste Ursache: Mitarbeitende wurden zu spät oder gar nicht in die Projektplanung einbezogen. KI-Lösungen, die Aufgaben automatisieren oder Entscheidungsunterstützung liefern, verändern Arbeitsrollen. Das löst Unsicherheit aus, die ohne Kommunikation in Widerstand umschlägt.

Ein praxisbewährtes Vorgehen für die interne Kommunikation folgt drei Phasen:

Frühzeitige Einbindung: Betroffene Mitarbeitende und Führungskräfte werden bereits in der Anforderungsphase einbezogen, nicht erst bei der Einführung. Ihre Erfahrung mit dem bestehenden Prozess ist eine wertvolle Informationsquelle und schafft Identifikation mit dem Projekt.
Transparente Kommunikation der Veränderungen: Klare Antworten auf die Fragen, welche Aufgaben sich verändern, welche Kompetenzen künftig wichtiger werden und was die Lösung nicht kann, bauen Vertrauen auf. Kommunikationslücken werden durch Gerüchte gefüllt, die regelmäßig negativer sind als die Realität.
Pilotphase mit Superusern: Die Einführung über eine kleine Gruppe technologieaffiner Mitarbeitender (Superuser oder Change Agents) ermöglicht es, Feedback früh zu integrieren, die Lösung vor dem Rollout zu verfeinern und interne Multiplikatoren aufzubauen, die Kollegen schulen und unterstützen.

Auch bei einer Standardlösung gilt: Ein gut kommuniziertes KI-Projekt mit mittelmäßiger Technologie übertrifft in der Praxis häufig ein technisch überlegenes Projekt, das intern niemand versteht oder nutzen will. Akzeptanzmanagement ist kein Nice-to-have, sondern ein Erfolgsfaktor, der gleichwertig neben Technologiewahl und Datenstrategie steht.

Praktisch empfehlenswert ist ein regelmäßiges Feedback-Format nach dem Go-live: monatliche Kurzumfragen bei den Hauptnutzern über Qualitätsprobleme, Funktionswünsche und Zufriedenheit. Diese Rückmeldungen fließen direkt in die Pflegeroadmap ein und signalisieren den Mitarbeitenden, dass ihre Erfahrungen zählen. Das stärkt die Nutzungsbereitschaft und liefert gleichzeitig wertvolle Hinweise für die Weiterentwicklung.

FAQ

Wann ist eine KI-Eigenentwicklung für den Mittelstand sinnvoll?
Wenn der Anwendungsfall strategisch differenzierend ist, ausreichend proprietäre und qualitativ hochwertige Daten vorhanden sind, interne oder dauerhaft gebundene externe KI-Kompetenz gehalten werden kann und Datensouveränität eine kritische Anforderung ist.

Was kostet ein typisches KI-Projekt im Mittelstand?
Die Spannbreite ist groß. Einfache Automatisierungslösungen auf Basis von Standardplattformen beginnen bei wenigen Zehntausend Euro Gesamtaufwand. Maßgeschneiderte Eigenentwicklungen für komplexe Prognose- oder Erkennungsmodelle können im mittelständischen Kontext sechs- bis siebenstellige Gesamtkosten erreichen, wenn Datenaufbereitung, Entwicklung, Integration und mehrjährige Pflege zusammengerechnet werden.

Was bedeutet Model Drift und warum ist er relevant?
Model Drift bezeichnet die schleichende Verschlechterung der Modellleistung, weil sich die reale Datenlage verändert, das Modell aber auf historischen Daten trainiert wurde. Ohne Monitoring und regelmäßiges Re-Training können auch initial gut funktionierende Modelle innerhalb von Monaten unzuverlässig werden. Das ist eines der häufigsten Probleme bei KI-Projekten ohne MLOps-Strategie.

Wie sollte die Evaluierung einer KI-Standardlösung ablaufen?
In fünf Schritten: Anforderungen präzise definieren, Marktübersicht erstellen, Shortlist auf drei bis fünf Anbieter reduzieren, Proof-of-Concept mit eigenen Daten durchführen, Vollkostenvergleich inklusive Implementierung und fünfjähriger Betriebskosten berechnen. Ohne den Proof-of-Concept mit echten Unternehmensdaten ist jede Kaufentscheidung ein Blindflug.

Kann ein mittelständisches Unternehmen KI ohne Data Scientists betreiben?
Für SaaS-Fertigprodukte mit klar definierten Anwendungsfällen und geringen Anpassungsanforderungen ist das möglich. Low-Code-Plattformen erfordern zumindest eine Person mit Datenkompetenz und Verständnis für Modellqualität. Reine Eigenentwicklungen ohne Data-Science-Kompetenz im Team sind kaum realisierbar.