RAG im Produktionseinsatz: Die Governance-Checkliste für Sicherheitsteams vor dem Go-Live

Die Lücke zwischen einem RAG-Pilotprojekt und einem produktiven Einsatz ist keine technische — sondern eine Governance-Lücke. Pilotprojekte dienen dem Nachweis der KI-Fähigkeit und nehmen daher Abkürzungen: weitreichende Service-Account-Berechtigungen, minimale Protokollierung, keine Richtliniendurchsetzung.

Genau diese Abkürzungen markieren Sicherheitsteams, sobald eine Produktionsfreigabe geprüft wird. Die meisten KI-Daten-Governance-Frameworks wurden nicht für KI-Retrieval-Pipelines entwickelt. Unternehmen, die RAG in den Produktivbetrieb bringen, navigieren daher Anforderungen, die nie für sie gedacht waren.

Dieser Beitrag bietet beiden Seiten — Sicherheitsteams und KI-Engineering-Teams — einen gemeinsamen Rahmen: die fünf Governance-Anforderungen, die RAG erfüllen muss, bevor es für den Produktivbetrieb freigegeben werden kann.

Executive Summary

Kernaussage: RAG-Pilotprojekte umgehen regelmäßig Zugriffskontrollen, Prüfprotokolle und Compliance-Pflichten, die im Produktivbetrieb zwingend sind. Die Lücke ist kein Technologieproblem — sondern ein Architekturproblem.

Warum das wichtig ist: Unternehmen, die Governance überspringen, um KI schneller einzuführen, schaffen Compliance-Risiken, die Aufsichtsbehörden früher oder später entdecken — und Sicherheitsvorfälle, die direkt auf unkontrollierten KI-Datenzugriff zurückzuführen sind. Die schnellsten Unternehmen sind diejenigen, die Governance von Anfang an einplanen — nicht die, die sie erst nach einer gescheiterten Sicherheitsprüfung nachrüsten.

5 Wichtige Erkenntnisse

1. RAG bedeutet Datenzugriff im großen Maßstab. Die gleichen gesetzlichen Vorgaben, die den Zugriff eines Menschen auf sensible Dateien regeln, gelten auch für eine KI, die diese Datei für eine RAG-Anfrage abruft — HIPAA, DSGVO und SOX machen keine Ausnahmen für KI, und die Aufsichtsbehörden machen das deutlich.
2. Die meisten RAG-Pilotprojekte gewähren dem KI-System weitreichenden Repository-Zugriff über überprivilegierte Service-Accounts. Im Produktivbetrieb ist eine Autorisierung pro Anfrage erforderlich — durch RBAC- und ABAC-Engines, die das Prinzip der minimalen Rechte auf der Retrieval-Ebene durchsetzen, nicht nur beim Verbindungsaufbau.
3. Ohne einen vollständigen Audit-Trail, der jede KI-Datenabfrage einem bestimmten Anwender, KI-System und Zeitstempel zuordnet, können Unternehmen nicht nachweisen, auf welche Daten ihre KI zugegriffen hat — eine Lücke, die die Dokumentationsanforderungen von HIPAA, DSGVO, SOX und FedRAMP nicht erfüllt.
4. Zero-trust-Architektur muss auch für KI-Systeme gelten. Eine KI-Pipeline ist kein vertrauenswürdiger Anwender. Jede Datenanfrage muss unabhängig authentifiziert und autorisiert werden, und Authentifizierungsdaten dürfen dem KI-Modell selbst niemals zugänglich sein.
5. Eine gesteuerte Datenschicht zwischen KI-System und Datenrepository ist das Architekturmodell, das die Lücke zwischen Pilot und Produktion schließt — sie erzwingt Zugriffskontrolle, erzeugt Audit-Trails und bewertet Compliance-Richtlinien, ohne eine separate KI-spezifische Governance-Infrastruktur zu benötigen.

Warum RAG-Pilotprojekte Sie nicht auf den Produktivbetrieb vorbereiten

RAG-Pilotprojekte beantworten nur eine Frage: Kann KI nützliche Antworten liefern, die auf unseren internen Daten basieren? Governance wird bewusst aufgeschoben, weil sie den Proof of Concept verlangsamt. Das Ergebnis ist eine Prototyp-Architektur, die eigentlich nie produktiv gehen sollte — es aber oft doch tut: mit einem Service-Account, der alles kann, ohne personenbezogene Zuordnung in den Logs und komplett ignorierten Datenklassifizierungen.

Sicherheitsteams blockieren RAG nicht, wenn sie solche Architekturen hinterfragen. Sie stellen die gleichen Fragen wie bei jedem System, das mit sensiblen Daten arbeitet: Wer kann auf was zugreifen? Wie wissen wir, worauf zugegriffen wurde? Wie weisen wir gegenüber Prüfern nach, dass der Zugriff gesteuert war? Das Problem: Die meisten RAG-Architekturen haben darauf keine Antworten. Die KI-Datenschutzkontrollen, die Unternehmensumgebungen verlangen, waren im Pilotdesign schlicht nicht vorgesehen.

Die folgende Checkliste bietet beiden Seiten konkrete Anforderungen — und eine gemeinsame Sprache, wie gesteuertes RAG tatsächlich aussieht.

Die Governance-Lücke: Was produktives RAG wirklich erfordert

Produktives RAG muss fünf Governance-Domänen erfüllen, bevor es eine Sicherheitsfreigabe erhält. Das sind keine idealistischen Best Practices — sondern Mindestanforderungen, die bestehende Daten-Compliance-Frameworks, zero trust-Prinzipien und die Praxis des KI-Betriebs im Unternehmensmaßstab vorgeben.

1. Zugriffskontrolle: Sieht die KI nur, was der Anwender sehen darf?

Die häufigste Governance-Schwachstelle bei RAG-Einführungen ist übermäßiger Datenzugriff. Eine RAG-Pipeline, die sich über einen privilegierten Service-Account mit einem Dokumentenrepository verbindet, kann alles abrufen, was dieser Account erreichen kann — unabhängig davon, ob der Anwender, der die Anfrage gestellt hat, dazu berechtigt ist. Das ist kein theoretisches Risiko, sondern Standard bei den meisten RAG-Piloten.

Im Produktivbetrieb muss das KI-System die Berechtigungen des Anwenders übernehmen, in dessen Auftrag es handelt — nicht mehr und nicht weniger. Das bedeutet: RBAC- und ABAC-Richtlinien werden auf der Retrieval-Ebene für jede Anfrage geprüft, nicht nur beim Verbindungsaufbau. Ein Mitarbeiter in einer Niederlassung darf nicht durch eine natürliche Sprachabfrage auf Vorstandsgehälter zugreifen. Eine KI-Pipeline darf keinen Zugriff über die bestehenden Zugriffskontrollen hinaus ermöglichen.

Zu überprüfen: Das KI-System kann keine Daten abrufen, für die der authentifizierte Anwender nicht explizit autorisiert ist, und die Autorisierung erfolgt pro Anfrage.

2. Audit-Trail: Können Sie nachweisen, worauf die KI zugegriffen hat?

Eine RAG-Pipeline im Produktivbetrieb erzeugt täglich tausende Datenabrufereignisse über viele Anwender hinweg. Jeder Abruf ist ein Datenzugriffsereignis. Jedes Ereignis muss zugeordnet werden. Ohne diese Attribution können Unternehmen die Fragen der Compliance-Frameworks nicht beantworten: Auf welche sensiblen Daten hat die KI zugegriffen, im Auftrag von wem, wann und was wurde damit gemacht?

Das Mindestmaß für ein Audit-Log im produktiven RAG-Betrieb erfasst die Identität des KI-Systems, des authentifizierten Anwenders, die abgerufenen Daten, den Zeitstempel und die Aktion. Diese Ereignisse müssen in Echtzeit an ein SIEM übermittelt werden — nicht gesammelt, nicht verzögert, nicht gedrosselt. Ein Sicherheitsteam, das erst drei Tage nach einem unautorisierten KI-Zugriff davon erfährt, kann nicht wirksam reagieren.

Das praktische Problem: Die meisten Unternehmen haben zwar ein Logging-System, aber ihre RAG-Pipeline protokolliert nur „KI-System hat Repository abgefragt“ — statt der Details, die HIPAA-, DSGVO- und FedRAMP-Programme tatsächlich verlangen.

3. Compliance-Ausrichtung: Erfüllt der KI-Datenzugriff die bestehenden gesetzlichen Vorgaben?

HIPAA-, DSGVO-, SOX- und FedRAMP-Compliance machen keine Ausnahmen für KI. Wenn eine RAG-Pipeline eine Patientenakte für eine klinische Entscheidung abruft, ist das ein HIPAA-Zugriffsereignis. Holt sie Finanzdaten für eine Analyse, gelten die SOX-Aufbewahrungspflichten. Aufsichtsbehörden machen klar: Bestehende Datenschutzrahmen gelten auch für KI-Datenzugriffe — Unternehmen, die auf KI-spezifische Regulierung warten, bevor sie Governance umsetzen, sind bereits im Rückstand.

Zwei typische Compliance-Lücken in RAG-Architekturen: Erstens das Umgehen von Sensitivitätslabels: RAG-Pipelines rufen oft Daten ab, ohne Datenklassifizierung oder Microsoft Information Protection (MIP)-Labels zu prüfen — so kann die KI vertrauliche oder eingeschränkte Daten anzeigen, die eigentlich geschützt sein sollten. Zweitens die Dokumentationslücke: Compliance-Frameworks verlangen den Nachweis, dass der Zugriff gesteuert wurde, nicht nur dass er stattfand. Ein Log-Eintrag „KI hat Dokumente abgerufen“ ist kein Governance-Nachweis.

Zu überprüfen: Sensitivitätslabels werden vor der Datenrückgabe geprüft und der Audit-Trail erzeugt das Dokumentationsformat, das für HIPAA-Compliance, DSGVO-Compliance und SOC 2-Prüfungen erforderlich ist.

4. Zero-Trust-Architektur: Wird Ihr KI-System als vertrauenswürdiger Akteur behandelt?

Traditionelle Integrationsmuster behandeln ein KI-System nach der Verbindung als vertrauenswürdigen Dienst — kann die Pipeline das Repository erreichen, gilt der Zugriff als autorisiert. Zero-trust-Datenaustausch lehnt diese Annahme ab. Ein KI-System ist kein vertrauenswürdiger Anwender. Es muss für jede Anfrage unabhängig die Autorisierung nachweisen, egal was es bei der vorherigen Anfrage durfte.

Zwei zero trust-Anforderungen sind bei RAG-Architekturen besonders wichtig. Erstens Credential-Sicherheit: Authentifizierungstokens dürfen dem KI-Modell niemals zugänglich sein. Eine RAG-Pipeline, die Zugangsdaten in Konfigurationsdateien speichert oder Tokens durch KI-Kontext schleust, ist anfällig für Prompt-Injection-Angriffe, die diese Credentials extrahieren und für weitreichenden Datenzugriff missbrauchen können. Tokens müssen im sicheren Credential Store des Betriebssystems liegen — nicht über KI-Prompts erreichbar. Zweitens: Assume-Compromise-Architektur — das System muss davon ausgehen, dass die KI-Pipeline irgendwann kompromittiert wird. Rate Limiting, Pfadvalidierung und Richtliniendurchsetzung auf der Retrieval-Ebene sind keine optionalen Härtungsmaßnahmen, sondern die Kontrollen, die KI-Risiken begrenzen, wenn etwas schiefgeht.

5. Daten-Exfiltrationskontrollen: Kann Ihre RAG-Pipeline zum Extraktionsvektor werden?

Eine RAG-Pipeline mit weitreichendem Datenzugriff und ohne Rate Limiting ist ein Massenauslese-Tool, das nur auf einen Angreifer wartet. Wer das KI-System kompromittiert — oder als Anwender erkennt, dass es keine Abfragelimits gibt — kann deutlich mehr Daten abrufen, als es bei Einzelzugriffen möglich wäre. Das ist kein neuer Angriffsvektor; es ist das gleiche Massenauslese-Risiko, das DLP-Programme für menschliche Anwender adressieren, jetzt aber für eine KI, die tausende Anfragen pro Sekunde ausführen kann.

Im Produktivbetrieb braucht RAG Rate Limiting für KI-Datenanfragen, Pfadüberprüfung zur Blockade von Systemdateien oder Verzeichnissen außerhalb des vorgesehenen Bereichs und standardmäßig absolute Pfadbeschränkungen. Außerdem ist eine Verhaltensbasislinie erforderlich: Wie sieht normales RAG-Abfrageverhalten für diese Anwendergruppe aus und welche Abweichung davon sollte eine Sicherheitswarnung auslösen? Ohne diese Basislinie bleibt anomale Extraktion unsichtbar, bis die Daten das Unternehmen bereits verlassen haben.

Pilot vs. Produktion: Die Governance-Lücke im Überblick

Wie Kiteworks gesteuertes RAG ermöglicht — und KI-Operationalisierung realisierbar macht

Die in dieser Checkliste beschriebenen Governance-Anforderungen sind keine Hürden für KI-Einführung. Sie sind die Voraussetzung für nachhaltige produktive KI. Unternehmen, die Governance als Voraussetzung betrachten — statt als nachträglichen Zusatz — erreichen den Produktivbetrieb schneller als jene, die unkontrollierte Piloten starten und dann an der Sicherheitsprüfung scheitern. Das Architekturmodell, das dies ermöglicht, ist eine gesteuerte Datenschicht zwischen KI-System und Datenrepository: Sie erzwingt Zugriffskontrolle, erzeugt Audit-Trails, bewertet Compliance-Richtlinien und setzt zero trust-Prinzipien um — ohne separate KI-spezifische Governance-Infrastruktur.

Das AI Data Gateway ist die speziell entwickelte Umsetzung dieses Modells von Kiteworks. Es bietet zero trust KI-Datenzugriff — jede Anfrage aus einer RAG-Pipeline oder einem KI-Assistenten wird authentifiziert, anhand von RBAC- und ABAC-Richtlinien autorisiert und protokolliert, bevor Daten zurückgegeben werden. Es unterstützt konformes RAG, indem Sensitivitätsklassifizierungen und MIP-Labels auf der Retrieval-Ebene geprüft werden und der Audit-Trail mit Attribution erzeugt wird, wie es HIPAA-Compliance, DSGVO-Compliance, SOX und FedRAMP-Compliance verlangen. Das Echtzeit-Tracking der Zugriffe wird sofort an das SIEM übermittelt — ohne Batch-Verarbeitung, ohne Drosselung, ohne Lücken. Und da es auf REST-APIs und dem Model Context Protocol (MCP) basiert, lässt es sich mit jeder RAG-Implementierung und jeder KI-Plattform ohne Vendor-Lock-in integrieren.

Entscheidend: Das AI Data Gateway erweitert die bestehende Governance eines Unternehmens — dieselben Daten-Governance-Richtlinien, dieselben Audit-Logs, dasselbe Private Data Network — auf jede KI-Interaktion. Es ist keine parallele Governance-Infrastruktur zu bauen und zu pflegen. Sicherheitsteams erhalten Transparenz über KI-Datenzugriffe in den Dashboards, die sie bereits nutzen. Compliance-Beauftragte bekommen KI-Operationen in die bestehenden regulatorischen Berichte integriert. Und KI-Engineering-Teams erhalten den gesteuerten Datenzugriff, den sie brauchen, um vom Pilot zur Produktion zu gelangen — ohne Sicherheitsprüfungs-Stillstand.

Für Unternehmen, die bereit sind, von KI-Experimenten zur KI-Operationalisierung überzugehen, ist die obige Checkliste der Startpunkt. Kiteworks macht es möglich, jede Anforderung abzuhaken. Erfahren Sie mehr — vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Die Zeit der KI-Policy-Absichtserklärungen ist vorbei — jetzt wollen Aufsichtsbehörden Beweise