Zum Inhalt springen
EN DE

Build vs. Buy

Dein CTO will ein eigenes LLM fine-tunen. Dein CEO hat gehört, dass Cursor mit einem “API Wrapper” Milliarden wert ist. Dein ML-Lead sagt, RAG sei “die Zukunft”. Alle reden über unterschiedliche Dinge, alle haben irgendwie recht.

Du bist der Product Manager. Du musst nicht entscheiden wie gebaut wird — aber wo auf dem Spektrum ihr startet. Und diese Entscheidung bestimmt Budget, Timeline und Vendor-Abhängigkeit für die nächsten Jahre.

Build vs. Buy ist keine binaere Entscheidung. Es ist ein Spektrum mit fuenf Stufen — und die meisten Teams starten zu weit oben.

LevelAnsatzKostenTime-to-ValueKontrolle
1Prompt Engineering$0–100/MonatStunden/TageNiedrig
2API Integration$100–10K/MonatTage/WochenMittel
3RAG (Retrieval-Augmented Generation)$70–1K/Monat InfraWochenMittel-Hoch
4Fine-Tuning$600–50K+Wochen/MonateHoch
5Training from Scratch$100K–$100M+Monate/JahreMaximum

Die goldene Regel: Starte auf Level 1 und eskaliere nur, wenn die vorherige Stufe nachweislich nicht reicht. Prompt Engineering → RAG → Fine-Tuning → Custom Model.

Diese Entscheidung trifft fast jedes AI-Produktteam irgendwann:

KriteriumRAGFine-Tuning
Aktuelle DatenJa (Echtzeit-Updates)Nein (Snapshot beim Training)
TCO10–50x guenstigerHoch (Training + Hosting)
QuelltransparenzJa (zitierbare Quellen)Nein (implizites Wissen)
Output-KonsistenzVariabelHoch (gelerntes Format)
Domaenen-SpezialisierungMittelHoch
Offline-DeploymentNeinJa
Team-SkillsData EngineeringML Engineering

67% der Organisationen wollen Abhängigkeit von einem einzigen AI-Provider vermeiden. Trotzdem bauen die meisten Teams direkt auf einer API auf — ohne Abstraktionsschicht.

Die Folgen: 57% der IT-Entscheider haben im letzten Jahr über $1M für Plattformmigrationen ausgegeben. Als OpenAI im Juni 2025 global ausfiel, waren Zendesk-Features stundenlang nicht verfügbar.

Schutzstrategien:

  • AI Gateway als Abstraktionsschicht (Gartner: bis 2028 nutzen 70% der Multi-LLM-Apps ein Gateway, vs. unter 5% in 2024)
  • Multi-Provider-Strategie für kritische Features
  • Modulare Architektur mit austauschbaren LLM-Modulen
  • Vertragliche Exit-Klauseln und Datenportabilitaet

Die Eskalationsmatrix — starte unten, gehe nur hoch wenn noetig:

FrageJa →Nein →
Reicht ein guter Prompt?Bleib bei Level 1Weiter
Braucht es eigene Daten im Context?RAG (Level 3)API reicht (Level 2)
Muss das Output-Format exakt konsistent sein?Fine-Tuning prüfen (Level 4)RAG reicht
Gibt es regulatorische Gruende für volle Kontrolle?Custom Model prüfen (Level 5)Fine-Tuning reicht

Vor jedem Level-Up fragen: Habe ich die aktuelle Stufe wirklich ausgereizt — oder hoffe ich, dass mehr Komplexität mein eigentliches Problem loest?

Du bist PM bei einem B2B-SaaS für Vertragsverwaltung. Feature-Anfrage: AI soll Vertraege zusammenfassen und Risiko-Klauseln markieren. 2.000 Kunden, 50.000 Vertraege/Monat.

Drei Optionen auf dem Tisch:

  • Option A — API (Level 2): Claude API + Prompting. $3K/Monat API-Kosten. Live in 2 Wochen.
  • Option B — RAG (Level 3): API + eigene Vertrags-Datenbank als Context. $5K/Monat gesamt. Live in 6 Wochen.
  • Option C — Fine-Tuning (Level 4): Eigenes Modell auf 100.000 annotierten Vertraegen. $80K Setup + $8K/Monat. Live in 4 Monaten.

Zusaetzlicher Kontext:

  • 42% der Unternehmen haben 2024 AI-Initiativen eingestellt — haeufigster Grund: zu frueh zu komplex gebaut
  • Klarna automatisierte 2/3 ihrer Chats per API, erzielte $40M Profit — musste dann zurueckrudern (“zu stark auf Effizienz fokussiert”) und wechselte zu einem Hybrid-Modell
  • GitHub Copilot (API-basiert): 15M Nutzer, 55% schnellere Tasks, aber 41% hoehere Code Churn Rate
Welchen Ansatz waehlst Du?

Die beste Entscheidung: Starte mit Option B (RAG) — aber baue Option A als erstes, um schnell zu lernen.

Warum:

  • Option A zuerst: In 2 Wochen live, echtes Nutzerfeedback. Prompt Engineering auf Vertraege ist ueberraschend leistungsfaehig
  • Dann Option B: Die eigene Vertragsdatenbank als RAG-Context verbessert die Erkennung kundenspezifischer Klausel-Muster erheblich
  • Option C ist zu frueh: Ohne 6+ Monate Nutzungsdaten weisst Du nicht, worauf Du fine-tunen solltest. Die 42% gescheiterten AI-Initiativen haben genau diesen Fehler gemacht
  • Baue eine Abstraktionsschicht ein — wenn Claude morgen ausfaellt oder teurer wird, musst Du den Provider wechseln können

Was viele falsch machen: Fine-Tuning als ersten Schritt planen, bevor Prompt Engineering und RAG ausgereizt sind. Oder variable LLM-Kosten in ein Fixed-Pricing-Modell einkalkulieren, ohne Nutzungsvolumen-Szenarien durchzurechnen.

  • Build vs. Buy ist ein Spektrum, keine binaere Entscheidung. Die fuenf Level erfordern radikal unterschiedliche Budgets, Timelines und Team-Skills. Starte niedrig, eskaliere mit Daten.
  • RAG vor Fine-Tuning. RAG ist 10–50x guenstiger, liefert transparente Quellen und braucht kein ML-Team. Fine-Tuning lohnt sich erst, wenn RAG nachweislich nicht reicht.
  • Vendor Lock-in ist ein Produkt-Risiko, kein Infra-Detail. Ein AI Gateway und Multi-Provider-Faehigkeit gehören in die Architektur ab Tag 1 — nicht als “spaetere Optimierung”.
  • Cursor zeigt den Sweet Spot: API-Wrapper + proprietäre UX-Innovation = Multi-Milliarden-Bewertung. Du musst kein eigenes Modell bauen, um gewaltigen Wert zu schaffen.

Quellen: Gartner “Innovation Insight: AI Gateways” (2024), Klarna “AI Assistant Report” (2024/2025), GitHub Blog “Research: Quantifying Copilot’s Impact” (2024), Cursor Financials (2025), OpenAI Outage Report (Juni 2025), IDC “AI Platform Migration Survey” (2024)

Part of AI Learning — free courses from prompt to production. Jan on LinkedIn