1. Was ist KI-Wis­sens­ma­nage­ment? #

KI-Wis­sens­ma­nage­ment bezeich­net den Ein­satz gene­ra­ti­ver KI, um inter­nes Unter­neh­mens­wis­sen für Mit­ar­bei­ter abruf­bar und pro­duk­tiv nutz­bar zu machen. Drei Eigen­schaf­ten unter­schei­den es von ein­fa­cher KI-Nutzung:

Ver­an­ke­rung in eige­nen Daten. Ant­wor­ten basie­ren nicht auf dem all­ge­mei­nen Trai­nings­wis­sen des Sprach­mo­dells, son­dern auf kon­kre­ten Doku­men­ten aus dem Unter­neh­men — Ver­trä­gen, Berich­ten, Wikis, Akten. Das Modell for­mu­liert, die Quel­len lie­fern die Inhalte.

Quell­nach­weis. Jede Ant­wort ver­weist auf die Ori­gi­nal­do­ku­men­te, aus denen sie stammt. Mit­ar­bei­ter kön­nen nach­voll­zie­hen, woher eine Infor­ma­ti­on kommt, und sie im Ori­gi­nal­text überprüfen.

Berück­sich­ti­gung von Berech­ti­gun­gen. Die KI ant­wor­tet nur auf Basis von Inhal­ten, auf die der fra­gen­de Nut­zer Zugriffs­rech­te hat. Per­so­nal­ak­ten, M&A‑Unterlagen, NDA-Doku­men­te blei­ben für Unbe­fug­te unsicht­bar — auch dann, wenn sie tech­nisch indi­ziert sind.

Damit ist KI-Wis­sens­ma­nage­ment deut­lich mehr als ein Chat­bot. Es ist eine Infor­ma­ti­ons­in­fra­struk­tur, die Suche, Sprach­ver­ständ­nis und Berech­ti­gungs­lo­gik zu einem Sys­tem verbindet.

2. Drei Treiber: Warum jetzt

KI-Wissensmanagement ist kein neuer Begriff, aber die Umsetzungsdringlichkeit ist 2026 deutlich gestiegen. Drei Treiber wirken zusammen.

Wettbewerbsdruck. Unternehmen, die KI produktiv einsetzen, verkürzen Recherche-, Erstell- und Entscheidungszeiten erheblich. Eine Studie der Federal Reserve Bank of St. Louis (Bick, Blandin, Deming, Erhebung November 2024) ermittelt eine durchschnittliche Zeitersparnis von rund 5,4 % der Wochenarbeitszeit bei regelmäßigen Nutzern generativer KI. McKinsey zitiert diese Zahl in „Superagency in the Workplace" 2025. Wer keine geprüfte KI-Lösung bereitstellt, verliert diesen Produktivitätsvorsprung — oder akzeptiert, dass Mitarbeiter ihn über Schatten-KI selbst herstellen.

Compliance-Lock. , und schaffen eine Lage, in der Cloud-KI für regulierte Daten faktisch ausgeschlossen ist. Gleichzeitig zwingen Artikel 4 des (KI-Kompetenzpflicht, anwendbar seit Februar 2025) und Verarbeitungsverzeichnis-Pflichten der Unternehmen dazu, ihre KI-Nutzung offenzulegen und zu steuern. Eine offizielle, geprüfte interne Lösung ist die einzig saubere Antwort.

Implementierungslücke. Laut McKinsey-Daten haben 88 % der Unternehmen KI in mindestens einer Funktion eingeführt — aber nur ein Bruchteil davon erreicht messbare Geschäftsergebnisse. BCG fand, dass rund 60 % der Unternehmen aus ihren KI-Investitionen bisher keinen wesentlichen Wert erzielen. Der Grund ist meist nicht das Modell, sondern die Anbindung an die eigenen Daten und Prozesse. Wer KI-Wissensmanagement systematisch aufbaut, schließt diese Lücke.

→ Thema: Schatten-KI
→ Thema:

3. Drei Wege zur loka­len KI im Ver­gleich #

Wer Cloud-KI für sen­si­ble Daten aus­schlie­ßen will, hat tech­nisch drei Optio­nen. Sie unter­schei­den sich grund­le­gend in Auf­wand, War­tung, Zukunfts­fä­hig­keit und in der Fra­ge, ob der Ansatz im Mit­tel­stand über­haupt trag­fä­hig ist.

3.1 Eige­nes LLM trai­nie­ren #

Ein eige­nes Sprach­mo­dell auf Basis öffent­li­cher oder eige­ner Trai­nings­da­ten. Maxi­ma­le Spe­zia­li­sie­rung, voll­stän­di­ge Kon­trol­le. In der Pra­xis nur für Groß­kon­zer­ne mit eige­ner KI-For­schungs­ab­tei­lung darstellbar.

Auf­wand: Mil­lio­nen-Euro-Inves­ti­ti­on für Hard­ware, Strom, Trai­nings­da­ten, ML-Team. Trai­nings­läu­fe dau­ern Wochen bis Monate.

Risi­ko: Modell ver­al­tet schnell. Die Open-Source-Model­le (Mis­tral, Llama, Qwen, Gem­ma) ent­wi­ckeln sich quar­tals­wei­se wei­ter — ein selbst trai­nier­tes Modell hängt nach weni­gen Mona­ten hinterher.

Geeig­net für: For­schungs­ein­rich­tun­gen, Groß­kon­zer­ne mit eige­ner KI-Stra­te­gie und mehr­jäh­ri­gem Zeithorizont.

3.2 DIY mit loka­len LLMs #

Open-Source-Tools wie Oll­ama, LM Stu­dio oder llama.cpp auf eige­ner GPU-Hard­ware. Eine RAG-Pipe­line und Kon­nek­to­ren wer­den selbst gebaut. Nied­ri­ger Ein­stieg, hohe Fle­xi­bi­li­tät für Entwickler.

Auf­wand: Gerin­ge Anfangs­in­ves­ti­ti­on in Hard­ware. Aber: Kon­nek­to­ren, Rech­te­ma­nage­ment, Vek­tor-Daten­bank, Audit-Trail, Modell-Updates müs­sen alle selbst imple­men­tiert und gepflegt werden.

Risi­ko: Ska­liert nicht über den Pro­to­ty­pen hin­aus. Sobald meh­re­re Quel­len, Rech­te­mo­del­le und Nut­zer­grup­pen ange­bun­den wer­den müs­sen, wird der War­tungs­auf­wand pro­hi­bi­tiv. Mit jedem neu­en Modell, jedem M365-Update, jeder Berech­ti­gungs­än­de­rung steigt die Komplexität.

Geeig­net für: Ein­zel­an­wen­der, For­schungs- und Ent­wick­lungs­ab­tei­lun­gen, Pro­to­ty­p­ing. Nicht für pro­duk­ti­ven Unter­neh­mens­be­trieb mit Compliance-Anforderungen.

3.3 Mana­ged Appli­ance #

Fer­ti­ge Hard­ware mit loka­lem Infe­ren­cing, pro­fes­sio­nel­lem RAG-Stack, Vek­tor-Daten­bank, Kon­nek­to­ren-Biblio­thek, AD-Inte­gra­ti­on und War­tungs­ver­trag. Der Anbie­ter pflegt Modell-Updates, Kon­nek­to­ren und Sicherheits-Patches.

Auf­wand: Höhe­re Ein­stiegs­in­ves­ti­ti­on als DIY. Aber plan­ba­re TCO ohne nut­zungs­ab­hän­gi­ge Token-Kos­ten und ohne eige­nes Betriebsteam.

Risi­ko: Gerin­ge­re Tuning-Frei­heit als bei einem eige­nen LLM. Die­ser Punkt ist für die meis­ten Mit­tel­stands­an­wen­dun­gen unkri­tisch, weil die pro­duk­ti­ven Use-Cases — Recher­ché, Zusam­men­fas­sung, Quell­fin­dung — kei­ne Modell-Spe­zia­li­sie­rung erfordern.

Geeig­net für: Mit­tel­stand, Behör­den, regu­lier­te Bran­chen, alle Orga­ni­sa­tio­nen ohne eige­nes KI-Forschungsteam.

Kri­te­ri­umEige­nes LLMDIY-LLMMana­ged Appliance
Anfangs­in­ves­ti­ti­onMil­lio­nen­be­reichNied­rigMit­tel
Deploy­ment-ZeitMona­te bis JahreWochen bis MonateTage bis Wochen
Betriebs­auf­wand internSehr hochHochNied­rig
Modell aktu­ell haltenSelbstSelbstAnbie­ter
Kon­nek­to­renSelbst bau­enSelbst bau­enMit­ge­lie­fert
Rech­te­ma­nage­mentSelbst bau­enSelbst bau­enInte­griert
Audit-TrailSelbst bau­enSelbst bau­enInte­griert
SLA / SupportIntern—Ver­trag­lich
Ska­liert auf UnternehmensbetriebJa, mit AufwandSchwerJa

Die prak­ti­sche Kon­se­quenz: Für die über­wie­gen­de Mehr­heit der Unter­neh­men ist die Mana­ged Appli­ance der ein­zi­ge Weg, der die Anfor­de­run­gen an Com­pli­ance, Wart­bar­keit und Pro­duk­ti­vi­tät gleich­zei­tig erfüllt.

→ Anwen­dung: Loka­les KI-Wis­sens­ma­nage­ment mit Silent AI

4. RAG-Architektur verstehen

(RAG) ist der Architektur-Standard für KI-Wissensmanagement. Das Konzept wurde 2020 von Patrick Lewis und Kollegen bei Facebook AI Research veröffentlicht und hat sich seitdem als robuste Methode etabliert, um e mit eigenem Wissen zu verbinden, ohne sie neu zu trainieren.

RAG kombiniert drei Komponenten:

Retrieval (Suche). Wenn ein Nutzer eine Frage stellt, sucht das System zunächst in einer Vektor-Datenbank nach Dokumenten, deren Inhalt semantisch zur Frage passt. Die Suche basiert nicht auf Stichwort-Matches, sondern auf der Bedeutung — eine Frage nach „Aufbewahrungsfristen für Personalakten" findet auch Dokumente, die das Wort „Aufbewahrungsfrist" nicht enthalten, aber das Thema behandeln.

Augmentation (Anreicherung). Die gefundenen Quelltexte werden zusammen mit der ursprünglichen Frage an das übergeben. Das Modell sieht damit nicht nur die Frage, sondern auch die relevanten Dokumente.

Generation (Antwort). Das formuliert eine Antwort, die sich auf die übergebenen Quellen stützt. Da die Quelltexte mitgegeben werden, lassen sich die zitierten Stellen direkt verlinken — en sind dadurch deutlich reduziert.

Zwei technische Bausteine sind dafür nötig:

Embeddings. Jeder Dokumentenabschnitt wird in einen mathematischen Vektor übersetzt, der seine Bedeutung repräsentiert. Ähnlich bedeutende Texte erhalten ähnliche Vektoren. Das ist die Grundlage der semantischen Suche.

Vektor-Datenbank. Speichert die Embeddings effizient und ermöglicht schnelle Ähnlichkeitssuchen über Millionen von Dokumenten. Die Vektor-Datenbank ist eine zentrale Komponente jedes ernsthaften KI-Wissensmanagement-Systems.

Der entscheidende Vorteil von RAG gegenüber dem Fine-Tuning eines Modells: Daten lassen sich jederzeit hinzufügen, ändern und entfernen. Ein neues Dokument ist sofort recherchierbar, ein zurückgezogenes Dokument ist sofort aus dem Index entfernt. Beim Fine-Tuning müsste das Modell jedes Mal neu trainiert werden.

RAG-Architektur
Retrieval-Augmented Generation in vier Schritten
So verbindet ein KI-Wissensmanagement-System Sprachmodelle mit dem eigenen Datenbestand — mit Quellnachweis, ohne Re-Training
Schritt 01
Frage
Ein Mitarbeiter stellt eine Frage in natürlicher Sprache an das System.
Schritt 02
Retrieval
Vektorsuche findet semantisch passende Dokumente — gefiltert nach Leserechten des Nutzers.
Schritt 03
Augmentation
Frage und gefundene Quelltexte werden zusammen an das Sprachmodell übergeben.
Schritt 04
Generation
Das Modell formuliert die Antwort auf Basis der übergebenen Quellen — mit Quellnachweis.
Input Natürlichsprachliche Eingabe · keine Stichwort-Syntax
Technik Embeddings · Ähnlichkeitssuche · AD-Rechtefilter
Technik Kontext-Window · Prompt-Komposition · Lokales LLM
Output Antwort + Quelllink zum Originaldokument
Vorteil
Daten lassen sich jederzeit hinzufügen, ändern und entfernen — ohne Re-Training des Modells. Ein neues Dokument ist sofort recherchierbar, ein zurückgezogenes sofort aus dem Index entfernt. Beim klassischen Fine-Tuning wäre das nicht möglich.
Methodische Grundlage: Lewis et al. (2020), „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401 · Icons: IBM Carbon Design System (Apache 2.0)

5. Kon­nek­to­ren-Stra­te­gie: Wel­che Quel­len, in wel­cher Rei­hen­fol­ge #

Die größ­te Hür­de beim KI-Wis­sens­ma­nage­ment ist sel­ten das Sprach­mo­dell — es sind die Kon­nek­to­ren zu den eige­nen Daten­quel­len. Prak­ti­sche Rei­hen­fol­ge für den Aufbau:

Stu­fe 1 — Micro­soft 365 und Share­Point. In den meis­ten Unter­neh­men liegt der über­wie­gen­de Teil des aktiv genutz­ten Wis­sens in M365 (Share­Point, One­Dri­ve, Teams-Datei­en, Exch­an­ge). Mit dem Anschluss von M365 ist ein gro­ßer Teil der wert­volls­ten Inhal­te sofort ver­füg­bar — vor­aus­ge­setzt, die Berech­ti­gun­gen sind sau­ber. Genau das ist oft nicht der Fall (sie­he Abschnitt 6).

Stu­fe 2 — Wiki- und Wis­sens­platt­for­men. Con­fluence, Next­cloud, Noti­on oder ande­re kol­la­bo­ra­ti­ve Platt­for­men ent­hal­ten Ver­fah­rens­an­wei­sun­gen, Archi­tek­tur­ent­schei­dun­gen, Onboar­ding-Mate­ri­al. Die­ser Anschluss ist meist tech­nisch ein­fach (offe­ne APIs) und lie­fert hohen Nutz­wert für Recherché.

Stu­fe 3 — File­ser­ver. NFS- und SMB-Shares ent­hal­ten oft das älte­re, weni­ger gepfleg­te Wis­sen — gewach­se­ne Struk­tu­ren, vie­le Ver­sio­nen, gemisch­te Berech­ti­gun­gen. Wert­voll für Recher­chen mit his­to­ri­scher Tie­fe, erfor­dert aber Sorg­falt bei der Berechtigungs-Spiegelung.

Stu­fe 4 — Struk­tu­rier­te Daten. SQL-Daten­ban­ken, ERP-Aus­zü­ge, CRM-Noti­zen. Hier braucht es spe­zia­li­sier­te Kon­nek­to­ren, die struk­tu­rier­te Daten in für RAG nutz­ba­re Tex­te umwandeln.

Stu­fe 5 — Spe­zi­al­sys­te­me. Dozu­ki, PLM-Sys­te­me, bran­chen­spe­zi­fi­sche Platt­for­men (KIS, RIS, PACS im Gesund­heits­we­sen). Häu­fig über REST-APIs anschließ­bar, manch­mal über Datei-Export.

Stu­fe 6 — Web­sei­ten und exter­ne Quel­len. Eige­ne Web­sei­te, Lie­fe­ran­ten-Por­ta­le, Behör­den-Web­sei­ten. Für aktu­el­le Infor­ma­tio­nen ergän­zend sinn­voll, aber kein Kernbestand.

Stu­fe 7 — Ad-hoc-Upload. Ein­zel­ne Doku­men­te, die nicht dau­er­haft in einer Quel­le lie­gen, soll­ten direkt im KI-Sys­tem hoch­lad­bar sein. Das deckt Recher­ché-Auf­ga­ben ab, die außer­halb des regu­lä­ren Wis­sens­be­stands liegen.

Prag­ma­ti­sche Emp­feh­lung: Stu­fen 1 bis 3 in den ers­ten 90 Tagen anbin­den. Stu­fen 4 bis 6 in einem zwei­ten Schritt nach Bedarf. Stu­fe 7 von Anfang an, weil sie orga­ni­sa­to­risch entlastet.

6. Rechtemanagement: Das übersehene Thema

Die häufigste und teuerste Fehlannahme beim KI-Wissensmanagement: „Unsere Berechtigungen sind in Ordnung." Sie sind es in den seltensten Fällen — und genau hier entstehen die größten Risiken.

Das Microsoft-Copilot-Beispiel. Microsoft selbst nennt überschießende Berechtigungen („oversharing") als wichtigsten Risikofaktor bei Copilot-Deployments. Copilot arbeitet innerhalb der bestehenden M365-Rechte und prüft nicht, ob ein Zugriff sachlich angemessen ist. Eine SharePoint-Site, die historisch auf „Anyone in the organization" gesetzt wurde, wird durch Copilot zur Quelle für jeden, der danach fragt. Microsoft empfiehlt vor jedem Copilot-Rollout einen vollständigen Berechtigungs-Audit über das eigene SharePoint Advanced Management.

Was in der Praxis passiert. Über die Jahre wachsen Berechtigungsstrukturen organisch. Mitarbeiter werden in Gruppen aufgenommen, scheiden aus, wechseln Rollen. Projekte werden mit weit gefassten Rechten gestartet und nie aufgeräumt. Ergebnis: Berechtigungen spiegeln nicht mehr das Soll, sondern eine Historie, die niemand mehr durchschaut.

Das Risiko bei KI. Bei klassischer Suche fällt eine zu weit gesetzte Berechtigung selten auf, weil Nutzer nicht aktiv danach suchen. Bei KI ist es anders: Eine Frage wie „Was wissen wir über Mitarbeiter X?" oder „Welche Vergütungsspannen sind im Unternehmen üblich?" trifft sofort jede überzogene Berechtigung — und legt sie offen.

Was souveränes KI-Wissensmanagement leistet. Drei Schichten arbeiten zusammen:

  1. Berechtigungs-Spiegelung. Beim Indizieren einer Quelle wird zu jedem Dokument festgehalten, wer Leserechte besitzt. Diese Information bleibt mit dem Embedding verknüpft.
  2. Anfrage-Zeit-Filter. Wenn ein Nutzer eine Frage stellt, filtert das System die Treffer vor der Antwortgenerierung: Nur Inhalte mit Leserecht für diesen Nutzer fließen in den Kontext.
  3. Audit-Trail. Jede Anfrage, jeder Quellnachweis und jede Antwort wird protokolliert. Fehlkonfigurationen werden über Auswertungen sichtbar — und korrigierbar.

Praktische Konsequenz. Vor jedem produktiven KI-Wissensmanagement-Rollout gehört eine Berechtigungs-Hygiene: Überschießende Sites identifizieren, „Anyone"-Links entfernen, verwaiste Arbeitsbereiche schließen, Gruppenmitgliedschaften prüfen. Diese Arbeit ist nicht Aufgabe der KI — sie ist Voraussetzung dafür, dass die KI ohne Schaden funktioniert.

7. Referenzarchitektur souveränes KI-Wissensmanagement

Ein produktionsreifes System für souveränes KI-Wissensmanagement besteht aus sechs Schichten plus einem querliegenden Audit-Trail.

Reference architecture: Sovereign AI knowledge management Six layers, fully local, with a cross-cutting audit trail LAYER 6 User front end Browser interface · chat interface · Teams integration LAYER 5 · INFERENCE CORE Language model (local) Open-source LLM (Mistral · Qwen · Gemma) on GPU hardware · RAG pipeline LAYER 4 Vector database Embeddings of all indexed content · permission metadata per document LAYER 3 Identity and permissions Active Directory / LDAP integration · permission mirroring per source and document LAYER 2 Connectors M365 · SharePoint · Exchange · Confluence · file servers · SQL · Nextcloud · Dozuki · web · upload LAYER 1 · EXISTING IT Source systems Existing data sources, no data copy required · read access only CROSS-CUTTING Audit trail Logged per query: Who? When? Which question? Which sources found? Which answer generated? Satisfies: GDPR Art. 30 Record of processing activities EU AI Act Art. 12 + 19 Logging obligation NIS2 traceability Fully local. No external telemetry. No cloud logging. SOVEREIGN LOGGING Inference core (cyan highlight) Local layer (standard) Existing source systems (external) Audit trail (cross-cutting)

Die sechs Schichten im Überblick:

  • Schicht 1 — Quellsysteme (bestehende IT): Lesender Zugriff auf bestehende Datenquellen, keine Datenkopie nötig.
  • Schicht 2 — Konnektoren: M365, SharePoint, Exchange, Confluence, Fileserver (NFS/SMB), SQL, Nextcloud, Dozuki, Webseiten, Ad-hoc-Upload.
  • Schicht 3 — Identität und Rechte: AD/LDAP-Integration, Rechte-Spiegelung pro Quelle und Dokument.
  • Schicht 4 — Vektor-Datenbank: Embeddings aller indizierten Inhalte plus Berechtigungs-Metadaten pro Dokument.
  • Schicht 5 — (Inferencing-Kern): Open-Source-LLM (Mistral, Qwen, Gemma) auf lokaler GPU-Hardware, RAG-Pipeline.
  • Schicht 6 — Nutzer-Frontend: Browser-Oberfläche, Chat-Interface, optional Teams-Integration.

Querliegender Audit-Trail. Protokolliert pro Anfrage: Wer hat wann was gefragt, welche Quellen wurden gefunden, welche Antwort wurde generiert. Vollständig lokal, ohne externe Telemetrie. Erfüllt Art. 30 (Verarbeitungsverzeichnis), Art. 12/19 (Logging-Pflicht für Hochrisiko-Systeme bzw. allgemeine Nachvollziehbarkeit) und -Anforderungen an Nachvollziehbarkeit.

Souveränität-Anforderungen pro Schicht:

  • Schicht 1 bis 2: Lesezugriff auf bestehende Systeme. Keine Migration, keine Datenkopie in Drittsysteme.
  • Schicht 3: Bestehende AD/LDAP-Strukturen werden gespiegelt, nicht ersetzt.
  • Schicht 4 bis 5: Vektor-Datenbank und laufen auf On-Premises-Hardware. Kein externer Inferencing-Dienst, keine Cloud-.
  • Schicht 6: Nutzer-Frontend innerhalb des Unternehmensnetzwerks. Keine externe SaaS-Komponente im Anfragepfad.
  • Audit-Trail: Vollständig lokal, ausreichend für -Verarbeitungsverzeichnis und -Risikomanagement.

Die Architektur erfüllt damit die drei Grundforderungen souveränen KI-Wissensmanagements: Daten bleiben im Haus, Berechtigungen werden durchgesetzt, jede Nutzung ist nachvollziehbar.

8. Erfolgsmessung und ROI

Eine wirtschaftliche Bewertung von KI-Wissensmanagement braucht mehr als das Versprechen einer abstrakten Produktivitätssteigerung. Vier Kennzahlen liefern belastbare Aussagen:

Zeit bis zur Antwort. Wie lange brauchen Mitarbeiter, um eine konkrete Information zu finden — vor und nach Einführung? Eine Reduktion von 15 Minuten Recherche auf 1 Minute KI-Antwort ist bei vielen Fragen realistisch und messbar.

Antwort-Qualität. Wie oft führt eine KI-Antwort tatsächlich zur Lösung — versus wie oft fragt der Mitarbeiter doch nochmal einen Kollegen? Diese Quote lässt sich über Stichproben oder Feedback-Buttons erheben.

Compliance-Reife. Wie viele Datenklassen sind durch die offizielle Lösung abgedeckt? Wie hoch ist der Anteil dokumentierter KI-Nutzung im Verarbeitungsverzeichnis? Eine vollständige Abdeckung ist messbar — und macht Schatten-KI strukturell unattraktiver.

Schatten-KI-Rückgang. Wiederholte Mitarbeiter-Umfragen (mit Amnestie) zeigen, ob die offizielle Lösung tatsächlich angenommen wird oder ob Schatten-KI weiterläuft.

Realistische Erwartungshaltung. Die St. Louis Fed-Studie (s. Abschnitt 2) misst rund 5,4 % Wochenzeit-Ersparnis bei regelmäßigen Nutzern generativer KI. Auf 50 Mitarbeiter mit 1.760 Jahresarbeitsstunden gerechnet entspricht das ungefähr 4.750 Stunden pro Jahr — in mittleren Stundensätzen zwischen 60 und 100 EUR ein erheblicher Wert. Wichtiger als die exakte Zahl ist die Erkenntnis: Der wirtschaftliche Effekt entsteht nicht durch das Tool, sondern durch konsequente Anbindung der eigenen Daten und durch Schulung der Mitarbeiter. Tools ohne Daten-Anbindung erzeugen Hype, aber keinen Wert.

9. 90-Tage-Handlungsleitfaden

Tag 1 bis 30: Voraussetzungen schaffen

Datenklassen definieren: Welche Daten dürfen in welche KI. Berechtigungs-Audit für die Top-3-Quellen (üblicherweise SharePoint, Fileserver, Confluence) durchführen. KI-Richtlinie entwerfen und Verarbeitungsverzeichnis ergänzen. KI-Kompetenz-Schulung gemäß Art. 4 aufsetzen.

Tag 31 bis 60: Pilot aufbauen

Managed Appliance evaluieren oder PoC starten. Pilot-Gruppe identifizieren (typisch: ein Fachteam mit klarem Wissensbedarf — z. B. Vertragsmanagement, Compliance, Service Operations). Konnektoren der Stufe 1 anbinden (M365, SharePoint). Erste Anfragen mit echten Use Cases durchspielen. Feedback einholen.

Tag 61 bis 90: Skalieren

Konnektoren Stufe 2 und 3 anbinden (Confluence, Fileserver). Zweite Nutzergruppe einbeziehen. Audit-Trail-Auswertung aufsetzen. Erste Berechtigungs-Drift-Analyse durchführen. Kommunikation an alle Mitarbeiter: Welche Lösung steht für welche Datenklassen zur Verfügung, was bleibt verboten — und warum die offizielle Lösung tatsächlich nützlich ist.

Nach 90 Tagen: Produktivbetrieb mit kontinuierlicher Erweiterung von Quellen, Nutzergruppen und Use Cases.

→ Anwendung: Lokales KI-Wissensmanagement mit Silent AI

10. Häufige Fragen (FAQ)

Copilot ist sinnvoll für unkritische Inhalte innerhalb der Microsoft-Welt, hat aber zwei strukturelle Schwächen für KI-Wissensmanagement im engeren Sinn: Erstens respektiert Copilot zwar SharePoint-Rechte, aber macht überschießende Berechtigungen sofort wirksam — eine schlecht konfigurierte Site wird sofort zur Datenquelle für alle. Microsoft empfiehlt deshalb einen vollständigen Berechtigungs-Audit vor jedem Copilot-Rollout. Zweitens ist Copilot Cloud-basiert — für regulierte oder besonders sensible Daten ist das nicht zulässig.

Technisch ja, die Open-Source-Bausteine sind verfügbar. Praktisch scheitern die meisten DIY-Projekte an Konnektoren, Rechtemanagement und Wartung. Ein PoC ist machbar, ein Produktivbetrieb mit Compliance-Anforderungen erfordert ein dauerhaftes Team.

Für KI-Wissensmanagement-Inferencing wird eine professionelle GPU mit ausreichend Speicher benötigt — der Bedarf hängt von Modell und Nutzeranzahl ab. Eine Managed Appliance liefert die Hardware mit der passenden Konfiguration. Wer DIY geht, sollte mindestens eine GPU der aktuellen Server-Generation einplanen.

Für die meisten Unternehmensszenarien sind Open-Source-Modelle wie Mistral, Qwen oder Gemma ausreichend leistungsfähig und in der Bedeutung gut beherrschbar. Wichtig ist, dass das Modell austauschbar bleibt — die Entwicklung läuft schnell, eine Festlegung auf ein einziges Modell ist riskant.

RAG reduziert en deutlich, weil das Modell auf konkrete Quellen zurückgreift. Aber sie sind nicht ausgeschlossen. Ein gutes System macht das transparent: Quellnachweise bei jeder Antwort, Markierung von Antworten ohne ausreichende Quellbasis, klare Hinweise an den Nutzer.

Im RAG-Modell ist das einfach: Dokument aus der Quelle entfernen, Reindexierung läuft. Bei nächster Anfrage ist das Dokument aus dem Treffer-Set verschwunden. Bei einem auf den Daten trainierten Modell wäre das wesentlich schwieriger.

Drei Kostenblöcke: Hardware (einmalig, je nach Anbieter und Konfiguration), Lizenzen (typisch in Paketen pro Anwender), Wartung (jährlich). Bei einer Managed Appliance ist die TCO planbar — keine nutzungsabhängigen Token-Kosten, keine Cloud-Rechnung. Konkrete Konditionen über das Sales-Team.

Disclaimer

Dieser Beitrag wurde redaktionell erstellt und mit KI-Unterstützung aufbereitet. Er gibt einen allgemeinen Überblick und stellt keine Rechtsberatung dar – für Ihre konkrete Situation empfehlen wir professionellen Rat.