Ein Company Brain darf nicht alles abrufen, nur weil Daten technisch vorhanden sind. Bei RAG muss die Rechteprüfung vor oder während des Retrievals greifen, sonst kann ein KI-Assistent vertrauliche Informationen aus HR, Geschäftsführung, Kalkulation oder Kundenprojekten in falschen Kontexten anzeigen. Ein gutes KI-Suche Berechtigungskonzept ist deshalb kein Zusatz, sondern die Grundlage für Vertrauen, DSGVO und sichere Nutzung.

Warum ist RAG ohne Berechtigungskonzept gefährlich?

Viele Unternehmen denken bei KI-Suche zuerst an Antwortqualität. Findet der Assistent die richtige Datei? Versteht er die Frage? Gibt er eine gute Zusammenfassung? Das ist wichtig, aber nicht die erste Sicherheitsfrage.

Die erste Sicherheitsfrage lautet: Darf der Nutzer diese Information überhaupt sehen?

Ein RAG-System sucht vor der Antwort relevante Inhalte aus Dokumenten, Datenbanken, Tickets, E-Mails oder Wissensquellen. Diese Inhalte werden dem Sprachmodell als Kontext gegeben. Danach formuliert das Modell eine Antwort. Wenn die Suche dabei Inhalte findet, die für den Nutzer nicht freigegeben sind, ist der Schaden bereits entstanden. Das Modell kann vertrauliche Informationen in eine scheinbar normale Antwort einbauen.

Das Risiko ist besonders groß, weil KI-Suche nicht wie klassische Suche wirkt. Ein Nutzer bekommt nicht nur eine Trefferliste, sondern eine zusammengeführte Antwort. Die Quelle kann aus mehreren Dokumenten stammen. Sensible Details können mit harmlosen Informationen kombiniert werden. Genau deshalb ist Access Control bei RAG nicht optional.

Oso beschreibt das Problem deutlich: RAG-Pipelines seien stark darin, relevante Informationen zu finden, aber schlecht darin, Berechtigungen zu respektieren, wenn Autorisierung nicht bewusst eingebaut wird. Quelle: https://www.osohq.com/post/right-approach-to-authorization-in-rag

Welche Daten sind in einem Company Brain besonders sensibel?

Ein Company Brain enthält selten nur harmlose Handbuchtexte. Sobald es wirklich nützlich wird, enthält es geschäftskritische Informationen.

Dazu gehören HR-Daten, Gehaltsinformationen, Bewerbungsnotizen, interne Bewertungen, Geschäftsführungsunterlagen, Kalkulationen, Preislogik, Margen, Kundensonderkonditionen, Vertragsdetails, Eskalationen, Projektprobleme, technische Zugriffsinformationen, Sicherheitsdokumente, interne Strategien und vertrauliche Kundenkommunikation.

Auch scheinbar harmlose Informationen können sensibel werden, wenn sie kombiniert werden. Ein einzelner Projektstatus ist vielleicht unkritisch. Zusammen mit Kalkulation, Kundenname, interner Einschätzung und Eskalationsnotiz entsteht plötzlich vertrauliches Wissen.

Genau darin liegt die besondere Gefahr von KI-Systemen. Sie finden nicht nur. Sie kombinieren.

Warum reicht es nicht, Berechtigungen nur in SharePoint oder im Dateisystem zu setzen?

Bestehende Rechte in SharePoint, Google Drive, Confluence, Jira oder Dateisystemen sind wichtig. Aber sie lösen das Problem nicht automatisch, sobald Daten in eine RAG-Pipeline übernommen werden.

Beim Indexieren werden Dokumente zerlegt, in Chunks umgewandelt, mit Embeddings versehen und in einer Such- oder Vektordatenbank gespeichert. Wenn dabei die ursprünglichen Berechtigungen nicht sauber übernommen werden, entsteht eine zweite Wissenswelt ohne dieselben Schutzregeln.

Besonders riskant sind diese Fälle:

Ein Nutzer hatte früher Zugriff, aber nicht mehr.
Ein Dokument wurde indexiert, bevor Rechte geändert wurden.
Ein Chunk enthält sensible Inhalte, aber die Berechtigung wurde nur auf Dokumentebene gespeichert.
Metadaten fehlen.
Embeddings oder Suchindizes enthalten Inhalte, die später nicht mehr sichtbar sein sollten.
Ein Agent ruft Daten über eine API ab, ohne Nutzerrechte sauber mitzugeben.

Ein RAG-System muss deshalb Berechtigungen nicht nur kennen, sondern aktiv anwenden.

Wo muss Access Control in RAG greifen?

Access Control kann an mehreren Stellen greifen. Je früher, desto besser. Je später, desto riskanter.

Die wichtigste Regel lautet: Der Assistent darf keinen Kontext erhalten, den der Nutzer nicht sehen darf. Nicht erst die Antwort muss sicher sein. Schon das Retrieval muss sicher sein.

Warum ist nachträgliches Filtern allein zu schwach?

Manche Systeme versuchen, sensible Inhalte erst nach der Antwort zu entfernen. Das ist gefährlich. Wenn das Sprachmodell vertrauliche Inhalte bereits gesehen hat, ist die Grenze überschritten. Selbst wenn die Antwort später gekürzt wird, können Informationen indirekt eingeflossen sein.

Ein Beispiel: Ein Mitarbeiter fragt: „Warum wurde Kunde A im letzten Quartal niedriger priorisiert?“ Das System findet vertrauliche Geschäftsführungsnotizen, interne Margenanalysen und eine kritische Kundenbewertung. Wenn diese Inhalte erst nach der Generierung herausgefiltert werden, kann die Antwort trotzdem indirekte Hinweise enthalten.

Sicherer ist ein Ansatz, bei dem unzulässige Inhalte gar nicht erst in den Modellkontext gelangen. Das bedeutet: Rechteprüfung vor oder während des Retrievals.

AWS beschreibt für RAG-Implementierungen, dass vergleichbare Autorisierungskontrollen für Vektordatenbank-Ergebnisse implementiert werden sollten, bevor diese als Kontext an ein Large Language Model weitergegeben werden. Quelle: https://aws.amazon.com/blogs/security/authorizing-access-to-data-with-rag-implementations/

Welche Kennzahlen zeigen, warum das Thema ernst ist?

IBM beziffert die globalen durchschnittlichen Kosten einer Datenpanne 2025 auf 4,4 Millionen US-Dollar. Der Bericht weist außerdem auf eine wachsende Lücke zwischen KI-Nutzung und KI-Governance hin. Für Company-Brain-Projekte bedeutet das: Sicherheitsarchitektur ist kein theoretisches Risiko, sondern ein wirtschaftliches Thema. Quelle: https://www.ibm.com/reports/data-breach

IBM berichtet außerdem, dass ungoverned AI, also KI-Nutzung ohne ausreichende Governance, häufiger mit Sicherheitsproblemen verbunden ist und Breach-Kosten erhöhen kann. Gerade ein internes RAG-System ohne saubere Zugriffskontrolle fällt genau in diesen Risikobereich, wenn Inhalte breit indexiert, aber nicht sauber autorisiert werden. Quelle: https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai

Der Verizon Data Breach Investigations Report 2025 analysierte 22.052 Sicherheitsvorfälle und 12.195 bestätigte Datenpannen. Das zeigt die Größenordnung realer Sicherheitsprobleme, in denen Zugriff, Berechtigungen, Fehlversand, Missbrauch legitimer Rechte und interne Fehler eine Rolle spielen. Quelle: https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf

OWASP nennt in den Top 10 für Large Language Model Applications sensible Informationsweitergabe als zentrales Risiko und empfiehlt, Datenquellen zu beschränken sowie Runtime-Orchestrierung sicher zu verwalten, um unbeabsichtigte Datenlecks zu vermeiden. Quelle: https://genai.owasp.org/llmrisk/llm02-insecure-output-handling/

Warum ist das besonders für DSGVO relevant?

DSGVO bedeutet nicht nur, Daten irgendwo sicher zu speichern. Es geht auch darum, wer personenbezogene Daten für welchen Zweck sehen und verarbeiten darf. Ein RAG-System, das personenbezogene Daten aus HR, Kundenprojekten oder internen Bewertungen in falschen Kontexten sichtbar macht, kann schnell problematisch werden.

Besonders kritisch sind personenbezogene Daten in Kombination mit KI-Antworten. Wenn ein System aus verschiedenen Quellen Informationen zusammenführt, können neue Risikokontexte entstehen. Ein einzelnes Dokument war vielleicht korrekt berechtigt. Die kombinierte Antwort kann trotzdem mehr offenlegen, als der Nutzer wissen darf.

Für ein Company Brain heißt das: Rollen, Zwecke, Datenkategorien, Berechtigungen und Protokollierung müssen von Anfang an mitgedacht werden.

„Wir haben die Daten doch intern“ ist kein ausreichendes Argument. Intern bedeutet nicht automatisch berechtigt.

Welche Berechtigungsmodelle kommen infrage?

In der Praxis gibt es mehrere Modelle.

Role-Based Access Control, kurz RBAC, ordnet Rechte über Rollen zu. Zum Beispiel Geschäftsführung, Vertrieb, Service, HR oder Projektleitung. Das ist verständlich und gut für den Start, wird aber bei Sonderfällen schnell grob.

Attribute-Based Access Control, kurz ABAC, nutzt Eigenschaften. Zum Beispiel Abteilung, Standort, Kunde, Projekt, Vertraulichkeitsstufe oder Beschäftigungsstatus. Das ist flexibler, braucht aber saubere Metadaten.

Relationship-Based Access Control, kurz ReBAC, prüft Beziehungen. Zum Beispiel: Nutzer ist Mitglied dieses Projektteams, betreut diesen Kunden oder ist Eigentümer dieses Vorgangs. Für moderne Company-Brain-Systeme ist das oft sehr interessant, weil Unternehmenswissen stark an Kunden, Projekte und Rollen gebunden ist.

In vielen Fällen braucht es eine Kombination. Ein Servicemitarbeiter darf vielleicht allgemeine Prozessinformationen sehen, aber keine Kalkulation. Ein Projektleiter darf Projektwissen sehen, aber keine HR-Notizen. Ein Vertriebsmitarbeiter darf Kundendaten sehen, aber nicht interne Margenbewertung.

Was bedeutet Access Control auf Chunk-Ebene?

RAG arbeitet selten mit ganzen Dokumenten. Dokumente werden in kleinere Chunks zerlegt. Genau deshalb reicht eine Berechtigung auf Dateiebene nicht immer.

Ein Dokument kann allgemeine Informationen und vertrauliche Abschnitte enthalten. Wenn daraus einzelne Chunks entstehen, müssen Berechtigungen mitwandern. Sonst kann ein harmloser Dokumenttitel dazu führen, dass ein sensibler Abschnitt gefunden wird.

Beispiel: Ein Projektabschlussbericht enthält eine allgemeine Projektzusammenfassung, technische Lessons Learned, interne Fehleranalyse, Kundeneinschätzung und Margenkalkulation. Nicht jeder Nutzer darf alles sehen. Wenn alle Chunks dieselbe Berechtigung erhalten, ist das entweder zu offen oder zu restriktiv.

Ein gutes Company Brain braucht deshalb Metadaten und Rechte auf Wissensebene, nicht nur auf Dateiablage-Ebene.

Warum sind Embeddings und Vektordatenbanken sicherheitstechnisch heikel?

Embeddings sind mathematische Repräsentationen von Text. Sie enthalten nicht einfach lesbaren Klartext, aber sie entstehen aus Inhalten und können Suchtreffer ermöglichen. Wenn sensible Inhalte ungeprüft eingebettet und in einer Vektordatenbank gespeichert werden, ist die Sicherheitsfrage nicht erledigt.

Wichtig ist: Die Vektordatenbank muss Berechtigungen kennen oder Retrieval-Ergebnisse müssen vor Übergabe an das Modell autorisiert werden. Sonst kann die Suche semantisch passende, aber unzulässige Inhalte finden.

Zusätzlich müssen Löschung und Rechteänderungen bedacht werden. Wenn ein Dokument gelöscht oder entzogen wird, müssen Index, Embeddings und Caches entsprechend aktualisiert werden. Sonst lebt Wissen in der KI-Suche weiter, obwohl es im Ursprungssystem nicht mehr zugänglich ist.

Warum sind Logs und Nachvollziehbarkeit wichtig?

Ein Company Brain muss nicht nur richtige Antworten geben. Es muss auch nachvollziehbar machen, wie Antworten entstanden sind.

Wer hat gefragt? Welche Quellen wurden abgerufen? Welche Treffer wurden dem Modell gegeben? Welche Antwort wurde erzeugt? Wurde eine Quelle wegen fehlender Berechtigung ausgeschlossen? Gab es eine Eskalation? Wurde eine vertrauliche Kategorie berührt?

Ohne Logs lassen sich Fehler nicht untersuchen. Ohne Logs ist auch schwer nachzuweisen, dass Berechtigungen eingehalten wurden. Für Vertrauen im Mittelstand ist das wichtig. Führungskräfte wollen wissen, dass ein KI-Assistent nicht still und unsichtbar Daten aus Bereichen zusammenzieht, die getrennt bleiben müssen.

Logging darf allerdings selbst nicht zum Datenschutzproblem werden. Auch Protokolle brauchen Zweck, Zugriffsbeschränkung, Löschkonzept und technische Absicherung.

Welche Fehler machen Unternehmen beim Berechtigungskonzept?

Der häufigste Fehler ist zu viel Vertrauen in bestehende Ordnerrechte. Unternehmen glauben, die Rechte seien bereits gelöst, weil SharePoint oder ein Dateiserver Berechtigungen hat. Nach der Indexierung gilt das aber nur, wenn diese Rechte sauber in die RAG-Pipeline übertragen und laufend aktualisiert werden.

Der zweite Fehler ist ein zu grobes Rollenmodell. „Alle Mitarbeiter“ ist in einem Company Brain fast nie eine gute Sicherheitskategorie.

Der dritte Fehler ist fehlende Aktualisierung. Mitarbeitende wechseln Rollen, verlassen Projekte, erhalten temporären Zugriff oder verlieren Zuständigkeiten. Wenn die KI-Suche das nicht zeitnah abbildet, entsteht ein Schattenzugriff.

Der vierte Fehler ist fehlende Trennung zwischen Suche und Antwort. Ein Treffer darf nicht nur deshalb verwendet werden, weil er relevant ist. Er muss relevant und erlaubt sein.

Wie sollte ein sicheres Company Brain aufgebaut werden?

Ein sicheres Company Brain beginnt mit Datenklassifikation. Welche Inhalte sind öffentlich, intern, vertraulich, streng vertraulich oder personenbezogen? Danach braucht es Rollen, Attribute und Beziehungen. Wer darf was sehen, aus welchem Grund und in welchem Kontext?

Dann folgt die technische Umsetzung: Berechtigungen müssen beim Indexieren übernommen, auf Chunks angewendet, beim Retrieval geprüft und in Antworten sichtbar gemacht werden. Quellen sollten angezeigt werden, soweit sie für den Nutzer freigegeben sind. Unsicherheit sollte zu einer Rückfrage oder Eskalation führen, nicht zu einer geratenen Antwort.

Zusätzlich braucht es regelmäßige Audits. Berechtigungen sind kein einmaliges Projekt. Sie verändern sich mit Mitarbeitern, Kunden, Projekten und Organisation.

Warum ist KI-Suche ohne Berechtigungskonzept gefährlich?

KI-Suche ohne Berechtigungskonzept ist gefährlich, weil sie Informationen nicht nur findet, sondern neu kombiniert und verständlich ausgibt. Dadurch können vertrauliche Inhalte sichtbar werden, auch wenn der Nutzer nie direkt nach einem geheimen Dokument gefragt hat.

Ein sicheres Company Brain muss deshalb die gleiche Grundregel erfüllen wie jedes professionelle IT-System: Zugriff nur, wenn Berechtigung, Zweck und Kontext passen.

Erst dann wird aus RAG ein vertrauenswürdiges Unternehmenswerkzeug.

Interessante Links

OWASP – Top 10 for Large Language Model Applications
https://owasp.org/www-project-top-10-for-large-language-model-applications/

AWS Security Blog – Authorizing access to data with RAG implementations
https://aws.amazon.com/blogs/security/authorizing-access-to-data-with-rag-implementations/

Auth0 – Build Trustworthy AI: Implementing Access Control for RAG Systems Using FGA
https://auth0.com/blog/rag-and-access-control-where-do-you-start/

Quellen der verwendeten Kennzahlen

IBM – Cost of a Data Breach Report 2025
https://www.ibm.com/reports/data-breach

IBM X-Force – 2025 Cost of a Data Breach Report: Navigating the AI rush without taking on security debt
https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai

Verizon – 2025 Data Breach Investigations Report Executive Summary
https://www.verizon.com/business/resources/reports/2025-dbir-executive-summary.pdf

OWASP – LLM02:2025 Sensitive Information Disclosure
https://genai.owasp.org/llmrisk/llm02-insecure-output-handling/

FAQ

Was bedeutet Access Control bei RAG?

Access Control bei RAG bedeutet, dass ein KI-System nur Inhalte abrufen und verwenden darf, für die der jeweilige Nutzer berechtigt ist. Die Prüfung muss vor oder während des Retrievals stattfinden. Es reicht nicht, sensible Informationen erst nach der Antwort zu entfernen, weil sie dann bereits im Modellkontext gelandet sind.

Warum ist KI-Suche ohne Berechtigungskonzept riskant?

KI-Suche kann Inhalte aus verschiedenen Quellen zusammenführen und als eine klare Antwort ausgeben. Wenn dabei HR-Daten, Kalkulationen, Geschäftsführungsunterlagen oder vertrauliche Kundeninformationen einfließen, entsteht ein Datenleck. Das Risiko ist größer als bei klassischer Suche, weil sensible Details indirekt kombiniert werden können.

Reichen SharePoint-Rechte für ein Company Brain aus?

SharePoint-Rechte sind wichtig, reichen aber nicht automatisch aus. Wenn Dokumente indexiert, zerlegt und in einer Vektordatenbank gespeichert werden, müssen die ursprünglichen Berechtigungen sauber übernommen und laufend aktualisiert werden. Sonst entsteht eine zweite Wissenswelt mit anderen oder unvollständigen Zugriffskontrollen.

Was ist der Unterschied zwischen RBAC, ABAC und ReBAC?

RBAC vergibt Rechte über Rollen wie Vertrieb, Service oder HR. ABAC nutzt Attribute wie Standort, Kunde, Projekt oder Vertraulichkeitsstufe. ReBAC prüft Beziehungen, etwa ob ein Nutzer Mitglied eines Projektteams ist. Für ein Company Brain ist oft eine Kombination sinnvoll, weil Wissen an Rollen, Kunden und Projekte gebunden ist.

Warum müssen Berechtigungen auf Chunk-Ebene betrachtet werden?

RAG-Systeme arbeiten meist nicht mit ganzen Dokumenten, sondern mit Textabschnitten. Ein Dokument kann harmlose und vertrauliche Abschnitte enthalten. Wenn alle Chunks dieselbe Berechtigung bekommen, ist das entweder zu offen oder zu restriktiv. Deshalb müssen Rechte und Metadaten möglichst auf Wissensebene mitgeführt werden.

Was passiert, wenn Rechte nach der Indexierung geändert werden?

Wenn Rechte geändert werden, muss die KI-Suche diese Änderung nachvollziehen. Sonst kann ein Nutzer weiterhin Inhalte über den Index finden, obwohl er im Ursprungssystem keinen Zugriff mehr hat. Deshalb braucht ein Company Brain Synchronisation, Re-Indexierung, Berechtigungsprüfung beim Retrieval und klare Regeln für Caches.

Welche Rolle spielt DSGVO bei RAG-Systemen?

DSGVO ist relevant, sobald personenbezogene Daten verarbeitet werden. Ein RAG-System darf solche Daten nicht beliebig abrufen, kombinieren oder anzeigen. Es braucht Zweckbindung, Zugriffsbeschränkung, Datenminimierung, Protokollierung und Löschkonzepte. Intern gespeicherte Daten sind nicht automatisch für jeden internen Nutzer freigegeben.

Wie startet man ein sicheres Berechtigungskonzept?

Der Start sollte mit Datenklassifikation beginnen. Danach werden Rollen, Attribute, Beziehungen und sensible Datenkategorien definiert. Anschließend wird festgelegt, welche Inhalte indexiert werden dürfen, welche Rechte auf Chunks gelten, wie Retrieval gefiltert wird und wie Zugriffe protokolliert und regelmäßig geprüft werden.