Eigenentwicklung oder Zukauf — die Make-or-Buy-Frage für KI-Produkte

Wer ein KI-Produkt verantwortet, steht am Tag eins vor einer Frage, die in keinem Modell-Benchmark steht: selbst bauen, zukaufen oder beides nebeneinander betreiben. Die Frage klingt nach Engineering, sie ist es aber nicht. Sie ist eine Frage der Rechnung über drei Jahre, der Verhandlungsposition gegenüber dem Anbieter und der Fähigkeit, einen Pilot nach sechs Wochen in eine Entscheidung zu überführen. Wer die Antwort aus der Modell-Diskussion ableitet, hat sie schon falsch. Wer den Kontext der Beschaffung ohne Lock-in noch nicht kennt, liest dort zuerst die Vertragsseite, die diese Frage begrenzt, und die Logik der Rechnung hinter einer KI-Investition, die hier vorausgesetzt wird.

Auf den Punkt

Wer die nächsten fünf Minuten nicht hat: Make-or-Buy ist eine Rechenfrage, keine Tool-Frage. Drei Achsen entscheiden — Total-Cost-of-Ownership über drei Jahre, Time-to-Market gegen den Wettbewerb und die Lock-in-Quote, die das Produkt am Modell-Anbieter hat. Wer alle drei Achsen sauber misst, sieht in den meisten Fällen, dass die Antwort hybrid lautet, nicht entweder/oder. Wer nur eine Achse misst, bekommt entweder einen schönen Pilot, der nie skaliert, oder einen Plattform-Deal, der sich bei der ersten Modell-Generation neu erfinden muss.

Glossar

Begriff

Eigenentwicklung

Bedeutung

Der Aufbau eines KI-Produkts auf offenen Modellen, eigener Infrastruktur und eigenem Fine-Tuning. Vorteil: volle Kontrolle über Daten, Modellwahl und Anbieterwechsel. Nachteil: Engineering-Overhead, der die ersten zwölf bis achtzehn Monate bindet, und eine Modell-Pflege, die nie endet.

Begriff

Zukauf

Bedeutung

Die Nutzung einer fertigen KI-Plattform oder eines Modell-Anbieters über API oder gehostete Anwendung. Vorteil: Time-to-Market in Wochen, nicht Monaten. Nachteil: Lock-in-Risiko, das im Vertrag steht und nicht in der Produkt-Demo.

Begriff

Hybridschnitt

Bedeutung

Die Kombination aus einer zugekauften Plattform für Standardaufgaben und einer eigenen Schicht für die domänenspezifische Logik. Vorteil: Time-to-Market des Zukaufs plus Verhandlungsposition der Eigenentwicklung. Nachteil: zwei Verträge, zwei Architekturen, eine Verantwortung.

Begriff

Total-Cost-of-Ownership (TCO)

Bedeutung

Die Summe aus Lizenz, Integration, Betrieb, Daten-Pflege, Review-Aufwand, Schulung und Wechselkosten über drei Jahre, nicht nur die Subscription. Wer TCO ernst nimmt, sieht, dass die Subscription typischerweise zwischen 25 und 40 Prozent der wahren Kosten ausmacht.

Begriff

Time-to-Market

Bedeutung

Die Zeit von der Produktidee bis zum zahlenden Kunden im Pilot. Bei KI-Produkten oft unterschätzt, weil die Modell-Reifezeit, Daten-Aufbereitung und Review-Schleife gemeinsam dauern, nicht parallel.

Begriff

Lock-in-Quote

Bedeutung

Der Anteil der Produktlogik, der bei einem Anbieterwechsel neu geschrieben werden müsste. Unter 20 Prozent ist ein günstiger Vertrag möglich, über 50 Prozent hat man einen Vermieter, nicht einen Lieferanten.

Drei Pfade und ihre Wahrheit

Eigenentwicklung, Zukauf und Hybridschnitt werden in den meisten Entscheidungen gegeneinander aufgewogen, als wären sie drei Produkte im Regal. Das sind sie nicht. Sie sind drei verschiedene Vertrags- und Architekturmodelle, und jeder hat eine eigene Rechnung.

Eigenentwicklung ist ehrlich, wenn das Produkt eine Kernkomponente hat, die das eigene Unternehmen vom Wettbewerb unterscheidet und die in keiner Standardplattform liegt. Sie ist unehrlich, wenn sie aus Bequemlichkeit gewählt wird, weil der CTO das Team führen will, das er hat, nicht das Team, das die Aufgabe verlangt. Wer sich für Eigenentwicklung entscheidet, verpflichtet sich auf eine Modell-Pflege, die mit jeder Modell-Generation neu beginnt. Fine-Tuning, das heute funktioniert, ist mit der nächsten Modellgeneration möglicherweise veraltet. Wer das ehrlich rechnet, sieht, dass ein selbstgebautes Modell nur dann günstiger ist als ein zugekauftes, wenn die Lock-in-Quote gegen null geht und das Team langfristig bleibt.

Zukauf ist ehrlich, wenn das Produkt in den ersten neun Monaten keinen Wettbewerbsvorteil aus der Modellwahl zieht und wenn die Use-Cases so generisch sind, dass eine Standardplattform sie abdeckt. Sie ist unehrlich, wenn der Anbieter mit Funktionen wirbt, die der Pilot erst in einem Jahr braucht, oder wenn der Vertrag so geschrieben ist, dass die Preise nach zwölf Monaten neu verhandelt werden, ohne dass der Kunde wechseln kann. Wer sich für Zukauf entscheidet, sollte denselben Vertrag lesen, den ein Beschaffungsprozess verlangt, und nicht den, den der Anbieter mitgebracht hat.

Hybridschnitt ist in den meisten Projekten, die ich in den letzten Monaten gesehen habe, die richtige Antwort. Er trennt das Produkt in eine Plattform-Schicht (Zukauf, Standard) und eine Domänenschicht (eigene Logik, eigener Datenraum). Die Plattform-Schicht ist ersetzbar, die Domänenschicht ist der Wettbewerbsvorteil. Wer diese Trennung konsequent zieht, hat 80% der Time-to-Market eines Zukaufs und 80% der Lock-in-Quote einer Eigenentwicklung — beides gleichzeitig, nicht im Trade-off.

Was der CFO wirklich rechnet

Der CFO fragt nicht nach Modell-Benchmarks, sondern nach einer Zahl, die in den nächsten drei Jahren im Finanz-Plan steht. Diese Zahl ist die Total-Cost-of-Ownership, und sie hat bei jedem Pfad eine andere Form.

Eigenentwicklung hat hohe Fixkosten am Anfang (Engineering, Infrastruktur, Daten-Pipeline) und niedrige variable Kosten pro Nutzer. Das ist klassische CapEx-Logik: wer das Volumen nicht erreicht, hat zu viel investiert. Wer das Volumen erreicht, hat mit der Zeit die günstigsten Stückkosten — aber nur, wenn das Team bleibt und das Modell nicht in eine Generationenfalle läuft.

Zukauf hat niedrige Fixkosten am Anfang und hohe variable Kosten, die mit der Nutzung skalieren. Das ist OpEx-Logik: wer das Volumen falsch schätzt, hat am Ende des Quartals eine Rechnung, die nicht im Plan steht. Token-Kosten, API-Overages und Review-Aufwand sind die drei Posten, die in der Subscription nicht sichtbar sind und die im Pitch verschwiegen werden.

Hybrid hat die Fixkosten einer Eigenentwicklung und die variablen Kosten eines Zukaufs. Das klingt nach dem schlechtesten aus beiden Welten, ist es aber nicht, wenn die Plattform-Schicht tatsächlich Standard ist und die Domänenschicht tatsächlich Wettbewerbsvorteil. Dann sind die Fixkosten halbiert (weil nicht das ganze Produkt selbst gebaut wird) und die variablen Kosten sind planbar (weil die Plattform-Schicht begrenzt ist).

Time-to-Market schlägt TCO

In der Theorie gewinnt die Eigenentwicklung, sobald das Volumen gross genug ist. In der Praxis gewinnt der Pfad, der den Markt am Tag X erreicht. Wer ein KI-Produkt sechs Monate später launchet als der Wettbewerb, hat in vielen Märkten den Markt verloren, unabhängig von der TCO-Rechnung. Time-to-Market ist deshalb die Achse, die in vielen Entscheidungen den Ausschlag gibt, nicht die TCO.

Die Frage ist, wie viel Time-to-Market jeder Pfad realistisch liefert. Die Antwort hängt weniger vom Pfad selbst ab als vom Reifegrad des Unternehmens, vom Datenzugang und von der Verfügbarkeit der Profile, die das Produkt tragen. Wer ein Datenteam hat, das in vier Wochen eine Pipeline bauen kann, hat in der Eigenentwicklung einen Vorteil, der in der TCO-Rechnung nicht steht. Wer kein solches Team hat, zahlt in der Eigenentwicklung die Wartezeit mit Zinsen.

Die Verhandlung mit dem Anbieter

Auch beim Zukauf ist Make-or-Buy nicht mit dem Vertragsabschluss entschieden. Die Vertragsklauseln, die in der Beschaffung ohne Lock-in beschrieben sind, gelten für jeden Pfad, der einen Anbieter enthält. Vier Klauseln, die auch beim Hybrid nicht verhandelbar sind, wenn man am Tag X wechseln können will:

Modell-Substitution. Die Klausel erlaubt, das im Vertrag genannte Modell jederzeit gegen ein gleichwertiges Modell desselben Anbieters oder eines Drittanbieters auszutauschen, ohne die Anwendung neu zertifizieren zu müssen. Ohne diese Klausel ist jeder Pfad, der den Anbieter enthält, ein Lock-in-Pfad.

Datenportabilität. Roh-Prompts zu exportieren ist trivial. Embeddings zu exportieren ist trivial. Beides ist wertlos ohne das Mapping-Dokument, das beschreibt, welche Embedding-Dimension, welche Distanzmetrik, welche Normalisierung. Wer diese Klausel im Vertrag hat, kann wechseln. Wer sie nicht hat, hat einen Migrationspunkt, der im Pilot unsichtbar ist.

Output-Persistenz. Speichert der Anbieter die Outputs? Wo und wie lange? Fliessen sie zurück in Trainingsdaten? Wer löscht was auf Verlangen? Wer diese drei Fragen nicht im Vertrag beantwortet hat, hat im ersten Audit eine Überraschung.

Exit-Kosten. Migration, Re-Zertifizierung, Schulung, verlorene Optimierungen. Wer diese Kosten nicht im Vertrag regelt, erfährt sie beim Wechsel als Projekt, nicht als Posten.

Wann der Pilot die Antwort gibt

In vielen Projekten ist die Make-or-Buy-Frage nicht am Schreibtisch entscheidbar, sondern im Pilot. Wer einen sechswöchigen Pilot mit klarer Exit-Option startet, kann am Ende dieser sechs Wochen eine informierte Entscheidung treffen. Wer den Pilot ohne Exit-Option startet, hat am Ende des Pilots eine Verhandlungsposition gegen den Anbieter, nicht gegen den Pfad.

Der Pilot beantwortet drei Fragen, die am Schreibtisch nicht beantwortbar sind: Wie viel Lock-in entsteht tatsächlich? Wie viel Engineering-Overhead fällt tatsächlich an? Wie viel Review-Aufwand kommt aus der tatsächlichen Nutzung? Wer den Pilot mit diesen drei Fragen als Endpunkte startet, hat am Ende eine Zahl, die in der TCO-Rechnung steht, und eine Position, die in der Verhandlung zählt.

Drei Fehler, die ich gesehen habe

Drei Fehler, die in den Make-or-Buy-Entscheidungen der letzten Monate immer wieder auftauchen. Sie sind vermeidbar, wenn man vorher weiss, dass sie kommen.

Fehler eins: Entscheidung gegen den Anbieter, nicht für einen Pfad. Wer einen Anbieter ablehnt, ohne den Pfad zu wählen, hat eine Verhandlung verloren, bevor sie begonnen hat. Wer einen Pfad wählt, ohne den Anbieter zu nennen, hat eine Architektur, die niemand verantwortet. Beide Fehler haben denselben Kern: die Verantwortung für die Entscheidung wird zwischen Engineering, Einkauf und Produkt aufgeteilt, und am Ende fühlt sich niemand zuständig.

Fehler zwei: TCO-Rechnung über ein Jahr. Wer die Rechnung über ein Jahr aufstellt, sieht den Subscription-Posten doppelt so gross wie er tatsächlich ist, und die Engineering-Posten halb so gross. Wer die Rechnung über drei Jahre aufstellt, sieht, dass die Subscription bei vielen Pfaden zwischen 25 und 40 Prozent der Gesamtkosten ausmacht, und dass der Rest Engineering, Daten-Pflege und Review-Aufwand ist, die im Pitch nie erwähnt werden.

Fehler drei: Hybridschnitt als Pfad ohne Verantwortung. Wer Hybrid wählt, ohne die Plattform-Schicht und die Domänenschicht explizit zu benennen, hat zwei Verträge und keine Architektur. Wer Hybrid wählt und die Trennung nicht durchsetzt, hat am Ende eine Anwendung, die weder austauschbar noch eigenständig ist — das Schlimmste aus beiden Welten.

Was am Ende zählt

Make-or-Buy ist eine Frage, die in der Mitte des Produkt-Lebenszyklus wieder auftaucht, nicht nur am Anfang. Wer sich heute für Zukauf entscheidet, sollte in zwölf Monaten prüfen, ob die Plattform-Schicht noch Standard ist oder ob die Domänenschicht soviel Wert generiert, dass eine Eigenentwicklung der Domäne günstiger wäre. Wer sich heute für Eigenentwicklung entscheidet, sollte in zwölf Monaten prüfen, ob die Plattform-Schicht, die das Team nebenbei mitgebaut hat, nicht selbst zum Produkt werden könnte.

Die Make-or-Buy-Frage hat keine endgültige Antwort. Sie hat eine Antwort, die zwölf Monate gilt, und dann eine neue Frage, die aus der ersten Antwort entstanden ist. Wer das versteht, versteht, warum die Verträge, die in Beschaffung ohne Lock-in beschrieben sind, nicht nur am Anfang zählen, sondern am Ende jedes Quartals neu verhandelt werden müssen. Und warum die Rechnung hinter einer KI-Investition nicht einmal aufgestellt und dann vergessen wird, sondern jährlich nachgezogen wird, mit den tatsächlichen Zahlen aus dem Pilot, nicht mit den Schätzungen aus dem Pitch.

Wer das versteht, hat die Make-or-Buy-Frage nicht beantwortet. Er hat sie in eine Disziplin überführt, die jedes Jahr eine Antwort liefert, die ehrlich ist. Das ist mehr, als die meisten Entscheider in dieser Frage haben.

Weiterführend

• The State of AI 2025 (McKinsey), wer die Verbreitung von KI-Plattformen im Markt verstehen will, findet hier die Zahlen, die eine Make-or-Buy-Entscheidung im Vorstand ermöglichen.
• a16z: Cost of Capital and AI Adoption zur Diskussion, warum KI-Investitionen anders zu bewerten sind als klassische SaaS-Ausgaben und welche Konsequenz das für die Eigenentwicklung hat.
• Gartner Magic Quadrant for AI Code Assistants als jährlicher Anbieter-Vergleich, der bei jeder Make-or-Buy-Runde die Ausgangsbasis liefert.