Die Rechtsabteilung weiß nichts von Ihrer RAG-Pipeline — und das ist ein Problem

Die Szene, die sich gerade quer durch Europa abspielt

Ein KI-Team eines mittelgroßen Finanzdienstleisters verbringt drei Monate damit, eine RAG-Pipeline aufzubauen. Sie indiziert interne Verträge, Richtliniendokumente und Kundenkorrespondenz. Das System funktioniert gut — die Antwortzeiten sind schnell, die Ergebnisse präzise. Das Team präsentiert es der Unternehmensführung. Die Führungsebene ist beeindruckt. Der Rollout beginnt.

Die Rechtsabteilung wurde nicht informiert.

Sechs Monate später fragt eine Aufsichtsbehörde das Unternehmen, welche KI-Systeme es betreibt, die personenbezogene Daten verarbeiten. Die Rechtsabteilung erhält eine Liste mit einem System, von dem sie noch nie gehört hat — betrieben auf Infrastruktur, die sie nie geprüft hat, und das Daten an einen Cloud-LLM-Anbieter sendet, mit dem kein Auftragsverarbeitungsvertrag besteht.

Dieses Szenario ist nicht hypothetisch. Laut der 2026er Analyse von InformationWeek zu Enterprise-KI-Deployments ist dies heute das häufigste Governance-Versagensmuster bei Enterprise-RAG-Einführungen.

Warum es immer wieder passiert

RAG-Systeme werden von Entwicklerteams gebaut, die auf Retrieval-Performance, Antwortqualität und Nutzererfahrung optimieren. Data Governance wird auf Verteidigbarkeit, Dokumentation und rechtliche Rechenschaftspflicht optimiert. Diese beiden Teams teilen selten eine gemeinsame Sprache — und fast nie einen gemeinsamen Freigabeprozess.

Das Ergebnis: KI-Systeme, die technisch funktionieren und rechtlich scheitern. Nicht weil jemand eine schlechte Entscheidung getroffen hat, sondern weil überhaupt niemand eine Entscheidung getroffen hat.

Das Problem ist struktureller Natur. RAG-Pipelines stehen an der Schnittstelle von drei Unternehmensfunktionen — IT, Informations-Governance und Recht — werden aber fast immer innerhalb einer vierten aufgebaut: dem KI-Team. Das bedeutet, dass die Personen, die für den Datenschutz verantwortlich sind, als letzte von der Existenz des Systems erfahren.

Was die Rechtsabteilung nicht weiß — aber wissen muss

Wenn ein Dokument in eine RAG-Pipeline gelangt, durchläuft es eine Reihe von Transformationen mit erheblichen rechtlichen Implikationen:

Ingestion und Chunking. Das Dokument wird in Fragmente aufgeteilt, typischerweise 200–500 Wörter. Dabei werden häufig Metadaten — wer das Dokument erstellt hat, welche Klassifizierung es trägt, ob es einem rechtlichen Haltebefehl unterliegt — entfernt oder nicht weitergegeben.

Embedding. Jeder Abschnitt wird durch ein Embedding-Modell in eine Vektordarstellung umgewandelt. Dieses Modell kann lokal laufen oder eine Cloud-API sein. Ist es eine Cloud-API, hat der Dokumenteninhalt Ihr Netzwerk bereits verlassen, bevor das eigentliche Retrieval überhaupt beginnt. Die meisten Rechtsabteilungen wissen nicht, dass dieser Schritt existiert.

Speicherung. Die Vektoren werden in einer Vektordatenbank gespeichert. Ist diese Datenbank cloud-gehostet, liegen Ihre Dokumenteninhalte — in einer rekonstruierbaren Form — auf der Infrastruktur Dritter, bis eine explizite Löschung implementiert wird.

Retrieval und Inferenz. Wenn ein Nutzer eine Frage stellt, ruft das System relevante Abschnitte ab und sendet sie an ein Sprachmodell. Ist das Sprachmodell cloud-gehostet, übertragen diese Abschnitte — die personenbezogene Daten, vertrauliche Geschäftsinformationen oder rechtlich privilegierte Inhalte enthalten können — bei jeder einzelnen Anfrage eine Drittanbieter-API.

Jeder dieser Schritte schafft Pflichten nach der DSGVO. Fast keiner davon ist für die Teams sichtbar, die diese Pflichten erfüllen müssen.

Die drei Risiken, die unerwartet auftauchen

1. Das Löschersuchen, das Sie nicht erfüllen können

Nach Artikel 17 DSGVO haben betroffene Personen das Recht auf Löschung. Wenn ein Mitarbeiter das Unternehmen verlässt, ein Kunde eine Beziehung beendet oder eine betroffene Person dieses Recht ausübt, müssen Sie deren personenbezogene Daten aus Ihren Systemen löschen können.

In einem herkömmlichen Dokumentenmanagementsystem ist das Löschen unkompliziert. In einer RAG-Pipeline nicht. Die personenbezogenen Daten existieren an mindestens drei Stellen: im Originaldokument, in den in der Vektordatenbank gespeicherten Chunks und potenziell in den Inferenzprotokollen jeder Anfrage, die diese Chunks abgerufen hat. Eine vollständige Löschung erfordert koordinierte Maßnahmen an all diesen Stellen — und die meisten RAG-Systeme haben dafür keinen Mechanismus.

Hat die Pipeline eine Cloud-Embedding-API verwendet, können die Daten auch in den eigenen Protokollen des Anbieters existieren. Ob diese Protokolle aufbewahrt werden und wie lange, hängt von Bedingungen ab, die Ihre Rechtsabteilung nie gelesen hat.

2. Der Audit-Trail, der nicht existiert

Aufsichtsbehörden erwarten zunehmend, dass Unternehmen nicht nur erklären können, welche KI-Systeme sie betreiben, sondern auch, wie eine bestimmte Ausgabe erzeugt wurde. Welche Dokumente haben eine bestimmte Antwort beeinflusst? Welche Version dieser Dokumente? War es die aktuellste verfügbare Version zum damaligen Zeitpunkt?

Standard-RAG-Architekturen speichern diese Informationen nicht. Das Retrieval findet statt, die Chunks werden an das Modell übergeben, die Antwort wird generiert — und der Kontext wird verworfen. Es gibt keine Verbindung zwischen Ausgabe, Quelle und Dokumentenverantwortlichem.

Unter dem EU AI Act — ab August 2026 vollständig durchsetzbar — müssen KI-Systeme, die bei folgenreichen Entscheidungen eingesetzt werden oder diese unterstützen, diese Art von Erklärung liefern können. „Wir wissen nicht genau, welche Dokumente diese Ausgabe beeinflusst haben" ist keine konforme Antwort.

3. Der Auftragsverarbeitungsvertrag, der nie unterzeichnet wurde

Wenn Ihre RAG-Pipeline Daten über einen Cloud-LLM-Anbieter leitet, ist dieser Anbieter nach DSGVO ein Auftragsverarbeiter. Ein Auftragsverarbeitungsvertrag ist Pflicht. Er muss festlegen, welche Daten zu welchem Zweck, unter welchen Aufbewahrungsbedingungen und mit welchen Unterauftragsverarbeitern verarbeitet werden.

Die meisten Organisationen, die Cloud-gehostete KI-APIs nutzen, haben eine Standard-Entwicklervereinbarung unterzeichnet. Das ist kein AVV. Der Unterschied ist erheblich: Ohne gültigen AVV ist die Datenübertragung rechtswidrig — unabhängig davon, ob mit den Daten tatsächlich etwas Nachteiliges passiert ist.

Der EU AI Act verstärkt dies. Betreiber — die Unternehmen, die KI-Systeme nutzen, nicht nur jene, die sie bauen — tragen jetzt Dokumentationspflichten. Wenn Ihr Anbieter keinen AVV abgeschlossen hat, liegt das regulatorische Risiko bei Ihnen, nicht bei ihm.

Das Gespräch, das geführt werden muss

Das Gespräch zwischen Ihrem KI-Team und Ihrer Rechtsabteilung sollte nicht auf einen Audit-Auslöser warten. Es sollte stattfinden, bevor ein RAG-System in Produktion geht — und eine kurze Liste konkreter Fragen umfassen:

Welche Daten verarbeitet dieses System, und enthält es personenbezogene Daten? Die meisten Enterprise-Dokumentensammlungen tun dies. Verträge enthalten Kundennamen. HR-Richtlinien enthalten Mitarbeiterinformationen. Besprechungsnotizen enthalten beides.

Wohin gehen Daten nach der Ingestion — und wer ist für jeden Schritt verantwortlich? Kartieren Sie die gesamte Pipeline: Embedding-Modell, Vektordatenbank, Retrieval-System, LLM-API. Identifizieren Sie, wer jede Komponente hostet, und welche Vereinbarungen die jeweilige Beziehung regeln.

Können wir ein Löschersuchen erfüllen? Wenn heute die personenbezogenen Daten einer Person in der Pipeline sind, beschreiben Sie die erforderlichen Schritte zur vollständigen Entfernung. Wenn Sie diese Frage nicht beantworten können, haben Sie eine Compliance-Lücke.

Wie sieht unser Audit-Trail aus? Wenn eine Aufsichtsbehörde in sechs Monaten fragt, welches Dokument eine bestimmte KI-Ausgabe beeinflusst hat — was können Sie vorweisen?

Haben wir eine DSFA durchgeführt? Nach DSGVO ist eine Datenschutz-Folgenabschätzung erforderlich, wenn die Verarbeitung „voraussichtlich ein hohes Risiko" birgt — was KI-Verarbeitung personenbezogener Daten in großem Umfang fast sicher erfüllt.

Keine dieser Fragen ist feindselig. Sie sind das Minimum, das eine Rechtsabteilung benötigt, um beurteilen zu können, ob ein System sicher betrieben werden kann.

Wie Architektur das Gespräch verändert

Der Grund, warum dieses Gespräch für die meisten Organisationen so schwierig ist: Die Antworten hängen vollständig davon ab, wohin die Daten gehen — und bei cloud-abhängigen RAG-Pipelines lautet die ehrliche Antwort oft: wir wissen es nicht genau.

Eine On-Premise-RAG-Architektur ändert dies grundlegend. Wenn Embedding-Modell, Vektordatenbank und Retrieval-Engine vollständig in Ihrer eigenen Infrastruktur laufen, werden die Antworten einfach:

• Daten verlassen das Netzwerk nicht. Es gibt keine Drittanbieter-Auftragsverarbeiter zu identifizieren.
• Löschung ist eine Datenbankoperation unter Ihrer Kontrolle.
• Der Audit-Trail befindet sich in Ihren eigenen Protokollen.
• Es gibt keine Cloud-API, mit der ein AVV abzuschließen wäre.

Das beseitigt nicht alle Pflichten — Sie sind nach wie vor für die Systemsicherung, das Zugriffsmanagement und die Verarbeitungsdokumentation verantwortlich. Aber es beseitigt die Klasse von Problemen, die entstehen, wenn man nicht weiß, was der Anbieter mit Ihren Daten macht — denn Ihr Anbieter hat Ihre Daten schlicht nicht.

Für Organisationen in regulierten Branchen — Finanzdienstleistungen, Gesundheitswesen, Recht, Pharma — ist das kein Nice-to-have. Es ist der Unterschied zwischen einem System, das in Produktion gehen kann, und einem, das es nicht kann.

Der praktische nächste Schritt

Wenn Ihre Organisation bereits ein RAG-System betreibt oder eines evaluiert, lohnt sich das Governance-Gespräch jetzt — nicht später. Die oben genannten Fragen sind ein Ausgangspunkt. Das Ziel ist nicht, KI-Projekte zu stoppen, sondern sicherzustellen, dass die für Recht und Datenschutz verantwortlichen Personen die Informationen haben, die sie für ihre Arbeit benötigen.

Wenn sie nicht wissen, dass die Pipeline existiert, können sie das nicht. Und wenn die Prüfung kommt — und im Jahr 2026 kommt sie zunehmend — wird diese Lücke zum Problem Ihrer Organisation, nicht Ihres KI-Teams.

---

KADARAGs On-Premise-Architektur hält die gesamte Dokumentenverarbeitung — Embedding, Retrieval und Inferenz — innerhalb Ihrer eigenen Infrastruktur. Die Rechtsabteilung erhält eine klare Antwort auf jede Datenschutzfrage. Demo vereinbaren und sehen Sie, wie es funktioniert.