RAG Berechtigungsmanagement: Vertrauliche Firmendaten im Company Brain vor Datenabfluss schützen

RAG Berechtigungsmanagement entscheidet darüber, ob ein unternehmensweiter KI-Assistent die Produktivität verdoppelt oder zu einem gravierenden Compliance-Verstoß führt. Wenn Unternehmen interne Wissensdatenbanken aufbauen, scheitern viele Pilotprojekte nicht an mangelnder Antwortqualität, sondern am Veto von Betriebsrat und Chief Information Security Officer (CISO). Der Grund ist struktureller Natur: Standard-Pipelines für Retrieval-Augmented Generation (RAG) erfassen Dokumente über administrative Service-Accounts und werfen sämtliche Inhalte in einen gemeinsamen Vektorraum – ohne die im Quellsystem hinterlegten Zugriffsrechte abzubilden.

Fragt ein Werkstudent den internen Chatbot nach Gehaltsbändern, Restrukturierungsplänen oder Vorstandsentscheidungen, sucht der Vektor-Index nach semantischer Ähnlichkeit. Fehlt eine Zugriffskontrolle, landen vertrauliche Chunks direkt im Kontextfenster des Large Language Models (LLM) und werden als Zusammenfassung ausgegeben. Wie wir bereits in der Analyse zum Aufbau eines skalierbaren Company Brains herausgearbeitet haben, erfordert Enterprise-Wissen mehr als bloßes Embedding. Es braucht eine Architektur, die Vertraulichkeit auf Chunk-Ebene garantiert.

Das Sicherheits-Dilemma im Company Brain: Warum Standard-RAG Rechte ignoriert

In klassischen Unternehmensanwendungen ist Zugriffskontrolle seit Jahrzehnten etabliert. SharePoint, Confluence, Jira oder Google Drive nutzen rollenbasierte Zugriffskontrollen (Role-Based Access Control, RBAC) sowie granulare Access Control Lists (ACLs). Ein Benutzer sieht bei einer Volltextsuche ausschließlich Treffer aus Dokumenten, für die sein Benutzerkonto oder seine Active-Directory-Gruppe eine Leseberechtigung besitzt.

Klassische RAG-Pipelines brechen dieses Sicherheitsmodell auf drei Ebenen:

1. Aggregierte Ingestion über Service-User: Der Ingestion-Worker nutzt einen API-Token mit globalen Leserechten, parst PDF-Dateien und Confluence-Seiten, zerlegt sie in Text-Chunks und generiert Embeddings. Das Quellsystem verliert ab diesem Moment die Hoheit über den Zugriff.
2. Blindheit des Vektorraums: Ein Vektorraum misst Kosinus-Ähnlichkeit oder Skalarprodukte zwischen Vektoren. Ein mathematischer Vektor speichert standardmäßig weder Gruppen-IDs noch Rollenbeschränkungen.
3. Vertrauen in Prompt-Anweisungen: Versuche, den Datenzugriff über System-Prompts zu steuern (wie „Beantworte Fragen zu Gehältern nur, wenn der Nutzer Personalverantwortlicher ist“), bieten keinerlei Schutz. Durch Prompt-Injection-Angriffe, indirektes Prompting oder Halluzinationen geben Modelle geschützte Fakten dennoch preis.

Um vertrauliche Firmendaten revisionssicher zu schützen, muss das Sicherheitsmodell aus den Quellsystemen direkt in den Retrieval-Prozess überführt werden.

Post-Filtering vs. Pre-Filtering: Warum Security-Trimming vor dem Retrieval Pflicht ist

Beim Durchsetzen von Zugriffsrechten in Vektordatenbanken stehen Entwickler vor der Wahl zwischen zwei Ansätzen: Filtern nach der Ähnlichkeitssuche (Post-Filtering) oder Filtern vor der Ähnlichkeitssuche (Pre-Filtering).

Nutzer-Query mit JWT / Token
       │
       ▼
┌─────────────────────────────────────────┐
│ Pre-Filtering (Empfohlen)               │
│ Metadaten-Filter:                       │
│ (allowed_groups IN user_groups)         │
│                   │                     │
│                   ▼                     │
│ Vektor-Index (ANN-Suche)                │
│ Treffer: Nur autorisierte Dokumente     │
└──────────────────┬──────────────────────┘
                   ▼
┌─────────────────────────────────────────┐
│ LLM Kontextfenster & Antwortgenerierung │
└─────────────────────────────────────────┘

Warum Post-Filtering in der Praxis versagt

Beim Post-Filtering führt die Vektordatenbank zunächst die Approximate Nearest Neighbor (ANN)-Suche über den gesamten Datenbestand durch und liefert die Top-k-Treffer (beispielsweise 10 Chunks) zurück. Anschließend prüft eine Middleware, ob der anfragende Nutzer Leserechte für die jeweiligen Quell-Dokumente besitzt. Alle unberechtigten Chunks werden verworfen.

Dieser Ansatz birgt gravierende Nachteile:

• Ergebnis-Verschluckung (Result Starvation): Besitzt der Nutzer keine Rechte für die ersten acht der zehn ähnlichsten Chunks, bleiben nach dem Filter nur zwei Chunks übrig. Die Antwortqualität des LLMs bricht ein, obwohl im Gesamtsystem hunderte relevante, berechtigte Dokumente vorhanden wären.
• Latenzverlust: Müssen verworfene Treffer durch iterative Nachabfragen (Over-Fetching) kompensiert werden, steigen die API-Latenzen sprunghaft an.
• Informationsabfluss über Metriken: Timing-Analysen und Debug-Logs können Angreifern Rückschlüsse darauf geben, dass geheime Dokumente zu einem Begriff existieren.

Pre-Filtering als Standard für Security-Trimming

Beim Pre-Filtering werden Metadaten-Filter direkt in die Vektorsuchanfrage eingebettet. Moderne Vektordatenbanken wie Qdrant, Pinecone oder pgvector werten den Berechtigungsfilter vor oder während des Vektor-Traversierens (Single-Stage Filtering) aus. Die ANN-Suche berücksichtigt ausschließlich Datenpunkte, deren hinterlegte ACLs mit den Rechten des anfragenden Nutzers übereinstimmen. Der Nutzer erhält verlässlich die semantisch besten k Chunks aus seinem persönlichen Berechtigungsraum.

Drei Architekturmodelle für Zugriffssteuerung in RAG (und ihre Trade-offs)

Je nach Sicherheitsanforderung, Dokumentenvolumen und Fluktuation von Berechtigungen haben sich drei Architekturmuster für RAG Berechtigungsmanagement etabliert.

1. Physische Daten-Silos (Multi-Index-Architektur)

In diesem Modell erhält jede Abteilung oder Vertraulichkeitsstufe (Public, Internal, Confidential, Secret) eine eigene Vektordatenbank oder eine separate Collection. Bei einer Abfrage wird der Vektorraum nur dann adressiert, wenn der Nutzer die entsprechende Freigabe besitzt.

• Vorteile: Vollständige Datenisolation; versehentliches Vermischen ist architektonisch ausgeschlossen.
• Nachteile: Extrem hoher Administrationsaufwand; abteilungsübergreifende Abfragen erfordern Multi-Query-Merging; skaliert nicht bei feinmaschigen Berechtigungen (z. B. 5.000 Einzelfreigaben in Google Drive).

2. Statisches Metadaten-Tagging auf Chunk-Ebene

Jeder Chunk wird beim Embedding mit den IDs der berechtigten Nutzer und Gruppen in den Metadaten versehen:

{
  "chunk_id": "chunk_98214",
  "document_id": "doc_hr_guidelines_2026",
  "text": "Gehaltsanpassungen fuer Level 4 erfolgen gemaess Matrix...",
  "metadata": {
    "tenant_id": "tenant_abc",
    "allowed_roles": ["hr_manager", "board"],
    "allowed_users": ["usr_102", "usr_405"]
  }
}

• Vorteile: Sehr performantes Pre-Filtering bei einfachen Rollenmodellen.
• Nachteile: Ändert sich die Zugriffsberechtigung einer Datei im Quellsystem, müssen alle zugehörigen Chunks in der Vektordatenbank aktualisiert werden. Bei großen Datenmengen führt dies zu erheblichen Synchronisationslatenzen.

3. Dynamische Token-Auflösung mit Entkopplung

Für komplexe Enterprise-Umgebungen empfiehlt sich die Trennung von Inhaltsvektoren und Benutzergruppen. Im Chunk-Metadatum wird lediglich eine eindeutige Ressourcen-ID (acl_resource_id) gespeichert. Wenn ein Nutzer eine Suchanfrage sendet, fragt das API-Gateway einen Identity- oder Autorisierungsdienst (beispielsweise Open Policy Agent oder Active Directory) ab, der die Liste aller für diesen Nutzer zugelassenen Ressourcen-IDs liefert. Diese ID-Liste wird als Filterkriterium an die Vektordatenbank übergeben.

In unserer Umsetzung für eine modulare Wissensbasis mit RAG und MCP setzen wir genau an dieser Schnittstelle an: Retrieval-Tools verarbeiten Anfragen stets im Kontext des authentifizierten Nutzertokens, wodurch unautorisierte Zugriffe bereits vor der semantischen Verarbeitung abgefangen werden.

Document-Level Security in der Praxis: ACL-Synchronisation aus SharePoint, Drive und Confluence

Die größte Herausforderung in der Praxis ist nicht die Filterlogik der Vektordatenbank, sondern die Synchronisation dynamischer Berechtigungsstrukturen aus den Quellsystemen. Enterprise-Berechtigungen sind hierarchisch aufgebaut und werden über Ordnerstrukturen oder Rollenhierarchien vererbt.

Umgang mit Berechtigungsvererbung

Ändert ein Mitarbeiter in Microsoft SharePoint die Freigabe eines übergeordneten Ordners, ändert sich implizit der Zugriff auf tausende Unterdokumente. Schreibt man Benutzerlisten statisch in jeden Chunk, müsste das System sofort zehntausende Vektoreinträge patchen. Dies erzeugt unzulässige Lastspitzen auf Vektordatenbanken.

Lösen lässt sich dies über zweistufige Berechtigungsmodelle:

1. Dokumenten-ACLs: In der Vektordatenbank werden Chunks nur mit der document_id und einer security_scope_id indiziert.
2. Graph-basierte Autorisierungsauflösung: Ein separater Cache (z. B. Redis) hält den Berechtigungsgraphen zwischen Nutzern, Sicherheitsgruppen und Scopes vor. Ändert sich eine Gruppenmitgliedschaft, wird lediglich der Eintrag im Cache invalidiert. Die Vektordatenbank bleibt unberührt.

Chunking und Kontextverlust berücksichtigen

Beim Aufteilen von Dokumenten in Chunks dürfen Sicherheitsmetadaten nicht isoliert betrachtet werden. Wie Studien zur kontextuellen Dokumentverarbeitung zeigen, führt fehlender Dokumentkontext in Chunks zu drastischen Präzisionsverlusten beim Retrieval. Strukturiertes Metadaten-Tagging – einschließlich Breadcrumb-Pfad, Quelltyp und Zugriffs-Scope – sorgt nicht nur für Security-Trimming, sondern senkt auch Retrieval-Fehlerraten nachweislich um bis zu 49 % bis 67 %.

Checkliste für Betriebsrat und CISO: So wird die KI-Wissensdatenbank freigabefähig

Bevor ein internes RAG-System den Produktivstatus erreicht, fordern Datenschutzbeauftragte, CISOs und Arbeitnehmervertretungen verifizierbare Nachweise über den Schutz von Mitarbeiter- und Unternehmensdaten. Folgende Kernfragen müssen beantwortet werden:

• Identitätsweitergabe (Identity Propagation): Wird der Identitätskontext (OAuth2 / OIDC JSON Web Token) des anfragenden Nutzers bis an die Retrieval-Komponente durchgereicht, oder nutzt die Engine einen generischen System-Account?
• Enforcement Point: Findet das Security-Trimming zwingend vor der Generierungsphase und vor der Re-Ranking-Pipeline statt? (Erfolgt Re-Ranking auf ungefilterten Daten, gelangen geschützte Inhalte in Cross-Encoder-Modelle dritter Anbieter).
• Synchronisationsfenster (Time-to-Revoke): Wie schnell wird der Entzug einer Leseberechtigung im Quellsystem (z. B. Kündigung eines Mitarbeiters) in der KI-Wissensdatenbank wirksam?
• Audit-Logging und Revisionssicherheit: Wird protokolliert, welcher Nutzer wann auf welche Dokument-Chunks zugegriffen hat, ohne dabei vertrauliche Inhalte im Klartext in Logs zu schreiben?
• Agentic Execution Safeguards: Wenn autonome Agenten Werkzeuge nutzen, müssen die Sicherheitsbeschränkungen auch über Tool-Aufrufe hinweg aufrechterhalten bleiben. Details dazu beleuchtet der Leitfaden zu Agentic RAG und Enterprise-Sicherheit.

Fazit: RAG Berechtigungsmanagement als Fundament jeder KI-Wissensarchitektur

Ein unternehmensweites Company Brain entfaltet seinen Mehrwert nur dann, wenn Mitarbeiter ihm uneingeschränkt vertrauen können – und wenn Unternehmensleitung sowie Compliance-Beauftragte sicher sein können, dass Betriebsgeheimnisse, Finanzkennzahlen und Personaldaten geschützt bleiben. Berechtigungsmanagement in RAG-Systemen darf kein nachträglich aufgesetztes Feature sein. Es bildet die architektonische Basis des Datenflusses.

Wer den Schritt vom isolierten Chatbot-Proof-of-Concept zur skalierbaren Enterprise-Wissensplattform plant, muss Sicherheits-Trimming über Pre-Filtering, saubere Identitätsweitergabe und entkoppelte Autorisierungsprüfungen von Tag eins an in die Pipeline integrieren.