Build vs. Buy: KI-Lösung selbst entwickeln oder kaufen?

Im Gespräch mit einem Produktionsleiter fällt die Frage, die wir in fast jedem Unternehmen hören, das heute über KI nachdenkt: „Kaufen wir ein fertiges Tool, oder müssen wir es selbst entwickeln?" Die Frage klingt einfach, verbindet aber tatsächlich drei verschiedene Entscheidungen — über Differenzierung, über Daten und über Kosten im Zeitverlauf. Wer sie in den ersten fünfzehn Minuten eines Meetings beantwortet, liegt meistens falsch.

Dieser Artikel bietet einen Rahmen, den wir in der Praxis an Dutzenden von Implementierungen erprobt haben. Es geht nicht um den Glaubenskrieg zwischen „Buy everything" und „Build everything" — beide Extreme sind falsch. Es geht darum zu wissen, welche Schicht einer konkreten Lösung man kaufen sollte, welche man selbst bauen sollte und wo die Grenze liegt, ab der sich das eine oder das andere nicht mehr lohnt.

Grundlage des Rahmens — drei Schichten jeder KI-Lösung

Jede produktive KI-Lösung lässt sich in drei Schichten aufteilen:

1. 1.Modell und Inferenz — LLM, Embedding-Modell, Serving-Infrastruktur. Das ist Commodity. OpenAI, Anthropic, Google oder Open-Weight-Modelle wie Qwen 3, Mistral, Llama 4 — alle liefern eine solide Grundlage, die Hunderte Millionen Dollar in der Entwicklung gekostet hat und die Sie für einen Bruchteil dieses Preises erhalten.
2. 2.Orchestrierung und Retrieval — RAG-Pipeline, Agenten-Logik, Memory, Tools, Guardrails. Das ist die Schicht, in der die Qualität der Ausgabe entschieden wird. Sie ist teilweise Commodity (Frameworks wie LangGraph, LlamaIndex, Vektordatenbanken wie Qdrant sind Open-Source und ausgereift), aber die Besonderheiten des Einsatzes — Ihre Daten, Ihre Prozesse, Ihre Edge-Cases — erfordern eigene Arbeit.
3. 3.Domänenschicht — Prompts, Datensätze, Fine-tuning, Evaluierungen, UI, Systemintegration. Hier entsteht Differenzierung. Niemand sonst hat Ihre Produktionsdaten, Ihre SOP-Dokumente oder Ihre Kundenhistorien. Diese Schicht können Sie nicht kaufen — Sie können sie nur selbst bauen.

Vereinfacht: Kaufen Sie Schicht 1 und einen Teil von Schicht 2, bauen Sie Schicht 3 und den Rest von Schicht 2. Das Problem entsteht, wenn ein Unternehmen Schicht 1 von einem Vendor kauft, der Schicht 2 und Schicht 3 in eine proprietäre Plattform verpackt — und das Unternehmen nicht merkt, was es unterschreibt.

Wann kaufen

Kaufen macht Sinn, wenn der Use-Case Commodity ist — das heißt, Ihr Problem lösen auch fünfzig andere Unternehmen, und es gibt einen ausgereiften Markt an Lösungen. Beispiele:

• Kundensupport mit FAQ (Zendesk AI, Intercom, Freshdesk AI) — Standardaufgabe, fertige Integrationen, schnelles Onboarding.
• Meeting-Zusammenfassung und Transkription (Otter.ai, Fireflies, Microsoft Copilot) — kein Differenzierungswert, Liefergeschwindigkeit ist entscheidend.
• Code-Assistent für das Team (GitHub Copilot, Cursor, Codeium) — generischer Use-Case, bei dem individuelles Fine-tuning marginale Verbesserungen zu unverhältnismäßig hohen Kosten bringt.
• HR-Screening der ersten Runde (es gibt mehrere ausgereifte Plattformen) — Commodity-Problem, regulierter Markt, fertige Compliance.

Neben der Commodity gilt: Kaufen Sie, wenn Geschwindigkeit bis zur Produktion wichtiger ist als Leistung. In manchen Fällen ist eine 80-%-Lösung, die morgen verfügbar ist, besser als eine 95-%-Lösung, die erst in acht Monaten bereitsteht.

Das letzte Argument fürs Kaufen: Wenn Ihr Unternehmen kein KI-Team mit den nötigen Kompetenzen hat und in absehbarer Zeit auch keines aufbauen wird, wird die Wartung einer eigenen Lösung mehr kosten als ein SaaS-Abonnement — sowohl in Kosten als auch in Unzuverlässigkeit.

Wann selbst entwickeln

Selbst entwickeln lohnt sich in drei Situationen:

Differenzierung durch Daten. Wenn Sie Daten besitzen, die kein anderer hat — Maschinendaten aus der Produktion, Reklamationshistorien, interne technische Normen, Messergebnisse — und wenn diese Daten die Quelle einer besseren Leistung als bei der Konkurrenz sein können, müssen Sie selbst entwickeln. Eine fertige Lösung integriert diese Daten nicht; wenn Sie sie kaufen, zahlen Sie für generische Qualität. Fine-tuning oder RAG auf eigenen Daten verwandelt ein generisches Modell in einen Domänenspezialisten — aber das erfordert Ihre eigene Arbeit.

Sicherheits- und regulatorische Anforderungen. Wenn Sie in einer Branche tätig sind, in der Daten das Netzwerk nicht verlassen dürfen (Gesundheitswesen, Energie, Verteidigung, Finanzinstitute mit NDA-Daten), scheiden SaaS-Lösungen schlicht aus. Hier ist die Antwort On-Prem-LLM — lokale Bereitstellung eines Open-Weight-Modells mit vLLM oder Ollama, bei der die Inferenz auf Ihrer Hardware läuft und kein Token das Netzwerk verlässt. Das ist nicht nur eine technische Entscheidung — es ist eine Compliance-Anforderung.

Prozessspezifika, die kein fertiges Produkt unterstützt. Wenn Ihr Use-Case nicht-standardisierte Schritte enthält — zum Beispiel Integration in ein älteres SCADA-System, Verarbeitung eines proprietären Dokumentationsformats oder einen mehrstufigen Agenten-Workflow, der exakt Ihren Fertigungsprozessen entspricht — wird keine fertige Plattform das ohne umfangreiche Anpassungen abdecken. Und diese Anpassungen führen Sie auf denselben Arbeitsaufwand wie eine eigene Lösung — nur mit fremdem Code darunter.

Hybridmodell — die Realität der meisten produktiven Implementierungen

In der Praxis haben wir selten eine rein selbst entwickelte oder rein gekaufte Implementierung erlebt. Eine typische Architektur, die funktioniert:

• Kaufen: LLM-API (Claude Sonnet, GPT, Gemini Flash) oder Open-Weight-Modell über vLLM auf dem eigenen Server; Vektordatenbank (Qdrant ist der de-facto-Standard für den mitteleuropäischen Markt — EU-gehostet, Apache 2.0); Embedding-Modell (die Open-Weight-BGE-Familie ist produktionserprobt).
• Selbst entwickeln: RAG-Pipeline mit spezifischen Retrieval-Strategien für Ihren Dokumententyp; Prompt-Schicht, die Unternehmensprozesse und -terminologie widerspiegelt; Fine-tuning auf dem Domänenvokabular, wenn der Qualitätsunterschied messbar ist; Integration in ERP/SCADA/MES-Systeme; Evaluierung und Performance-Monitoring im Produktionsbetrieb.

Dieser Hybridansatz gibt Ihnen die Geschwindigkeit kommerzieller Schichten (Modell und Datenbank sind am ersten Tag fertig) und die Differenzierung eigener Schichten (die Domänenlogik bleibt Ihre). Gleichzeitig reduziert er das Lock-in-Risiko — wenn morgen ein besseres Modell erscheint, tauschen Sie den API-Aufruf aus, ohne die gesamte Lösung umzuschreiben.

Total Cost of Ownership — wo sich die Kalkulation ändert

Der häufigste Fehler bei der Build-vs.-Buy-Entscheidung ist der Vergleich des SaaS-Abonnementpreises mit den einmaligen Entwicklungskosten. Die richtige Kalkulation muss die Gesamtbetriebskosten (TCO) über 3–5 Jahre umfassen:

SaaS / Buy TCO: - Monatliches Abonnement (skaliert mit der Nutzeranzahl oder dem Datenvolumen — beobachten Sie das) - Onboarding und Integration (meistens nicht kostenlos) - Ausfälle durch API-Änderungen oder Änderungen der Nutzungsbedingungen (wir haben Preislistenerhöhungen von 40–80 % bei Vertragserneuerung erlebt) - Unsichtbare Kosten: Daten verlassen das Unternehmen → Datenschutzrisiko → potenzielle Compliance-Kosten

Build TCO: - Initiale Entwicklung (typischerweise der dominante Posten im ersten Jahr) - Hardware bei On-Prem (GPU-Server — orientierend 15.000–60.000 EUR für produktive Implementierungen je nach Anforderungen, typischerweise über 3 Jahre amortisiert) - Personalkosten für Wartung und Iteration (nicht null — realistisch kalkulieren) - Abhängigkeit von internem Know-how (Abgang eines Schlüsselingenieurs = Risiko)

Ein entscheidender Punkt: SaaS erscheint im ersten Jahr günstiger, selbst entwickeln zahlt sich ab Jahr 2–3 aus. Wenn der Use-Case vorübergehend ist (Pilotprojekt, Hypothesentest, Saisongeschäft), kaufen. Ist er strategisch und langfristig, hat Build typischerweise niedrigere TCO und mehr Kontrolle.

Lock-in — das unterschätzte Risiko

Vendor-Lock-in hat im KI-Kontext drei Formen, die schlimmer sind als klassisches Software-Lock-in:

Datenseitigem Lock-in. Wenn Ihre Unternehmensdaten (Dokumente, Historien, Annotationen, Feedback) ausschließlich auf der Plattform des Vendors leben, ist die Migration schmerzhaft bis unmöglich. Prüfen Sie vor dem Kauf immer: Kann ich 100 % meiner Daten in einem Standardformat exportieren? Wenn nicht, befinden Sie sich ab Tag eins im Lock-in.

Modell-Lock-in. Wenn Sie Prompt-Logik, Fine-tuning-Datensätze oder Evaluierungen für ein bestimmtes Modell aufgebaut haben (z. B. GPT-4-Klasse), erfordert die Migration auf ein anderes Modell eine Überarbeitung — auch wenn das neue Modell besser ist. Lösung: eine Abstraktionsschicht in der Orchestrierung, in der das Modell eine Konfiguration ist, kein Hardcode.

Integrations-Lock-in. Einige Plattformen bieten Konnektoren zu Ihren Systemen — ERP, CRM, SCADA. Wenn diese Konnektoren proprietär und undokumentiert sind, tauschen Sie die Plattform nur zum Preis einer vollständigen Integration-Neuentwicklung aus. Bevorzugen Sie immer offene APIs und Standardprotokolle.

Die gute Nachricht: Open-Weight-Modelle (Llama 4, Qwen 3, Mistral — die meisten unter Apache 2.0 oder einer vergleichbaren kommerziellen Lizenz) haben den Modell-Lock-in in den letzten zwei Jahren grundlegend gesenkt. Frontier-Leistung ist lokal erreichbar, ohne an einen bestimmten Anbieter gebunden zu sein.

Entscheidungskarte — 5 Fragen vor dem Urteil

Gehen Sie im Team diese fünf Fragen durch, bevor Sie eine abschließende Entscheidung treffen:

1. 1.Ist der Use-Case Commodity? Wenn zwei Dutzend Unternehmen in der gleichen Branche dasselbe Problem auf dieselbe Weise lösen, ist eine fertige Lösung wahrscheinlich effizienter.
2. 2.Sind unsere Daten eine Quelle der Differenzierung? Wenn ja, müssen Sie selbst entwickeln — ein fertiges Produkt verarbeitet sie nicht so, dass Sie einen Vorteil daraus ziehen.
3. 3.Dürfen Daten das Netzwerk verlassen? Wenn nicht, ist Build/On-Prem die einzige Option.
4. 4.Haben wir ein Team (oder können wir eines aufbauen), das entwickelt und wartet? Build ohne kompetentes Team ist schlechter als Buy — die Zusammensetzung des Teams für ein KI-Projekt ist ein separates Thema, das parallel gelöst werden muss.
5. 5.Wie lange planen wir, diese Lösung zu betreiben? Unter 12 Monate oder bei unsicherem Use-Case → kaufen. 2+ Jahre mit klaren Ergebnissen → Build oder Hybrid schneidet besser ab.

Wenn die Antworten auf diese Fragen keinen eindeutigen Sieger ergeben, handelt es sich meistens um einen Hybridfall — Basisschichten kaufen, Domänenspezialisierung selbst entwickeln.

Typische Fehler, die wir beobachten

Den gesamten Stack von einem einzigen Vendor kaufen, ohne zu prüfen, ob jede Schicht tatsächlich Best-in-Class ist. Plattformen, die alles machen, machen nichts wirklich gut. Immer mehr erfolgreiche produktive Implementierungen kombinieren Komponenten verschiedener Anbieter: Modell-API von einer Seite, Vektordatenbank Open-Source, Orchestrierung eigens entwickelt.

Entwickeln ohne definierten Use-Case. „Wir wollen KI, also bauen wir es selbst" ist eine Expedition ohne Karte. Die meisten Projekte, die wir scheitern gesehen haben, hatten vor dem Start keine definierten Erfolgsmetriken — und damit auch keine Möglichkeit zu erkennen, ob das, was sie entwickeln, Wert hat. ROI von KI-Projekten muss vom ersten Tag an gemessen werden.

Unterschätzung der Datenkosten. Bevor Sie entwickeln können, brauchen Sie Daten — bereinigt, strukturiert, in einem Format, das ein LLM verarbeiten kann. Laut Cisco AI Readiness Index bewerten nur ~34 % der Unternehmen ihre Datenbereitschaft als ausreichend. Wenn Sie zu den anderen 66 % gehören, ist die Datenpipeline Ihr erstes Projekt — nicht die KI selbst.

Den EU AI Act ignorieren. Ab August 2026 gelten konkrete Pflichten für Unternehmen, die KI-Systeme in regulierten Kontexten einsetzen. Wenn Sie eine Plattform kaufen, prüfen Sie, ob der Vendor Compliance-Dokumentation bereitstellt. Wenn Sie selbst entwickeln, liegt die Compliance-Dokumentation in Ihrer Verantwortung. Diesen Aspekt heute zu ignorieren, kann bedeuten, die Lösung später überarbeiten zu müssen.

Häufige Fragen

Macht es Sinn, eine fertige Lösung als Proof-of-Concept zu testen und sie dann durch eine eigene zu ersetzen?

Ja, aber mit einer Bedingung: Der Pilot muss Ihren konkreten Use-Case testen, kein generisches Demo. Wenn ein Pilot mit einer gekauften Lösung zeigt, dass der Use-Case Wert hat, haben Sie einen Nachweis für die Investition in eine eigene Entwicklung. Wichtig ist, dass die Pilotarchitektur die Datenlogik von der Plattform trennt — so gestaltet sich die spätere Migration einfacher.

Was bedeutet „Open-Weight-Modell" im Hinblick auf Lizenz und kommerziellen Einsatz?

Modelle wie Qwen 3 oder Mistral werden unter der Apache-2.0-Lizenz veröffentlicht — Sie können sie kommerziell ohne Lizenzgebühren nutzen. Llama 4 hat eine eigene Lizenz (kostenloser kommerzieller Einsatz bis zu einem bestimmten Limit an monatlich aktiven Nutzern). Überprüfen Sie immer die aktuellen Lizenzbedingungen des jeweiligen Modells und der jeweiligen Version vor dem Einsatz.

Ist eine On-Prem-Implementierung für ein Unternehmen ohne großes IT-Team realistisch?

Ja, wenn der Use-Case klar abgegrenzt ist. Einen GPU-Server mit Ollama und einem kleineren Open-Weight-Modell (z. B. Qwen 3 8B oder Phi-4 14B) kann ein erfahrener Ingenieur in einem Tag bereitstellen. Anspruchsvoller ist eine produktive Implementierung mit hoher Verfügbarkeit, Monitoring und CI/CD — das erfordert mehr. Die richtige Wahl für ein Unternehmen ohne KI-Team ist in der Regel eine betreute On-Prem-Lösung mit externer Unterstützung, keine selbstverwaltete Infrastruktur.

Wann ist Fine-tuning Teil einer „Build"-Strategie und wann nicht?

Fine-tuning macht Sinn, wenn Sie das Modell auf Ihr Sprachregister, Ihre Terminologie oder Ihr Ausgabeformat spezialisieren möchten — und wenn Sie ausreichend qualitative Trainingsdaten haben (orientierend 5.000+ Beispielpaare für ein grundlegendes SFT). Wenn Sie keine Daten haben oder wenn das Problem mit einer gut konzipierten RAG-Pipeline lösbar ist, ist Fine-tuning eine verfrühte Optimierung. Mehr zu dieser Entscheidung im Artikel RAG vs. Fine-tuning.

Was ist die häufigste Ursache dafür, dass Build-Projekte das Budget überschreiten?

Aus unserer Erfahrung: die Unterschätzung von Evaluierung und Iteration. Die erste Version zu entwickeln, dauert vorhersehbar lang — aber zu messen, ob sie funktioniert, zu erkennen, wo sie versagt, und das zu beheben, dauert genauso lang nochmal. Projekte, die das von Anfang an einplanen, liefern im Zeit- und Budgetrahmen. Projekte, die davon ausgehen, dass die erste Version produktionsreif ist, nicht.

*MP Industrial Solutions unterstützt Unternehmen bei der Build-vs.-Buy-Entscheidung mit konkreten Zahlen in der Hand — von der Use-Case-Kartierung über TCO-Kalkulationen bis zur ersten produktiven Implementierung. Wenn Sie vor dieser Entscheidung stehen, bewerten wir Ihren konkreten Fall gerne gemeinsam mit Ihnen.*