Corporate LLM: Was es ist, welche Bauformen es gibt und wann sich welche lohnt

Was ist ein Corporate LLM?

Corporate LLM ist ein Marktbegriff, kein technischer. Gemeint ist ein großes Sprachmodell, das in einem definierten Rahmen für ein Unternehmen arbeitet: mit geklärter Datenhaltung, mit Anbindung an interne Systeme und mit einer Zugriffssteuerung, die den Rechten der Belegschaft folgt. Was der Begriff üblicherweise nicht bedeutet: dass das Unternehmen ein eigenes Modell trainiert hat.

Hinter dem Satz "wir brauchen ein eigenes LLM" stehen typischerweise drei Anforderungen — einzeln oder in Kombination: Vertrauliche Daten dürfen nicht unkontrolliert abfließen. Das Modell soll interne Inhalte kennen — Verträge, Handbücher, Tickets, Projektdokumentation. Oder Antworten sollen im Ton und Format des Hauses erscheinen. Diese drei Anforderungen werden von völlig verschiedenen technischen Bausteinen erfüllt. Sie sauber zu trennen ist die wichtigste Entscheidung im ganzen Vorhaben, weil jede Verwechslung direkt in ein zu großes oder ein wirkungsloses Projekt führt.

Ein Corporate LLM ist deshalb kein Produkt, das man kauft, sondern eine Kombination aus Bauform, Wissensanbindung und Regelwerk. Bei der Bauform gibt es drei gängige Varianten: ein Public-Cloud-LLM mit Enterprise-Vertrag, ein LLM in eigener Cloud-Tenancy oder EU-Region und ein selbst gehostetes Open-Weight-Modell. Ein fine-getuntes eigenes Modell ist keine vierte Bauform, sondern eine Anpassung, die auf einer der drei aufsetzt. Wie sich das in die restliche Systemlandschaft einfügt, beschreibt der Überblick zu Unternehmens-KI.

• Bauform / Betriebsmodell: Wo läuft die Inferenz, wer kontrolliert Daten und Logs, wer betreibt die Hardware.
• Wissenszugang: Woher kommen die Fakten für eine konkrete Antwort — aus dem Modelltraining, aus einer Suche über eigene Dokumente oder aus einem Fachsystem.
• Modellverhalten: Wie das Modell antwortet — Struktur, Ton, Fachsprache, Formatvorgaben. Geregelt über System-Prompts, Kontextregeln und im Ausnahmefall Fine-Tuning.

Die drei Bauformen im Vergleich — und wo Fine-Tuning hineingehört

Die Bauform bestimmt, wer die Verarbeitung kontrolliert und was der Betrieb kostet — an Geld und an Personal. Sie bestimmt nicht, wie gut das System eure internen Fragen beantwortet. Diese Trennung fällt in Entscheidungsvorlagen oft unter den Tisch. Die letzte Tabellenzeile steht deshalb bewusst abgesetzt: Ein fine-getuntes eigenes Modell ist keine vierte Bauform, sondern eine Anpassung, die zusätzlich zu einer der drei Bauformen kommt.

Praktisch relevant, aber selten in Vergleichstabellen: der Unterschied zwischen einem fertigen Chat-Produkt mit Oberfläche, Nutzerverwaltung und Konnektoren und einem reinen API-Zugang, auf dem man selbst eine Anwendung baut. Beide werden unter "Enterprise" verkauft und bedeuten völlig unterschiedliche Projektgrößen.

In der Praxis entscheiden sich Unternehmen selten für genau eine Zeile. Naheliegend ist ein Mischbetrieb: ein starkes zugekauftes Modell für den Alltag, ein kleines selbst gehostetes Modell für Daten, die das Netz nicht verlassen dürfen, und ein einheitliches Gateway davor, das Routing, Protokollierung und Kostenzuordnung übernimmt. Was ein solches Gateway leisten muss, behandelt der Überblick zur KI-Infrastruktur. Wer eine EU-Verarbeitung braucht, findet auch bei europäischen Modellanbietern brauchbare Optionen.

Corporate LLM, RAG und Fine-Tuning — drei verschiedene Dinge

Diese drei Begriffe geraten in Angeboten und Gremiensitzungen leicht durcheinander. Sie beantworten aber völlig unterschiedliche Fragen. Die Bauform sagt, wo das Modell läuft. RAG sagt, woher das Wissen für eine bestimmte Antwort kommt. Fine-Tuning sagt, wie das Modell antwortet.

Ein teurer Irrtum in diesem Feld, der immer wieder auftaucht, lautet: "Wir trainieren das Modell auf unsere Daten, dann kennt es unsere Prozesse." Fine-Tuning ist ein Verfahren zur Verhaltensanpassung. Faktenwissen lässt sich damit zwar mittrainieren, bleibt aber unzuverlässig. Aktualisierbarkeit, Rechtefilterung je Nutzer, Belegbarkeit mit Quellen und gezielte Löschbarkeit — diese vier Eigenschaften sind im Unternehmenseinsatz Pflicht, und genau die bietet Fine-Tuning nicht.

Praktisch heißt das: Wissen kommt über Retrieval ins System, Verhalten über Prompt und im Zweifel über Fine-Tuning, Kontrolle über die Bauform. Wer bei einem Problem die falsche Ebene anfasst, investiert viel und ändert wenig.

Was "eigene Daten" technisch wirklich bedeutet

Es gibt genau drei Wege, wie ein Sprachmodell an Unternehmensinhalte kommt. Erstens: direkt in der Anfrage, indem der Text mit in den Prompt geschrieben wird. Zweitens: über Retrieval, bei dem eine Suchschicht passende Ausschnitte findet und sie der Frage voranstellt. Drittens: über die Modellgewichte, also Training oder Fine-Tuning. In den ersten beiden Fällen liegen die Daten nie in den Modellgewichten — sie werden pro Anfrage mitgegeben und vom Modell nicht behalten. Auf Systemebene können sie trotzdem in Logs, Zwischenspeichern und Missbrauchsprüfung landen; das regelt der Vertrag, nicht die Technik.

Technisch läuft der zweite Weg so ab: Dokumente werden in Abschnitte zerlegt (Chunking), jeder Abschnitt wird in einen Vektor überführt (Embedding) und in einem Vektorindex abgelegt. Zur Anfragezeit wird die Frage ebenfalls eingebettet, die ähnlichsten Abschnitte werden geholt — in produktiven Systemen häufig kombiniert mit klassischer Stichwortsuche (Hybrid Search), weil reine Vektorsuche bei Eigennamen, Artikelnummern und exakten Formulierungen schwächelt — und dem Modell als Kontext übergeben. Die Antwortqualität hängt dann stark an der Suchqualität: Was die Suche nicht findet, kann auch das beste Modell nicht beantworten. Das ist der Grund, warum ein Wechsel auf ein größeres Modell schlechte Antworten selten repariert.

Diese Unterscheidung hat unmittelbare rechtliche Folgen. Ein Retrieval-Index lässt sich durchsuchen, korrigieren und löschen; ein Löschbegehren ist umsetzbar. Trainingsdaten in Modellgewichten lassen sich nicht gezielt entfernen — was dort einmal drin ist, bleibt bis zum nächsten Trainingslauf. Wie man Quellen für ein solches System überhaupt erst in einen brauchbaren Zustand bringt, behandelt der Beitrag zum KI-Wissensmanagement.

• Kontext gilt nur für die eine Anfrage und ist dabei nachvollziehbar — begrenzt durch das Kontextfenster, auf Systemebene aber trotzdem protokollierbar.
• Retrieval ist aktualisierbar, filterbar und belegbar — der Normalfall für Unternehmenswissen.
• Gewichte sind dauerhaft, undurchsichtig und nicht selektiv löschbar — nur für stabiles Verhalten sinnvoll, nicht für Fakten.
• Kein Weg macht schlecht gepflegte Quellen gut: Veraltete Handbücher werden durch Indexierung nur schneller auffindbar.

Zugriffskontrolle und Mandantentrennung

Das ist die Anforderung, die nach einem begeisternden Prototyp zum Bremsklotz wird. Ein Assistent, der auf allen Dokumenten sucht, macht jedes Berechtigungskonzept im Unternehmen wirkungslos: Die Gehaltsliste im Index ist genau so gut geschützt wie die Frage, die zufällig danach gestellt wird.

Richtig gelöst wird das nur an einer Stelle — im Retrieval, zur Abfragezeit. Die Identität des fragenden Nutzers muss von der Oberfläche über die Anwendung bis in die Suche durchgereicht und dort als harter Filter angewendet werden. Die Berechtigungen aus dem Quellsystem müssen bei der Indexierung mitwandern und bei Änderungen nachgeführt werden, sonst antwortet das System auf Basis eines veralteten Rechtestands. Was nicht funktioniert: dem Modell im System-Prompt zu sagen, es solle bestimmte Inhalte nicht verwenden. Das ist eine Bitte, keine Kontrolle.

Für Mandanten — Tochtergesellschaften, Kundenumgebungen, Betriebsratsbereiche — gilt dieselbe Logik eine Ebene höher. Metadaten-Filter in einem gemeinsamen Index sind bequem und fehleranfällig; getrennte Indizes oder getrennte Namespaces sind aufwendiger und deutlich schwerer versehentlich zu durchbrechen. Sobald Agenten ins Spiel kommen, die eigenständig Werkzeuge aufrufen, wird die Frage schärfer: Ein Agent handelt mit den Rechten seines technischen Kontos, nicht mit denen des Anfragenden — es sei denn, man baut das ausdrücklich so. Die organisatorische Seite dieser Fragen behandelt der Überblick zur KI-Governance.

• Identität des Nutzers bis in die Dokumentsuche durchreichen, nicht erst in der Antwort filtern.
• Berechtigungen aus den Quellsystemen bei der Indexierung übernehmen und bei Änderungen nachziehen.
• Protokollieren, welche Quellen in eine Antwort eingeflossen sind — sonst ist im Nachhinein nichts prüfbar.
• Indexierte Dokumente als potenziell feindliche Eingabe behandeln: Anweisungen in einem PDF können Modellverhalten beeinflussen (Prompt Injection).
• Technische Konten von Agenten mit engem Rechteumfang ausstatten, statt ihnen Administratorrechte zu geben.

Was im Anbietervertrag stehen muss

Bei den ersten beiden Bauformen ersetzt der Vertrag einen Teil dessen, was beim Self-Hosting die Technik leistet. Entsprechend genau lohnt sich der Blick. Die folgenden Punkte sind der Kern; sie sind auch dann sinnvoll zu prüfen, wenn die Rechtsabteilung ohnehin beteiligt ist, weil sie technische Konsequenzen haben.

Bei Modellwechseln und Deprecation-Fristen wird das Risiko leicht unterschätzt: Wenn eine Modellversion abgekündigt wird, ändert sich das Verhalten aller darauf aufgebauten Prompts und Auswertungen. Ohne vereinbarte Vorlauffrist ist das ein ungeplantes Migrationsprojekt.

Regulatorisch trennt der EU AI Act zwischen Anbietern und Betreibern von KI-Systemen. Wer ein zugekauftes Modell im eigenen Haus einsetzt, fällt typischerweise in die Betreiberrolle — die Einordnung im Einzelfall hängt aber an Zweckbestimmung und Risikoklasse des konkreten Systems. Wer ein Hochrisiko-System unter eigenem Namen bereitstellt, es wesentlich verändert oder seine Zweckbestimmung ändert, kann nach Art. 25 EU AI Act in die Anbieterrolle wechseln — mit deutlich weiteren Pflichten. Für Allzweck-KI-Modelle (GPAI) gilt ein eigenes Regime für nachgelagerte Anpasser. Ob Fine-Tuning oder das Weiterreichen eines Assistenten an Kunden diese Schwelle reißt, hängt am Einzelfall und gehört mit der Rechtsabteilung geklärt. Die datenschutzrechtliche Seite ist davon unabhängig und im Beitrag DSGVO und KI ausführlicher behandelt.

• Auftragsverarbeitungsvertrag mit Subprozessorenliste und Informationspflicht bei Änderungen.
• Ausdrücklicher Ausschluss der Nutzung von Ein- und Ausgaben für Modelltraining.
• Speicherdauer der Prompts, Option auf Zero Retention, und wo Logs aus der Missbrauchsprüfung liegen.
• Verarbeitungsregion — einschließlich Support und Sicherheitsprüfung, die häufig anderswo stattfinden.
• Verfügbarkeitszusagen, Ratenlimits und dokumentiertes Verhalten bei Kapazitätsengpässen.
• Vorlauffristen bei Abkündigung von Modellversionen.
• Exit-Fähigkeit: Export von Konfiguration, Prompts und Evaluierungsdaten; Portabilität der Anwendung über die Modellgrenze hinweg.
• Zertifizierungen, Auditrechte und Meldewege bei Sicherheitsvorfällen.

Betrieb, Kosten und die Update-Frage

Die Kostenstruktur unterscheidet sich zwischen den Bauformen grundsätzlich, nicht graduell. Zugekaufte Modelle sind überwiegend variabel: Die Rechnung folgt der Nutzung, der Einstieg ist billig, und bei massenhafter Dokumentverarbeitung wird es spürbar. Self-Hosting dreht das um: hohe Fixkosten für Hardware, Strom und Personal, danach niedrige Grenzkosten je Anfrage. Der Umschlagpunkt liegt dort, wo dauerhaft hohe und gleichmäßige Last anfällt — nicht bei schwankender Nutzung von ein paar Abteilungen.

In RAG-Systemen entfällt oft ein großer Teil der Token-Kosten auf den Eingabekontext, obwohl Ausgabe-Tokens je Token teurer abgerechnet werden — schlicht weil der mitgeschickte Kontext um ein Vielfaches länger ist als die Antwort. Prüft dieses Verhältnis an eurer eigenen Abrechnung, statt es anzunehmen. Wer bei jeder Frage deutlich mehr Dokumentausschnitte mitschickt als nötig, vervielfacht den Anteil der Retrieval-Treffer am Eingabekontext — ohne dass die Antwort dadurch zwangsläufig besser wird, wenn die Suche ohnehin die richtigen Stellen findet. Bessere Suchqualität ist damit auch eine Kostenmaßnahme.

Die Update-Frage wird selten früh gestellt und ist bei jeder Bauform anders gelagert. Beim zugekauften Modell verbessert sich die Qualität ohne eigenes Zutun, aber das Verhalten ändert sich mit jeder Version — Prompts, die gestern zuverlässig strukturiertes JSON lieferten, können nach einem Versionssprung anders reagieren. Über die API lässt sich eine Version meist festschreiben, was den Wechsel planbar macht; irgendwann erzwingt ihn die Deprecation-Frist trotzdem. Beim selbst gehosteten Modell passiert das Gegenteil: Nichts ändert sich, bis jemand aktiv einen Wechsel betreibt. Das ist Stabilität und Stillstand zugleich.

• Betriebsaufgaben bei Self-Hosting: GPU-Kapazitätsplanung, Inferenz-Stack mit Batching, Monitoring von Latenz und Auslastung, Modell- und Sicherheitsupdates, Failover.
• Kostenblöcke unabhängig von der Bauform: Vektorindex, Anwendung, Konnektoren zu Quellsystemen, Qualitätssicherung, Schulung.
• Ein Evaluierungsset aus echten Fragen mit erwarteten Antworten ist die Voraussetzung für jeden Modellwechsel — unabhängig davon, wer das Modell betreibt.
• Kostenzuordnung je Abteilung oder Anwendungsfall früh einbauen, sonst ist die Rechnung nach einem halben Jahr nicht mehr erklärbar.

Wann sich ein eigenes Modell nicht lohnt

Diese Möglichkeit wird selten offen ausgesprochen. Bei Vorhaben, die als "eigenes LLM" starten, ist das eigentliche Problem oft fehlender Zugang zu internem Wissen — nicht die Bauform. Dieses Problem löst kein GPU-Server, sondern eine Retrieval-Schicht auf gepflegten Quellen. Wer zuerst die Infrastruktur baut, hat danach ein teures System, das die Produktdokumentation immer noch nicht kennt.

Der zweite Grund ist der Qualitätsabstand. Frei verfügbare Open-Weight-Modelle sind für viele Aufgaben gut genug — Zusammenfassungen, Klassifikation, Extraktion aus strukturierten Texten. Bei breiter Assistenz, bei mehrstufigem Vorgehen und bei langen Kontexten ist der Unterschied zu den jeweils stärksten gehosteten Modellen spürbar. Aus eigenen Tests mit lokal über Ollama betriebenen Modellen — unter anderem Llama 3, Qwen und Mistral; Setup und Modellstände stehen im verlinkten Beitrag: Für einzelne, klar umrissene Aufgaben tragen sie zuverlässig; sobald mehrere Schritte aufeinander aufbauen oder viel Kontext im Spiel ist, brechen die kleineren Modelle früher ein als die großen gehosteten. Wer das selbst prüfen will, findet den praktischen Einstieg unter LLM lokal installieren.

Der dritte Grund ist organisatorisch. Ein selbst betriebenes Modell braucht dauerhaft jemanden, der zuständig ist: für Kapazität, Updates, Sicherheitspatches, Störungen um drei Uhr nachts. Wenn diese Rolle nicht besetzt und finanziert ist, ist die Entscheidung faktisch schon gefallen — nur wird sie dann erst nach der Beschaffung sichtbar.

• Das Problem ist Wissen, nicht Modellqualität — dann ist Retrieval die Antwort, nicht die Bauform.
• Die Nutzung ist schwankend und in Summe gering — Fixkosten für Hardware laufen ins Leere.
• Es gibt kein Evaluierungsset, mit dem sich Qualität vor und nach einem Wechsel vergleichen ließe.
• Niemand ist dauerhaft für Betrieb und Modellpflege zuständig.
• Die geforderte Aufgabe ist breit und offen — genau dort ist der Abstand zu den stärksten gehosteten Modellen am teuersten.

Ein pragmatischer Einführungspfad

Die Reihenfolge ist wichtiger als das Tempo. Jede Stufe erzeugt Erkenntnisse, ohne die die nächste Entscheidung raten wäre. Insbesondere die Bauform sollte so spät wie möglich endgültig festgelegt werden — nämlich dann, wenn Lastprofil, Datenklassen und tatsächlich genutzte Anwendungsfälle bekannt sind.

Wer diesen Weg geht, stellt nach Stufe 2 oft fest, dass die ursprünglich diskutierte Frage — eigenes Modell oder nicht — für einen großen Teil der Anwendungsfälle keine Rolle spielt. Übrig bleiben ein paar klar benennbare Fälle mit besonderer Schutzbedürftigkeit, und für die lässt sich eine gezielte Lösung bauen, statt die gesamte Landschaft danach auszurichten.

Braucht euer Unternehmen ein selbst betriebenes LLM — oder einen kontrollierten Zugang zu einem zugekauften Modell?

Häufige Fehler

1. Die Bauform vor dem Anwendungsfall entscheiden Hardware und Hosting werden festgelegt, bevor klar ist, welche Aufgaben das System übernehmen soll und mit welchen Daten. Danach richtet sich der Anwendungsfall nach der Infrastruktur statt umgekehrt — und die Anforderungen, die die Beschaffung ursprünglich begründet haben, tauchen im Betrieb gar nicht auf.
2. Fine-Tuning wählen, um Wissen einzuspeisen Ein technischer Irrtum, der in diesem Feld immer wieder auftaucht. Fine-Tuning ändert Verhalten, nicht zuverlässig Faktenwissen. Trainiertes Wissen ist nicht aktualisierbar, nicht pro Nutzer filterbar, nicht mit Quellen belegbar und nicht gezielt löschbar — entfernen lässt es sich nur über einen neuen Trainingslauf. Für Unternehmensinhalte ist Retrieval die richtige Methode.
3. Zugriffsrechte im System-Prompt regeln Dem Modell zu schreiben, es solle bestimmte Inhalte nicht verwenden, ist keine Zugriffskontrolle. Die Daten liegen dann bereits im Kontextfenster und damit in Logs und Zwischenspeichern. Rechte gehören als harter Filter in die Suchschicht, angewendet zur Abfragezeit mit der Identität des Fragenden.
4. Selbst hosten ohne Betriebsmannschaft GPU-Server sind der einfache Teil. Kapazitätsplanung, Inferenz-Stack, Monitoring, Sicherheitsupdates und Modellwechsel sind Daueraufgaben. Ist dafür keine Rolle besetzt und finanziert, veraltet das Modell still und die Verfügbarkeit hängt an Einzelpersonen.
5. Ohne Evaluierungsset starten Ohne einen Satz echter Fragen mit erwarteten Antworten lässt sich weder ein Modellwechsel bewerten noch eine Verschlechterung bemerken. Das Set sollte vor der ersten Architekturentscheidung existieren und aus dem Fachbereich kommen, nicht aus der IT.
6. Quellen indexieren, die niemand pflegt Ein Retrieval-System macht veraltete Handbücher und widersprüchliche Ablagen nicht besser, sondern nur schneller auffindbar. Wer keine Verantwortlichen je Quelle benennt und keine Regeln für Aktualität hat, produziert falsche Antworten mit korrekter Quellenangabe — das ist schlimmer als gar keine Antwort.

Weiterlesen

Verwandte Themen

• RAG: Retrieval Augmented Generation — die technische Referenz
• KI-Infrastruktur: die technische Basis für KI im Unternehmen
• KI-Governance: der Rahmen, der KI-Nutzung nicht ausbremst