RAG (Chat mit internen Dokumenten): So bauen Unternehmen „internen KI“-Chat ohne Datenleck

Die meisten Unternehmen brauchen keine KI, die Gedichte schreibt. Sie brauchen eine KI, die am Montag um 09:12 eine ganz konkrete Frage beantworten kann: „Wie läuft unser Standard-Onboarding für neue Kunden?“, „Wo liegt die aktuelle VPN-Richtlinie?“, oder „Was sagt das SLA zur Reaktionszeit bei Incidents?“

Dieses Wissen existiert bereits—verteilt über SharePoint-Ordner, PDFs, interne Wikis, E-Mail-Threads, Ticketing-Systeme und alte Word-Dokumente. Das Problem ist nicht fehlende Information. Das Problem ist, die richtige Information schnell, konsistent und sicher zu finden.

Genau hier wird Retrieval-Augmented Generation (RAG) zu einem praktischen Blueprint. Statt ein Modell auf privaten Daten zu „trainieren“, holt RAG bei jeder Frage die relevanten internen Textstellen und nutzt sie als belastbaren Kontext. Richtig umgesetzt liefert das hohe Genauigkeit, ohne dass Dokumente zu einer dauerhaften „Modell-Erinnerung“ werden.

Was RAG ist (und was es nicht ist)

RAG ist ein System-Design-Pattern. Wenn ein Nutzer eine Frage stellt, durchsucht das System Ihre interne Wissensbasis nach den relevantesten Passagen und gibt diese Passagen an ein Sprachmodell weiter, das daraus die Antwort formuliert.

• Es ist kein „Fine-Tuning“ des Modells mit Firmendaten
• Es ist kein magisches Suchfeld—Qualität hängt von Dokumenten und Rechten ab
• Es ist nicht automatisch sicher—Sicherheit muss ins Design

RAG kann mit Cloud-Modellen, privaten Modellen oder in einem Hybrid-Setup betrieben werden. Das Risiko ist nicht das Akronym—entscheidend sind Zugriffskontrolle, Daten-Grenzen und Logging.

Die häufigsten RAG-Anwendungsfälle in Unternehmen

RAG wirkt besonders dort, wo Wissen „stabil“ ist und Fragen sich wiederholen. Typische High-Impact-Use-Cases sind:

• Interne Knowledge Base: Policies, SOPs, Onboarding, HR-Prozesse
• Verträge und Klauseln: relevante Stellen schnell finden
• Ticketing & Support: Incidents zusammenfassen, Schritte vorschlagen, Runbooks verlinken
• IT-Betrieb: Konfig-Dokus, Architektur-Notizen, Troubleshooting-Guides durchsuchen
• Compliance: Nachweise, Logs und Dokumentation für Audits finden

Das echte Sicherheitsproblem: „Wer darf was sehen?“

Das größte Risiko bei interner KI ist nicht, dass die Antwort falsch ist. Das größte Risiko ist, dass sie richtig ist—aber für die falsche Person.

Wenn jemand aus dem Vertrieb die Assistenz nach „allen Kundenverträgen mit Sonderrabatten“ fragen kann, ist das Sicherheitsproblem nicht KI—sondern fehlende Autorisierung.

Ein produktionsreifes RAG-System muss Berechtigungen beim Retrieval durchsetzen. Es darf nur Dokumente und Textstellen liefern, die der Nutzer auch wirklich öffnen dürfte. Ist die Retrieval-Schicht rechteblind, wird es früher oder später zu Datenabfluss kommen.

Architektur: Secure RAG in 7 Bausteinen

Secure RAG ist kein einzelnes Tool, sondern eine Pipeline. Ein praxisnaher Blueprint sieht so aus:

• Ingestion: Datenquellen anbinden (SharePoint/Drive, Wiki, Ticketing, File-Server)
• Normalisierung: konsistenter Text + Metadaten (Owner, Team, Tags)
• Chunking: Dokumente in sinnvolle Teile splitten (nicht zu lang, nicht zu kurz)
• Indexing: Embeddings + Metadaten in Vector DB oder Search Index speichern
• Retrieval: Top-Chunks holen—MIT Berechtigungs-Filter
• Generation: Modell antwortet strikt auf Basis des Kontextes
• Observability: Audit-Logs, Monitoring und Qualitätsmessung

Berechtigungsmodell: Nicht verhandelbar

Der robusteste Ansatz ist, jedem Chunk Zugriffs-Metadaten mitzugeben und diese bei der Suche durchzusetzen. Dafür braucht das System eine klare Identität pro Nutzer (SSO/OAuth) und eine Rechte-Matrix.

• User Identity: SSO (Microsoft/Google/Okta) oder internes Auth
• Rollen: IT, HR, Finance, Management, Externe Partner
• Document ACL: wer darf welche Quelle/Ordner lesen
• Chunk-Level Enforcement: Chunks erben ACL vom Quelldokument

Wenn ein Nutzer ein Dokument normalerweise nicht öffnen dürfte, darf das RAG-System es nicht retrievalen. KI ist keine neue Tür zu Daten—sie ist ein schnelleres Interface zu dem, was ohnehin erlaubt ist.

Audit-Logs: Ihre beste Absicherung

Interne KI ist ein Business-System. Sie brauchen Nachvollziehbarkeit. Mindestens sollten Sie loggen:

• Wer gefragt hat (User-ID, Rolle, Tenant, IP)
• Welche Dokumente/Chunks geholt wurden (IDs, Titel, Zeitstempel)
• Welches Modell und welches Prompt-Template genutzt wurde
• Ob die Antwort Zitate/Links zu internen Quellen enthält
• Blockierte Retrievals wegen fehlender Rechte

Das hilft nicht nur bei Incidents, sondern auch bei Compliance und kontinuierlicher Qualitätsverbesserung.

Datenminimierung: Nicht mehr senden als nötig

Sicherheit heißt auch: weniger Exposure. Selbst mit korrekten Rechten sollten Sie den Kontext klein halten:

• Nur die relevantesten Chunks holen (nicht ganze Dokumente)
• Secrets (API-Keys, Passwörter) beim Ingestion redigieren
• Sehr sensible Quellen (z. B. Payroll) nur bei echtem Bedarf einbinden
• Kurzlebige Prompts und vorsichtige Conversation-Speicherung

Tabelle: „gute“ vs. „riskante“ RAG-Entscheidungen

Go-Live in 2–4 Wochen ohne Overengineering

Die meisten Unternehmen brauchen nicht sofort eine perfekte Plattform. Ein sicherer MVP ist möglich, wenn Sie den Scope richtig wählen:

• Start mit 1–2 Quellen: Knowledge Base + Ticket-Summaries
• User-Gruppe begrenzen: zuerst IT + Management
• Zitate verpflichtend: jede Antwort muss Quellen verlinken
• „I don’t know“: ohne Kontext muss das System ablehnen
• Erfolg messen: Zeitersparnis, schnellere Ticketlösung, weniger Wiederholfragen

Fazit: Interne KI ist ein Security-Projekt, kein Chatbot-Projekt

RAG kann den Zugriff auf Wissen massiv beschleunigen—aber nur, wenn Security und Governance von Anfang an mitgedacht werden. Ziel ist nicht, clever zu klingen. Ziel ist, internes Wissen durchsuchbar, prüfbar und berechtigungssicher zu machen.

Wenn Sie RAG wie Infrastruktur behandeln—Identität, Zugriff, Logging und Monitoring—können Sie interne KI einführen, ohne Datenlecks zu riskieren.