KI-Wissensmanagement mit lokalen & Corporate LLMs – der vollständige Leitfaden

Fast jedes Unternehmen sitzt auf einem Schatz, den es kaum hebt: dem eigenen Wissen. Es steckt in Köpfen, in Verträgen, in SharePoint-Ordnern und halbfertigen Excel-Dateien. Künstliche Intelligenz verspricht, dieses Wissen endlich nutzbar zu machen. Doch der Reihenfolge nach: Bevor Chatbots, Agenten und Automatisierung wirklich liefern, muss das Fundament stimmen. Dieser Leitfaden erklärt Schritt für Schritt, wie das geht – und warum „lokal" dabei oft die klügere Wahl ist als die Cloud.

1. Das eigentliche Problem: Wissen ist da – nur nicht nutzbar

Der Engpass im Mittelstand ist selten fehlendes Wissen. Es ist die Unzugänglichkeit dieses Wissens. Informationen liegen verstreut über Laufwerke, Postfächer, Köpfe und Systeme, die nicht miteinander sprechen. Die Folge: Mitarbeitende verbringen einen erheblichen Teil ihrer Arbeitszeit mit Suchen statt mit Wertschöpfung. In einer Befragung von 12.000 Wissensarbeitenden beziffert Atlassian in seinem „State of Teams 2025" den Anteil der Arbeitszeit, der für die Suche nach Informationen draufgeht, auf rund 25 % – rechnerisch tut damit jede vierte Arbeitskraft nichts anderes, als Wissen zusammenzusuchen. 56 % geben an, benötigte Informationen nur zu bekommen, indem sie jemanden fragen oder ein Meeting ansetzen.^[1]

Gleichzeitig experimentieren zwar fast alle mit KI, aber kaum jemand kommt über Pilotprojekte hinaus. Laut McKinsey („The state of AI", 2025) nutzen bereits rund 88 % der Unternehmen KI in mindestens einer Funktion (nach 78 % im Vorjahr) – doch die Mehrheit steckt weiter im Pilotstadium, und nur eine Minderheit skaliert KI unternehmensweit mit messbarem Ergebnis.^[2] Der Grund ist fast immer derselbe: Die KI hat keinen Zugang zum eigenen Firmenwissen und bleibt deshalb ein besseres Spielzeug.

Der demographische Wandel verschärft alles

Was das Thema von einer „Nice-to-have"-Optimierung zu einer strategischen Notwendigkeit macht, ist die Demographie. Die geburtenstarken Jahrgänge – die „Babyboomer" – verlassen in den kommenden Jahren in großer Zahl den Arbeitsmarkt. Das Statistische Bundesamt rechnet damit, dass 13,4 Millionen Erwerbspersonen in den nächsten rund 15 Jahren das gesetzliche Rentenalter erreichen – etwa ein Drittel aller Erwerbstätigen.^[3] Das Institut der deutschen Wirtschaft (IW Köln) erwartet allein bis 2036 eine Lücke von rund 4,3 Millionen Arbeitskräften.^[4]

Für Unternehmen bedeutet das: Mit jedem erfahrenen Kopf, der in Rente geht, droht jahrzehntelang aufgebautes Spezialwissen unwiederbringlich verloren zu gehen – wenn es nicht vorher gesichert und zugänglich gemacht wurde. Der klassische Wissenstransfer von Mensch zu Mensch funktioniert schon heute oft nicht mehr und wird schlicht mathematisch schwieriger, je mehr Erfahrungsträger gleichzeitig ausscheiden. Wissensmanagement ist damit keine IT-Fleißaufgabe mehr, sondern Risikomanagement.

2. Erst das Wissen, dann die KI

Hier liegt der wichtigste Denkfehler vieler KI-Projekte: Sie starten mit dem Sichtbaren – dem Chatbot, dem Agenten, der Automatisierung – und wundern sich, dass die Ergebnisse dünn bleiben. Die Reihenfolge ist aber umgekehrt. Automatisierung, KI-Agenten und Assistenten liefern nur dann verlässlich, wenn sie auf strukturiertem, zugänglichem Wissen aufsetzen. Sonst automatisieren sie Lücken – und skalieren im schlimmsten Fall Fehler.

Was heißt „KI-ready" konkret?

„Das Wissen KI-fähig machen" klingt abstrakt, ist aber ein handfester Prozess in vier Schritten:

1. Bestandsaufnahme: Wo liegt welches Wissen? Was ist geschäftskritisch, was ist Ballast? Welche Abteilungen und welche Dokumententypen (Verträge, Handbücher, Angebote, E-Mails, Wikis) sind relevant?
2. Digitalisieren & erfassen: Papier, Scans und Wissen aus Köpfen (etwa via Interviews oder Transkription) werden in maschinenlesbare Form gebracht. Ein PDF ist nicht automatisch „lesbar" – ein eingescanntes Fax muss erst per Texterkennung (OCR) erschlossen werden.
3. Bereinigen & strukturieren: Dubletten raus, veraltete Stände markieren, einheitliche Benennungen. Wissen ohne Ordnung erzeugt schlechte KI-Antworten – „Müll rein, Müll raus" gilt hier besonders.
4. Aufbereiten für die KI: Die Inhalte werden in eine Form gebracht, die eine KI zuverlässig durchsuchen kann. Wie das technisch funktioniert (Chunks, Embeddings, Vektoren), sehen wir gleich im RAG-Kapitel.

Der Aufwand lohnt sich doppelt: Selbst ohne jede KI ist ein aufgeräumtes, auffindbares Wissen bereits wertvoll. Mit KI wird es zum Motor – für Onboarding, Entlastung der Führung und schnellere Entscheidungen. Wichtig ist die Reihenfolge: Erst wird das Fundament gelegt, dann darauf gebaut.

3. Corporate LLM & „lokal" – aber ist das schon alles?

Ein LLM (Large Language Model, großes Sprachmodell) ist die Technologie hinter Anwendungen wie ChatGPT: eine KI, die menschliche Sprache versteht und selbst formuliert. Ein Corporate LLM ist – vereinfacht gesagt – ein solches Sprachmodell, das speziell für ein Unternehmen betrieben wird: mit Zugriff auf das eigene Firmenwissen, zentraler Benutzerverwaltung und, ganz entscheidend, unter eigener Kontrolle.

Beim „unter eigener Kontrolle" reicht es aber nicht, nur zwischen „Cloud" und „lokal" zu unterscheiden. Entscheidend sind zwei Fragen: Wo liegen die Daten (Ihre Dokumente, die Vektordatenbank) – und wo liegt das Modell, das damit rechnet? Daraus ergibt sich ein Spektrum:

Die Spalten unter Datensicherheit ergeben zusammen, wie geschützt Ihre Daten wirklich sind: Datenstandort, Modellstandort, Training und möglicher Zugriff Dritter. Daneben zählen für die Wahl Leistung, Nutzungsgrenzen und Kosten.

Der wichtigste Unterschied bei den Enterprise-Angeboten betrifft genau diese zwei Orte – Daten und Modell. Dabei gibt es zwei grundverschiedene Wege zu denselben Spitzenmodellen:

• (1) Direkt bei den führenden LLM-Anbietern (OpenAI, Anthropic/Claude): Ihre Daten werden nicht zum Training verwendet, und mit gewissen Maßnahmen lassen sich Dokumente und Vektordatenbank sogar self-hosted in der EU halten – an das Modell geht dann nur die jeweilige Anfrage. Das Modell selbst läuft jedoch außerhalb der EU (in den USA); die eigentliche Verarbeitung findet also dort statt. Für viele Unternehmen ist genau das der Knackpunkt.
• (2) Über die Hyperscaler (Microsoft Azure OpenAI, AWS Bedrock, Google Vertex AI): Hier liegen Modell und Daten auf europäischen Servern (EU-Region wählbar), ebenfalls ohne Training auf Ihren Daten. Dass nicht nur die Daten, sondern auch das Modell in der EU bleibt, ist der entscheidende Vorteil gegenüber (1).

Ein Restrisiko bleibt auch bei (2): Der Betreiber ist ein US-Konzern. Über Regelungen wie den US CLOUD Act könnten US-Behörden theoretisch auf Daten zugreifen, die auf EU-Servern eines US-Unternehmens liegen. Die Datenhoheit ist damit vertraglich und technisch gut, juristisch aber nicht so eindeutig wie bei einer wirklich eigenen Lösung (self-hosted oder lokal). Für Berufsgeheimnisträger und besonders sensible Daten ist das häufig der Unterschied zwischen „darf man" und „darf man nicht".

Eine hilfreiche Analogie für das Ganze: Öffentliche Cloud-KI ist das Restaurant (man weiß nicht, was in der Küche passiert, und zahlt pro Gang). Enterprise-Cloud ist das Catering mit Vertrag (fremde Küche, aber schriftliche Zusagen). Ein lokales Modell ist der eigene Koch zu Hause. Und ein Corporate LLM ist die Firmenkantine mit mehreren Köchen und geregelten Zugängen.

4. Wie es funktioniert: RAG, Embeddings und semantische Suche

Man könnte meinen, es reicht, alle Firmendokumente in ein Sprachmodell zu „kippen". Das funktioniert nicht. Ein LLM kann die schiere Menge an Unternehmenswissen nicht auf einmal überblicken – es schaut dann wie durch ein Schlüsselloch nur auf Ausschnitte, gibt lückenhafte Antworten und beginnt zu halluzinieren, also fehlende Informationen einfach zu erfinden.

Die Lösung heißt RAG – „Retrieval-Augmented Generation", also eine Antwort, die durch gezieltes Nachschlagen ergänzt wird. Auf oberster Ebene sieht das so aus:

Wie kommt das Wissen überhaupt in die Vektordatenbank?

Damit die Datenbank etwas zum Nachschlagen hat, durchläuft jedes Dokument einmalig eine Aufnahme-Pipeline (englisch „Ingestion"):

• Chunking: Ein Dokument wird in überschaubare Abschnitte („Chunks") zerteilt – oft etwa 500–1.000 Zeichen mit etwas Überlappung, damit kein Zusammenhang an der Schnittkante verloren geht.
• Tokenisierung: Jeder Abschnitt wird in Tokens zerlegt – kleine Wortbausteine, die das Rechenmodell verarbeiten kann (ein Token ist grob ein kurzes Wort oder Wortteil).
• Embedding: Ein spezialisiertes Embedding-Modell (z. B. nomic-embed-text oder Googles EmbeddingGemma) übersetzt jeden Chunk in einen Vektor – eine lange Zahlenreihe, die die Bedeutung des Textes abbildet. Wichtig: Es ist ein eigenes, kleines Modell, nicht das Chat-LLM – und beim Speichern und beim späteren Suchen muss dasselbe Embedding-Modell verwendet werden.
• Speichern: Die Vektoren landen samt Herkunftsangabe (Dateiname, Quelle) in der Vektordatenbank (z. B. Qdrant). Neue Dateien lassen sich automatisch nachladen, sodass das Wissen aktuell bleibt.

Was heißt „semantische Suche"?

Der eigentliche Trick ist die Bedeutung. Ein Embedding-Modell ordnet Begriffe mit ähnlicher Bedeutung nah beieinander an – in einem hochdimensionalen „Bedeutungsraum". Stark vereinfacht auf zwei Dimensionen sieht das so aus:

Bei einer Suche wird die Frage genauso in einen Vektor übersetzt wie zuvor die Dokumente. Das System sucht dann die Wissensbausteine, deren Vektoren dem Frage-Vektor am nächsten liegen – also die inhaltlich passendsten, nicht nur die mit denselben Stichworten. Deshalb findet eine semantische Suche auch dann die richtige Vertragsklausel, wenn die Nutzerin ganz andere Worte verwendet als im Dokument stehen. Diese passenden Chunks bekommt das LLM als Kontext – und formuliert daraus eine präzise, belegbare Antwort.

5. Der Elefant im Raum: Rechenleistung und Quantisierung

Wer ein Modell selbst betreibt, stößt schnell auf die Frage: Läuft das überhaupt auf bezahlbarer Hardware? Große Sprachmodelle bestehen aus Milliarden Parametern – den „Stellschrauben", die das Modell beim Training gelernt hat. Diese Parameter werden standardmäßig sehr präzise gespeichert, etwa mit 16 oder 32 Bit pro Wert. Das ist genau, aber speicher- und rechenintensiv.

Hier kommt Quantisierung ins Spiel: Man reduziert die Präzision jedes Parameters – zum Beispiel von 16 auf 4 Bit. Vereinfacht ausgedrückt „rundet" man die Milliarden Zahlen etwas gröber. Die Analogie: Man muss die Uhrzeit nicht auf die Millisekunde angeben – „kurz nach zehn" reicht für die meisten Zwecke.

Die praktisch wichtigste Faustregel: Q4 (4-Bit, meist als „Q4_K_M" bezeichnet) ist der Standard für lokale Modelle – etwa ein Viertel der Größe eines vollpräzisen Modells bei weiterhin guter Qualität. Q8 (8-Bit) halbiert die Größe bei nahezu perfekter Qualität und ist dann sinnvoll, wenn es auf höchste Genauigkeit ankommt.

6. Welche Hardware brauche ich?

Die benötigte Hardware hängt vor allem von der Modellgröße ab (angegeben in Milliarden Parametern) und davon, ob Sie quantisierte Modelle einsetzen. Als grobe Orientierung bei Q4-Quantisierung:

Zwei Einstellungen werden dabei oft übersehen und entscheiden über Nutzbarkeit:

• Kontextfenster – wie viel Text das Modell gleichzeitig „im Kopf" behält. Viele lokale Setups starten mit nur wenigen tausend Tokens; für die Arbeit mit längeren Dokumenten muss dieser Wert deutlich erhöht werden, sonst „vergisst" das Modell.
• KV-Cache-Quantisierung – auch der Zwischenspeicher lässt sich quantisieren und spart so noch einmal spürbar Arbeitsspeicher, bei minimalem Qualitätsverlust.

Als Faustregel gilt zudem: Der reale Speicherbedarf liegt oft 10–20 % über der reinen Modellgröße – für KV-Cache, Zwischenaktivierungen und Framework-Overhead.^[5]

7. Welche Modelle gibt es – und wie klein darf es sein?

Die Landschaft offener („open-weight") Modelle, die man selbst hosten kann, hat sich rasant entwickelt. Einen guten, laufend aktualisierten Überblick über Qualität, Geschwindigkeit und Hardwarebedarf bietet das Self-Hosted-LLM-Leaderboard von Onyx, das offene Modelle über etablierte Benchmarks (u. a. MMLU-Pro, GPQA, SWE-bench) vergleicht.^[5] Grob lassen sich zwei Ligen unterscheiden:

• Praxistauglich für begrenzte Hardware – hier holt man das beste Preis-Leistungs-Verhältnis: etwa Mistral Small (≈ 24 Mrd. Parameter), Phi-4 (≈ 14 Mrd., Microsoft), Gemma (Google), Llama (Meta) und Qwen (Alibaba). Diese Modelle laufen auf gehobener Business-Hardware oder einem einzelnen Server und decken den Großteil der Unternehmens-Use-Cases ab.
• Spitzenklasse der offenen Modelle – sehr leistungsfähig, aber mit hohem Hardwarebedarf (teils Hunderte GB VRAM): DeepSeek R1 (671 Mrd.), Qwen 3.5, GLM-5 (Zhipu AI) oder Kimi K2.5 (Moonshot, ~1 Billion Parameter). Diese Klasse braucht dedizierte GPU-Server – oder man nutzt sie über einen Hosting-Anbieter.

Und der wichtigste Punkt gegen einen verbreiteten Irrtum: Man braucht selten das allergrößte Modell. Gut gewählte, kleinere Modelle erreichen bei vielen Unternehmensaufgaben ein Niveau, das nah an den kommerziellen Spitzenmodellen liegt. Entscheidend ist weniger die reine Größe als vielmehr, wie man das Modell einsetzt. Die wirksamsten Hebel:

• Prompt-Engineering – präzise, gut strukturierte Anweisungen.
• RAG – das Modell mit dem richtigen Firmenwissen im richtigen Moment versorgen.
• Fine-Tuning – das Modell für einen konkreten Anwendungsfall nachschärfen (dazu gleich mehr).

Kann ich diese Modelle wirklich selbst fine-tunen?

Technisch: ja. Weil die Gewichte offener Modelle frei verfügbar sind, lassen sie sich nachtrainieren. In der Praxis macht man das aber fast nie „voll" (jedes einzelne Gewicht anpassen – das ist teuer und rechenintensiv), sondern mit parameter-effizienten Verfahren wie LoRA / QLoRA: Dabei wird nur ein kleiner Zusatz-Baustein trainiert, während das große Modell unangetastet bleibt. Das ist auf gehobener Hardware machbar.

Wichtiger ist aber die Erwartung: Fine-Tuning ist gut, um einem Modell einen Stil, ein Format oder eine eng umrissene Fähigkeit beizubringen – nicht, um ihm neues Faktenwissen einzuprägen. „Wissen hinzufügen" ist die Aufgabe von RAG, nicht von Fine-Tuning. Für die allermeisten Unternehmen gilt daher: Erst RAG und gutes Prompting, und nur wenn ein sehr spezieller, wiederkehrender Fall es rechtfertigt, zusätzlich Fine-Tuning. Sonst investiert man viel Aufwand für wenig Mehrwert.

Was bedeutet „Mixture-of-Experts"?

Ein klassisches („dense") Modell schickt jede Anfrage durch alle seine Parameter – groß = langsam und teuer. Ein Mixture-of-Experts-Modell (MoE) ist stattdessen in viele kleinere Teilnetze, die „Experten", aufgeteilt. Ein winziger Router entscheidet pro Token, welche wenigen Experten zuständig sind – und nur die rechnen mit.

Das Ergebnis: Ein Modell kann insgesamt sehr groß sein (breites Wissen), aktiviert pro Anfrage aber nur einen Bruchteil. Beispiel: Ein MoE mit 400 Mrd. Parametern „gesamt" nutzt womöglich nur ~30 Mrd. „aktive" Parameter je Token – es rechnet dadurch so schnell wie ein kleines Modell, weiß aber so viel wie ein großes. Der Preis: Der Speicher muss trotzdem alle Experten vorhalten, denn welcher gebraucht wird, entscheidet sich erst zur Laufzeit. Viele aktuelle Top-Modelle (etwa aus den Qwen-, DeepSeek- und GLM-Familien oder Mixtral) sind genau deshalb MoE-Modelle – sie machen leistungsfähige KI effizienter und besser betreibbar.

8. Vor- und Nachteile ehrlich abgewogen

Lokale und Corporate LLMs sind kein Selbstzweck. Ob sie sich lohnen, hängt vom Anwendungsfall ab. Die ehrliche Gegenüberstellung:

In der Praxis ist die Antwort selten „entweder/oder", sondern ein Hybrid-Ansatz: sensible Daten und der Kern des Firmenwissens laufen lokal oder self-hosted, während für unkritische Aufgaben bei Bedarf auch ein starkes Cloud- oder Enterprise-Modell zugeschaltet werden kann – zentral verwaltet, mit klaren Regeln, wer was nutzen darf.

9. Für wen lohnt sich das?

Besonders klar ist der Fall für Berufsgeheimnisträger – Kanzleien, Steuerberatungen, Arztpraxen, Gutachter: Hier dürfen Mandanten- und Patientendaten schlicht nicht in ein öffentliches Cloud-Modell. Ein lokales oder self-hosted System ist oft die einzige rechtssichere Option.

Für den breiten Mittelstand ist die Kostenrechnung entscheidend: Pro-Kopf-Abos für Cloud-KI summieren sich schnell – bei 100 Mitarbeitenden können das leicht mittlere fünfstellige Beträge pro Jahr sein, für dieselbe Software nur mit persönlichem Zugang. Ein eigener Workspace erlaubt dagegen praktisch beliebig viele Konten. Ab einer gewissen Nutzerzahl kippt die Rechnung deutlich zugunsten der eigenen Lösung – und man bekommt Datenschutz und Kontrolle gratis dazu.

Und schließlich – ein oft unterschätzter Punkt: Nicht jedes Problem braucht überhaupt ein LLM. Manche Aufgaben (etwa das Auslesen standardisierter Formulare) löst man zuverlässiger und günstiger mit klassischen Verfahren. Eine gute Beratung sagt Ihnen auch, wann KI nicht die Antwort ist.