Build vs. Buy ist ein Spektrum, kein Schalter
„Selbst bauen oder kaufen“ klingt nach einem Schalter mit zwei Stellungen. Bei KI ist es eher ein Regler mit drei Positionen. Sie können ein fertiges Produkt kaufen und so nutzen, wie es kommt. Sie können ein System von Grund auf selbst bauen. Oder — die Variante, die die meisten vergessen — Sie bauen auf Modellen auf, die jemand anderes bereits trainiert hat, und setzen genau die Teile, die Sie brauchen, um ein Fundament herum zusammen, das Sie pro Token mieten. Kein Mittelständler sollte sein eigenes großes Sprachmodell trainieren; dieser Teil ist gelöst, extrem teuer und gehört in die Hände der wenigen Labore, die nichts anderes tun. Die eigentliche Frage ist also enger als „bauen oder kaufen“. Sie lautet: Wie viel davon setzen wir selbst zusammen, und wie viel nehmen wir fertig von der Stange?
Wer es als Alles-oder-nichts betrachtet, landet bei einem der beiden Klassiker. Der eine: Sie kaufen ein Tool, das fast passt, und biegen still Ihren Prozess darum herum — bis am Ende das Tool und nicht Sie entscheidet, wie die Arbeit läuft. Der andere: Sie lassen etwas maßschneidern, das ein Produkt für vierzig Euro im Monat längst gut erledigt, und zahlen dafür, es auf ewig selbst warten zu dürfen. Beides ist teuer, und beides lässt sich vermeiden, sobald man aufhört, das Ganze als ein einziges Ja/Nein zu behandeln.
Wann ein fertiges Tool gewinnt
Kaufen Sie, wenn die Aufgabe eine Commodity ist — etwas, bei dem die Art, wie Sie es tun, keinen Vorteil bringt und weder Kunde noch Wettbewerber merken würde, wenn Sie den Anbieter austauschen. Transkription, Übersetzung, Meeting-Protokolle, Rechtschreibprüfung, ein Coding-Assistent für Ihre Entwickler, ein Chatbot, der Fragen aus einer öffentlichen Hilfeseite beantwortet: Das sind gelöste Produkte. Dutzende Anbieter machen sie gut, die Qualität reicht, und eine eigene Variante zu bauen würde Monate verbrennen, um irgendwo etwas Schlechterem zu landen.
Zwei weitere Signale sprechen fürs Kaufen. Das erste ist Tempo: Ein SaaS-Tool läuft heute Nachmittag, ein Eigenbau in ein paar Wochen. Wenn der Wert darin liegt, jetzt etwas zu haben, kaufen Sie jetzt und schauen später erneut. Das zweite ist das Volumen. Eigenentwicklung hat eine feste Kostenschwelle, die sie erst überschreiten muss, damit sie sich rechnet; wer fünfzig Dokumente im Monat verarbeitet, fährt mit einem Lizenzprodukt jahrelang günstiger als mit allem Maßgeschneiderten. Der Reflex, eine Commodity-Aufgabe „aus Kontrollgründen“ selbst zu bauen, ist meist eine Milchmädchenrechnung — Sie übernehmen Wartung, Hosting und eine sich ständig verschiebende Modelllandschaft, um etwas zu besitzen, das Sie ohnehin nie vom Wettbewerb abgehoben hätte.
Wann sich der Eigenbau lohnt
Eigenentwicklung zahlt sich aus, wenn das, was Sie automatisieren, nah daran liegt, wie Sie tatsächlich im Wettbewerb bestehen — oder wenn kein Produkt am Markt Ihre spezifischen Daten, Prozesse oder Rahmenbedingungen bedienen kann. Das trifft auf mehr der spannenden Mittelstand-Anwendungsfälle zu, als das SaaS-Marketing vermuten lässt — und auf deutlich weniger, als die hausinterne Begeisterung fürs „eigene KI-System“ glauben machen will.
Wenn Ihre Daten oder Ihr Prozess der Vorsprung sind
Das stärkste Argument fürs Bauen sind eigene Daten. Ihre zwanzig Jahre an Serviceticket-Historie, Ihr Vertragsarchiv, Ihre ERP-Datensätze, das gesammelte Urteilsvermögen darin, wie Ihr bester Kalkulator einen Auftrag bepreist — kein Tool von der Stange hat davon je etwas gesehen, und keines wird es je. Ein eigenes Retrieval- oder Agenten-System, das über Ihrem eigenen Bestand argumentiert, leistet etwas, das ein generisches Produkt strukturell nicht kann — und genau dort zahlt sich KI im Mittelstand aus, nicht in der Demo (mehr dazu, wo sie verlässlich landet). Dasselbe gilt, wenn Ihr Prozess eigenwillig ist. Ein Standardtool kodiert die Vorstellung eines Unternehmens davon, wie die Arbeit fließen soll — meist nicht Ihre. Wenn genau Ihre Art, es zu tun, ein Grund ist, warum Kunden bleiben, werfen Sie mit dem Zwang in einen fremden Workflow das Wertvollste weg. Konkret: Ein Maschinenbauer, dessen Kalkulationslogik in den Köpfen zweier erfahrener Ingenieure steckt, hat etwas, das sich zu kodieren lohnt; ein Betrieb, der nur seine Meeting-Notizen aufgeräumt haben will, hat es nicht.
Die versteckten Kosten auf beiden Seiten
Keine der beiden Optionen ist so günstig wie ihr Preisschild. Kaufen wirkt billig, bis Sie die Integrations-Klebearbeit dazurechnen, die Sie doch selbst schreiben müssen, die Pro-Nutzer-Preise, die mit steigender Verbreitung schlecht skalieren, eine Roadmap, die Sie nicht steuern, Preiserhöhungen, die Sie nicht ablehnen können, und das stille Risiko, dass Ihre Daten Ihr Haus in Richtung einer Anbieter-Cloud verlassen — ein echtes DSGVO-Problem, wenn Sie deren Subunternehmer nicht prüfen können. Bauen wirkt anfangs teuer und kostet dann weiter: Jemand muss es warten, überwachen und abfedern, wenn sich das Modell des Anbieters unter ihm verändert. Ich habe an anderer Stelle geschrieben, was ein KI-Projekt wirklich kostet; kurz gesagt entscheiden die versteckten Posten, nicht die sichtbaren, ob sich der eine oder andere Weg gelohnt hat. Bei regulierten oder sensiblen Daten kann die ganze Rechnung auf einen einzigen Faktor zusammenschrumpfen: Wenn es keine konforme SaaS-Option gibt, ist ein On-Premise- oder in Deutschland gehosteter Eigenbau nicht die teure Wahl — er ist die einzige.
Der Mittelweg: darauf aufbauen, nicht bei null anfangen
Für die meisten Unternehmen liegt die richtige Antwort in keinem der Extreme. Sie mieten den schweren, generischen Teil — ein Basismodell, per API oder als selbst gehostete Open-Weights-Variante — und bauen nur die dünne, wertvolle Schicht, die wirklich Ihre ist: das Retrieval über Ihren Daten, die Integrationen in die Systeme, die Sie ohnehin betreiben, die Leitplanken, die es sicher halten, und eine Oberfläche, die Ihre Leute tatsächlich benutzen. Hier geht die Rechnung auf. Sie bekommen das meiste von dem, was „maßgeschneidert“ verspricht, ohne dafür zu zahlen, den Teil neu zu erfinden, den ein Labor für hunderte Millionen Euro richtig gemacht hat. Es ist auch die auf Dauer robusteste Position: Werden die zugrunde liegenden Modelle besser — und das werden sie, auf fremde Rechnung —, tauschen Sie den Motor und behalten alles, was Sie drum herum gebaut haben. Der Bau bei null bedeutet dagegen, Probleme selbst zu schultern, die die ganze Branche bereits für Sie löst.
Ein Entscheidungsrahmen
Mit fünf Fragen kommen Sie den meisten Antworten sehr nahe. Ist das zentral dafür, wie wir im Wettbewerb bestehen, oder eine Commodity, die jeder kaufen kann? Braucht es unsere eigenen Daten oder unseren eigenen Prozess, um es gut zu machen? Ist unser Volumen hoch genug, um die Pro-Nutzer-Preise zu schlagen? Haben wir eine Compliance-Anforderung — On-Premise, DSGVO, Datenstandort —, die die naheliegenden Tools ausschließt? Und wie stark muss es mit Systemen verzahnt sein, die wir schon betreiben? Vor allem „Commodity, geringes Volumen, keine Auflagen“ zeigt klar aufs Kaufen. „Kernnah, eigene Daten, echte Integration, eine Compliance-Linie zu halten“ zeigt aufs Bauen — und das heißt in der Praxis fast immer auf einem Modell aufbauen, selten bei null. Den Eigenbau danach sicher in den täglichen Betrieb zu bringen, ist eine eigene Disziplin; darum geht es in KI im Unternehmen einsetzen.
Ein kurzes Beispiel. Ein Regionalversicherer will Erstantworten auf Fragen zu Policen entwerfen. Geht es darum, generische Fragen aus den öffentlichen Bedingungen zu beantworten, ist das nah an einem gekauften Chatbot und sollte wohl einer bleiben. Geht es darum, die konkreten Klauseln aus dem Vertrag genau dieses Kunden und die Notizen zu seinen letzten drei Schadensfällen zu ziehen, kann das kein Produkt — und auf einem Modell aufzubauen, mit Retrieval über dem Policenarchiv, das aus DSGVO-Gründen auf den eigenen Servern bleibt, ist die ehrliche Antwort. Dieselbe Abteilung, derselbe Nachmittag, zwei verschiedene Urteile. Deshalb muss die Frage pro Anwendungsfall gestellt werden, nicht pro Unternehmen.
Genau diese Entscheidung soll der KI-Readiness-Check treffen. Statt Build vs. Buy im Abstrakten zu diskutieren, lässt er Ihren echten Anwendungsfall auf Ihren echten Daten laufen und kommt mit einer fundierten Empfehlung zurück — kauft dies, baut jenes, baut auf jenem auf — von jemandem, der alle drei Wege in die Produktion gebracht hat und Ihnen kein Produkt verkaufen will. Wenn Sie die Abwägung lieber erst besprechen möchten, nehmen Sie Kontakt auf.