Was ist Retrieval-Augmented Generation (RAG) – und was bedeutet das für Ihre sensiblen Daten?

Retrieval-Augmented Generation ermöglicht es einem KI-Modell, Fragen anhand der eigenen Dokumente und Datenbanken Ihres Unternehmens zu beantworten – nicht nur mit dem, was es während des Trainings gelernt hat. Genau das macht RAG so wertvoll – und genau das macht es zu einer Data-Security-Frage, die Sie verstehen sollten, bevor Sie RAG einführen.

Im Kern ist jedes RAG-System eine Pipeline, die ein Sprachmodell mit einer Datenquelle verbindet. Enthält diese Datenquelle sensible Daten – Kundendaten, Finanzinformationen, geschützte Gesundheitsdaten (PHI) oder Controlled Unclassified Information (CUI) –, dann eröffnet das RAG-System einen neuen Zugriffspfad zu diesen Daten, mit eigenen Anforderungen an Authentifizierung, eigenen Pflichten zur Protokollierung und einer eigenen Angriffsfläche. Wie RAG funktioniert, ist schnell erklärt. Was es tatsächlich braucht, um es abzusichern, ist der Punkt, an dem die meisten Unternehmen hinterherhinken.

Executive Summary

Kernaussage: RAG verbessert die Genauigkeit von KI-Modellen, indem relevante Informationen aus externen Datenquellen abgerufen werden, bevor eine Antwort generiert wird. Für jedes Unternehmen, das RAG auf Daten mit sensiblen oder regulierten Inhalten anwendet, ist die Retrieval-Ebene ein Kontrollpunkt für den Datenzugriff – und muss mit derselben Sorgfalt gesteuert werden wie jedes andere System, das mit diesen Daten in Berührung kommt.

Warum das für Sie relevant ist: RAG-Systeme werden branchenübergreifend in regulierten Bereichen rasant eingeführt – Gesundheitsdienstleister verbinden KI mit Patientendaten, Finanzunternehmen verbinden KI mit Transaktionsdaten, Rüstungsunternehmen verbinden KI mit CUI. Keines der Compliance-Frameworks, die diese Daten regeln – HIPAA, CMMC, DSGVO –, sieht eine Ausnahme für KI vor. Wenn Ihr RAG-System sensible Daten abrufen kann, unterliegt jeder Zugriff auf diese Daten über die RAG-Pipeline denselben regulatorischen Pflichten wie jeder andere Zugriff – und die meisten Unternehmen haben keinen Einblick, ob ihre RAG-Implementierungen tatsächlich compliant sind.

Die wichtigsten Erkenntnisse

1. RAG verbindet ein Sprachmodell zum Zeitpunkt der Anfrage mit externen Daten. Statt sich ausschließlich auf das Wissen zu verlassen, das einem Modell während des Trainings einprogrammiert wurde, ruft ein RAG-System relevante Dokumente oder Daten aus einer externen Quelle ab – einer Datenbank, einem Dokumentenspeicher, einem Suchindex – und stellt diese abgerufenen Inhalte dem Modell als Kontext zur Verfügung, bevor es eine Antwort generiert. So kann das Modell Fragen anhand aktueller, unternehmensspezifischer oder proprietärer Informationen beantworten, die nicht Teil seiner Trainingsdaten waren.
2. Die Retrieval-Quelle ist die eigentliche Sicherheitsgrenze – nicht das Modell. Diskussionen über KI-Sicherheit konzentrieren sich oft auf das Modell – Prompt Injection, Jailbreaking, Modellverhalten. Bei RAG-Systemen liegt die entscheidendere Sicherheitsgrenze jedoch bei der Retrieval-Quelle: auf welche Daten das System zugreifen kann, wer oder was diese abfragen darf und was darüber entscheidet, was zurückgegeben wird. Ein Modell mit perfektem Verhalten legt trotzdem sensible Daten offen, wenn die Retrieval-Ebene keine Zugriffskontrollen hat.
3. RAG übernimmt die Compliance-Pflichten der Daten, die es abruft. Ruft ein RAG-System Daten aus einer Quelle mit PHI ab, unterliegt das System den technischen Schutzmaßnahmen von HIPAA – Zugriffskontrollen, Audit-Protokollierung, Verschlüsselung –, unabhängig davon, ob das Unternehmen es als „KI-Projekt“ oder als „Compliance-System“ betrachtet. Dieselbe Logik gilt für CUI im Rahmen von CMMC, für personenbezogene Daten unter der DSGVO und für jede andere regulierte Datenkategorie. Der Einsatz von RAG schafft keine Compliance-Ausnahme – er schafft einen neuen Zugriffspfad, der die bestehende Pflicht übernimmt.
4. Ungeprüfte Retrieval-Quellen schaffen eine reale Angriffsfläche. Greift ein RAG-System auf Quellen zu, die nicht sorgfältig geprüft wurden – externe Websites, nicht validierte Dokumente, gemischte interne Repositorys mit uneinheitlichen Zugriffskontrollen –, kann es manipuliert werden, um bösartige oder unautorisierte Inhalte abzurufen und wiederzugeben. Sicherheitsforscher bezeichnen dieses Muster als indirekte Prompt Injection durch Retrieval Poisoning. Retrieval-Quellen müssen mit derselben Sorgfalt vertrauenswürdig gemacht und zugriffskontrolliert werden wie jede andere Datenquelle, die ein Produktivsystem versorgt.
5. Die Absicherung von RAG erfordert die Steuerung der Datenebene, nicht nur der KI-Ebene. Die technischen Kontrollen, die eine RAG-Implementierung verteidigbar machen, sind dieselben Kontrollen, die jeden Zugriff auf sensible Daten regeln: authentifizierter Zugriff nach dem Least-Privilege-Prinzip auf die Retrieval-Quelle, Verschlüsselung der zugrunde liegenden Daten, ein Audit-Trail darüber, was mit welcher Anfrage abgerufen und an wen zurückgegeben wurde, sowie Output-Filterung, die verhindert, dass regulierte Datenkategorien Endnutzer erreichen, die nicht zur Einsicht berechtigt sind.

Wie RAG funktioniert

Ein RAG-System besteht im Kern aus zwei zusammenarbeitenden Komponenten: einem Retriever und einem Generator.

Wenn ein Nutzer eine Anfrage stellt, durchsucht der Retriever eine externe Wissensquelle – eine Vektordatenbank, einen Dokumentenspeicher, eine strukturierte Datenbank – nach Inhalten, die für diese Anfrage relevant sind. Er liefert die relevantesten Treffer zurück, in der Regel als Textpassagen oder Dokumentauszüge. Der Generator, ein großes Sprachmodell, erhält anschließend sowohl die ursprüngliche Anfrage als auch die abgerufenen Inhalte als Kontext und erzeugt eine Antwort, die auf diesen abgerufenen Informationen basiert – statt sich ausschließlich auf das während des Trainings gelernte Wissen zu verlassen.

Diese Architektur löst zwei Probleme, die reine Sprachmodelle für sich genommen haben. Erstens adressiert sie das Problem des Wissensstands: Ein Modell, das mit Daten bis zu einem bestimmten Datum trainiert wurde, hat keine Kenntnis von allem, was danach passiert ist – ein RAG-System kann jedoch zum Zeitpunkt der Anfrage aktuelle Informationen abrufen. Zweitens adressiert es das Problem der Halluzinationen in relevantem Umfang: Indem Antworten auf abgerufenem Quellmaterial basieren statt auf der internen (und manchmal fehlerhaften) Faktendarstellung des Modells, reduziert RAG die Häufigkeit selbstbewusst formulierter, aber sachlich falscher Ausgaben – auch wenn Halluzinationen dadurch nicht vollständig verschwinden.

RAG ist die Grundlage dafür, dass ein KI-Chatbot Fragen zu den internen Richtlinien eines Unternehmens beantworten, ein Kundensupport-System auf aktuelle Produktdokumentation verweisen oder ein Recherche-Tool Informationen aus einem bestimmten Dokumentenbestand statt aus dem offenen Internet zusammenfassen kann.

Warum RAG eine Data-Security-Frage ist – nicht nur eine Frage der KI-Architektur

Der Retrieval-Schritt ist der Moment, in dem die tatsächliche Datenexposition eines RAG-Systems entsteht. Jede an das System gestellte Anfrage führt zu einer Suche in der Retrieval-Quelle – und alles, was diese Quelle enthält, ist potenziell für jeden zugänglich, der das System abfragen kann.

Das schafft ein spezifisches und oft unterschätztes Risiko: Die Zugriffskontrollen auf die zugrunde liegende Datenquelle müssen mindestens so streng sein wie die Zugriffskontrollen auf das RAG-System selbst, denn das RAG-System ist faktisch eine neue Schnittstelle zu diesen Daten. Ein Unternehmen, das sorgfältig regelt, wer eine Datenbank mit PHI direkt abfragen darf, aber gleichzeitig ein RAG-System einsetzt, das auf dieselbe Datenbank zugreift – ohne gleichwertige Zugriffskontrollen –, hat einen neuen, schlechter kontrollierten Pfad zu denselben regulierten Daten geschaffen.

Dieses Problem verschärft sich, wenn RAG-Systeme auf mehrere, gemischte Quellen zugreifen – manche mit regulierten Daten, andere ohne, oft mit uneinheitlichen Zugriffskontrollen je Quelle. Ohne einheitliche Governance kann ein RAG-System, das für die allgemeine interne Nutzung gedacht war, versehentlich regulierte Daten für Nutzer offenlegen, die nie dazu berechtigt waren – weil die Retrieval-Ebene nicht zwischen einer öffentlichen internen Wiki-Seite und einem Dokument mit CUI unterscheidet.

Was die Absicherung einer RAG-Implementierung tatsächlich erfordert

Authentifizierter Zugriff nach dem Least-Privilege-Prinzip. Der Zugriff des RAG-Systems auf seine Retrieval-Quelle sollte auf das beschränkt sein, was der abfragende Nutzer oder Agent tatsächlich einsehen darf – nicht auf eine pauschale Verbindung, die unabhängig vom Anfragenden auf den gesamten zugrunde liegenden Datenspeicher zugreift. Attributbasierte Zugriffskontrollrichtlinien, die auf der Retrieval-Ebene angewendet werden – nicht nur auf der Anwendungsebene – machen das durchsetzbar.

Geprüfte und bereinigte Retrieval-Quellen. Retrieval-Quellen sollten auf einer Whitelist stehen, intern sein und zugriffskontrolliert werden – nicht offen für beliebige externe Inhalte, die genutzt werden könnten, um die Ausgaben des Systems durch Retrieval Poisoning zu manipulieren. Die Vermischung vertrauenswürdiger interner Dokumente mit nicht validierten externen Quellen im selben Retrieval-Index ist eine der häufigsten Ursachen für unnötige Risiken in RAG-Implementierungen.

Verschlüsselung der zugrunde liegenden Datenquelle. Alles, worauf das RAG-System zugreift – eine Vektordatenbank, ein Dokumentenspeicher, eine strukturierte Datenbank – sollte im Ruhezustand und während der Übertragung nach denselben Standards verschlüsselt sein, die für jedes andere System mit sensiblen oder regulierten Daten gelten. AES-256 mit FIPS-140-3-validierten Kryptografiemodulen ist aktuell der föderale Referenzstandard in den USA.

Output-Filterung für regulierte Datenkategorien. Selbst bei gut kontrolliertem Retrieval-Zugriff bietet eine zusätzliche Ebene der Output-Filterung – die regulierte Felder oder vertrauliche Details blockiert, bevor eine Antwort einen Endnutzer oder ein nachgelagertes System erreicht – zusätzlichen Schutz in der Tiefe gegen fehlkonfigurierte Zugriffskontrollen oder unerwartete Abfragemuster.

Ein vollständiger Audit-Trail der Retrieval-Aktivität. Jedes Retrieval-Ereignis – was abgefragt wurde, was zurückgegeben wurde, von wem und wann – sollte in einem Format protokolliert werden, das sowohl Sicherheitsüberwachung als auch Compliance-Reporting unterstützt. Für RAG-Systeme, die auf regulierte Daten zugreifen, ist dieser Audit-Trail das, was gegenüber einem Prüfer oder einer Aufsichtsbehörde belegt, dass der Zugriff angemessen begrenzt und überwacht wurde.

RAG-Compliance-Überlegungen nach regulatorischem Rahmenwerk

Ein RAG-System, das auf regulierte Daten zugreift, wird nicht nach einem anderen Maßstab bewertet als jedes andere System mit Zugriff auf diese Daten – die Anforderungen des jeweiligen Rahmenwerks gelten unmittelbar.

Gesundheitswesen (HIPAA). Ein RAG-System, das auf eine Datenquelle mit ePHI zugreift, unterliegt den technischen Schutzmaßnahmen der HIPAA Security Rule – Zugriffskontrollen, Audit-Kontrollen und Verschlüsselung –, angewendet auf die Retrieval-Pipeline selbst. Erfahren Sie, wie die 2025 vorgeschlagenen Änderungen der Security Rule KI-Systeme mit PHI-Zugriff betreffen.

Verteidigung (CMMC). Ein RAG-System, das auf eine Datenquelle mit CUI zugreift, muss dieselben Anforderungen des NIST SP 800-171 erfüllen – Zugriffskontrolle, Audit und Nachvollziehbarkeit, Schutz von Systemen und Kommunikation – wie jedes andere System, das CUI verarbeitet. Lesen Sie den CMMC-Compliance-Leitfaden von Kiteworks.

Datenschutz (DSGVO und vergleichbare Rahmenwerke). Ruft ein RAG-System personenbezogene Daten ab, gelten dieselben Anforderungen an Rechtsgrundlage, Datenminimierung und Betroffenenrechte, die für jede Verarbeitung dieser Daten gelten, auch für den Retrieval-Vorgang und die Ausgabe des RAG-Systems.

Wie Kiteworks RAG und andere KI-Datenzugriffsmuster absichert

Kiteworks setzt bei der Absicherung von RAG genau auf der Ebene an, auf der das eigentliche Risiko liegt: bei der Datenquelle, auf die das RAG-System zugreift – nicht beim Sprachmodell, das die Antworten generiert.

Das Kiteworks AI Data Gateway schafft eine kontrollierte Zugriffsebene zwischen KI-Systemen – einschließlich RAG-Pipelines – und den sensiblen Daten, auf die sie zugreifen. Jede Retrieval-Anfrage wird gegen attributbasierte Zugriffskontrollrichtlinien authentifiziert, sodass ein RAG-System ausschließlich Daten abrufen kann, die der abfragende Nutzer oder Agent tatsächlich einsehen darf. Über das Gateway abgerufene Daten werden mit FIPS-140-3-validierten Kryptografiemodulen und kundeneigenen Verschlüsselungsschlüsseln verschlüsselt, und jedes Retrieval-Ereignis wird in einem unveränderlichen, konsolidierten Audit-Trail protokolliert – demselben Audit-Trail, der sich über die Kanäle Secure E-Mail, sicheres File-Sharing und Managed File Transfer von Kiteworks erstreckt.

Für Unternehmen, die RAG-Systeme auf Basis regulierter Daten aufbauen – PHI, CUI, Finanzdaten oder andere sensible Datenkategorien – bedeutet das: Die Retrieval-Ebene übernimmt den bestehenden Compliance-Status von Kiteworks – FedRAMP-Moderate-Autorisierung, Unterstützung der Anforderungen von CMMC 2.0 Level 2 und HIPAA-konforme technische Schutzmaßnahmen –, statt eine eigenständige, speziell für den KI-Anwendungsfall entwickelte Sicherheitsarchitektur zu benötigen.

Um zu sehen, wie Kiteworks RAG und andere KI-Datenzugriffsmuster für Ihre spezifischen Compliance-Anforderungen absichert, vereinbaren Sie eine individuelle Demo.

Zurück zum Risk & Compliance Glossar