KI selbst bauen oder kaufen? Die Make-or-Buy-Entscheidung.

Sobald ein Unternehmen einen sinnvollen KI-Anwendungsfall gefunden hat, stellt sich die nächste grundlegende Frage: Kaufen wir eine fertige Lösung, bauen wir selbst, oder etwas dazwischen? Diese Make-or-Buy-Entscheidung wird oft aus dem Bauch heraus getroffen — mal aus Begeisterung für die eigene Entwicklung, mal aus Bequemlichkeit für das fertige Produkt. Beides kann teuer enden. Eine saubere Entscheidung folgt klaren Kriterien, nicht der ersten Sympathie.

Die drei Wege im Überblick.

In der Praxis gibt es nicht nur zwei, sondern drei grundsätzliche Wege, und der mittlere wird am häufigsten übersehen:

1. Kaufen (Buy): Eine fertige Standardlösung oder ein spezialisiertes Produkt, das den Anwendungsfall direkt abdeckt — etwa ein KI-Chatbot-Produkt, ein Übersetzungsdienst oder eine fertige Dokumentenlösung.
2. Zusammensetzen (Assemble): Bestehende Bausteine — ein Sprachmodell über eine Cloud-API, eine Vektordatenbank, Automatisierungs-Werkzeuge — werden zu einer maßgeschneiderten Lösung kombiniert, ohne das Modell selbst zu entwickeln.
3. Bauen (Make): Eigenentwicklung in der Tiefe — bis hin zum Betrieb oder zur Feinabstimmung eigener Modelle.

Der mittlere Weg ist für die meisten Unternehmen der realistischste. Niemand muss heute ein eigenes Sprachmodell trainieren, um eine maßgeschneiderte Lösung zu bekommen — die starken Modelle gibt es als Dienst, und der Wert entsteht in der klugen Kombination und Anbindung.

Wann Kaufen die richtige Wahl ist.

Eine fertige Lösung ist immer dann erste Wahl, wenn der Anwendungsfall ein verbreitetes Standardproblem ist, das viele Unternehmen ähnlich haben. Übersetzungen, allgemeine Texterstellung, einfache Chatbots, gängige Dokumentenverarbeitung — hier haben spezialisierte Anbieter bereits ausgereifte Produkte, in die viel Entwicklungsarbeit geflossen ist. Das selbst nachzubauen wäre Verschwendung.

Die Vorteile liegen auf der Hand: schneller Start, kein eigener Entwicklungsaufwand, laufende Pflege durch den Anbieter, klar kalkulierbare Kosten. Der Preis dafür ist weniger Kontrolle, Abhängigkeit vom Anbieter und Grenzen bei der Anpassung. Wenn das Produkt zu achtzig Prozent passt und die fehlenden zwanzig Prozent nicht geschäftskritisch sind, ist Kaufen meist der klügere Weg.

Wann Zusammensetzen Sinn ergibt.

Sobald der Anwendungsfall spezifisch für das eigene Unternehmen ist — eigene Daten, eigene Prozesse, eigene Systemlandschaft — stoßen Standardprodukte an Grenzen. Dann ist das Zusammensetzen aus Bausteinen der richtige Weg: ein leistungsfähiges Sprachmodell über eine API, angebunden an die eigenen Daten und Systeme, eingebettet in die eigenen Abläufe.

Dieser Weg verbindet das Beste aus beiden Welten: Man profitiert von der Qualität führender Modelle, ohne sie selbst entwickeln zu müssen, und behält gleichzeitig die Kontrolle über Logik, Daten und Integration. Der Aufwand liegt in der Entwicklung der Verbindung — also genau dort, wo der unternehmensspezifische Wert entsteht. Für die meisten ernsthaften Unternehmens-Use-Cases ist dies der tragfähigste Mittelweg.

Wann echte Eigenentwicklung gerechtfertigt ist.

Die tiefe Eigenentwicklung — eigene Modelle betreiben oder feinabstimmen — ist nur in bestimmten Situationen gerechtfertigt. Sie kostet erheblich mehr und braucht Kompetenz, die nicht jedes Unternehmen vorhalten kann oder will. Sinnvoll wird sie vor allem dann, wenn:

• Datenschutz oder Souveränität es erzwingen, dass keine Daten das Haus verlassen dürfen und auch keine Cloud-API mit Auftragsverarbeitung in Frage kommt.
• Sehr hohe Volumina dauerhaft anfallen, sodass laufende API-Kosten den Betrieb eines eigenen Modells wirtschaftlich übertreffen.
• Die KI selbst das Kernprodukt ist und damit eine strategische Eigenleistung, die man nicht aus der Hand geben will.
• Sehr spezielle Fachdomänen vorliegen, in denen allgemeine Modelle nachweislich nicht ausreichen.

Trifft keiner dieser Punkte zu, ist die tiefe Eigenentwicklung meist die teure und langsame Antwort auf eine Frage, die der Mittelweg günstiger und schneller löst.

Die Entscheidungskriterien im Vergleich.

Statt sich auf ein Bauchgefühl zu verlassen, hilft eine nüchterne Gegenüberstellung der drei Wege entlang der entscheidenden Kriterien:

Die Tabelle macht den typischen Zielkonflikt sichtbar: Wer schnell und günstig starten will, zahlt mit Kontrolle und Anpassbarkeit. Wer volle Kontrolle will, zahlt mit Zeit, Geld und Kompetenzbedarf. Der richtige Punkt auf diesem Spektrum hängt vom konkreten Anwendungsfall ab.

Die unterschätzte Frage: Abhängigkeit.

Ein Kriterium verdient besondere Aufmerksamkeit, weil es gern übersehen wird: die Abhängigkeit vom Anbieter, oft als Vendor-Lock-in bezeichnet. Wer eine fertige Lösung kauft, bindet sich an deren Preise, deren Weiterentwicklung und deren Fortbestand. Ändert der Anbieter sein Preismodell, stellt ein Produkt ein oder verschlechtert die Qualität, hat man wenig Handhabe.

Beim Zusammensetzen lässt sich dieses Risiko mildern: Wenn die eigene Logik und Daten getrennt vom Modell liegen und das Modell über eine austauschbare Schnittstelle angebunden ist, kann man den Anbieter im Zweifel wechseln. Diese Austauschbarkeit kostet etwas mehr Sorgfalt beim Aufbau — und ist eine der besten Versicherungen gegen unangenehme Überraschungen. Wer sich diese Flexibilität von Anfang an bewahrt, entscheidet später aus einer Position der Stärke.

Ein praktischer Entscheidungsweg.

Die Entscheidung lässt sich entlang weniger Fragen strukturieren, die man der Reihe nach durchgeht:

1. Ist das Problem ein verbreitetes Standardproblem? Wenn ja und es gibt ein ausgereiftes Produkt, das gut genug passt — kaufen.
2. Hängt der Wert an eigenen Daten und Prozessen? Wenn ja, führt meist kein Weg an einer maßgeschneiderten Lösung vorbei — zusammensetzen.
3. Gibt es zwingende Gründe gegen jede Cloud-Nutzung? Strikter Datenschutz, Souveränität, extreme Volumina — dann erst kommt echte Eigenentwicklung ins Spiel.
4. Habe ich die Kompetenz und den Willen für Betrieb und Pflege? Wer dauerhaft niemanden dafür hat, sollte Make ehrlich ausschließen.

Für die allermeisten Unternehmen landet dieser Weg beim Zusammensetzen — der Mittelweg, der Qualität und Kontrolle verbindet, ohne den vollen Aufwand der Eigenentwicklung zu tragen.

Der häufigste Fehler in beide Richtungen.

Zwei gegensätzliche Fehler sieht man immer wieder. Der eine ist Überengineering: Aus technischer Begeisterung wird etwas selbst gebaut, das es als ausgereiftes Produkt längst günstiger gibt. Das Ergebnis ist ein teures, schlechter gepflegtes Eigengewächs, das Ressourcen bindet, die anderswo fehlen.

Der andere Fehler ist die Scheinlösung von der Stange: Ein Standardprodukt wird gekauft, obwohl der eigentliche Wert an unternehmensspezifischen Daten und Prozessen hängt, die das Produkt nicht abbilden kann. Es wird benutzt, bringt aber nie den erhofften Nutzen, weil es das Kernproblem gar nicht trifft. Beide Fehler haben dieselbe Wurzel: Die Make-or-Buy-Frage wurde nicht entlang des konkreten Anwendungsfalls beantwortet, sondern entlang einer Vorliebe.

Was ich aus der Praxis mitgebe.

• Der Mittelweg wird unterschätzt. Bestehende Modelle klug zusammenzusetzen, ist für die meisten Use-Cases sinnvoller als Kaufen oder tiefes Selbstbauen.
• Niemand muss heute Modelle trainieren. Wer eine maßgeschneiderte Lösung will, bekommt sie über Anbindung — nicht über Eigenentwicklung von Grund auf.
• Austauschbarkeit einplanen. Logik und Daten getrennt vom Modell halten — das schützt vor Abhängigkeit und teuren Überraschungen.
• Entlang des Use-Cases entscheiden. Nicht aus Begeisterung selbst bauen und nicht aus Bequemlichkeit kaufen — sondern dem konkreten Bedarf folgen.

Sie stehen vor der Frage, ob Sie eine KI-Lösung kaufen, zusammensetzen oder selbst bauen sollen? Unverbindlich anfragen — wir bewerten Ihren Anwendungsfall entlang klarer Kriterien statt entlang von Vorlieben.