+150 XP

Build, Buy oder Embed: KI-Anbieter bewerten

# Build, Buy oder Embed: KI-Anbieter bewerten

Ein mittelgroßes SaaS-Unternehmen für Customer Support hat 14 Monate und rund 2 Millionen Dollar in einen internen KI-Klassifizierer für Tickets investiert. Als er ausgeliefert wurde, erreichten die Standard-APIs von OpenAI und Anthropic die gleiche Genauigkeit zu einem Bruchteil der Kosten. Das Team hatte keinen Moat gebaut, sondern ein Museumsstück.

Dieses Szenario wiederholt sich im SaaS-Sektor jedes Quartal. Die Entscheidung ist nicht ideologisch (build gut, buy schlecht). Sie ist ein Tradeoff zwischen Kosten, Kontrolle und Geschwindigkeit, der sich danach richtet, was das KI-Feature für Ihr Produkt tatsächlich leistet.

Die drei Wege

Build: Die KI-Fähigkeit intern entwickeln, meist durch Fine-Tuning von Open-Weight-Modellen (Modelle wie Metas Llama oder Mistral, deren Weights, also die gelernten Parameter, öffentlich herunterladbar sind) oder durch Training eigener Modelle auf proprietären Daten.

Buy: Eine Point Solution kaufen, also ein Anbieterprodukt für genau eine Aufgabe (ein Tool zur Fraud Detection, ein Lebenslauf-Screening, eine Engine für Call-Transkription).

Embed: Eine Foundation-Model-API aufrufen (ein universell einsetzbares Large Language Model über das Internet, etwa GPT-4o, Claude oder Gemini) und die eigene Produktlogik und Oberfläche darum herum bauen.

Die meisten SaaS-Unternehmen nutzen 2026 alle drei parallel, für unterschiedliche Features. Die Kunst besteht darin, den richtigen Weg mit dem richtigen Use Case zu verbinden.

Die Tradeoffs bewerten

Gesamtkosten

Build sieht auf einer Folie günstig aus (nur Gehälter für Engineers), verbirgt aber Kosten: Data Labeling, GPU-/Cloud-Compute, laufendes Retraining und die Opportunitätskosten dafür, dass Ihre besten Engineers nicht am Kernprodukt arbeiten. Eine glaubwürdige Spanne für ein eigenes Modell mit echter Produktionsstabilität: mehrere Hunderttausend bis einige Millionen Dollar im ersten Jahr, vor Wartung.

Buy hat sichtbare, vorhersehbare Kosten: eine Subscription oder eine nutzungsabhängige Gebühr. Anbieter wie Intercom (Fin), Zendesk oder spezialisierte Fraud-Detection-Player (z. B. Sift) rechnen pro Seat oder pro Lösung eines Falls ab. Leicht zu budgetieren, schwerer anzupassen.

Embed-Kosten skalieren mit der Nutzung. Anfang 2026 liegen die API-Preise von OpenAI und Anthropic je nach Modellklasse im Bereich von wenigen Dollar bis einigen Dutzend Dollar pro Million Tokens (eine grobe, öffentlich gelistete Schätzung, die sich häufig ändert; aktuelle Sätze siehe OpenAIs Pricing-Seite). Die Kosten sind variabel, die festen Overheads niedrig. Ein Startup kann für unter 500 Dollar prototypen.

Rechenbeispiel: Ein SaaS-Unternehmen ergänzt ein KI-Summarization-Feature für 10.000 Kundengespräche pro Monat mit durchschnittlich 1.500 Output-Tokens je Gespräch.

  • 10.000 Calls × 1.500 Tokens = 15.000.000 Tokens/Monat
  • Bei einem beispielhaften Satz von 10 Dollar pro Million Output-Tokens: 15 × 10 $ = 150 $/Monat
  • Im Vergleich ein Point-Solution-Anbieter mit 0,50 $ pro Call: 10.000 × 0,50 $ = 5.000 $/Monat
  • Im Vergleich Build: ein ML Engineer mit voll belasteten ~180.000 $/Jahr, plus Compute, übersteigt im ersten Jahr amortisiert leicht 20.000 $/Monat.

Embed gewinnt hier bei den reinen Kosten, sofern das Call-Volumen nicht um den Faktor 100 wächst. Dann skaliert die API-Rechnung linear und die Ökonomie von Buy oder Build verändert sich.

Lock-in

Lock-in ist das Maß dafür, wie teuer oder langsam ein späterer Anbieterwechsel ist. Er kommt in drei Varianten:

  • Data Lock-in: Ihre proprietären Daten liegen im System eines Anbieters, und der Export oder die Weiterverwendung ist schwierig.
  • Workflow Lock-in: Die Prozesse Ihres Teams sind um das UI und die Eigenheiten eines Tools herum gebaut.
  • Model Lock-in: Ihre Prompts, Ihr Fine-Tuning und Ihr Evaluation-Harness sind auf das spezifische Verhalten eines Modells abgestimmt.

Der Kauf einer Point Solution bedeutet meist den tiefsten Lock-in: Der Wechsel des Fraud-Detection-Anbieters heißt, APIs neu zu integrieren, Mitarbeiter neu zu schulen und oft historisches Model Tuning zu verlieren.

Das Embedding von Foundation Models hat einen moderaten Lock-in. Anbieter unterstützen zunehmend portable Formate, und Open-Weight-Alternativen (Llama, Mistral, Qwen) erlauben Self-Hosting, wenn sich Preis oder Policy eines Anbieters ändern. Prompt Engineering und Evaluation Pipelines sind zwischen Modellfamilien aber selten ohne Nacharbeit vollständig portabel.

Build hat den geringsten Vendor Lock-in, aber den größten internen Lock-in: Die undokumentierten Entscheidungen Ihres eigenen Teams werden zur Abhängigkeit.

Time-to-Value

Embed ist am schnellsten. Ein funktionierender Prototyp mit GPT- oder Claude-APIs kann in Tagen ausgeliefert werden. Deshalb startete nahezu jedes zwischen 2023 und 2026 angekündigte SaaS-KI-Feature als eingebundener API-Call.

Buy ist schnell, wenn der Use Case des Anbieters eng zu Ihrem passt; langsam, wenn Sie viel Customizing brauchen (Integration, Security Review und Procurement können im Enterprise-Kontext Monate dauern).

Build ist fast immer am langsamsten. Selbst einfache eigene Modelle erfordern Datenerhebung, Labeling, Training, Evaluation und Safety-Tests vor dem Release.

Ein Entscheidungsframework

Stellen Sie vor der Wahl drei Fragen:

1. Ist diese Fähigkeit zentral für Ihren Wettbewerbsvorteil? Wenn KI *Ihr* Produkt ist (z. B. ein KI-Coding-Assistent), sind Build oder tiefes Customizing wahrscheinlich gerechtfertigt. Ist KI ein Feature, das an ein bestehendes Workflow-Tool angeflanscht wird (z. B. automatische Zusammenfassung von Tickets in einem CRM), dann embed oder buy.

2. Ist die zugrunde liegende Aufgabe commoditisiert? Textzusammenfassung, Übersetzung und einfache Klassifizierung sind bei Foundation-Model-Anbietern heute Commodity-Fähigkeiten. Build zahlt sich hier selten aus. Stark domänenspezifische Aufgaben (etwa das Parsen von Nischen-Rechtsverträgen mit proprietärer Taxonomie) können Fine-Tuning oder eine spezialisierte Point Solution rechtfertigen.

3. Wie sehen Ihr realistisches Nutzungsvolumen und Ihre Wachstumskurve aus? Geringes Volumen spricht für Embed (nahezu keine Fixkosten). Sehr hohes, stabiles Volumen kann die Rechnung in Richtung Build oder Self-Hosting eines Open-Weight-Modells kippen, da API-Kosten dauerhaft linear skalieren, Infrastrukturkosten aber abflachen können.

Ein einfacher Bauchtest, den mehrere SaaS-Produktverantwortliche nutzen: Wenn Sie nicht in einem Satz begründen können, warum diese KI-Fähigkeit proprietär sein muss, dann embed als Default.

Wissenscheck

1. Das 14-monatige Build-Projekt des Customer-Support-SaaS-Unternehmens im Millionenbereich illustriert vor allem welches Risiko des „Build“-Wegs?

2. Welcher Faktor unterscheidet den „Buy“-Weg am unmittelbarsten vom „Embed“-Weg?

3. Warum beschreibt die Lektion Build-Kosten als „auf einer Folie günstig aussehend“, während sie oft unterschätzt werden?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten: Welche der folgenden Aussagen beschreiben die drei in der Lektion dargestellten KI-Anbieterwege zutreffend?

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten: Was macht die Build-Buy-Embed-Entscheidung laut Lektion grundsätzlich zu einem Tradeoff statt zu einer ideologischen Wahl?

Wählen Sie alle richtigen Antworten aus.

Evaluations-Checkliste für jeden Anbieter oder jede API

Bevor Sie etwas unterschreiben, sollten SaaS-Käufer bei Anbietern nachbohren:

  • Benchmarks auf Ihren Daten, nicht auf deren. Öffentliche Benchmarks (etwa die auf Stanfords HELM getrackten) zeigen allgemeine Leistungsfähigkeit, nicht die Performance auf Ihren spezifischen Dokumenten oder der Sprache Ihrer Kunden.
  • Datenverarbeitung und Residency. Wohin gehen Ihre Daten? Werden sie für weiteres Modelltraining genutzt? Unterstützt der Anbieter für EU-Kunden die Anforderungen der DSGVO (Datenschutz-Grundverordnung) an Auftragsverarbeitungsverträge?
  • Latenz- und Uptime-SLAs (Service Level Agreements, vertragliche Garantien für Antwortzeit und Verfügbarkeit).
  • Exit-Plan. Können Sie Ihre Fine-Tuning-Daten, Prompts und Logs exportieren, wenn Sie gehen?
  • Regulatorische Exposition. Unter dem EU AI Act (in Stufen zwischen 2025 und 2027 wirksam) bringen bestimmte „hochriskante“ KI-Anwendungsfälle (z. B. Credit Scoring, Bewerber-Screening) Dokumentations- und Transparenzpflichten mit sich, die teilweise beim einsetzenden Unternehmen liegen, nicht nur beim Modellanbieter. Wenn Sie KI in einen regulierten Workflow kaufen oder einbinden, klären Sie, wer für Compliance verantwortlich ist.

Eine kurze technische Illustration

So sieht „Embedding“ in der Praxis aus, ein paar Zeilen, die eine Foundation-Model-API zur Klassifizierung von Support-Tickets aufrufen:

python
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Classify ticket urgency: low, medium, high."},
        {"role": "user", "content": ticket_text}
    ]
)
print(response.choices[0].message.content)

Das ist bei vielen SaaS-Produkten in der ersten ausgelieferten Version das komplette „KI-Feature“. Die Build-Entscheidung wird erst später relevant, wenn Genauigkeit, Kosten bei Skalierung oder Datenschutzanforderungen einen Wechsel zu Fine-Tuning oder Self-Hosting erzwingen.

Key Takeaways

  • Passen Sie den Weg zum Use Case an, nicht zum Trend. Commodity-Aufgaben (Summarization, Klassifizierung) sprechen für Embed; Kern-Differenzierer können Build rechtfertigen; enge, regulierte Aufgaben sprechen eher für eine spezialisierte Point Solution.
  • Kostenvergleiche müssen versteckte Kosten enthalten. Build verbirgt Engineering-Zeit und Wartung; Buy verbirgt Grenzen der Anpassbarkeit; Embed verbirgt langfristige Skalierungskosten.
  • Lock-in ist nicht binär. Bewerten Sie ihn getrennt entlang der Dimensionen Daten, Workflow und Modell, bevor Sie einen Vertrag unterschreiben.
  • Geschwindigkeit spricht fast immer für Embed. Nutzen Sie es, um Nachfrage zu validieren, bevor Sie in ein aufwändigeres Build- oder Buy-Investment gehen.
  • Compliance-Pflichten (EU AI Act, DSGVO) bleiben oft beim einsetzenden SaaS-Unternehmen, unabhängig vom gewählten Weg. Anbieterverträge sollten daher festlegen, wer welche Dokumentation verantwortet.