Jeder zweite Geschäftsführer stellt im ersten Call genau diese Frage: "Sollen wir das selber bauen oder eine fertige Lösung kaufen?" Die ehrliche Antwort ist meistens unbefriedigend — "es kommt drauf an" — aber die Variablen, auf die es ankommt, sind klar definierbar. Und je früher ihr die richtigen vier Dimensionen abklopft, desto weniger fahrt ihr in die teure Sackgasse aus 18 Monaten Eigenbau, der hinterher durch ein Off-the-Shelf-Tool ersetzt wird.
1. Warum die Frage so oft falsch gestellt wird
Build vs. Buy klingt nach binärer Entscheidung — ist es aber 2026 fast nie. Wer eine ChatGPT-Enterprise-Lizenz kauft und alle internen Workflows darüber laufen lässt, hat trotzdem "gebaut": eine Prompt-Bibliothek, Zugriffsrechte, Schulungen, Eskalations-Workflows. Wer angeblich "selbst baut", verwendet darunter Anthropic API, OpenAI API oder ein gehostetes Open-Source-Modell. Die echte Frage ist nicht "Build vs. Buy", sondern: welche Schichten kaufen wir, welche bauen wir selbst?
Die typische KI-Anwendung 2026 besteht aus fünf Schichten:
- Foundation Model (Claude, GPT, Llama, Mistral) — fast immer gekauft oder gehostet
- Infrastruktur (Cloud, Vector-DB, Monitoring) — meistens gekauft (Azure, AWS, Hetzner)
- RAG- und Tool-Use-Layer (eure Daten, eure Workflows) — fast immer gebaut
- Anwendungs-Logik (Prozess-Integration, UI, Business-Rules) — gebaut oder konfiguriert
- Operations und Care (Monitoring, Eval, Updates) — Mischform, oft mit externem Partner
Wer "Build vs. Buy" als Frage zu Schicht 1 versteht, antwortet falsch. Die echte strategische Frage steckt in Schicht 3–5.
2. Die vier Entscheidungs-Dimensionen
Dimension 1: Differenzierungs-Wert
Erste und wichtigste Frage: Trägt die KI direkt zur Wettbewerbsdifferenzierung bei — oder ist sie Commodity?
- Commodity → kaufen. Beispiele: Meeting-Transkription, E-Mail-Zusammenfassungen, Standard-Chatbots für FAQ, Übersetzungen, CV-Vorselektion. Hier gibt es 5–10 etablierte Anbieter, die euer Use Case zu €5–50 pro User und Monat erschlagen. Eigenbau wäre Geldverbrennung.
- Differenzierung → bauen. Beispiele: ein KI-gestützter Tarif-Optimizer für eine Versicherung, ein RAG über die proprietäre Bauteil-Datenbank eines Industriebetriebs, ein Agent, der die spezifische Arbeitsweise eures Sales-Teams 1:1 abbildet. Off-the-Shelf gibt es hier nicht — und das ist gut so, weil das genau das ist, was Wettbewerber nicht kopieren können.
Faustregel: Wenn drei Wettbewerber das gleiche Tool nutzen würden, ist es Commodity. Wenn ihr beim Beschreiben des Use Case anfangt, eure spezifischen Prozesse, Daten oder Kunden-Logik zu erklären — Eigenbau.
Dimension 2: Daten-Sensitivität
Welche Daten gehen ins System? Drei Stufen:
- Public oder gering-sensitiv: Marketing-Texte, externe Recherche, generische Übersetzungen. Off-the-Shelf-Tools mit EU-Hosting (Anthropic API, Mistral) sind hier völlig ausreichend.
- Intern-sensitiv: Kunden-Daten, Verträge, interne Strategie-Dokumente. Anthropic API mit Zero-Retention-Vertrag oder Azure OpenAI mit dedicated Endpoint reichen meistens. DSGVO-Setup beachten.
- Hoch-sensitiv oder reguliert: Patientendaten, Bankkunden-Daten, Verteidigungs-Kontexte. Hier ist meistens On-Prem oder Private Cloud Pflicht — was praktisch heißt: Open-Source-Modell selbst hosten (Llama, Mistral, Qwen). Das ist kein "kaufen" mehr, sondern ein klassisches IT-Projekt.
Dimension 3: Kosten-Skalierung
Schwelle, ab der Eigenbau gegen Off-the-Shelf TCO-mäßig kippt — laut Gartner-Modellierung 2026
Die Gartner-Schwelle ist eine Faustregel, keine Garantie. Aber das Muster ist robust: Off-the-Shelf-Tools rechnen pro User pro Monat (typisch €15–80). Das ist linear — 1.000 User kosten 1.000-mal so viel wie ein User. Eigenbau hat hohe Fixkosten (Implementation €30k–150k) und niedrige variable Kosten (API-Tokens, Hosting). Bei niedrigen Nutzerzahlen ist Off-the-Shelf günstiger, ab einer Schwelle (für die meisten Anwendungen 1.500–4.000 User) kippt es.
Zweites Argument: ein Differenzierungs-Use-Case mit 50 internen Power-Usern kann trotz niedriger Nutzerzahl Eigenbau rechtfertigen, weil der Business-Value pro User extrem hoch ist. Skalierung ist nur eine Variable, nicht die einzige.
Dimension 4: Time-to-Value
Wann muss das System live sein? Drei Realitäten:
- <6 Wochen: Kaufen, fast immer. Bauen dauert minimum 8–12 Wochen für etwas Ernsthaftes.
- 6–16 Wochen: Beide Optionen offen. Hängt vom Use Case ab.
- >16 Wochen: Wenn ihr 4 Monate Zeit habt, ist Bauen oft die strategisch klügere Wahl — vor allem bei Differenzierungs-Use-Cases.
Wer "wir bauen das, aber bitte in 4 Wochen" sagt, kauft sich praktisch immer einen halbfertigen Prototypen, der dann doch durch ein Off-the-Shelf-Tool ersetzt wird. Time-to-Value ist die unterschätzteste Variable im ganzen Modell.
3. Die Hybrid-Realität — was wir in der Praxis sehen
Konkrete Beispiele aus unseren Projekten:
- Wiener Steuerberater: Foundation-Modell Anthropic API gekauft, RAG-Layer für interne Mandanten-Dokumente und Steuerrechts-Datenbank selbst gebaut, UI ist Microsoft Teams-Plugin (Off-the-Shelf-Plattform).
- Industriebetrieb mit Predictive Maintenance: Sensor-Pipeline und ML-Modell selbst gebaut (Differenzierung!), Foundation-Modell für die Operator-Erklärungen Off-the-Shelf, Reporting-Dashboard fertige Software.
- Versicherungs-KMU: CRM-Integration und Lead-Scoring-Logik gebaut, Foundation-Modell und Voice-Layer gekauft, Compliance-Layer in Eigenbau wegen Regulatorik.
Das Muster: Schicht 1 (Foundation) wird fast immer gekauft. Schicht 3 (RAG mit eigenen Daten) wird fast immer gebaut. Alles dazwischen ist verhandelbar.
4. Die häufigsten Fehlentscheidungen
Aus zwei Jahren Audit-Praxis: drei Anti-Patterns, die teuer werden.
Anti-Pattern 1 — "Wir bauen alles selbst, weil wir Tech-DNA haben". Funktioniert bei Tech-Konzernen mit 50 ML-Engineers. Im Mittelstand führt es zu 12 Monaten Eigenbau, der hinterher von einem Junior-Mitarbeiter alleine gewartet werden muss — der nach 9 Monaten kündigt. Realistische Frage: habt ihr das Team, um das in 3 Jahren noch zu betreiben?
Anti-Pattern 2 — "Wir kaufen einfach Microsoft Copilot für alle, dann sind wir KI". Copilot ist ein hervorragendes Office-Tool. Es ersetzt aber nicht den Use Case "spezifische Workflow-Automation in unserer Branche". Wer 60 Lizenzen kauft und dann erwartet, dass damit die Customer-Service-Quote sinkt, hat €25k pro Jahr ausgegeben und keinen messbaren ROI.
Anti-Pattern 3 — "Wir warten, bis es einen Anbieter gibt". In schnell-bewegten Branchen ist das eine valide Strategie. In Nischen-Märkten (Schweizer Steuerrecht, spezielle Versicherungstarife, B2B-Bauchemie) gibt es keinen Anbieter, der euch versteht. Wer wartet, wartet 3–5 Jahre — und konkurriert dann gegen einen Wettbewerber, der vor 3 Jahren angefangen hat zu bauen.
5. Wann Open-Source ein Sweet Spot ist
Open-Source-Modelle (Llama 4, Mistral, Qwen) sind 2026 in einer ernsthaften Position. Drei Szenarien, in denen sie die richtige Antwort sind:
- Hochsensible Daten (Gesundheit, Verteidigung, Bankenkern), die das Unternehmen nicht verlassen dürfen — On-Prem-Hosting auf eigener Infrastruktur.
- Sehr hohe Volumina (Millionen API-Calls pro Tag) — ab gewissen Volumen ist self-hosted Llama 4 deutlich günstiger als Anthropic oder OpenAI API.
- Vermeidung von Vendor-Lock-in als strategische Entscheidung — wenn ihr in 5 Jahren nicht von einem US-Provider abhängig sein wollt.
Was Open-Source nicht löst: ihr braucht Infrastruktur-Know-how (GPU-Hosting, Latenz-Tuning, Model-Updates), und die Qualitäts-Lücke zu Top-Closed-Modellen ist 2026 zwar kleiner geworden, aber bei komplexem Reasoning immer noch real.
6. Eine pragmatische Entscheidungs-Heuristik
Wenn ihr in 30 Minuten eine erste Einschätzung braucht, beantwortet die folgenden fünf Fragen:
- Ist der Use Case Commodity (gibt's bei 5+ Anbietern)? Ja → kaufen.
- Geht es um hochsensible oder regulierte Daten? Ja → On-Prem oder Hybrid mit dediziertem Hosting.
- Habt ihr in den nächsten 12 Monaten >3.000 aktive User auf dem System? Ja → Eigenbau prüfen, sonst kaufen.
- Müsst ihr in <6 Wochen live sein? Ja → kaufen oder mit fertigem Framework anfangen.
- Ist der Use Case ein echter Wettbewerbsvorteil? Ja → bauen, auch wenn 1–4 dagegen sprechen.
Drei oder mehr "Kaufen"-Antworten? Off-the-Shelf mit minimalem Custom-Layer. Drei oder mehr "Bauen"-Antworten? Hybrid-Architektur mit Foundation-Modell-Kauf und eigenem Anwendungs-Layer.
Häufige Fragen
Build vs. Buy — was Geschäftsführer fragen.
Wann sollten wir Open-Source-Modelle nutzen statt Anthropic oder OpenAI API?
Wie minimiere ich Vendor-Lock-in, wenn wir auf Anthropic oder OpenAI setzen?
Was zählt überhaupt als 'eigene KI'?
Bei 50 Mitarbeitern bauen oder kaufen?
Was, wenn der Vendor 5× teurer ist als unsere geschätzten Eigenbau-Kosten?
Was als Nächstes?
Die Build-vs-Buy-Entscheidung ist keine Excel-Übung, sondern eine strategische Diskussion zwischen Geschäftsführung, IT und Fachbereich. Ein Audit M kostet €9.500–18.000, dauert 2–3 Wochen und liefert für eure 15–25 priorisierten Use Cases eine konkrete Build/Buy/Hybrid-Empfehlung — inklusive Vendor-Shortlist, Architektur-Skizze und ROI-Bandbreite. Wer den ersten Schritt machen will, bucht den 30-Minuten-Discovery-Call. Im Call schauen wir uns euren konkretesten Use Case an und sagen euch ehrlich, ob ihr ihn kaufen, bauen oder hybridisieren solltet.