Zugriffskontrolle als Kernproblem von Enterprise-KI

Ein HR-Mitarbeiter arbeitet drei Monate lang in einem vertraulichen Reorganisationsprojekt. Er sieht Organigramme, Risikolisten, Standortentscheidungen, Gesprächsleitfäden und erste Entwürfe für Rollenänderungen. Danach wechselt er in eine andere Funktion. In SharePoint, Confluence oder Google Drive werden seine Rechte entzogen. Formal ist der Zugriff beendet.

Aber weiß das auch die KI?

Bei Enterprise-RAG entscheidet Zugriffskontrolle darüber, welcher Kontext überhaupt ins Modell gelangt. Nicht erst, welche Antwort am Ende angezeigt wird. Wenn ein System alte Chunks aus einem vertraulichen HR-Projekt weiterhin semantisch findet, kann es aus ehemals berechtigten Informationen neue Antworten synthetisieren. Genau deshalb ist Enterprise-KI Zugriffskontrolle kein Prompt-Thema, sondern ein Architekturthema.

Die TensorFive RAG API setzt hier an: als Enterprise-RAG-as-a-Service und als technische Grundlage für T5.Chat. Sie ist nicht nur ein Such- oder Chat-Feature, sondern integriert Berechtigungslogik für Retrieval, Kontextbildung und Audit-orientierte Nachvollziehbarkeit in KI-Anwendungen, die Unternehmenswissen nutzen.

Warum klassische Berechtigungen bei RAG nicht automatisch reichen

In klassischen Unternehmenssystemen ist Zugriffskontrolle vergleichsweise klar: Ein Nutzer öffnet ein Dokument, das System prüft die Berechtigung, der Zugriff wird erlaubt oder verweigert.

RAG verändert diese Linie. Ein Enterprise-RAG-System liest aus vielen Quellen, übernimmt Dokumente, zerlegt sie in Chunks, erzeugt Embeddings, reichert Kontext an, sucht semantisch, rankt Treffer und erzeugt daraus eine Antwort. Zwischen Quelle und Antwort liegt eine Pipeline. Jeder Schritt kann Berechtigungsinformationen erhalten, verlieren, veralten oder falsch interpretieren.

Das Problem lautet also nicht nur: „Darf Person A Dokument B sehen?“ Die präzisere Frage lautet: „Darf Person A eine Antwort erhalten, die aus Dokument B, aus Chunks von Dokument B oder aus Beziehungen zu Dokument B abgeleitet wurde?“

Gerade HR zeigt die Schärfe des Problems. Reorganisationsdaten sind zeitkritisch, personenbezogen, rollenabhängig und politisch sensibel. Ein Mitarbeitender kann gestern berechtigt gewesen sein und heute nicht mehr. Gruppenmitgliedschaften ändern sich. Projektbereiche werden geschlossen. Externe Berater verlassen den Tenant. Führungskräfte wechseln Rollen.

Wenn der RAG-Index diese Änderungen nur verzögert berücksichtigt, entsteht ein Konsistenzfenster. In diesem Fenster kann ein System technisch korrekt suchen und fachlich trotzdem falsch handeln.

Warum „wir prüfen das am Ende“ nicht reicht

In vielen KI-Projekten taucht früh eine scheinbar pragmatische Gegenposition auf: Das Modell arbeitet zuerst, danach prüft ein Prompt, eine Policy oder ein Output-Filter, ob die Antwort erlaubt ist.

Das ist zu spät.

Ein Output-Filter sieht nur die fertige Antwort. Er sieht nicht zwingend, welche Chunks in den Kontext gelangt sind, aus welchen Quellen eine Schlussfolgerung stammt oder ob eine paraphrasierte Aussage aus vertraulichen Inhalten abgeleitet wurde. Das Modell „versteht“ Berechtigungen nicht wie ein Autorisierungssystem. Es verarbeitet Text.

Guardrails sind wichtig, aber sie sind die letzte Verteidigungslinie. Sie ersetzen nicht die Entscheidung, ob ein Chunk überhaupt in den Modellkontext darf. Kleine interne, simulationsbasierte Validierungen im TensorFive-Kontext stützen diese Vorsicht qualitativ: Direkte Verstöße waren leichter zu erkennen als indirekte Referenzen auf eingeschränkte Inhalte. Diese Ergebnisse sind kein allgemeiner Benchmark, aber sie zeigen den Architekturpunkt: Wer RAG Berechtigungen erst am Ende prüft, macht die unsicherste Schicht zur entscheidenden.

Zwei Schutzmodelle, ein Ziel

Für saubere Diskussionen muss man zwei Ebenen trennen.

Das erste Modell ist pipeline-seitig. Es beschreibt, wie Permission-Aware Retrieval entlang des RAG-Prozesses abgesichert wird:

1. Ingestion-Time Permission Extraction
2. Query-Time Filtering
3. Real-Time Authorization
4. Output Guardrails

Das zweite Modell sind die öffentlich beschriebenen Zugriffsschichten der TensorFive RAG API. Dazu gehören:

1. API-Key-Scope
2. Tenant-Isolation
3. Projekt-Scoping
4. Dokumentbasierte Berechtigungen und ReBAC

Beide Modelle widersprechen sich nicht. Sie betrachten dieselbe Sicherheitsfrage aus unterschiedlichen Perspektiven. Die Pipeline fragt: An welcher Stelle im Retrieval-Prozess wird geprüft? Die API fragt: Welche Grenzen gelten für Nutzer, Projekte, Mandanten und Dokumente?

Wie Permission-Aware Retrieval funktioniert

Das folgende Diagramm liest man von links nach rechts: Zuerst werden Quellen und Berechtigungen aufgenommen, dann wird bei der Suche gefiltert, bei sensiblen oder dynamischen Daten zusätzlich autorisiert und erst danach Kontext an das Modell übergeben.

flowchart LR
    A["Quellsysteme<br/>SharePoint, Confluence, Google Drive, Jira"] --> B["Ingestion-Time<br/>Permission Extraction"]
    B --> C["Identitätsauflösung<br/>User, Gruppen, Rollen"]
    C --> D["Permission Store<br/>ReBAC"]
    B --> E["RAG Index<br/>Chunks, Embeddings, Metadaten"]
    F["Nutzerfrage<br/>Tenant, Projekt, API-Key-Scope"] --> G["Query-Time Filtering"]
    D --> G
    E --> G
    G --> H{"Sensible oder<br/>hochdynamische Daten?"}
    H -- "Ja" --> I["Real-Time Authorization"]
    H -- "Nein" --> J["Autorisierte Chunks"]
    I --> J
    J --> K["LLM / Antwortgenerierung"]
    K --> L["Output Guardrails<br/>Policy, Quellen, Leakage Checks"]
    L --> M["Antwort + Audit Log"]

Die zentrale Aussage des Diagramms: Zugriffskontrolle beginnt vor der Antwort. Der entscheidende Kontrollpunkt liegt dort, wo aus vielen möglichen Treffern ein erlaubter Modellkontext wird.

Schutzebene 1: Permissions bei der Ingestion übernehmen

Der erste Schritt ist, Berechtigungen aus den Quellsystemen beim Indexieren zu übernehmen. Dazu gehören direkte Nutzerrechte, Gruppenrechte, geerbte Ordnerrechte und Quell-IDs, die auf kanonische Unternehmensidentitäten abgebildet werden.

Das klingt einfacher, als es ist. SharePoint, Google Drive, Confluence, Jira und relationale Datenbanken modellieren Zugriff unterschiedlich. Manche Quellen haben explizite ACLs, andere arbeiten stärker mit Gruppen, Rollen, Bereichen oder Projektmitgliedschaften. Auch E-Mail-Aliasse, externe Gäste und verschachtelte Gruppen müssen sauber aufgelöst werden.

Die TensorFive RAG API übernimmt bestehende Berechtigungen connector- und detailgradabhängig, insbesondere dokumentenbasiert. Das ist ein wichtiger Schutz gegen den häufigsten Fehler in Enterprise-RAG: Inhalte werden semantisch verfügbar gemacht, ohne ihre Zugriffswirklichkeit mitzunehmen.

Gleichzeitig muss die Grenze klar sein. Wenn eine Quelle feinere Rechte auf Abschnitts-, Zeilen-, Feld- oder Chunk-Ebene hat, müssen diese gesondert modelliert werden. Dokumentenbasierte Berechtigungen reichen dann nicht automatisch aus.

Schutzebene 2: Query-Time Filtering vor dem Kontext

Die zweite Ebene ist Query-Time Filtering. Bevor Chunks an das Modell gehen, wird die Suche auf das eingeschränkt, was der Nutzer im aktuellen Tenant, Projekt und Berechtigungskontext sehen darf.

Das ist ein zentraler Unterschied zu nachgelagerten Filtern: Nicht die Antwort wird bereinigt, sondern der Kontext wird begrenzt, bevor das Modell ihn verarbeitet. Bei RAG ist der Modellkontext selbst eine Sicherheitsgrenze. Was nie im Kontext landet, muss später nicht durch Prompt-Regeln wieder eingefangen werden.

In der TensorFive RAG API greifen hier API-Key-Scopes, Tenant-Isolation, Projekt-Scoping und dokumentbasierte Berechtigungen ineinander. Diese Architektur ist auch die Grundlage für T5.Chat, das Unternehmenswissen semantisch durchsucht. T5.Chat basiert auf der RAG API; die Berechtigungslogik sitzt damit nicht nur in der Chat-Oberfläche, sondern in der darunterliegenden Retrieval-Schicht.

Schutzebene 3: Real-Time Authorization für sensible Daten

Die dritte Ebene ist Real-Time Authorization. Dabei wird kurz vor der Nutzung eines Treffers geprüft, ob der Nutzer weiterhin berechtigt ist. Diese Prüfung kann gegen ein Autorisierungssystem oder gegen aktuelle Berechtigungsinformationen aus der Quelle erfolgen.

Diese Ebene ist nicht für jeden Use Case gleich zwingend. Ein internes FAQ mit stabil freigegebenen Informationen braucht nicht dieselbe Strenge wie HR-Reorganisationsunterlagen, Vertragsdaten, Kundendaten, Audit-Unterlagen oder regulatorische Dokumente.

Für sensible, regulierte oder hochdynamische Daten sollte Real-Time Authorization jedoch als verbindliche Architekturvorgabe behandelt werden. Dort ist das Risiko eines Konsistenzfensters am höchsten: Rechte wurden entzogen, aber der Index oder ein Gruppen-Cache arbeitet noch mit einem alten Stand.

Interne simulationsbasierte Analysen im TensorFive-Kontext zeigen dieses Muster klar: Ohne zusätzliche Echtzeitprüfung bleibt ein System während eines Sync-Fensters anfälliger für veraltete Berechtigungsstände. Mit Echtzeitprüfung kann dieses Risiko deutlich reduziert werden. Das ist kein Produktionsbenchmark und keine Sicherheitsgarantie, aber ein belastbares Argument für die Architekturentscheidung.

Schutzebene 4: Output Guardrails als letzte Kontrolle

Output Guardrails prüfen, ob eine Antwort sensible Muster enthält, ob Quellen fehlen, ob Inhalte außerhalb autorisierter Kontexte auftauchen oder ob bestimmte Policy-Regeln verletzt werden.

Sie sind sinnvoll für Monitoring, Audit und zusätzliche Schadensbegrenzung. Aber sie dürfen nicht als primäre Zugriffskontrolle verstanden werden. Guardrails können indirekte Hinweise, Zusammenfassungen und semantisch abgeleitete Aussagen übersehen. Sie sind eine letzte Kontrolle, nicht der Ort, an dem die eigentliche Autorisierungsentscheidung fallen sollte.

ReBAC, Zanzibar und OpenFGA: Warum Beziehungen besser passen

Erst nach dem Problem lohnt sich der Blick auf die Begriffe.

Relationship-Based Access Control, kurz ReBAC, beschreibt Berechtigungen als Beziehungen: Nutzerin ist Mitglied einer Gruppe. Gruppe hat Zugriff auf Ordner. Ordner enthält Dokument. Dokument erzeugt Chunks. Ein Projekt gehört zu einem Tenant. Ein API-Key darf nur in einem bestimmten Scope lesen.

Das passt besser zu Unternehmen als starre Rollenmodelle allein. Zugriff entsteht oft aus Teammitgliedschaft, Projektzugehörigkeit, Mandant, Dokumentbesitz, Freigabe und Vererbung.

Google Zanzibar hat dieses Denken im großen Maßstab bekannt gemacht. OpenFGA ist eine verbreitete offene Implementierung für solche relationellen Autorisierungsmodelle. TensorFive ist in diesem Sinne ReBAC- und Zanzibar-inspiriert. Das bedeutet nicht, dass TensorFive mit Zanzibar gleichzusetzen ist oder alle Zanzibar-Mechanismen identisch übernimmt.

Eine wichtige Grenze sind zookie-artige Konsistenz-Tokens. Zanzibar nutzt solche Konzepte, um Race Conditions zwischen Rechteänderung und Zugriff zu adressieren. Für Enterprise-RAG sind vergleichbare Versionierungs- und Konsistenzmechanismen eine relevante Weiterentwicklung, besonders bei sehr sensiblen oder stark dynamischen Datenräumen.

DSGVO-konforme Deployments brauchen mehr als Technik

Die TensorFive RAG API unterstützt DSGVO-konforme Deployments unter anderem durch DSGVO-konforme Architektur, EU-Rechenzentrum, On-Premise-Optionen, Tenant-Isolation, dokumentbasierte Zugriffskontrolle und Audit-orientierte Nachvollziehbarkeit.

Trotzdem sollte der Begriff eng geführt werden. Eine Plattform schafft technische und organisatorische Voraussetzungen, aber die konkrete Compliance entsteht im Deployment. Dazu gehören Auftragsverarbeitungsvertrag, technische und organisatorische Maßnahmen, Subprozessoren, Lösch- und Exportprozesse, Betroffenenrechte, Rollen- und Berechtigungskonzepte, Protokollierung sowie die dokumentierte Rechtsgrundlage.

Bei HR-Daten ist zusätzlich besondere Vorsicht geboten. Je nach Einsatzszenario können Datenschutz-Folgenabschätzung, arbeitsrechtliche Mitbestimmung und unter der EU-KI-Verordnung eine Prüfung von Hochrisiko- oder Fundamental-Rights-Impact-Aspekten relevant werden. Gerade deshalb muss Zugriffskontrolle früh in die Architektur und nicht erst in die Betriebsdokumentation.

Grenzen, die früh auf den Tisch gehören

Sichere Enterprise-KI beginnt nicht mit großen Versprechen, sondern mit klaren Grenzen.

Erstens: Konsistenzfenster verschwinden nicht automatisch. Wenn Quellsysteme, Gruppenverzeichnisse und RAG-Indizes asynchron arbeiten, gibt es Zeiträume, in denen alte Berechtigungsstände noch sichtbar sein können. Real-Time Authorization reduziert dieses Risiko erheblich, ersetzt aber nicht jedes Konsistenzdesign.

Zweitens: Permission-Aware Retrieval ersetzt nicht Prompt-Injection-Sanitizing. Retrieved Chunks müssen als potenziell unsichere Inhalte behandelt werden. Ein Dokument kann selbst Anweisungen enthalten, die das Modell manipulieren sollen. Deshalb braucht es Trust Boundaries zwischen Systeminstruktionen, Nutzerfragen und abgerufenen Inhalten.

Drittens: Embeddings sind eigene Schutzobjekte. Wer sehr sensible Daten indexiert, muss auch über Schutzkonzepte für Vektoren, Metadaten, Mandantentrennung, Verschlüsselung, Löschung und mögliche Rekonstruktionsrisiken nachdenken.

Viertens: Dokumentrechte können zu grob sein. Wenn ein Dokument sowohl allgemeine Policy-Abschnitte als auch personenbezogene HR-Details enthält, braucht es unter Umständen Sub-Document-Rechte, Chunk-Level Permissions oder Redaction-Strategien.

Fünftens: Auditierbarkeit ist kein Nebenprodukt. Wer Enterprise-KI in regulierten Umgebungen betreibt, muss nachweisen können, wer wann mit welchem Berechtigungskontext auf welche Wissensbasis zugegriffen hat und welche Quellen in eine Antwort eingeflossen sind.

Was Entscheider daraus ableiten sollten

Für CTOs, CIOs, CDOs, Security und Datenschutz lautet die wichtigste Architekturentscheidung: Zugriffskontrolle muss vor der Generierung greifen.

Ein KI-System, das unautorisierten Kontext erst ins Modell gibt und danach auf Filter hofft, ist für sensible Enterprise-Use-Cases falsch geschnitten. Die bessere Architektur prüft Berechtigungen entlang der Pipeline: beim Indexieren, beim Suchen, vor der Kontextübergabe, bei der Antwortkontrolle und im Audit.

Für die Auswahl einer Enterprise-RAG-Plattform ergeben sich daraus konkrete Fragen:

• Wie werden Berechtigungen aus SharePoint, Confluence, Google Drive, Jira oder Datenbanken übernommen?
• Welche Rechte werden dokumentenbasiert übernommen, und wo braucht es feinere Modelle?
• Wie werden Tenant, Projekt, API-Key und Nutzeridentität kombiniert?
• Wann wird nur gefiltert, und wann erfolgt Real-Time Authorization?
• Welche Audit-Informationen werden für Datenschutz, Security und Revision bereitgestellt?
• Wie werden Prompt Injection, unsichere Chunks und Embedding-Schutz zusätzlich adressiert?

Die TensorFive RAG API ist darauf ausgelegt, diese Fragen architektonisch zu adressieren: als Grundlage für Enterprise-RAG-Anwendungen, einschließlich T5.Chat. Zugriffskontrolle wird damit nicht an die Oberfläche delegiert, sondern in die Retrieval-, Kontext- und Audit-Schicht gelegt.

Genau dort gehört sie hin.

Fazit: Die KI darf nicht mehr wissen als der Nutzer

Enterprise-KI wird nur dann produktionsreif, wenn sie die Zugriffswirklichkeit des Unternehmens respektiert. Nicht ungefähr. Nicht nachträglich. Nicht nur per Prompt.

Das HR-Beispiel zeigt, warum: Ein ehemaliges Projektmitglied darf nach einem Rollenwechsel nicht durch semantische Suche, alte Chunks oder synthetisierte Antworten weiter Zugriff auf vertrauliche Reorganisationsinformationen behalten.

Permission-Aware Retrieval ist deshalb kein Detail der Suchqualität. Es ist die Sicherheitsarchitektur von Enterprise-RAG.

Wer RAG im Unternehmen einführt, sollte die entscheidende Frage früh stellen: Welche Berechtigung entscheidet, ob dieser Chunk überhaupt in den Kontext darf?

Wenn Sie diese Frage für Ihre eigene Architektur klären möchten, sprechen Sie mit TensorFive über die RAG API als Berechtigungsschicht für Enterprise-RAG, T5.Chat und sichere KI-Anwendungen auf Unternehmenswissen.