Teil 4: LLMs mit Unternehmensdaten nutzen

Serie: Was jeder CEO über Generative KI wissen sollte

Im November 2022 veröffentlichte OpenAI die erste Version von ChatGPT. Es war das erste Large Language Model (LLM), das wirklich jede und jeder nutzen konnte. Seitdem hat sich generative KI sowohl privat als auch in Unternehmen rasant verbreitet. In den meisten Organisationen wurden LLMs bisher nur für einfache Aufgaben eingesetzt – etwa um E‑Mails zu formulieren, Marketingtexte zu erstellen oder einfache Chatbots zu betreiben.

Doch das ändert sich gerade. Unternehmen fragen nicht mehr: „Können wir diese Technologie nutzen?“ Sie stellen inzwischen eine viel wichtigere Frage: „Wie bringen wir dieses neue System dazu, unser Unternehmen und unsere Abläufe wirklich zu verstehen?“

Fast alle wertschöpfenden Anwendungsfälle erfordern ein Modell, das die Daten eines Unternehmens versteht. Genau hier werden die Grenzen von Standard‑LLMs sichtbar. In diesem Artikel zeige ich die verschiedenen Möglichkeiten auf, wie die Daten Ihres Unternehmens mit grossen Sprachmodellen (LLMs) gewinnbringend genutzt werden können und welche Herausforderungen und Risiken damit einhergehen. Auch wenn dieser Beitrag etwas länger ist als gewohnt, ist es mein Ziel, diese Kernfragen so zu vermitteln, dass sie sowohl leicht verständlich als auch technisch präzise bleiben.

Was „Pretrained“ für das Wissen von LLMs bedeutet

Das „P“ in ChatGPT steht für Pretrained, also „vortrainiert“. Das bedeutet: Das Modell wurde bereits anhand eines riesigen Datensatzes trainiert und ist sofort einsatzbereit. Das klingt praktisch, hat aber einen gewichtigen Nachteil: Man arbeitet mit einem allgemeinen Modell, das nicht auf das spezifische Wissen eines Unternehmens angepasst ist.

Was das Modell während des Trainings gelernt hat, ist alles, was es weiß - nicht mehr und nicht weniger.

LLM-Wissen ist immer veraltet

Um ein LLM zu trainieren, braucht man riesige Datenmengen und enorm viel Rechenzeit. Das Vorbereiten, Bereinigen und Trainieren der Daten dauert Monate. Wenn ein Modell veröffentlicht wird, sind große Teile seines Wissens schon wieder veraltet.

Jedes LLM hat einen Knowledge Cut-Off. Das ist der Stichtag, nach dem es nichts mehr über die Welt weiß.

Ein Beispiel: ChatGPT 5.1 ist ein relativ aktuelles Modell, aber sein Wissensstand endet am 30. September 2024. Als es im November 2025 veröffentlicht wurde, war sein Wissen also bereits mehr als ein Jahr alt. Fragt man das Modell nach Ereignissen, die erst nach diesem Datum stattgefunden haben, weiß es schlicht nichts darüber.

LLMs kennen dein Unternehmen nicht

Und dann gibt es ein noch größeres Problem: Die internen Daten deines Unternehmens waren nie Teil des Trainingsdatensatzes eines LLM.

Nicht, weil sie unwichtig wären, sondern weil sie privat und geschützt sind. Genau diese Art von Informationen willst du nicht im offenen Internet haben: Geschäftsprozesse, Kundendaten, interne Dokumente, Strategieunterlagen, Produktspezifikationen und vieles mehr.

Doch genau dieses interne Wissen brauchst du, wenn ein LLM deine Abläufe unterstützen, als interner Assistent dienen oder Prozesse automatisieren soll. Ohne Zugriff auf diese Informationen bleibt das Modell zwar intelligent, hat aber keine Ahnung von deinem tatsächlichen Geschäft.

Wie bringen wir ein LLM dazu, unsere Unternehmensdaten zu verstehen und damit zu arbeiten?

Vielleicht denkst du zuerst: „Dann trainieren wir das LLM einfach mit all unseren internen Daten.“ In der Praxis ist das für die meisten Unternehmen jedoch keine realistische Option.

Erstens: Die leistungsstärksten Modelle heute sind proprietär. Externe Unternehmen dürfen sie gar nicht nachtrainieren. Und selbst wenn man ein Open‑Source‑Modell verwendet, ist ein vollständiges Nachtrainieren äusserst anspruchsvoll. Es braucht enorme Rechenleistung, kostet oft Millionen und erfordert spezielle, sehr teure KI‑Hardware.

Zweitens: Die Herausforderung ist nicht nur technischer oder finanzieller Natur. Deine Daten müssten zudem aufwendig bereinigt und in genau das Format gebracht werden, das das Modell für sein Training benötigt. Und selbst wenn all das gelingt, bleibt ein grosses technisches Risiko: das sogenannte catastrophic forgetting. Dabei kann ein Modell beim Nachtrainieren Teile seines ursprünglichen Wissens überschreiben oder schlicht vergessen.

Genau deshalb gelten die Basis‑Modelle (Foundation Models) der grossen LLM‑Anbieter nach dem Training praktisch als „unveränderbar“.

Es gibt im Grunde nur zwei Wege, eigene Daten in ein LLM zu bringen

LLMs sind Black‑Box‑Systeme: Man weiss nicht genau, was darin vorgeht, und man hat nur sehr begrenzte Möglichkeiten, ihre innere Arbeitsweise zu verändern oder ihnen neue Inhalte dauerhaft beizubringen. In der Praxis bleiben deshalb nur zwei grundlegende Optionen, wenn ein Modell etwas über dein Unternehmen verstehen soll:

•  Fine-Tuning: Das Modell wird mit den Unternehmensdaten fein-justiert. Feinjustieren des allgemeinen Modells

• Nötige Informationen als Input mitliefern: Alle wichtigen Informationen werden bei jeder Anfrage ans Modell mitgegeben.

Beim Fine‑Tuning werden gezielt einige dafür vorgesehene Bereiche des Modells mit geschäftsspezifischen Informationen trainiert. Rund 99 % des Modells bleiben unverändert. So lassen sich negative Auswirkungen auf das Basis‑Modell vermeiden.

Fine‑Tuning hat jedoch klare Nachteile: Es erfordert hohe Rechenleistung, spezielle KI‑Hardware, verursacht schnell Kosten im höheren vierstelligen bis fünfstelligen Bereich und es braucht Zeit. Fine‑Tuning eignet sich deshalb vor allem dafür, grundlegende branchenspezifische Konzepte, Terminologien oder typische Formulierungen zu vermitteln.

Für häufig wechselnde Fakten, wie Bestellhistorien, Produktionszahlen oder aktuelle Kundeninformationen, ist es dagegen völlig ungeeignet. Diese wären längst veraltet, bevor der Trainingsvorgang abgeschlossen wäre.

Informationen als Input an das LLM übergeben – das Context Window

Für solche schnell ändernden faktischen Informationen muss die zweite Option genutzt werden. Die Idee dabei ist sehr einfach: Bei jeder Anfrage liefern wir alle wichtigen unternehmensspezifischen Informationen einfach mit.

Jedes LLM verfügt über einen Speicherbereich, der von aussen beschrieben werden kann und als Input dient: das sogenannte Context Window. Dieses Fenster ist sozusagen der aktuelle Blick des Modells auf die Welt.

Alles, was wir der LLM mitteilen wollen,  Befehle, Fragen, Hinweise, Dokumente , usw. muss in diesem Context Window bereitgestellt werden. Dazu gehören neben dem Prompt auch alle unternehmensinternen Informationen, die das Modell benötigt, um die Anfrage korrekt zu beantworten.

Das Context Window dient auch als Kurzzeit-Gedächtnis. Die LLM hat ein Langzeitgedächtnis mit allem Wissen, welches es während der Trainingsphase gelernt hat. Es hat aber kein Kurzzeitgedächtnis. Das bedeutet: Das Modell verarbeitet deine Anfrage, erzeugt eine Antwort. Danach ist alles wieder weg, vergessen.

Wenn du zum Beispiel möchtest, dass sich die LLM an die vergangene Kommunikation zwischen Benutzern und Modell erinnert, musst du den gesamten bisherigen Chat‑Verlauf jedes Mal erneut im Context Window mitgeben.

Mit anderen Worten: Alles, was die LLM für eine Antwort wissen muss, musst du dem Modell im Context Window bereitstellen. Dazu gehören der Prompt des Benutzers, interne Unternehmensinformationen,  externe Informationen (z. B. aus dem Internet), Chat‑Verläufe, Ergebnisse früherer Modellaufrufe und alle weiteren kontextrelevanten Inhalte.

Abbildung 1: LLM und Context Window

Alles, was im Context Window enthalten ist, kann das LLM für seine Überlegungen und Antworten nutzen. Der Output hängt nicht nur davon ab, welche Informationen und Instruktionen im Context Window bereitgestellt werden, sondern auch wie sie formuliert sind, in welcher Reihenfolge sie erscheinen und welches Format sie haben. Der Prozess, bei dem das Context Window gezielt so „befüllt“ wird, dass das Modell die bestmöglichen Ergebnisse liefert, nennt sich Context Engineering.

Und dies ist genau, was alle LLM-basierten Applikationen machen. Selbst ChatGPT arbeitet so. Wenn du eine Chat‑Anfrage eingibst, wird im Hintergrund immer der gesamte bisherige Chat‑Verlauf sowie zusätzliche Systeminstruktionen in das Context Window eingefügt und dann an das LLM geschickt.

 Kontextfenster‑Beschränkungen / Der RAG‑Ansatz

Um dem LLM zu ermöglichen, mit unseren internen Unternehmensdaten zu arbeiten, müssen wir die relevanten Informationen im Context Window bereitstellen.

Doch hier kommt der Haken: Die Grösse des Context Window ist strikt begrenzt. Es hat eine feste Grösse. GPT‑4.0 zum Beispiel hat ein Kontextfenster von etwa 32’000 Tokens. Dies entspricht knapp 50 Seiten Text.

Fünfzig Seiten klingen vielleicht viel, sind aber im Vergleich zu den Terabytes an Dokumenten, E‑Mails, Berichten und Datenbanken eines Unternehmens verschwindend wenig. Man kann unmöglich alles in dieses Fenster packen. In der Praxis müssen wir daher genau diejenigen Informationsbausteine auswählen, die für die jeweilige Nutzerfrage wirklich relevant sind.

Genau hier kommt Retrieval‑Augmented Generation (RAG) ins Spiel: RAG ist eine Systemarchitektur, deren Aufgabe es ist, den Prompt des Nutzers zu analysieren und aus dem grossen Pool von Unternehmensdaten genau jene Dokumente oder Fakten herauszufiltern, die das Modell braucht, um die Aufgabe korrekt zu bearbeiten.

Abbildung 2: Vereinfachte RAG-Architektur

Wenn man sich das obige Diagramm anschaut, wirkt der Prozess eigentlich ziemlich unkompliziert. Viele Experten werfen beim Stichwort RAG mit Begriffen wie Embedding, Vector Datebases, Cosine Similarity, usw. um sich.

Eigentlich ist es einfach ein System, welches die relevanten Informationen aus der riesigen Menge an Unternehmensdaten herausfiltert. Diese werden dann im Hintergrund an das LLM gesandt. Den Benutzerinnen und Benutzer bleibt dies verborgen, was die Gefahr birgt, dass Unternehmensdaten unkontrolliert an die LLM geschickt werden.

Datenqualität ist der Schlüssel für gute LLM‑Ergebnissen

Aus all den Unternehmensdaten die relevantesten und zuverlässigsten Informationen herauszufiltern, klingt zunächst sehr einfach. In der Realität ist dies jedoch überaus anspruchsvoll. Damit eine Anfrage korrekt mit den passenden Dokumenten verknüpft werden kann, muss das System die Bedeutung der Wörter verstehen. Dafür braucht es eine sogenannte semantische Suche, die meist mithilfe von Vektor‑Datenbanken umgesetzt wird.

Die Technologie dahinter ist zwar komplex, aber gut beherrschbar. Was jedoch deutlich schwieriger ist: Die Daten müssen in der erforderlichen Qualität vorliegen. Wenn die Datenqualität schlecht ist, liefert selbst das beste KI‑System unzuverlässige oder schlicht falsche Ergebnisse.

In den meisten Unternehmen ist die Datenqualität weit von ideal entfernt. Sie muss häufig erheblich verbessert werden, bevor eine KI verlässlich damit arbeiten kann. Deshalb gilt: Bevor du überhaupt an ein KI‑Projekt denkst, musst du zuerst deine Daten in Ordnung bringen. Und genau das ist oft ein gewaltiges Unterfangen.

Eine manuelle Bereinigung ist in grösserem Umfang praktisch unmöglich. Zwar gibt es Tools, die helfen, fehlerhafte oder unvollständige Daten zu identifizieren. Selbst mit diesen Werkzeugen bleibt viel menschliche Arbeit notwendig. Nicht selten ist die Datenaufbereitung deshalb teurer als Anschaffung und Betrieb der eigentlichen KI‑Technologie.

Ein einfaches Beispiel verdeutlicht das Problem:

In vielen Unternehmen existiert dasselbe Dokument an mehreren Stellen. Manche sind Duplikate, manche sind veraltete Versionen, manche unterscheiden sich nur leicht in der Formatierung. Wenn man diese nicht konsolidiert, kann es passieren, dass das System mehrere Versionen desselben Dokuments an das LLM weitergibt. Das führt zu zwei Problemen:

1. Das Modell könnte die relevanten Informationen aus einem veralteten Dokument entnehmen

2. Wenn das gleiche oder fast gleiche Dokument mehrfach auftaucht, „denkt“ das Modell, dass es wichtiger ist als andere Informationsquellen, was die Ergebnisse verzerrt.

Genau deshalb sind Datenbereinigung und Konsolidierung so entscheidend. Sie kosten viel Geld und es gibt keine Abkürzung: Wenn man bei der Datenaufbereitung spart, wird das System schlicht nicht gut funktionieren. Die Antworten werden unzuverlässig. Im besten Fall schadet das der Glaubwürdigkeit und Reputation des Unternehmens. Im schlimmsten Fall führt es zu falschen Entscheidungen, finanziellen Verlusten oder sogar Sicherheitsrisiken.

Datensicherheit, Datenschutz und Schutz von geistigem Eigentum

Die RAG‑Architektur aus Abbildung 2 hat sehr ernsthafte Auswirkungen auf den Datenschutz. In den meisten Fällen läuft das LLM selbst in der Cloud und wird von einem externen Anbieter betrieben. Und auch wenn Nutzerinnen und Nutzer es nicht sehen: In dem Moment, in dem eine Frage gestellt wird, übermittelt das System im Hintergrund die relevanten Teile eurer internen Unternehmensdaten als Klartext an dieses externe LLM.

Wenn man nicht äusserst vorsichtig ist, bedeutet das: Wertvolle und sensible Informationen,  einschliesslich eurer Intellectual Property, können auf Servern in anderen Ländern landen, wo andere gesetzliche Rahmenbedingungen gelten.

Cloud‑Anbieter verfügen zwar über Datenschutzrichtlinien und vertragliche Schutzmechanismen. Auf dem Papier wirken diese oft solide. Doch am Ende vertraut man einem externen Unternehmen sehr weitreichend. Die Risiken beschränken sich dabei nicht nur auf kommerzielle Datenlecks oder versehentliche Fehler. In manchen Ländern können staatliche Behörden über gesetzliche Verfahren oder andere Wege Zugriff auf Cloud‑Daten erhalten.

Für bestimmte Branchen ist das schlicht nicht akzeptabel: Rüstungsindustrie, Luft‑ und Raumfahrt, Finanzwesen, Life Sciences und der öffentliche Sektor haben alle sehr gute Gründe, hier maximale Vorsicht walten zu lassen. Diese Bedenken sind keineswegs theoretisch: Es gibt gut dokumentierte Fälle, in denen staatliche Akteure vertrauliche Informationen von Wettbewerbern an die heimische Industrie weitergegeben haben.

Wenn du planst, LLMs mit den Daten deines Unternehmens einzusetzen, musst du daher sehr genau darüber nachdenken:

• Wohin diese Daten gelangen

• Wer potenziell darauf zugreifen könnte

• Welche Konsequenzen ein Datenabfluss für dein Unternehmen haben könnte

On‑Premise LLMs zum Schutz der Unternehmensdaten

Wenn eine Anwendung mit hochsensiblen Informationen arbeiten muss, etwa personenbezogenen Daten, Geschäftsgeheimnissen, Forschungsergebnissen oder regulierten Dokumenten, gibt es im Grunde nur einen Weg, maximalen Schutz zu gewährleisten:

Du betreibst die gesamte LLM‑Infrastruktur on‑premise, also in deiner eigenen, vollständig kontrollierten Umgebung. Alles bleibt innerhalb eurer gesicherten Systeme: das Large Language Model selbst, das RAG‑System, alle unterstützenden Dienste und sämtliche Datenquellen. Nichts verlässt eure eigene IT-Infrastruktur.

Natürlich tauscht man dabei Komfort gegen Kontrolle: Cloud‑basierte Modelle sind einfacher zu nutzen und stets auf dem neuesten Stand, während On‑Premise‑Systeme mehr Aufwand bei Einrichtung und Betrieb erfordern. Ein weiterer Nachteil: Man hat keinen Zugriff auf die allerneuesten, gerade veröffentlichten Spitzenmodelle.

In der Praxis ist das jedoch selten ein Problem. Da du das Modell mit deinen eigenen Daten versorgst, brauchst du nicht das absolut neueste LLM, um hervorragende Ergebnisse zu erzielen. Es gibt eine grosse Auswahl leistungsstarker Modelle wie Llama 3, Mistral, Qwen, DeepSeek und andere, die sich zuverlässig on‑premise betreiben lassen und für Unternehmensanwendungen mehr als genügend Fähigkeiten bieten.

Vier zentrale Erkenntnisse für den Einsatz von LLMs mit Unternehmensdaten

Wenn du deine eigenen Daten in LLMs einbringst, kannst du enorme Wertschöpfung erzielen. Allerdings nur, wenn du dabei umsichtig vorgehst. Gute Planung, sorgfältige Vorbereitung und ständiger Focus auf Datenschutz und -Sicherheit entscheiden darüber, ob daraus eine transformative Lösung wird oder eine teure Problem-Applikation resultiert.

Hier sind die vier wichtigsten Erkenntnisse:

1. LLMs kennen dein Unternehmen nicht. Das Wissen der LLMs ist immer veraltet. Zudem haben sie keinerlei Einblick in die internen Unternehmens-Daten. Wenn du hilfreiche und präzise Antworten willst, musst du dem Modell die fehlenden Informationen bereitstellen.

   
   

2. Es gibt nur zwei Wege, diese Informationen dem LLM bereitzustellen: 
   

   • Fine Tuning und

   • Bereitstellen der nötigen Informationen als Kontexts bei jeder Anfrage.

   
   

   Fine Tuning hilft bei Fachbegriffen, Tonalität und übergeordneten Konzepten, nicht aber bei konkreten Fakten. In fast allen realen Implementierungen arbeitet man deshalb mit dem Context Window. Dafür müssen aus Terabytes interner Daten zeitnah die wirklich relevanten Informationen extrahiert und im Kontext für das LLM bereitgestellt werden. Genau dafür wurden RAG‑Systeme entwickelt.

   
   

3. Datenqualität ist alles. Du musst ausreichend Budget für das Bereinigen, Konsolidieren und Vorbereiten deiner Daten einplanen. Wenn du diesen Schritt auslässt oder versuchst, ihn abzukürzen, wird das KI‑System nicht zuverlässig funktionieren. Die Ergebnisse werden unpräzise und das gesamte Projekt scheitert.

   
   

4. Schütze deine sensiblen Informationen. Immer wenn Daten an ein cloudbasiertes LLM gesendet werden, musst du die Auswirkungen auf Datenschutz und den Schutz deines geistigen Eigentums verstehen. Für hochvertrauliche oder regulierte Informationen gibt es nur eine wirklich sichere Option: die gesamte LLM‑Infrastruktur on‑premise zu betreiben.