Ein Foundation-Model- und LLM-Business-Case stellt die Frage, ob und wie ein Unternehmen ein Large Language Model als zugrunde liegende Fähigkeit einführen sollte, nicht ob sich KI im Allgemeinen lohnt. Das Framework besteht aus vier Teilen — Entscheidung zur Modellbeschaffung, Kostenarchitektur, Differenzierungs-Moat und Anbieterrisiko. Die entscheidende Fähigkeit besteht darin, das Foundation Model selbst als Commodity-Input mit einer realen Kostenkurve zu betrachten und den eigentlichen geschäftlichen Wert an anderer Stelle zu verorten: in proprietären Daten, der Workflow-Integration oder der Gestaltung von Wechselkosten.
Foundation-Model- und LLM-Cases haben sich von generischen KI-Strategie-Cases abgespalten, weil die zugrunde liegende Entscheidung eine andere ist: welches Modell, wie gehostet, zu welchen Kosten pro Nutzungseinheit, mit welchem Abhängigkeitsrisiko. Basierend auf unserer Analyse aktueller Cases aus dem Technologiesektor präsentieren Interviewer zunehmend ein Szenario, in dem der Kunde bereits entschieden hat, ein Large Language Model einzusetzen, und testen dann, ob der Kandidat über Modellauswahl, Kostenstruktur und Vendor-Lock-in nachdenken kann — die Ebene unterhalb der Frage “Sollen wir überhaupt KI einsetzen?”, bei der die meisten generischen KI-Frameworks stehenbleiben.
Warum Foundation-Model-Cases ein eigenständiger Case-Typ sind
Ein generischer KI-Strategie-Case fragt, ob und wo ein Unternehmen in KI investieren sollte. Ein Foundation-Model-Case setzt diese Entscheidung voraus und testet etwas Enger Gefasstes: Gegeben, dass der Kunde ein Large Language Model einsetzen wird, wie sollte er es beziehen, wie die Preisgestaltung darum aufbauen und sich davor schützen, dass sich die Modell-Ebene unter ihm verändert. Dies ist ein Commodity-Input-Problem, das als Technologieproblem verkleidet ist, und Interviewer nutzen es, um zu prüfen, ob Kandidaten standardmäßig zu “einfach das beste Modell nehmen” tendieren oder tatsächlich über Total Cost of Ownership und Abhängigkeitsrisiko nachdenken.
Die drei Variablen, die diese Cases von einem Standard-Build-vs-Buy-Case unterscheiden:
| Variable | Warum sie sich von Standard-Software unterscheidet | Was sie Sie zu analysieren zwingt |
|---|---|---|
| Token-basierte Kosten | Grenzkosten skalieren mit Nutzungsvolumen und Output-Länge, nicht mit pauschaler Lizenzierung | Bruttomarge im Skalenbereich, nicht nur Anfangskosten |
| Modell-Fluktuation | Frontier-Modelle werden alle 6-12 Monate abgekündigt, neu bepreist oder übertroffen | Wechselkosten und Multi-Modell-Architektur |
| Commodity-Kern | Die meisten Anbieter greifen auf dieselbe Handvoll zugrunde liegender Modellfamilien zurück | Woher die tatsächliche Verteidigungsfähigkeit kommt |
Das Foundation-Model-Entscheidungs-Framework
Vier Fragen bestimmen, wie ein Unternehmen ein Produkt oder eine Fähigkeit angehen sollte, die von einem Foundation Model abhängt, und sie müssen in dieser Reihenfolge beantwortet werden — Kosten- und Risiko-Schlussfolgerungen ergeben erst Sinn, wenn die Beschaffung geklärt ist.
flowchart TD
A[Foundation-Model-Geschäftsentscheidung] --> B[Modellbeschaffung]
A --> C[Kostenarchitektur]
A --> D[Differenzierungs-Burggraben]
A --> E[Vendor-Risiko]
B --> B1[Frontier-API vs. Open-Weight vs. Fine-Tune]
B --> B2[Einzelmodell vs. Multi-Modell-Routing]
C --> C1[Kosten pro Token beim Zielvolumen]
C --> C2[Bruttomarge im Skalenbereich, nicht im Pilotprojekt]
D --> D1[Proprietäre Datenebene]
D --> D2[Workflow-Integration vs. reiner Output]
E --> E1[Risiko durch Abkündigung und Neubepreisung]
E --> E2[Wechselkosten bei Vertragsänderungen des Anbieters]
style A fill:#1e3a5f,color:#fff
style B fill:#2563eb,color:#fff
style C fill:#2563eb,color:#fff
style D fill:#2563eb,color:#fff
style E fill:#2563eb,color:#fff
Teil 1: Die Modellbeschaffungs-Entscheidung
Die meisten Kandidaten springen direkt zu “sollten wir unser eigenes Modell entwickeln” — fast immer der falsche Instinkt. Ein Foundation Model von Grund auf zu trainieren erfordert Hunderte von Millionen Dollar an Compute und Daten, eine Hürde, die nur eine Handvoll Unternehmen weltweit überwinden kann. Die eigentliche Beschaffungsentscheidung liegt eine Ebene darunter.
| Ansatz | Kostenstruktur | Time to Deploy | Differenzierung | Beste Eignung |
|---|---|---|---|---|
| Frontier-API (Pay-per-Token) | Variabel, skaliert mit der Nutzung | Tage bis Wochen | Niedrig — Wettbewerber greifen auf dasselbe Modell zu | Schnelle Validierung, nicht kernrelevante Funktionen |
| Open-Weight, selbst gehostet | Feste Infrastruktur + Betrieb, nahezu null Grenzkosten | Wochen bis Monate | Mittel — Kontrolle über Deployment und Daten | Hochvolumige Workloads, Anforderungen an Datenresidenz |
| Fine-Tuning auf Basis eines Foundation Models | API-/Hosting-Gebühr + einmalige Tuning-Kosten | Wochen | Mittel bis hoch — proprietäre Datenebene über der Commodity-Basis | Domänenspezifische Genauigkeit bei moderatem Volumen |
| Von Grund auf trainiert | 50-500+ Mio. USD Compute und Daten | 12+ Monate | Theoretisch hoch, in der Praxis selten gerechtfertigt | Extreme Skalierung oder einzigartige Architekturanforderungen — ein enger Kreis von Fällen |
Die Erkenntnis, die Interviewer honorieren: Für die überwältigende Mehrheit der Unternehmen ist “eigenes Foundation Model entwickeln” die falsche Antwort, und die stärksten Kandidaten schließen diese Option explizit mit einem Kostenargument aus, statt einfach daran vorbeizugehen.
Teil 2: Kostenarchitektur — Wo die Marge tatsächlich einbricht
Modell-Ökonomie sieht in einem Pilotprojekt attraktiv aus und wird im Skalenbereich fragil, weil Pilotprojekte mit kleinen Volumina laufen, bei denen Token-Kosten im Vergleich zu eingesparten Personalkosten unsichtbar sind. Strukturieren Sie Ihre Kostenanalyse rund um die Bruttomarge beim Zielvolumen, nicht um das Pilotprojekt.
Wichtige Kostenkomponenten, die Kandidaten routinemäßig unterschätzen:
- Output-Länge, nicht nur Input-Länge: Anbieter bepreisen Output-Tokens typischerweise mit einem Vielfachen der Input-Tokens — eine Funktion, die Langform-Output generiert (Berichte, Code, Zusammenfassungen), kostet pro Interaktion deutlich mehr als eine, die kurze Antworten klassifiziert oder extrahiert.
- Context-Window-Inflation: Retrieval-Augmented-Workflows, die lange Dokumente in jeden Aufruf packen, multiplizieren die Kosten pro Anfrage, oft schneller, als Teams es in ihrem anfänglichen Business Case modellieren.
- Retry- und Korrektur-Overhead: Hallucination-Handling — menschliche Überprüfung, erneutes Prompting, Fallback-Logik — verursacht Kosten, die im anfänglichen ROI-Modell selten auftauchen, sich aber sofort in der Produktion zeigen.
Ein nützlicher Realitätscheck für ein Case-Interview: Wenn die KI-Funktion pro Nutzer und Monat mehr kostet, als der zusätzliche Abonnement-Umsatz einbringt, den sie freisetzt, scheitert der Business Case unabhängig davon, wie gut die Output-Qualität ist. Für die weiterführende Mechanik der Go-to-Market-Preisgestaltung unter dieser Kostenstruktur siehe KI-Produkteinführungs-Cases.
Teil 3: Differenzierungs-Burggraben — Wo der Wert tatsächlich liegt
Da die meisten Anbieter auf dieselbe kleine Gruppe zugrunde liegender Modellfamilien zurückgreifen, ist das Modell selbst selten der Differenzierungsfaktor. Interviewer nutzen diesen Case-Typ gezielt, um zu testen, ob ein Kandidat Wert an einer anderen Stelle als “unsere KI ist schlauer” lokalisieren kann.
Drei Stellen, aus denen Verteidigungsfähigkeit tatsächlich entstehen kann:
- Proprietäre Datenebene: Fine-Tuning oder Retrieval, das auf Daten basiert, auf die Wettbewerber keinen Zugriff haben — historische Transaktionsdaten, interne Dokumente, domänenspezifische gelabelte Beispiele.
- Workflow-Integration: In das Tool eingebettet zu sein, in dem der Nutzer bereits arbeitet, schlägt ein technisch überlegenes eigenständiges Produkt, das einen Kontextwechsel erfordert.
- Vertrauens- und Validierungsinfrastruktur: Konfidenzbewertung, Audit-Trails und Human-in-the-Loop-Überprüfung, die Output in regulierten oder risikoreichen Workflows nutzbar machen — ein Burggraben, in den Wettbewerber zu wenig investieren, weil er in einer Demo nicht sichtbar ist.
Wenn keine dieser drei Punkte zutrifft, lautet die ehrliche Antwort in einem Case-Interview, dass die KI-Funktion ein vorübergehender Gleichstand-Move ist, kein dauerhafter Vorteil — und die Empfehlung sollte entsprechend bepreist und mit Ressourcen ausgestattet werden.
Teil 4: Vendor-Risiko und Modell-Fluktuation
Die Abhängigkeit von Foundation Models bringt eine Risikokategorie mit sich, die es bei der Standard-Softwareanbieterauswahl nicht gibt: Das zugrunde liegende Modell selbst wird ungefähr alle 6-12 Monate abgekündigt, neu bepreist oder von einem Wettbewerber überholt.
flowchart LR
A[Vendor-Risiko-Exposure] --> B[Abkündigungsrisiko]
A --> C[Neubepreisungsrisiko]
A --> D[Risiko durch Fähigkeitssprung]
B --> B1[Modell-Sunset mit kurzem Migrationsfenster]
C --> C1[Preisänderungen pro Token außerhalb der eigenen Kontrolle]
D --> D1[Wettbewerber liefert auf Basis eines deutlich besseren Modells]
Gegenmaßnahmen, die Kandidaten ansprechen sollten: eine Abstraktionsebene entwerfen, die es dem Produkt erlaubt, zugrunde liegende Modelle ohne einen kompletten Umbau zu tauschen, Evaluierungs-Benchmarks pflegen, damit ein Modellwechsel schnell validiert werden kann, und eine enge Kopplung an proprietäre Funktionen eines einzelnen Anbieters (Fine-Tuning-APIs, Tool-Calling-Formate) vermeiden, die teuer rückgängig zu machen wäre. Für das breitere Build-vs-Buy-Toolkit, aus dem diese Risikobetrachtung schöpft, siehe Tech-Build-vs-Buy-Entscheidungs-Cases.
Typische Case-Szenarien
Szenario 1 — Beschaffungsentscheidung für eine neue Funktion. Ein B2B-SaaS-Unternehmen möchte eine LLM-gestützte Dokumentenanalyse-Funktion hinzufügen. Sollte es eine Frontier-API aufrufen, ein Open-Weight-Modell selbst hosten oder Fine-Tuning betreiben? Arbeiten Sie zuerst Teil 1 durch — schlagen bei dem erwarteten Volumen feste Selbsthosting-Kosten die variable API-Preisgestaltung, und benötigt der Anwendungsfall Frontier-Level-Reasoning oder reicht ein kleineres, günstigeres Modell aus?
Szenario 2 — Vendor-Konzentrationsrisiko. Ein Unternehmen hat sein Kernprodukt auf einem einzigen Foundation-Model-Anbieter aufgebaut. Dieser Anbieter hat gerade die Preise um 40 % mit 90 Tagen Vorlauf erhöht. Diagnostizieren Sie die Wechselkosten (Teil 4) und strukturieren Sie dann eine Antwort: Kosten selbst tragen, an Kunden weitergeben oder in eine Multi-Modell-Architektur investieren, um zukünftige Exposition zu reduzieren.
Szenario 3 — Margenerosion im Skalenbereich. Eine KI-Funktion, die in einem Pilotprojekt mit 500 Nutzern profitabel aussah, verliert bei 50.000 Nutzern Geld. Gehen Sie Teil 2 durch, um herauszufinden, wo das Kostenmodell zusammengebrochen ist — meist Output-Länge, Wachstum des Context-Windows oder Retry-Overhead, den das Pilotprojekt nie sichtbar machte —, bevor Sie eine Preis- oder Architekturkorrektur empfehlen.
Wichtige Erkenntnisse
- Foundation-Model-Cases setzen voraus, dass “ein LLM einsetzen” bereits entschieden ist, und testen stattdessen Modellbeschaffung, Kostenarchitektur, Differenzierung und Vendor-Risiko
- Ein Foundation Model von Grund auf zu trainieren ist für fast jedes Unternehmen die falsche Standardantwort — schließen Sie diese Option explizit mit einem Kostenargument aus
- Strukturieren Sie die Kostenanalyse rund um die Bruttomarge beim Zielvolumen, nicht um die Pilotprojekt-Ökonomie — Output-Länge und Wachstum des Context-Windows sind die am häufigsten unterschätzten Kostentreiber
- Da die meisten Anbieter auf dieselben zugrunde liegenden Modelle zurückgreifen, muss Differenzierung aus proprietären Daten, Workflow-Integration oder Vertrauensinfrastruktur kommen — nicht aus dem Modell selbst
- Vendor-Risiko ist eine eigenständige Kategorie gegenüber Standard-Software-Risiko: Modell-Abkündigung, Neubepreisung und Fähigkeitssprünge geschehen in einem 6-12-Monats-Zyklus
- Eine starke Empfehlung beinhaltet eine Abstraktionsebene oder einen Evaluierungsprozess, der es dem Kunden erlaubt, Modelle ohne einen kompletten Umbau zu tauschen
Foundation-Model- und LLM-Cases üben
Entdecken Sie strategische Entscheidungs-Cases und Kostensenkungs-Cases in unserer Case-Bibliothek, oder lesen Sie KI- und Emerging-Tech-Cases für die breitere KI-Strategie-Ebene, auf der dieses Framework aufbaut.
Um echtes Urteilsvermögen für dieses Framework aufzubauen, kommt es mehr auf Übung als auf Lesen an. Der Guided Mode von CasesCoach führt Sie durch einen Foundation-Model-Beschaffungs-Case mit Hinweisen an jedem Entscheidungspunkt — nützlich, um die Struktur aufzubauen, bevor Sie sie unter Druck anwenden können. Sobald das Framework selbstverständlich sitzt, wechseln Sie zum Expert Mode, um vollen Interviewdruck ohne Unterstützung zu simulieren. Für ein Szenario wie den obigen Vendor-Konzentrations-Case lässt Sie Chat with Case einen echten Foundation-Model-Case end-to-end durcharbeiten — Hintergrund, Framework-Auswahl, Datenanalyse und Empfehlung —, während ein KI-Partner in Echtzeit Ihre Logik hinterfragt.
Jede Session bewertet Sie über fünf Dimensionen — Struktur, Analyse, Kommunikation, Business Acumen und Mathematik —, damit Sie genau wissen, wo die Lücken liegen, bevor es ins echte Interview geht.
Melden Sie sich kostenlos an, um 3 vollständige Cases plus eine KI-Mock-Interview-Session auszuprobieren. Bereit für mehr? Pro schaltet alle 835+ Cases der Bibliothek und mehrere KI-Mock-Interview-Sessions frei. Starten Sie mit dem KI-Mock-Interview oder sehen Sie sich die Preise für Details zu den Plänen an.