Warum RAG-Implementierungen Sicherheitsprüfungen nicht bestehen – und wie Sie eine entwickeln, die überzeugt
Die Demo funktionierte. Das Pilotprojekt überzeugte. Das Business Case war überzeugend. Und dann begann die Sicherheitsüberprüfung.
Für viele KI-Teams in Unternehmen ist dies der Punkt, an dem Retrieval Augmented Generation (RAG)-Projekte ins Stocken geraten – nicht, weil die Technologie versagt hat, sondern weil die Architektur, die eine überzeugende Demo ermöglichte, nicht die Architektur ist, die die Anforderungen des Security-Teams an ein produktives Datenzugriffssystem erfüllt.
Das Scheitern folgt einem vorhersehbaren Muster: Das KI-Team baut ein System, das auf optimale Retrieval-Qualität und Entwicklergeschwindigkeit ausgelegt ist; das Security-Team bewertet es als System, das auf sensible Unternehmensdaten im großen Maßstab zugreift; die beiden Perspektiven führen zu unterschiedlichen Einschätzungen der Einsatzbereitschaft.
Dieser Beitrag richtet sich an VP AI/ML Engineering und CISOs, die das Muster verstehen, die Lücke schließen und RAG ohne erneuten Neustart der Sicherheitsüberprüfung in die Produktion bringen wollen.
Executive Summary
Hauptaussage: RAG-Implementierungen scheitern aus sechs vorhersehbaren Gründen an der Sicherheitsüberprüfung, die alle auf dieselbe Ursache zurückzuführen sind: Die Retrieval-Schicht wurde als Infrastruktur und nicht als gesteuertes Datenzugriffssystem behandelt. Security-Teams blockieren RAG nicht, weil sie gegen KI sind – sie blockieren, weil die Retrieval-Komponente das Datenzugriffsprofil eines privilegierten Systems und die Governance-Haltung eines Entwicklungstools hat. Die Behebung der sechs Fehlerquellen erfordert, dass die Governance-Schicht vor der Sicherheitsüberprüfung in die Retrieval-Architektur integriert wird – nicht erst währenddessen.
Warum das wichtig ist: Jeder Zyklus, den ein RAG-Projekt mit der Behebung von Sicherheitsüberprüfungsbefunden verbringt, ist ein Zyklus, in dem es keinen geschäftlichen Mehrwert liefert. Die Kosten sind nicht nur Verzögerungen – es geht um die Glaubwürdigkeit des KI-Programms gegenüber den Stakeholdern, die das Projekt genehmigt haben, und um die Beziehung zwischen KI-Team und Security-Funktion, die alle künftigen KI-Projekte steuern wird. RAG von Anfang an richtig zu bauen, ist keine Compliance-Übung; es ist die Grundlage für das Vertrauen, das künftige Projekte beschleunigt.
5 Wichtige Erkenntnisse
- Security-Teams bewerten RAG-Pipelines als Datenzugriffssysteme, nicht als KI-Tools. Die Bewertungskriterien sind die gleichen wie für jedes System, das auf sensible Unternehmensdaten im großen Maßstab zugreift: Authentifizierung, Zugriffskontrollen, Audit-Logging, Monitoring und Incident Response. KI-Teams, die RAG als Produktivitätsanwendung präsentieren, beantworten Fragen, die das Security-Team nicht stellt.
- Die sechs häufigsten Fehlerquellen bei der Sicherheitsüberprüfung sind alle architektonisch, nicht konfigurationsbedingt. Sie lassen sich nicht durch zusätzliche Dokumentation oder Anpassung von Richtlinien beheben. Es sind Änderungen an der Authentifizierungsarchitektur, der Autorisierung der Retrieval-Schicht, der Logging-Infrastruktur und der Monitoring-Integration erforderlich – Änderungen, die deutlich einfacher vor dem Bau der Retrieval-Schicht umzusetzen sind als nach dem Pilotbetrieb.
- Die Lücke zwischen den Anforderungen der Security und dem, was KI-Teams bauen, ist kein Kommunikationsproblem – es ist ein Priorisierungsproblem. Retrieval-Qualität, Entwicklererfahrung und Time-to-Demo werden in der Bauphase optimiert; Zugriffskontrollen, Audit-Logging und Monitoring nicht. Das Ergebnis ist ein System, das in den vom KI-Team gemessenen Dimensionen gut abschneidet und in den vom Security-Team gemessenen Dimensionen scheitert.
- Pre-Retrieval-Authorization-Scoping ist die architektonische Entscheidung, die die meisten Sicherheitsfragen gleichzeitig löst. Wenn die Retrieval-Schicht pro Anfrage RBAC und ABAC durchsetzt und den Zugriff auf das beschränkt, wozu der authentifizierte Anwender berechtigt ist, wird das Problem der übermäßigen Berechtigungen gelöst, die Frage der Durchsetzung der Datenklassifizierung beantwortet und der Test auf Autorisierungsgleichwertigkeit erfüllt.
- Eine gesteuerte Retrieval-Schicht ist keine Einschränkung für RAG-Funktionalität – sie ist der Unterschied zwischen einem RAG-Projekt, das produktiv wird, und einem, das immer wieder durch die Sicherheitsüberprüfung fällt. Das AI Data Gateway liefert die Governance-Schicht als einsatzbereite Komponente statt als Eigenentwicklung, sodass KI-Teams die Sicherheitsanforderungen erfüllen können, ohne die Retrieval-Architektur neu zu bauen.
Warum Sicherheitsüberprüfungen RAG-Projekte stoppen: Das strukturelle Missverständnis
Das Missverständnis zwischen KI-Teams und Security-Teams bei RAG ist strukturell, nicht persönlich. KI-Teams bauen RAG-Pipelines mit Frameworks wie LangChain, LlamaIndex, Haystack, die auf Retrieval-Qualität und Entwicklungsgeschwindigkeit optimiert sind. Diese Frameworks beherrschen Vektorindizierung, Embedding, semantische Suche und Kontextzusammenstellung. Sie bieten jedoch keine per-Anwender-Autorisierung, kein pro-Dokument-Logging, keine Durchsetzung von Sensitivitätskennzeichnungen oder SIEM-Integration – denn das sind keine Retrieval-Qualitätsprobleme, sondern Governance-Probleme, die von den Framework-Entwicklern nicht gelöst wurden.
Wenn ein Security-Team das resultierende System prüft, wendet es die gleichen Bewertungskriterien an wie bei jedem neuen Datenzugriffssystem. Es fragt: Wer kann auf welche Daten zugreifen, wie wird dieser Zugriff gesteuert, wie wird er protokolliert, wie wird er überwacht und was passiert, wenn etwas schiefgeht?
Die RAG-Pipeline beantwortet diese Fragen schlecht – nicht, weil das KI-Team nachlässig war, sondern weil das verwendete Framework diese Fragen standardmäßig nicht gut beantwortet. Das Servicekonto existiert, weil es der einfachste Weg war, Retrieval zum Laufen zu bringen. Das Session-Logging existiert, weil es das Framework so vorsieht. Das Fehlen der Durchsetzung von Sensitivitätskennzeichnungen existiert, weil das Framework keine MIP-Labels kennt.
Das Ergebnis ist ein sich wiederholender Zyklus in Unternehmen: KI-Team präsentiert die Demo, Security-Team prüft, findet sechs Probleme, KI-Team behebt diese in zwei Monaten, während Business-Stakeholder fragen, wann das Projekt live geht, KI-Team präsentiert erneut, Security-Team findet drei verbleibende Probleme, Zyklus wiederholt sich. Die Projekte, die diesen Zyklus durchbrechen, sind diejenigen, bei denen die Retrieval-Architektur von Anfang an mit den Sicherheitskriterien entwickelt wurde – bei denen Data Governance ein Design-Input war und kein Gate am Ende.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es auch nachweisen?
Jetzt lesen
Die sechs Fehlerquellen: Was Security findet und warum sie die Freigabe blockiert
Die folgenden sechs Fehlerquellen treten in den meisten RAG-Sicherheitsüberprüfungen in regulierten Branchen auf. Jede steht für eine Frage, die das Security-Team stellt, eine Antwort, die das KI-Team mit der Standard-RAG-Architektur nicht geben kann, und eine architektonische Änderung, die zur Lösung erforderlich ist.
| Fehlerquelle | Was das KI-Team gebaut hat | Warum Security blockiert | Was es löst |
|---|---|---|---|
| Übermäßige Berechtigungen beim Retrieval | RAG-Pipeline nutzt ein Servicekonto mit weitreichendem Repository-Zugriff; Retrieval basiert auf Relevanz ohne per-Anwender-Autorisierung | Security-Team fragt: Was verhindert, dass ein Anwender Dokumente außerhalb seiner Berechtigungsstufe abruft? Das KI-Team hat keine Antwort, die keine grundlegende architektonische Änderung erfordert. | Durchsetzung von RBAC/ABAC pro Anfrage in der Retrieval-Schicht; Zugriff nur auf das, wozu der authentifizierte Anwender berechtigt ist, nicht auf alles semantisch Relevante im gesamten Korpus |
| Servicekonto-Authentifizierung | KI-System authentifiziert sich an Datenquellen über ein gemeinsames Servicekonto oder statischen API-Key; keine individuelle Anwenderidentität wird erhalten | Security-Team fragt: Wer ist für jeden Datenzugriff verantwortlich? Das KI-Team kann keine individuelle Zuordnung liefern – im Log steht nur das Servicekonto. | OAuth 2.0 mit PKCE und anwenderdelegierter Autorisierung; individuelle Anwenderidentität wird im Authentifizierungsprozess bis zur Retrieval-Schicht erhalten und bei jedem Zugriff protokolliert |
| Kein Audit-Trail auf der Retrieval-Schicht | Logging erfolgt auf der KI-Anwendungsebene (Session-Logs, Query-Logs), aber nicht auf der Datenebene; einzelne Dokumentenabrufe werden nicht erfasst | Security-Team fragt: Können Sie für jedes abgerufene Dokument, den Anwender und das Datum einen Nachweis liefern? Das KI-Team kann Session-Logs liefern, die die Anforderungen an pro-Dokument/pro-Anwender-Aufzeichnung nicht erfüllen. | Pro-Dokument-Logging auf der Datenebene, das Dokumenten-ID, Anwenderidentität, Autorisierungsentscheidung, Sensitivitätsklassifizierung und Zeitstempel für jedes Retrieval-Ereignis erfasst |
| Keine Durchsetzung von Sensitivitätskennzeichnungen | RAG-Pipeline ignoriert vorhandene MIP- oder Datenklassifizierungskennzeichnungen auf indizierten Dokumenten; Retrieval basiert auf semantischer Relevanz, unabhängig von der Klassifizierung | Security-Team fragt: Was verhindert, dass die KI ein als „Eingeschränkt“ oder „Vertraulich“ markiertes Dokument für einen Anwender ohne entsprechende Berechtigung abruft? Das KI-Team hat keine technische Kontrolle zum Nachweis. | MIP-Label-Prüfung in der Retrieval-Schicht; Dokumente oberhalb der Berechtigungsstufe des Anwenders werden vor dem Eintritt in den KI-Kontext abgelehnt; Ablehnung wird mit Richtlinienbegründung protokolliert |
| Keine Kontrolle über Datenresidenz oder -souveränität | RAG-Pipeline indiziert Dokumente aus Repositorys in verschiedenen Jurisdiktionen; Retrieval und Verarbeitung können außerhalb der gesetzlich vorgeschriebenen Datenresidenz stattfinden | Security- oder Legal-Team fragt: Wo werden diese Daten verarbeitet und erfüllt das unsere DSGVO/Sovereign-Cloud-Anforderungen für EU/UK-Daten? Das KI-Team kann ohne Infrastruktur-Dokumentation keine Antwort geben. | Datenresidenz-Kontrollen, die festlegen, wo Retrieval, Verarbeitung und Speicherung erfolgen; Mandantenisolation, die sicherstellt, dass Daten aus verschiedenen Jurisdiktionen nicht im Retrieval vermischt werden |
| Keine Incident-Response-Integration | RAG-Pipeline hat kein dokumentiertes Verfahren zur Erkennung, Eindämmung oder Behebung von Datenzugriffs-Vorfällen; keine SIEM-Integration; keine Anomalieerkennung für Retrieval-Volumen oder -Muster | Security-Team fragt: Wenn die KI-Pipeline für Massendatenextraktion genutzt wird, wie würden Sie das erkennen? Was ist das Reaktionsverfahren? Das KI-Team hat keine dokumentierte Antwort. | Echtzeit-SIEM-Integration mit Retrieval-Aktivität; pro-Anwender-Baselines für Retrieval-Volumen und Anomalie-Alerts; dokumentierte KI-spezifische Incident-Response-Prozesse, integriert in das übergeordnete IR-Programm |
Was Security-Teams wirklich verlangen
Die Übersetzung von Anforderungen aus der Sicherheitsüberprüfung in architektonische Spezifikationen ist ein wiederkehrender Reibungspunkt zwischen KI-Teams und Security-Funktionen. Die Fragen der Security sind nicht willkürlich. Sie entsprechen direkt den Sicherheitskontrollen, die in allen privilegierten Datenzugriffssystemen von Unternehmenssicherheitsprogrammen angewendet werden – abgeleitet aus denselben Framework-Anforderungen, die auch für EHR-Zugriff, Finanzsysteme und regulierte File-Transfer-Infrastrukturen gelten. Wer versteht, was die Fragen wirklich verlangen, kann die erforderliche Architektur ableiten.
Wenn Security fragt „Was verhindert, dass ein Anwender auf Daten außerhalb seiner Berechtigung zugreift“…
…dann verlangen sie einen Nachweis, dass das Retrieval-System die Zugriffskontrollrichtlinien des Unternehmens pro Anfrage und nicht pro Session durchsetzt. Die gesuchte Antwort ist: „Retrieval ist auf das RBAC- und ABAC-Profil des authentifizierten Anwenders zum Zeitpunkt jeder Abfrage beschränkt; Dokumente außerhalb dieses Bereichs werden vor dem Eintritt in den KI-Kontext ausgeschlossen.“ Die nicht gesuchte Antwort ist: „Das KI-Modell wird angewiesen, keine Dokumente zu referenzieren, die der Anwender nicht sehen darf.“
Wenn Security fragt „Wer ist für jeden Datenzugriff verantwortlich“…
…dann verlangen sie eine individuelle Anwenderzuordnung im Audit-Log, nicht eine Servicekonto-Identität. Die gesuchte Antwort ist: „OAuth 2.0 mit anwenderdelegierter Autorisierung erhält die Identität des authentifizierten Anwenders bis zur Retrieval-Schicht; jeder Log-Eintrag enthält sowohl die KI-System- als auch die individuelle Anwenderidentität.“ Die nicht gesuchte Antwort ist: „Die KI-Plattform loggt die Session und wir können das mit der Anwenderaktivität korrelieren.“
Wenn Security fragt „Wie würden Sie Massendatenextraktion erkennen“…
…dann verlangen sie eine Monitoring-Architektur, keine theoretische Beschreibung von Anomalien. Die gesuchte Antwort ist: „Retrieval-Aktivität wird in Echtzeit an SIEM übermittelt; pro Anwender werden Baselines für Retrieval-Volumen gebildet; Abweichungen über Schwellenwert lösen automatisierte Alerts aus.“ Die nicht gesuchte Antwort ist: „Wenn das jemand machen würde, würden wir es wahrscheinlich in den Logs sehen.“
Wenn Security fragt „Was passiert, wenn dieses System kompromittiert wird“…
…dann verlangen sie dokumentierte Incident-Response-Prozesse speziell für die KI-Pipeline, nicht nur einen Verweis auf die allgemeine IR-Policy. Die gesuchte Antwort ist: „Der IR-Plan hat einen KI-spezifischen Anhang mit Erkennungsindikatoren, Eindämmungsmaßnahmen für die Retrieval-Komponente, forensischen Sicherungsmaßnahmen und dem Benachrichtigungsworkflow bei PHI oder personenbezogenen Daten.“
Security-Review-Readiness: Zehn Anforderungen und was jeweils nötig ist
Die folgende Checkliste ordnet die zehn häufigsten Anforderungen aus Sicherheitsüberprüfungen für RAG-Implementierungen den jeweils nötigen architektonischen Fähigkeiten zu. KI-Teams sollten diese Liste vor der Einreichung zur Sicherheitsüberprüfung durchgehen – jede Anforderung, bei der die Antwort „noch nicht“ lautet, verzögert die Freigabe.
| Anforderung aus der Sicherheitsüberprüfung | Kategorie | Was zur Erfüllung erforderlich ist |
|---|---|---|
| Können Sie nachweisen, dass Retrieval auf das beschränkt ist, wozu der anfragende Anwender berechtigt ist, nicht auf den gesamten Korpus? | Authentifizierung / Zugriff | Erfordert pro-Anfrage-RBAC/ABAC-Durchsetzung in der Retrieval-Schicht mit protokollierten Autorisierungsentscheidungen; reines Relevanz-Retrieval ohne Anwender-Scoping erfüllt diese Anforderung nicht |
| Können Sie zeigen, dass keine geteilten Servicekonten oder statischen API-Keys für den KI-Datenzugriff verwendet werden? | Authentifizierung | Erfordert OAuth 2.0 mit anwenderdelegierter Autorisierung; individuelle Anwenderidentität muss bis zur Retrieval-Schicht erhalten bleiben und in jedem Audit-Log-Eintrag erscheinen |
| Können Sie einen Beispiel-Log-Eintrag zeigen, der den individuellen Anwender, das spezifisch abgerufene Dokument, die Autorisierungsentscheidung und den Zeitstempel für ein RAG-Retrieval-Ereignis enthält? | Audit / Logging | Erfordert pro-Dokument-Retrieval-Logging auf der Datenebene; Session- oder Applikationslogs erfüllen diese Anforderung nicht; der Beispiel-Log-Eintrag ist die häufigste Evidenzanforderung in der Sicherheitsüberprüfung |
| Können Sie nachweisen, dass MIP-Sensitivitätskennzeichnungen auf indizierten Dokumenten zum Retrieval-Zeitpunkt ausgewertet werden? | Datenklassifizierung | Erfordert MIP-Label-Integration in der Retrieval-Schicht; Dokumente oberhalb der Anwenderberechtigung müssen vor Eintritt in den KI-Kontext abgelehnt werden; Ablehnung muss mit Richtlinienbegründung protokolliert werden |
| Können Sie nachweisen, dass KI-Datenzugriffsereignisse in Echtzeit an SIEM übermittelt werden? | Monitoring / Erkennung | Erfordert Echtzeit-SIEM-Integration in der Retrieval-Schicht; periodische Log-Exporte erfüllen die Anforderungen an kontinuierliches Monitoring für FedRAMP, SOC 2 oder Unternehmensrichtlinien nicht |
| Können Sie die aktiven Anomalieerkennungsregeln für KI-Retrieval-Aktivitäten beschreiben und einen Beispiel-Alert zeigen? | Monitoring / Erkennung | Erfordert dokumentierte Baseline-Regeln für Retrieval-Volumen und Abfragemuster sowie mindestens einen Beispiel-Alert, der zeigt, dass das Monitoring tatsächlich aktiv ist |
| Können Sie nachweisen, dass Retrieval und Verarbeitung von Daten mit Residenzanforderungen innerhalb der erforderlichen Jurisdiktion erfolgen? | Datenresidenz | Erfordert Infrastrukturdokumentation zu Retrieval-, Verarbeitungs- und Speicherorten; für DSGVO-relevante Daten muss EU/UK-Residenz oder ein rechtmäßiger Transfermechanismus nachgewiesen werden |
| Gibt es einen dokumentierten Incident-Response-Prozess speziell für KI-Datenzugriffsereignisse? | Incident Response | Erfordert einen KI-spezifischen Anhang zum bestehenden IR-Plan, der Erkennungsindikatoren, Eindämmungsmaßnahmen und forensische Sicherungsschritte für RAG-Pipeline-Vorfälle abdeckt |
| Können Sie nachweisen, dass die auf KI-Datenzugriff angewendeten Zugriffskontrollen denjenigen für menschlichen Zugriff auf dieselben Daten entsprechen? | Access-Control-Gleichwertigkeit | Erfordert, dass die RBAC/ABAC-Richtlinien für menschlichen Zugriff auf das Repository auch für KI-Retrieval gelten; separate, schwächere KI-Zugriffskontrollen bestehen diesen Test nicht |
| Können Sie zeigen, dass das KI-System keine Daten abrufen oder verarbeiten kann, auf die der steuernde Anwender über keinen anderen Kanal zugreifen dürfte? | Autorisierungsumfang | Erfordert Pre-Retrieval-Authorization-Scoping, nicht Post-Retrieval-Filtering; der Test ist, ob unautorisierte Daten überhaupt in den KI-Kontext gelangen, nicht ob sie aus der Antwort entfernt werden |
Architektur, die besteht: Die Governance-Schicht vor der Sicherheitsüberprüfung bauen
Der effektivste Weg, eine RAG-Sicherheitsüberprüfung zu bestehen, ist, eine Vorab-Version davon durchzuführen. Bevor die Retrieval-Architektur finalisiert wird, sollte das KI-Team die zehn Anforderungen oben durchgehen und identifizieren, welche davon architektonische Entscheidungen erfordern und nicht nur Konfiguration.
Dies sind die Entscheidungen, deren nachträgliche Änderung teuer ist. Die, die später einfach ergänzt werden können – Dokumentation, Policy-Updates, IR-Plan-Anhänge – können warten. Die, die einen Umbau des Authentifizierungsmodells, der Retrieval-Autorisierung oder die Ablösung von Servicekonten erfordern, sind nicht günstig nachzurüsten.
Die Entscheidung über die Authentifizierungsarchitektur ist die folgenreichste und am wenigsten reversible. Die Wahl von OAuth 2.0 mit anwenderdelegierter Autorisierung statt eines Servicekontos als Retrieval-Authentifizierungsmechanismus bestimmt, ob die individuelle Anwenderzuordnung in jedem Log-Eintrag, jedem Audit-Trail und jeder Benachrichtigung im Falle eines Datenschutzverstoßes verfügbar ist.
Diese Entscheidung ist architektonisch einfach vor dem Bau zu treffen; sie nachträglich in eine bestehende Pipeline zu integrieren, deren Session-Management auf Servicekonten basiert, ist teuer.
Die Entscheidung über die Retrieval-Autorisierungsarchitektur ist die zweitwichtigste. Pre-Retrieval-Authorization-Scoping – also die Durchsetzung von RBAC- und ABAC-Beschränkungen vor dem Retrieval, nicht als nachgelagerten Filter – erfordert, dass das Retrieval-System das Autorisierungsprofil des anfragenden Anwenders kennt.
Dies ist in Standard-RAG-Framework-Konfigurationen nicht vorgesehen; es erfordert eine gesteuerte Retrieval-Schicht zwischen Anwenderabfrage und Vektorsuche. Wird diese Schicht von Anfang an gebaut, ist es einfach; sie nachträglich in eine Pipeline zu integrieren, in der die Vektorsuche direkt auf den gesamten Korpus zugreift, bedeutet, die Retrieval-Komponente neu zu bauen.
Die Entscheidung über die Logging-Architektur ergibt sich aus der Retrieval-Autorisierung. Pro-Dokument-Retrieval-Logging erfordert, dass die Retrieval-Schicht für jedes zurückgegebene Dokument ein Log-Ereignis mit Dokumenten-ID, Anwenderidentität, Autorisierungsentscheidung und Sensitivitätsklassifizierung erzeugt.
Dieses Log-Ereignis muss in der Retrieval-Schicht erzeugt werden, nicht aus Applikationslogs rekonstruiert werden. Wenn die Retrieval-Schicht dies nicht von Haus aus erzeugt, erfordert die nachträgliche Ergänzung eine Instrumentierung der Retrieval-Komponente – was einfacher ist, wenn die Komponente für Governance gebaut wurde, als wenn sie eine Framework-Standard-Vektorsuche ist.
Die Governance-Schicht: Warum das AI Data Gateway das Problem der Sicherheitsüberprüfung löst
Die architektonische Erkenntnis, die die RAG-Sicherheitsüberprüfung vereinfacht, ist, dass alle sechs Fehlerquellen durch eine einzige Governance-Schicht gelöst werden können, die zwischen der Retrieval-Anfrage der RAG-Pipeline und den indizierten Datenquellen sitzt.
Diese Governance-Schicht übernimmt Authentifizierung (OAuth 2.0 mit PKCE), per-Anfrage-Autorisierung (RBAC und ABAC auf Basis des Anwenderprofils), Durchsetzung von Sensitivitätskennzeichnungen (MIP-Label-Prüfung beim Retrieval), pro-Dokument-Logging (jeder Retrieval-Vorgang wird mit voller Attribution protokolliert) und SIEM-Integration (Echtzeit-Weiterleitung).
Die RAG-Pipeline selbst – Vektorindizierung, Embedding, Kontextzusammenstellung, Modell – bleibt unverändert. Die Governance-Schicht ist keine Einschränkung für die Retrieval-Qualität; sie ist ein Wrapper um den Retrieval-Vorgang, der konformen Zugriff statt unkontrolliertem Zugriff ermöglicht.
Das ist das AI Data Gateway-Prinzip. Anstatt Governance-Fähigkeiten direkt ins RAG-Framework zu bauen – was Eigenentwicklungen gegen Frameworks erfordert, die dafür nicht ausgelegt sind – ist die Governance-Schicht eine separate Komponente, die der Retrieval-Vorgang durchläuft.
Die RAG-Pipeline fordert ein Retrieval an; die Governance-Schicht prüft die Anfrage gegen das Autorisierungsprofil des authentifizierten Anwenders, setzt Sensitivitätsrichtlinien durch, führt das Retrieval auf dem autorisierten Teil des Korpus aus, loggt das Ergebnis und gibt die abgerufenen Dokumente an die Pipeline zurück.
Aus Sicht der RAG-Pipeline erhält sie die angeforderten Dokumente. Aus Sicht des Security-Teams wurden alle Anforderungen der Sicherheitsüberprüfung erfüllt, bevor die Dokumente zurückgegeben werden.
Die Build-vs.-Buy-Abwägung für dieses Muster ist für die meisten Unternehmen eindeutig. Eine gesteuerte Retrieval-Schicht von Grund auf zu bauen, erfordert: Implementierung von OAuth 2.0 mit PKCE und Integration ins Unternehmens-Identity- und Access-Management; Bau einer per-Anfrage-Autorisierungs-Engine, die RBAC- und ABAC-Richtlinien aus dem Policy-Store auswertet; Integration der MIP-Label-Prüfung in den Retrieval-Pfad; Aufbau einer pro-Dokument-Logging-Infrastruktur mit SIEM-Weiterleitung; und den Betrieb all dessen als Produktivsystem.
Die Alternative ist der Einsatz eines speziell entwickelten AI Data Gateway, das all diese Fähigkeiten als Managed-Komponente bereitstellt – so kann sich das KI-Team auf die KI-Anwendung konzentrieren, während die Governance-Schicht die Anforderungen des Security-Teams erfüllt.
Wie Kiteworks RAG in die Produktion bringt
Die Grundannahme hinter dem Kiteworks AI Data Gateway ist, dass das Scheitern von RAG-Sicherheitsüberprüfungen ein architektonisches Problem mit einer architektonischen Lösung ist – und dass diese Lösung nicht den Neubau der RAG-Pipeline erfordert, sondern nur die Governance-Schicht, die bisher fehlte. Das AI Data Gateway stellt diese Schicht als einsatzbereite Komponente bereit, integriert in das Private Data Network von Kiteworks, und schließt jede der sechs Fehlerquellen der Sicherheitsüberprüfung ohne Eigenentwicklung.
Die Authentifizierung erfolgt über OAuth 2.0 mit PKCE und erhält die Identität des authentifizierten Mitarbeiters vom KI-Assistenten bis zur Retrieval-Schicht. Kein Servicekonto vermittelt die Zugriffskette; jeder Retrieval-Vorgang wird unter der individuellen Anwenderidentität autorisiert und jeder Audit-Log-Eintrag enthält diese Identität neben der KI-System-Identität.
RBAC- und ABAC-Autorisierung pro Anfrage wird in der Retrieval-Schicht durch die Data Policy Engine von Kiteworks durchgesetzt, die das Autorisierungsprofil des Anwenders gegen das angeforderte Dokument prüft, bevor das Dokument in den KI-Kontext gelangt. MIP-Sensitivitätskennzeichnungen werden beim Retrieval ausgewertet; Dokumente oberhalb der Berechtigungsstufe des Anwenders werden vor dem Retrieval abgelehnt, und die Ablehnung wird mit Richtlinienbegründung protokolliert.
Pro-Dokument-Retrieval-Logging erzeugt für jedes Retrieval-Ereignis einen vollständigen Audit-Log-Eintrag: Anwenderidentität, KI-System-Identität, Dokumenten-ID, Sensitivitätsklassifizierung, Autorisierungsentscheidung und Zeitstempel. Jeder Eintrag wird in Echtzeit an die SIEM-Integration von Kiteworks weitergeleitet, sodass der kontinuierliche Monitoring-Nachweis entsteht, den Security-Teams und Compliance-Frameworks verlangen.
Pro-Anwender-Baselines für Retrieval-Volumen sind standardmäßig aktiv, und Anomalie-Alerts werden bei Abweichungen generiert – so entsteht die Erkennungsfähigkeit, nach der Security-Teams fragen und die KI-Teams selten überzeugend beantworten können.
Die zero trust Data-Exchange-Architektur, die sichere Filesharing-, Managed File Transfer– und Secure Email-Prozesse im gesamten Unternehmen steuert, gilt für jeden RAG-Retrieval-Vorgang – sodass die für traditionelle Datenkanäle nachgewiesene Data-Governance-Haltung auch für die KI-Pipeline gilt.
Es gibt keine separate Sicherheitsüberprüfung für eine neue Datenzugriffsarchitektur; es gibt eine Erweiterung eines bereits genehmigten Governance-Frameworks auf ein neues Nutzungsmuster. Für KI-Teams, die RAG vom Pilotbetrieb in die Produktion bringen wollen, ist das der Unterschied zwischen einem sechsmonatigen Sicherheitsüberprüfungszyklus und einem überschaubaren Prozess.
Für VP AI/ML Engineering und CISOs, die nicht länger RAG-Projekte am Security-Gate verlieren wollen, liefert Kiteworks die Governance-Schicht, die die Lücke schließt. Wie das AI Data Gateway jede der zehn Anforderungen der Sicherheitsüberprüfung erfüllt, können Sie in einer individuellen Demo erleben.
Häufig gestellte Fragen
RAG-Frameworks sind darauf ausgelegt, Retrieval-Qualitätsprobleme zu lösen: semantische Suche, Embedding-Qualität, Kontextzusammenstellung und Antwortgenauigkeit. Sie sind nicht dafür gebaut, Governance-Probleme zu lösen: per-Anwender-Autorisierung, pro-Dokument-Audit-Logging, Durchsetzung von Sensitivitätskennzeichnungen und SIEM-Integration. Wenn ein KI-Team eine RAG-Pipeline mit Standard-Frameworks baut, die auf Retrieval-Qualität optimiert sind, entsteht ein System, das in den Retrieval-Dimensionen überzeugt und in den Governance-Dimensionen schwach ist. Security-Teams bewerten die Governance-Dimensionen, finden Defizite und blockieren die Freigabe. Das Scheitern ist vorhersehbar, weil die Frameworks Governance-Fähigkeiten nicht standardmäßig bieten und die meisten KI-Teams sie erst ergänzen, wenn Security danach fragt. Die Governance-Schicht vor der Sicherheitsüberprüfung in die Retrieval-Architektur zu integrieren, ist der einzige verlässliche Weg, diesen Zyklus zu durchbrechen.
Pre-Retrieval-Authorization-Scoping erzwingt das RBAC- und ABAC-Autorisierungsprofil des anfragenden Anwenders als Einschränkung für den Retrieval-Vorgang selbst, sodass die Vektorsuche nur Dokumente zurückgibt, auf die der Anwender berechtigt ist. Post-Retrieval-Filtering ruft zunächst alle semantisch relevanten Dokumente ab und entfernt dann diejenigen, die der Anwender nicht sehen darf. Der Sicherheitsunterschied ist grundlegend: Beim Post-Retrieval-Filtering wurden unautorisierte Dokumente bereits abgerufen und in den KI-Kontext gebracht – der unautorisierte Zugriff ist also schon erfolgt. Pre-Retrieval-Authorization-Scoping bedeutet, dass unautorisierte Dokumente gar nicht erst abgerufen werden. Security-Teams verlangen Letzteres, weil Ersteres den Datenzugriff nicht verhindert, sondern nur die Antwort filtert.
Die Sicherheitsüberprüfung für RAG-Authentifizierung verlangt drei Dinge: individuelle Anwenderidentität bis zur Retrieval-Schicht (kein geteiltes Servicekonto), kurzlebige Tokens statt statischer API-Keys (um das Zeitfenster für Credential-Exponierung zu minimieren) und Authentifizierung, die mit dem bestehenden Identity- und Access-Management-Framework des Unternehmens kompatibel ist. OAuth 2.0 mit PKCE erfüllt alle drei Anforderungen: Anwenderdelegierte Autorisierung erhält die individuelle Anwenderidentität bis zur Retrieval-Schicht; Tokens sind kurzlebig und PKCE verhindert das Abfangen von Authorization Codes; und OAuth 2.0 lässt sich mit Unternehmens-Identity-Providern integrieren. Servicekonten und statische API-Keys erfüllen die erste Anforderung nicht und werden in praktisch jeder RAG-Bewertung in regulierten Branchen als Sicherheitsbefund festgestellt.
Technisch ist es möglich, praktisch aber schwierig. Standard-RAG-Frameworks bieten keine per-Anfrage-ABAC-Autorisierung, kein pro-Dokument-Retrieval-Logging, keine MIP-Label-Integration und keine SIEM-Weiterleitung als integrierte Funktionen. Die Implementierung dieser Fähigkeiten auf Basis von Standard-Frameworks erfordert Eigenentwicklungen: eine OAuth-2.0-Integrationsschicht, eine per-Anfrage-Autorisierungs-Engine, eine Retrieval-Instrumentierung für pro-Dokument-Logging, eine MIP-Label-Integration und eine Log-Weiterleitung – jeweils als produktionsfähiges System. Unternehmen, die dies selbst bauen, entwickeln im Grunde ein AI Data Gateway von Grund auf. Der Einsatz einer speziell entwickelten Komponente ist schneller, zuverlässiger und liefert ein Evidenzpaket für die Sicherheitsüberprüfung, das direkt auf die Bewertungskriterien passt, statt dass das KI-Team dokumentieren muss, wie jede Eigenentwicklung die Anforderungen erfüllt.
Eine korrekt implementierte Governance-Schicht beeinträchtigt weder die Retrieval-Qualität noch die Antwortgenauigkeit; sie verändert lediglich den Umfang des Retrieval-Vorgangs. Pre-Retrieval-Authorization-Scoping bedeutet, dass die Vektorsuche auf dem Teil des Korpus ausgeführt wird, auf den der Anwender berechtigt ist, nicht auf dem gesamten Korpus. Für die meisten Anwender ist dies der Bereich, in dem sie erwarten, dass die KI sucht – ihre autorisierte Data-Governance-Domäne. Die Antwortgenauigkeit für ihren autorisierten Bereich bleibt unverändert. Die einzige Änderung ist, dass die KI keine Dokumente außerhalb der Berechtigungsstufe des Anwenders referenziert – was das gewünschte Verhalten ist, nicht eine Verschlechterung. Das zero trust Data-Exchange-Prinzip, jede Anfrage zu verifizieren statt breitem Zugriff zu vertrauen, gilt hier: Ein gesteuertes Retrieval, das genaue Ergebnisse im autorisierten Bereich liefert, ist ein besseres Produktivsystem als ein ungesteuertes Retrieval, das gelegentlich Ergebnisse außerhalb des autorisierten Bereichs liefert.
Weitere Ressourcen
- Blog-Beitrag
Zero‑Trust-Strategien für kostengünstigen KI-Datenschutz - Blog-Beitrag
Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blog-Beitrag
Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten - Blog-Beitrag
Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.