Bei der Build-vs.-Buy-Frage für KI geht es nicht um Ingenieursstolz – es geht darum, wo Ihr dauerhafter Vorteil tatsächlich liegt. Ziehen Sie die Grenze falsch, mieten Sie entweder Ihre Differenzierung bei einem Anbieter oder bauen eine Commodity zum dreifachen Preis nach.

Jede Enterprise-KI-Roadmap landet irgendwann an derselben Weggabelung: Bauen wir das selbst, kaufen wir ein Produkt, oder legen wir eine dünne eigene Schicht um ein Foundation Model (Wrap)? Entschieden wird meist aus dem Bauch heraus – das Engineering-Team will bauen, der Einkauf will kaufen, und wer im Raum am lautesten ist, gewinnt. So kommt es, dass Unternehmen eine massgeschneiderte Vektordatenbank betreiben, die ein Managed Service für ein Fünftel der Kosten erledigt hätte, oder ihre sensibelste Preislogik durch eine SaaS-Blackbox schicken, die sie nicht auditieren können.

Wir haben diese Entscheidung auf beiden Seiten getroffen, für Banken, Versicherer und Telcos, und das Muster, das sich bewährt, lautet nicht «Bauen Sie die schwierigen Dinge». Es lautet: «Bauen Sie nur, was sich aufzinst.»

Das eigentliche Problem: Teams optimieren auf der falschen Achse

Die meisten Build-vs.-Buy-Debatten drehen sich um Aufwand – wie viele Ingenieurmonate wird es dauern? Aufwand ist der am wenigsten dauerhafte Faktor in dieser Entscheidung. Ein neunmonatiger Build ist ein einmaliger Kostenblock; eine falsch gezogene Grenze ist eine wiederkehrende Steuer, die Sie jahrelang jedes Quartal bezahlen.

Die zwei Achsen, auf die es wirklich ankommt, sind Differenzierung (macht diese Fähigkeit Sie für Ihre Kunden messbar besser als Ihre Wettbewerber?) und Kontrollbedarf (wie stark zwingen Sie Datensensibilität, Latenz, Audit und regulatorische Vorgaben, die Umsetzung selbst zu besitzen?). Der Aufwand entscheidet nur bei Gleichstand.

Ordnen Sie eine beliebige KI-Fähigkeit auf diesen zwei Achsen ein, und die Antwort ergibt sich von selbst:

• Hohe Differenzierung, hoher Kontrollbedarf → Build. Das ist Ihr Burggraben. Ein Modell für die Schadentriage, trainiert auf fünfzehn Jahren eigener Schadendaten, kauft man nicht; es ist der Grund, warum sich ein Kunde für Sie entscheidet. Besitzen Sie es durchgängig.
• Geringe Differenzierung, hoher Kontrollbedarf → Wrap. Sie brauchen Kontrolle, aber die Fähigkeit ist generisch. Zum Beispiel Frage-Antwort über interne Richtlinien: Die Intelligenz ist ein Commodity-Modell, aber Daten und Audit-Trail müssen bei Ihnen bleiben. Legen Sie Ihr eigenes Retrieval, Logging und Ihre Guardrails um ein Foundation Model.
• Hohe Differenzierung, geringer Kontrollbedarf → enge Partnerschaft. Selten, und meist ein Zeichen, dass Sie den Kontrollbedarf falsch eingeschätzt haben. Wenn Sie etwas wirklich differenziert, müssen Sie es fast immer auch kontrollieren.
• Geringe Differenzierung, geringer Kontrollbedarf → Buy. Meeting-Transkription, generische Coding-Assistenz, Entwürfe für Marketingtexte. Kaufen Sie das SaaS, verhandeln Sie den Preis pro Lizenz, weiter geht’s. Hier selbst zu bauen ist Ingenieurseitelkeit.

Ein Rahmen, der die Kosten eines Irrtums einbezieht

Der Quadrant zeigt die Richtung. Um die Entscheidung in einer Budgetrunde zu verteidigen, brauchen Sie drei weitere Zahlen – und genau diese lassen Teams aus:

1. Wechselkosten. Wenn Sie kaufen und der Anbieter seinen Preis verdoppelt oder übernommen wird: Was kostet der Ausstieg? Ist diese Zahl hoch und die Fähigkeit zentral, dann ist «Buy» stillschweigend ein «Build» mit schlechterer Wirtschaftlichkeit und einer Deadline, die Sie nicht kontrollieren.
2. Unterhaltskosten eines Builds. Ein Modell in Produktion ist kein Projekt; es ist ein Service mit einem Owner, einer Rufbereitschaft, einer Eval-Suite und einem Retraining-Rhythmus. Budgetieren Sie pro Jahr 20–30 % der ursprünglichen Build-Kosten, um es am Leben zu halten. Ein Build, für dessen Unterhalt niemand finanziert ist, ist die teuerste Option von allen.
3. Time-to-defensible-Value. Nicht die Zeit bis zur Demo – sondern die Zeit, bis die Fähigkeit verlässlich zur Erfolgsrechnung beiträgt. Kaufen gewinnt oft allein deshalb, weil es den Nutzen zwei Quartale früher liefert, und zwei Quartale Nutzen können die Lizenzdifferenz bei Weitem übertreffen.

Durchgerechnetes Beispiel: Dokumentenverarbeitung für einen Versicherer

Ein mittelgrosser Schweizer Versicherer wollte mit KI strukturierte Daten aus eingehenden Schadendokumenten extrahieren – rund 40’000 Dokumente pro Monat, gemischt aus PDFs, Scans und E-Mails. Drei Optionen lagen auf dem Tisch.

Buy – ein spezialisiertes Document-AI-SaaS zu ca. CHF 0.42 pro Dokument. Jährliche Betriebskosten: 40’000 × 12 × 0.42 ≈ CHF 200k/Jahr, linear mit dem Volumen skalierend. Schnell eingeführt (~6 Wochen). Aber die Schadendaten verlassen den Perimeter, und das Extraktionsschema gehört dem Anbieter, nicht dem Versicherer.

Build von Grund auf – eine eigene Pipeline und feinabgestimmte Modelle. Geschätzt CHF 480k bis zum ersten produktiven Nutzen über ~7 Monate, plus ~CHF 120k/Jahr für den Betrieb. Volle Kontrolle, aber das Team hätte OCR und Layout-Parsing nachgebaut, die echte Commodity sind.

Wrap – Managed OCR plus ein Foundation Model hinter dem eigenen Retrieval, Schema, der eigenen Validierung und dem eigenen Audit-Logging des Versicherers, in dessen eigener Cloud-Region. Build-Kosten ~CHF 180k über ~10 Wochen, Betriebskosten ~CHF 55k/Jahr (Inference + Infrastruktur), die Daten verlassen die Region nie.

Die Wrap-Option gewann – und nicht, weil sie im ersten Jahr am günstigsten war. Sie gewann, weil die Differenzierung in ihrem Extraktionsschema und ihren Validierungsregeln lag – dem Teil, der abbildet, wie genau dieser Versicherer tatsächlich zeichnet –, während die Commodity-Intelligenz (OCR, Basis-Extraktion) gemietet wurde. Sie besassen die 20 %, die sich aufzinsen, und kauften die 80 %, die es nicht tun. Die Drei-Jahres-TCO lag bei rund CHF 345k gegenüber CHF 600k für Buy und CHF 840k für den vollständigen Build – und die Anforderung an die Datenresidenz war konstruktionsbedingt erfüllt.

Die Grenze verschiebt sich – planen Sie dafür

Der teuerste Fehler ist, Build vs. Buy als einmalige Entscheidung zu behandeln. Die Grenze zwischen dem, was Sie besitzen, und dem, was Sie mieten sollten, verschiebt sich über die Zeit, und zwar in eine vorhersehbare Richtung: Fähigkeiten, die heute differenzieren, werden morgen zur Commodity. Vor drei Jahren war eigenes Dokumenten-OCR vernünftiges Engineering; heute ist es eine gelöste, günstige Commodity, die selbst zu bauen töricht wäre. Dieselbe Drift wird sich auch das holen, was Sie dieses Jahr bauen. Ein Entscheidungsrahmen, der das ignoriert, produziert ein Portfolio massgeschneiderter Systeme, die jedes für sich zum damaligen Zeitpunkt Sinn ergaben und zusammen zur Wartungslast wurden, als der Markt unter ihnen aufholte.

Die praktische Absicherung: Architektieren Sie selbst Ihre «Build»-Entscheidungen so, dass die Commodity-Schichten austauschbar bleiben. Wenn wir eine differenzierende Fähigkeit bauen, isolieren wir trotzdem die generischen Komponenten – das Basismodell, das OCR, den Vector Store – hinter Schnittstellen, damit wir die Eigenentwicklung, sobald sie zur Commodity wird (und das wird sie), fallen lassen und die günstigere Marktoption übernehmen können, ohne den Teil anzufassen, der tatsächlich differenziert. So wird aus einem «Build» von heute in zwei Jahren kein «Rebuild», sondern eine dünne eigene Schicht über einer immer günstigeren Commodity-Basis. Der Burggraben schrumpft genau auf den Teil, der wirklich Ihnen gehört, und alles darum herum profitiert vom Preisverfall am Markt.

Das verändert die ganze Übung. Die Frage lautet nicht «Bauen oder kaufen wir diese Fähigkeit?», sondern «Welche dünne Schicht dieser Fähigkeit gehört dauerhaft uns, und wie besitzen wir diese, während wir alles darunter mieten?». Das Hantel-Portfolio ist nicht statisch – es wird aktiv gepflegt: Fähigkeiten wandern vom «Build»-Ende zum «Buy»-Ende, sobald sie zur Commodity werden, und die Organisation lässt bewusst massgeschneiderte Systeme los, die nicht mehr differenzieren. Die Disziplin, etwas nicht mehr zu besitzen, ist ebenso wichtig wie die Disziplin, es zu bauen – und weit seltener.

Fallstricke, die wir immer wieder sehen

• «Wir können es bauen» mit «Wir sollten es bauen» verwechseln. Ein starkes Team kann fast alles bauen. Genau deshalb braucht die Entscheidung die Differenzierungsachse – die Fähigkeit ist nicht der Engpass, der Fokus ist es.
• Das Foundation Model als Produkt betrachten. Das Modell ist die am wenigsten verteidigbare Schicht; es wird in sechs Monaten günstiger und besser sein, egal was Sie tun. Ihr Burggraben sind die Daten, die Workflow-Integration und die Evals darum herum.
• Die Exit-Kosten bei «Buy» ignorieren. Die günstigste Lizenz mit einer restriktiven Regelung zum Datenexport ist eine Falle. Verlangen Sie Ihre Daten und Ihre Prompt-Logs in einem portablen Format im Vertrag, bevor Sie unterschreiben.
• Unfinanzierte Builds. Wer das Build-Budget genehmigt, aber nicht das Betriebsbudget, garantiert ein Modell, das still vor sich hin verrottet, bis jemand bemerkt, dass die Genauigkeit schon vor einem Jahr eingebrochen ist.

Die Entscheidungs-Checkliste

Bevor Sie sich festlegen, sollten Sie alle sieben Fragen beantworten können:

1. Macht uns diese Fähigkeit für Kunden messbar besser oder nur intern effizienter? (Differenzierung)
2. Zwingen uns Datensensibilität, Latenz oder Audit-Vorgaben, die Umsetzung selbst zu besitzen? (Kontrolle)
3. Wenn wir kaufen: Was kostet es – an Zeit und Geld –, im dritten Jahr den Anbieter zu wechseln?
4. Wenn wir bauen: Wer ist in Produktion verantwortlich, und ist diese Zeit finanziert?
5. Wie lange dauert es bei jeder Option bis zum verteidigbaren Nutzen, und was sind zwei Quartale dieses Nutzens wert?
6. Welche Schicht bildet den Burggraben – und bauen wir gezielt diese Schicht, oder bauen wir eine Commodity drumherum nach?
7. Wie hoch ist die Drei-Jahres-TCO, inklusive Betriebskosten und eines realistischen Retraining-Rhythmus?

Die gridz-Sicht

Die stärksten Enterprise-KI-Portfolios, die wir aufgebaut haben, haben die Form einer Hantel: eine kleine Zahl tief verankerter, differenzierender Fähigkeiten im Eigenbesitz, und alles andere gekauft oder mit einer dünnen Schicht versehen. Das Versagensmuster ist die breiige Mitte – halbfertige Plattformen, die nichts differenzieren und ein ganzes Team für den Unterhalt binden. Entscheiden Sie, wo Ihr Vorteil tatsächlich liegt, bauen Sie genau das, und mieten Sie den Rest ohne Sentimentalität. Wenn Sie gerade vor dieser Weggabelung stehen, sprechen Sie uns an: Wir spielen den Quadranten und die Drei-Jahres-TCO in ein paar Workshops mit Ihren echten Zahlen durch – und sagen Ihnen ehrlich, welche Ihrer KI-Ambitionen Burggraben sind und welche Wartungsaufwand.