Make vs. Buy — selbst bauen oder einkaufen?

Die falsche Frage

"Sollen wir KI selbst bauen oder kaufen?" ist oft die erste Frage, die in KI-Gesprächen aufkommt. Sie ist meistens verfrüht. Erst wenn der Use-Case geklärt ist (Lektion 1), der Pilot gelaufen ist (Lektion 2) und die Datenlage geprüft ist, kann die Make-vs-Buy-Entscheidung sinnvoll getroffen werden.

In dieser Lektion lernen Sie, welche Kriterien wirklich zählen, welche Muster sich bewährt haben und wann eine Mischstrategie die beste Antwort ist.

Die drei Schichten, die man unterscheiden muss

Eine KI-Anwendung besteht aus drei Schichten. Die Make-vs-Buy-Entscheidung fällt auf jeder Schicht anders.

Schicht 1: Das Modell (LLM). Praktisch niemand baut heute eigene Sprachmodelle. Selbst große Konzerne nutzen Claude, GPT, Gemini oder Open-Source-Modelle wie Llama oder Mistral. "Make" auf dieser Ebene bedeutet im Mittelstand immer: ein fertiges Modell einsetzen — maximal über eigene Infrastruktur hosten.

Schicht 2: Die Anwendungslogik. Der Prompt, die RAG-Pipeline, die Integrationen in bestehende Systeme, die fachspezifische Logik. Hier liegt der Differenzierungsspielraum. Make oder Buy wird hier tatsächlich entschieden.

Schicht 3: Die Nutzeroberfläche. Chat-Interface, Admin-Bereich, Auswertungen. Meistens lohnt es sich, auf Standard-Bausteine zu setzen und nur dort selbst zu gestalten, wo der Prozess es erfordert.

Wann Make die richtige Entscheidung ist

Vier Signale sprechen für Eigenentwicklung:

• Kerndifferenzierung. Der Use-Case betrifft ein Feld, in dem Sie sich vom Wettbewerb absetzen — Ihre Beratungsmethodik, Ihre Entscheidungslogik, Ihre Expertise in einem Nischenmarkt.
• Eigene Datenschätze. Sie haben Daten, die Wettbewerber nicht haben: historische Vorgänge, Kundenprofile, technische Details. Diese Daten im Einsatz bringen einen Vorteil.
• Tiefe Integration in eigene Systeme. Die Lösung muss in bestehende Prozesse, ERP-Systeme, eigene Tools eingebettet sein. Standardprodukte stoßen hier oft an Grenzen.
• Kontrolle über Roadmap und IP. Sie wollen selbst bestimmen, was wie funktioniert, und Abhängigkeiten vermeiden.

Make heißt übrigens nicht "komplett von null". Heute bauen Mittelständler Lösungen meistens auf fertigen Bausteinen: ein LLM-Anbieter, eine Vektor-Datenbank, ein Framework. Der Eigenanteil liegt in der Anwendungslogik und der Integration.

Wann Buy die richtige Entscheidung ist

Drei Signale sprechen für Einkauf:

• Kommoditisierter Use-Case. Standard-E-Mail-Klassifikation, generischer Übersetzer, allgemeine Rechnungsextraktion. Diese Felder haben etablierte Anbieter mit ausgereiften Lösungen — eine Eigenentwicklung lohnt sich selten.
• Schneller Markteintritt. Sie brauchen eine Lösung in 4 bis 8 Wochen, nicht in 6 Monaten. Buy ist schneller.
• Fehlende interne Kapazität. Sie haben keine internen Entwickler oder KI-Spezialisten, und der Aufbau solcher Kapazität steht nicht auf Ihrer Roadmap. Die Buy-Variante ist dann nicht nur schneller, sondern auch nachhaltiger.

Der häufigste Fehler bei Buy: Die Software wird gekauft, bevor der Use-Case wirklich verstanden ist. Ergebnis sind Regallizenzen — Tools, die keiner nutzt.

Die Mischform: Buy + Custom

In der Praxis läuft ein großer Teil der KI-Projekte im Mittelstand als Mischform:

• Der LLM-Anbieter wird gekauft (Claude, GPT, Gemini über API).
• Das RAG-Framework wird als Standard übernommen (z. B. LangChain, LlamaIndex, hauseigene Baukästen von Microsoft oder Google).
• Die Vektor-Datenbank wird gekauft oder open-source installiert (pgvector, Qdrant).
• Die Anwendungslogik wird selbst entwickelt oder mit einem Partner umgesetzt.
• Die Oberfläche kommt aus einem Standard-Framework oder als White-Label-Komponente.

Diese Kombination aus Standardbausteinen und fachspezifischer Eigenentwicklung hält die Kosten in Grenzen und erlaubt trotzdem echte Differenzierung.

Drei Kriterien, die die Entscheidung erleichtern

Wenn Sie unsicher sind, hilft oft ein ehrlicher Blick auf drei Punkte:

Zeit bis zum Nutzen. Wie schnell muss die Lösung im Einsatz sein? Buy gewinnt bei kurzen Horizonten, Make bei langfristigen Vorhaben.

Total Cost of Ownership. Buy-Lösungen sind oft günstiger in der Einführung, aber teurer im langfristigen Lizenzmodell. Make hat höhere Anfangskosten, niedrigere Betriebskosten — wenn die Lösung stabil läuft.

Risikoprofil. Eine gekaufte Lösung verlagert Risiken auf den Anbieter, bringt aber Abhängigkeiten. Eine Eigenentwicklung erhöht das Umsetzungsrisiko, gibt aber Kontrolle. Welches Risiko Sie lieber tragen, ist eine strategische, keine technische Frage.

Der externe Partner als dritter Weg

Neben Make und Buy gibt es die externe Umsetzung: Ein spezialisierter Partner baut die Lösung auf Ihrer Infrastruktur, mit Ihren Daten, nach Ihren Anforderungen. Das ist weder Make noch reines Buy, sondern ein hybrider Weg — in Kurz: "Make-as-a-Service".

Sinnvoll ist dieser Weg, wenn:

• der Use-Case differenzierend ist, aber intern keine Entwicklerteams verfügbar sind.
• eine schnelle Umsetzung ohne Aufbau einer eigenen KI-Abteilung nötig ist.
• Sie langfristig die Lösung in eigenen Betrieb übernehmen wollen, aber für den Start Expertise brauchen.

Was Sie aus dieser Lektion mitnehmen

Make-vs-Buy ist selten schwarz-weiß. Die Kernfrage ist: Welcher Teil der Lösung ist differenzierend, und welcher ist kommoditisiert? Standard-Bausteine sollten fast immer gekauft werden, fachspezifische Logik eher selbst umgesetzt — intern oder mit einem spezialisierten Partner. Im nächsten Kapitel geht es um Budget, Scope und Zeitplanung.