Corporate LLM: selbst bauenoder einkaufen?

„Sollen wir uns nicht einfach ein eigenes KI-Modell bauen — wegen der Daten?" Diese Frage hören wir in fast jedem Erstgespräch mit einem Mittelständler. Die Sorge dahinter ist berechtigt. Die spontane Antwort darauf ist 2026 trotzdem meistens falsch.

Dieser Leitfaden ordnet die Build-vs-Buy-Entscheidung mit belegten Zahlen ein — Modellqualität, Kosten, Datenschutz, EU AI Act — und sagt dir auch, wo Eigenbetrieb sich wirklich lohnt und wo nicht. Eine Vorbemerkung: Modellpreise und Anbieter-Konditionen ändern sich 2026 im Monatstakt. Alle Zahlen sind ein datierter Snapshot, kein Naturgesetz.

„Corporate LLM" oder „Enterprise LLM" ist kein einzelnes Produkt, sondern ein Spektrum. Bevor man Build gegen Buy abwägt, lohnt es, die Begriffe zu sortieren — weil die meisten Missverständnisse genau hier entstehen:

• Buy — kommerzielle API im Enterprise-Tier. Du nutzt ein fertiges Modell (z. B. von OpenAI, Anthropic, Google) über eine Schnittstelle, mit vertraglichen Datenschutz-Zusagen. Kein eigenes Modell, kein eigener Betrieb.
• Build — ein eigenes LLM selbst hosten. Du betreibst ein offenes Modell (Llama, Mistral, DeepSeek, Qwen) selbst — auf eigener oder gemieteter Infrastruktur. Volle Kontrolle, voller Betriebsaufwand.
• RAG statt eigenes Modell. „Das Modell soll unsere Daten kennen" heißt fast nie „eigenes Modell trainieren". Meist ist Retrieval-Augmented Generation gemeint: ein fertiges Modell beantwortet Fragen auf Basis deiner Dokumente, ohne dass diese ins Modell eintrainiert werden.
• Fine-Tuning. Ein bestehendes Modell wird auf deinen Stil oder deine Aufgaben nachtrainiert. Aufwändiger als RAG und nur in spezifischen Fällen nötig.

Der wichtigste Unterschied ist nicht der Preis pro Token, sondern die Struktur der Kosten und die Zeit bis zur Produktivität:

• Buy ist der schnellste Weg zur Produktivität. Eine API ist in Tagen angebunden, du brauchst praktisch keine eigene Hardware. Die Vorab-Investition steckt in Security-Reviews, Integration und Schulung — nicht in Rechenzentrum und GPUs.
• Buy skaliert variabel — mit Budget-Unsicherheit. Du zahlst nach Nutzung. Das ist im Einstieg günstig, schafft aber Planungsunsicherheit: Anbieter können Preise anpassen oder Einführungsrabatte beenden.
• Build hat stabile, aber hohe Fixkosten. Eigene oder gemietete GPUs, Strom, Wartung und vor allem qualifiziertes Personal laufen unabhängig von der Nutzung weiter. Dafür ist der Preis pro Anfrage am Ende sehr niedrig — wenn die Auslastung stimmt.

Anders gesagt: Buy verschiebt die Kosten von der Investition (CAPEX) in den laufenden Betrieb (OPEX) und macht sie planbar klein — bis das Volumen sehr groß wird. Genau dort beginnt die Zahlen-Frage.

Zwei Größen entscheiden die rationale Wahl — wie gut die offenen Modelle inzwischen sind, und wie viel günstiger sie pro Token laufen. Dazu der DACH-Kontext, der den Datensouveränitäts-Druck quantifiziert:

Die ehrliche Lesart: Offene Modelle sind dramatisch günstiger — aber der Preisvorteil kommt mit einem realen Qualitätsabstand zur proprietären Spitze. Für viele Standardaufgaben (Zusammenfassen, Klassifizieren, einfache Texte) reicht ein offenes Modell locker. Für anspruchsvolles Reasoning bleibt die proprietäre Spitze vorn.

Und der Break-even? Im Netz kursieren konkrete Schwellen — „ab 10 Millionen Token pro Tag rechnet sich Self-Hosting". Wir haben diese Zahlen geprüft und bewusst aussortiert: Sie stammen aus Sekundärquellen und halten einer Prüfung nicht stand. Belastbar ist nur die Richtung: Der Punkt, ab dem Eigenbetrieb insgesamt günstiger wird, liegt bei sehr hohem, dauerhaftem Volumen — für die meisten Mittelständler unrealistisch hoch. Wer dir eine pauschale Token-Schwelle nennt, rechnet zu einfach.

Das ist der Punkt, an dem die meisten US-Vergleiche schweigen — und der für den deutschen Mittelstand oft den Ausschlag gibt. Zwei Sorgen muss man trennen:

• „Trainiert der Anbieter auf unseren Daten?" Im Enterprise- und API-Tier lautet die Antwort bei den großen Anbietern standardmäßig: nein. OpenAI, Azure OpenAI, Anthropic und Google trainieren laut eigenen Bedingungen per Default nicht auf Geschäftskunden-Daten und schließen Auftragsverarbeitungsverträge (AVV/DPA) ab. Achtung: Das gilt für die bezahlten Enterprise-Stufen — nicht für kostenlose Consumer-Apps.
• „Wo werden die Daten verarbeitet?" Hier unterscheiden sich die Anbieter deutlich — und hier liegt die eigentliche Buy-Entscheidung für DSGVO-sensible Branchen.

Diese Tabelle ist der Grund, warum „welches Modell ist das beste?" die falsche erste Frage ist. Für ein DSGVO-Publikum lautet sie: welcher Anbieter verarbeitet wo — und unter welchem Vertrag? Ein exzellentes Modell ohne EU-Verarbeitungspfad ist für sensible Daten keine Option, solange es nicht über eine EU-Partnercloud läuft.

Der EU AI Act wird ab dem 2. August 2026 breit anwendbar, erste Pflichten (etwa zur KI-Kompetenz im Unternehmen) gelten bereits. Für die Build-vs-Buy-Frage ist eine Unterscheidung zentral:

• Die meisten Mittelständler sind „Anwender" (Deployer), nicht „Anbieter". Laut Bitkom sehen sich nur 23 % der Unternehmen als Anwender betroffen, 1 % als Anbieter. Wer ein KI-System einkauft und nutzt, trägt deutlich weniger regulatorische Last als wer eines in Verkehr bringt.
• Buy verlagert Provider-Pflichten auf den Anbieter. Kaufst du ein Modell als API ein, trägt der Anbieter den Großteil der Pflichten für das KI-Modell selbst. Baust du dein eigenes, rückst du näher an die Anbieter-Rolle — mit allem, was an Dokumentation und Konformität dranhängt.

Das ist ein selten genanntes, aber handfestes Argument für Buy: Compliance ist nicht nur eine Frage der Daten, sondern auch der Haftungsverteilung. Der Aufwand ist real — 93 % der betroffenen Unternehmen erwarten laut Bitkom einen hohen Umsetzungsaufwand (eine Wahrnehmungszahl, aber eine vielsagende).

Buy ist die Standard-Antwort — nicht die einzige. Es gibt klare Fälle, in denen Eigenbetrieb oder eine Hybrid-Architektur die bessere Entscheidung ist:

• Strenge Datensouveränität. Wenn aus regulatorischen oder vertraglichen Gründen wirklich nichts das eigene Perimeter verlassen darf (z. B. Teile des Gesundheits-, Finanz- oder Verteidigungssektors), führt an einem self-hosted oder dedizierten Modell kaum ein Weg vorbei. Der europäische Anbieter Mistral etwa deckt genau diesen Mittelweg ab — bis hin zum Betrieb im eigenen Rechenzentrum.
• Sehr hohes, dauerhaftes Volumen. Wer ein gleichbleibend hohes Anfragevolumen hat, kann den Fixkostenblock des Self-Hostings über die Auslastung rechtfertigen. Das ist eine Einzelfallrechnung, keine Faustregel.
• Hybrid als Normalfall. In der Praxis ist die Frage selten „alles Cloud oder alles lokal", sondern: welcher Inhalt darf in die API, welcher bleibt lokal? Sensible Daten laufen über ein lokales Modell, der unkritische Rest über die beste verfügbare API. Genau diese Logik nutzen wir auch in unserer Analyse zu Local LLMs für den Mittelstand.

Wenn du es auf drei Fragen eindampfst, kommst du in den meisten Fällen zur richtigen Architektur:

• Buy, wenn du schnell produktiv werden willst, kein Spezialteam für KI-Betrieb hast und mit einer EU-residenten Enterprise-API plus AVV deine Datenschutz-Anforderungen erfüllst. Das trifft auf die große Mehrheit der Mittelständler zu.
• Hybrid, wenn ein Teil deiner Daten besonders sensibel ist, der Rest aber unkritisch. Sensibles lokal, den Rest über die beste API — das beste Verhältnis aus Schutz, Qualität und Aufwand.
• Build, wenn harte Souveränitäts-Vorgaben oder ein sehr hohes, konstantes Volumen es rechtfertigen — und du den laufenden Betrieb wirklich stemmen kannst oder einen Partner hast, der ihn stemmt.

Häufige Fragen zu Corporate LLMs