Warum die Frage heute anders aussieht
Noch vor wenigen Jahren war „Buy" für die meisten Unternehmen die naheliegende Antwort, weil das Entwickeln eigener KI-Systeme Spezialistenteams und hohe Grundinvestitionen voraussetzte. Mit verfügbaren Sprachmodellen, offenen Frameworks und standardisierten Komponenten hat sich das verschoben. Heute kann ein kleines Team in wenigen Wochen einen Assistenten bauen, der sich nicht mehr grundsätzlich hinter gekauften Produkten verstecken muss.
Gleichzeitig ist der Markt an fertigen Lösungen explodiert. Für nahezu jede Disziplin gibt es inzwischen spezialisierte Tools, die KI-Features eingebaut haben. Die Entscheidung verläuft deshalb längst nicht mehr zwischen „alles selbst bauen" und „fertiges Produkt kaufen", sondern entlang einer Reihe von konkreten Fragen zum Use Case, zu Daten, zu Integration und zu Risikotragfähigkeit.
Was „Build" und „Buy" heute wirklich bedeuten
„Buy" umfasst heute mehrere Varianten. Am einen Ende steht ein fertiger SaaS-Assistent, der sich über wenige Klicks in Slack, Teams oder ein Helpdesk einhängt. Am anderen Ende steht eine Plattform, die sich weitreichend anpassen lässt, aber ein definiertes Datenmodell und eine vorgegebene Architektur mitbringt. Gemeinsam ist beiden, dass der Anbieter Modelle, Retrieval, Oberfläche und Betrieb als Paket liefert.
„Build" bedeutet nicht mehr, Modelle selbst zu trainieren. In der Praxis heißt es, ein eigenes System aus bewährten Bausteinen zusammenzusetzen: ein Basismodell über API, eine definierte Retrieval-Schicht, Anbindungen an eigene Systeme, eigene Prompts, eigene Qualitätssicherung. Die Komplexität steckt weniger im Modell als in Integration, Daten und Betrieb.
Wann „Buy" die richtige Entscheidung ist
Eine gekaufte Lösung ist dann überlegen, wenn der Use Case gut verstanden und weit verbreitet ist. Ein generischer Support-Chatbot auf einer öffentlichen Website, eine Schreibhilfe in einer Office-Umgebung oder ein Meeting-Protokollant sind Standardfälle. In diesen Bereichen lohnt es sich selten, eine eigene Architektur gegen ausgereifte Produkte zu stellen, bei denen hunderte Kunden dieselben Verbesserungen bezahlen.
„Buy" ist ebenfalls die richtige Wahl, wenn Zeit entscheidend ist. Wenn eine Abteilung in sechs Wochen einen produktiven Assistenten braucht und der Use Case mit einem Standardprodukt sauber abgedeckt ist, erzeugt Eigenentwicklung vor allem eines: Wartezeit. Gleiches gilt, wenn intern keine Kapazität für den laufenden Betrieb vorhanden ist. Ein System, das niemand pflegt, veraltet schneller, als es gebaut wurde.
Wann „Build" sich lohnt
Eigenentwicklung lohnt sich, sobald der Use Case eng mit internen Prozessen, Daten oder Differenzierung verbunden ist. Ein Assistent, der auf Vertragswerke, interne Richtlinien oder branchenspezifische Fachbegriffe zugreifen muss, lässt sich in einem Standardprodukt meist nur schwer abbilden, ohne genau die Teile zu verlieren, die ihn wertvoll machen.
Build ist ebenfalls angebracht, wenn mehrere Use Cases auf derselben Grundlage aufsetzen sollen. Wer heute einen Assistenten für Support baut und morgen einen für Sales, spart mittelfristig deutlich, wenn Retrieval, Berechtigungen und Monitoring einmal sauber aufgesetzt und mehrfach genutzt werden. Die initiale Investition in AI Engineering amortisiert sich dann über die Breite der Anwendungen.
Der dritte Fall betrifft Risiko und Kontrolle. Wo sensible Daten, regulatorische Anforderungen oder klare Audit-Pflichten im Spiel sind, ist ein System, dessen Datenflüsse, Modelle und Logs vollständig unter eigener Kontrolle liegen, oft der einzige gangbare Weg. Das schließt fertige Produkte nicht grundsätzlich aus, verschiebt aber die Schwelle spürbar Richtung Eigenentwicklung.
Die versteckten Kosten von „Build"
Der erste unterschätzte Kostenblock ist nicht die Entwicklung, sondern die Datenaufbereitung. Handbücher, Wikis und Archive sind selten so strukturiert, dass ein Assistent ohne Aufräumarbeit sinnvolle Antworten liefert. Wer diese Vorarbeit nicht einplant, baut ein System, das die Defizite der Datenlage sichtbar macht, statt sie zu lösen.
Der zweite Block betrifft Qualität und Betrieb. Ein produktiver Assistent braucht Testfälle, Monitoring und einen definierten Umgang mit Fehlverhalten. Diese Disziplinen verlangen eigenes Know-how, das in vielen Organisationen noch nicht vorhanden ist. Ohne ein Verständnis für LLM-Qualitätssicherung läuft eine Eigenentwicklung nach dem Go-Live Gefahr, stillschweigend zu degradieren.
Der dritte Block ist organisatorisch: interne Verantwortlichkeiten, Governance und Weiterentwicklung. Wer ein Build-Vorhaben startet, muss klären, wer Inhalte pflegt, wer Tests freigibt, wer im Betrieb zuständig ist. Ohne diese Klärung landet selbst ein gut gebautes System im Niemandsland zwischen IT, Fachbereich und Digitalstab.
Die versteckten Kosten von „Buy"
Auch beim Einkauf entstehen Kosten, die in der ersten Kalkulation selten auftauchen. Die offensichtlichste ist die Abhängigkeit vom Anbieter. Wer sich auf eine Plattform festlegt, übernimmt deren Roadmap, deren Preisanpassungen und deren Entscheidungen bei Modellen und Datenhaltung. Ein Wechsel ist möglich, aber selten billig.
Der zweite Kostenblock ist die Anpassung. Standardprodukte sind selten so generisch, dass sie ohne Customizing produktiv laufen. Integration in bestehende Systeme, eigene Terminologie, Berechtigungen und die Anbindung von Datenquellen verschlingen regelmäßig einen Aufwand, der an ein eigenes Projekt heranreicht.
Der dritte Block wird oft unterschätzt: Compliance und Datenschutz. Viele gekaufte Lösungen sind technisch stark, aber die Frage, welche Daten an welche Modelle wohin fließen, ist nicht in jedem Produkt sauber dokumentiert. Je sensibler der Use Case, desto teurer wird dieser Kostenblock in der Bewertung.
Hybride Modelle sind oft die realistische Antwort
In der Praxis ist die Entscheidung selten binär. Viele Unternehmen kaufen eine Plattform für generische Aufgaben und bauen daneben gezielt eigene Assistenten für die wenigen Bereiche, in denen sie tatsächlich Differenzierung oder Kontrolle brauchen. Diese Arbeitsteilung ist meist die stabilste Variante: Standardnutzen aus dem Regal, spezifischer Nutzen aus der eigenen Werkbank.
Hybrid heißt auch, eigene KI-Agenten auf bestehende Plattformen zu setzen oder APIs fremder Produkte zu nutzen, statt alles selbst zu orchestrieren. Entscheidend ist, dass die Schnittstelle zwischen gekauften und gebauten Teilen bewusst gestaltet wird und nicht unter der Hand entsteht.
Typische Fehler in der Entscheidung
Der häufigste Fehler ist, die Entscheidung am Beschaffungsprozess aufzuhängen statt am Use Case. Wer gewohnt ist, Software einzukaufen, kauft auch KI ein. Wer gewohnt ist, selbst zu bauen, baut auch KI. Beides kann im Einzelfall richtig sein, ist aber als Grundhaltung ein teurer Reflex.
Der zweite Fehler ist eine Scheinrechnung. Lizenzkosten lassen sich gut tabellieren, aber sie sind in der Regel nur ein Bruchteil der Gesamtkosten. Umgekehrt werden beim Selberbauen oft Entwicklung, aber nicht Betrieb, Daten und Qualitätssicherung eingepreist. Eine ehrliche Rechnung umfasst mindestens drei Jahre und alle vier Blöcke.
Der dritte Fehler ist, die Entscheidung zu früh zu treffen. Viele Teams legen sich auf „Build" oder „Buy" fest, bevor der Use Case sauber geschnitten ist. Ein scharfer Use Case macht die Entscheidung oft einfacher, als sie ohne diesen Zuschnitt scheint. Genau hier setzt gutes AI Consulting an: bei der Frage, was eigentlich gebraucht wird, bevor die Frage nach Herkunft der Lösung überhaupt sinnvoll gestellt werden kann.
Wann externe Unterstützung sinnvoll ist
Für klar geschnittene Standardfälle ist die Entscheidung selten strittig. Sobald aber mehrere Use Cases, eine heterogene Systemlandschaft oder regulatorische Anforderungen zusammenkommen, wird Build vs. Buy zu einer Architekturfrage mit Konsequenzen über Jahre. In diesen Fällen lohnt sich eine strukturierte Bewertung: nicht als Präsentation, sondern als konkrete Rechnung über Use Cases, Kosten, Risiken und Anschlussszenarien.
Wir begleiten Unternehmen genau an dieser Stelle: bei der Einordnung, welche Vorhaben besser gekauft, welche besser gebaut und welche bewusst hybrid aufgesetzt werden. Ziel ist nicht die elegantere Architektur, sondern das stabilere Ergebnis im Alltag. Wenn Sie gerade vor dieser Entscheidung stehen, sprechen Sie uns an, bevor ein Vertrag unterschrieben oder ein Team aufgesetzt ist.