RAG-Pipeline absichern: Datenlecks in Retrieval-Augmented Generation verhindern

RAG-Pipelines rufen automatisch interne Dokumente ab und senden sie an LLM-Provider — jeder Chunk ist ein potenzielles Datenleck. So schützen Sie, was durch Ihre Retrieval-Pipeline fließt.

Das versteckte Datenleck in jeder RAG-Pipeline

Sie haben eine RAG-Pipeline gebaut, weil Ihr KI-Feature auf echten Daten basieren soll. Ihren eigenen Daten. Interne Dokumente, Support-Tickets, Produktspezifikationen, Kundendaten — was auch immer Ihre Anwendung braucht, um nützliche, kontextbezogene Antworten zu liefern.

Und es funktioniert. Der Retrieval-Schritt zieht relevante Chunks aus Ihrer Vektordatenbank, packt sie in einen Prompt und sendet sie an OpenAI, Anthropic oder welchen Provider Sie auch nutzen. Das Modell gibt eine deutlich bessere Antwort als ohne Kontext. Alle sind zufrieden.

Nur gibt es einen Punkt, der zu wenig Beachtung bekommt: Jeder einzelne Chunk, den Ihr Retriever abruft, verlässt Ihre Infrastruktur. Automatisch. Im großen Maßstab. Ohne dass ein Mensch prüft, was in jeder Anfrage steckt.

Eine einzelne RAG-Anfrage ruft vielleicht fünf Dokument-Chunks ab. Jeder davon könnte Kundennamen, E-Mail-Adressen, interne Projektcodes, Finanzzahlen enthalten — was auch immer im Originaldokument in der Nähe der semantisch relevanten Passage stand. Ihr Retriever kümmert sich nicht um Sensitivität. Er kümmert sich um Kosinus-Ähnlichkeit.

Wenn Sie ein paar hundert Anfragen pro Tag verarbeiten, fließen täglich tausende Dokument-Chunks an eine Drittanbieter-API. Wenn eines dieser Dokumente PII enthält — und das ist fast sicher der Fall — senden Sie bei jeder Anfrage personenbezogene Daten an einen externen Provider, ob Sie das beabsichtigt haben oder nicht.

Das ist kein theoretisches Risiko. Es ist das Standardverhalten jeder RAG-Pipeline ohne expliziten Schutz.

Warum RAG Sicherheitsrisiken schafft, die reguläre LLM-Aufrufe nicht haben

Bei einer regulären LLM-Integration schreibt ein Entwickler ein Prompt-Template. Jemand kann prüfen, welche Daten in dieses Template fließen. Sie kontrollieren die Eingaben, weil Sie den Code geschrieben haben, der sie zusammenstellt.

RAG bricht dieses Modell auf fundamentale Weise: Sie kontrollieren nicht, was im Prompt landet. Das entscheidet der Retriever. Zur Laufzeit. Basierend auf dem, was der Nutzer gefragt hat und was zufällig in Ihrer Vektordatenbank steht.

Und Ihre Vektordatenbank ist ein Sammelsurium. Überlegen Sie, was tatsächlich drin ist. Wenn Sie die interne Wissensbasis Ihres Unternehmens indexiert haben, enthält sie wahrscheinlich HR-Richtlinien mit Mitarbeiternamen, Support-Tickets mit Kunden-PII, Entwicklerdokumentation mit API-Schlüsseln in Codebeispielen, Vertriebsdokumente mit Vertragsdetails von Kunden und Besprechungsnotizen mit allem von Umstrukturierungsplänen bis hin zur Privatadresse von jemandem.

Der Retriever unterscheidet nicht zwischen einer Produkt-FAQ und einem internen HR-Dokument. Er weiß nicht, dass der Chunk mit „Sarah Müllers Leistungsbeurteilung" sensibler ist als einer, der Ihren Authentifizierungsablauf beschreibt. Er findet einfach die Chunks mit der höchsten semantischen Ähnlichkeit zur Anfrage und gibt sie zurück.

Ein konkretes Szenario: Ein Nutzer fragt Ihre RAG-gestützte App: „Wie ist der Zeitplan für das Acme-Projekt?" Der Retriever durchsucht Ihre Vektordatenbank und liefert fünf Chunks zurück. Drei davon stammen aus Projektplanungsdokumenten — in Ordnung. Aber einer ist aus einem Kundenvertrag, der den Auftragswert und Zahlungsbedingungen erwähnt. Ein weiterer ist aus einem E-Mail-Thread mit der direkten Telefonnummer des Kunden und dem Namen ihres CEOs.

Alle fünf Chunks werden in den Prompt gepackt und an Ihren LLM-Provider gesendet. Der Nutzer bekommt eine hilfreiche Antwort zum Projektzeitplan. Und Sie haben gerade vertrauliche Kundenfinanzdaten und persönliche Kontaktinformationen an OpenAIs API gesendet.

Niemand hat Code geschrieben, um diese Daten einzubeziehen. Niemand hat einen Fehler gemacht. Das System hat genau wie designed funktioniert — es hat nur kein Konzept von „dieser Chunk ist zu sensibel zum Senden."

Fünf Datenleck-Vektoren in RAG

Nicht alle RAG-Datenlecks sehen gleich aus. Die spezifischen Vektoren zu verstehen hilft, sich dagegen zu schützen.

PII eingebettet in Dokumenten. Das ist der häufigste Fall. Namen, E-Mail-Adressen, Telefonnummern und manchmal Ausweisnummern stecken in Besprechungsnotizen, Support-Tickets, Kundenkorrespondenz und HR-Dokumenten. Wenn diese in Ihre Vektordatenbank indexiert werden, wird jeder PII-Wert zum Retrieval-Kandidaten. Eine Frage zu einem völlig unrelated Thema kann einen Chunk mit persönlichen Informationen zurückliefern, wenn der umgebende Text zufällig semantisch relevant ist.

Secrets in technischer Dokumentation. Codebeispiele in internen Docs enthalten oft echte API-Schlüssel, Datenbank-Verbindungsstrings und OAuth-Tokens. Entwickler kopieren aus ihren tatsächlichen Konfigurationen in die Dokumentation. Wenn diese Docs indexiert werden, liegen die Secrets in Ihrer Vektordatenbank und warten darauf, abgerufen und an einen LLM-Provider gesendet zu werden. Wir sehen das häufiger als man erwarten würde — unser Leitfaden zu PII-Erkennungs-Best-Practices behandelt, worauf man achten sollte.

Proprietäre Geschäftsdaten. Finanzprognosen, Preisstrategien, M&A-Pläne, unveröffentlichte Produkt-Roadmaps. Das ist kein PII — es wird keinen Namen- oder E-Mail-Detektor auslösen — aber es ist oft schädlicher zu leaken als einzelne PII-Datensätze. Wenn Ihre Vektordatenbank interne Strategiedokumente enthält, sind diese für den Retrieval freigegeben.

Cross-Tenant-Leakage in Multi-Tenant-RAG. Das ist der gefährlichste Fall. Wenn Sie eine RAG-Anwendung bauen, die mehrere Kunden bedient, und eine gemeinsame Vektordatenbank mit Tenant-Filterung verwenden, bedeutet ein Bug in Ihrer Filterlogik, dass die Anfrage von Nutzer A Dokumente von Nutzer B abrufen könnte. Das LLM verarbeitet die gemischten Ergebnisse bereitwillig und könnte sogar Daten des anderen Tenants in der Antwort ausgeben. Der Blast Radius eines Filter-Bugs in Multi-Tenant-RAG ist enorm.

Prompt Injection über vergiftete Dokumente. Ihre Wissensbasis ist eine Angriffsfläche. Wenn ein Angreifer ein Dokument in Ihre Vektordatenbank einschleusen kann — über ein Support-Ticket, ein geteiltes Dokument, ein Nutzerformular — kann er Prompt-Injection-Payloads einbetten, die abgerufen und vom Modell ausgeführt werden. Das macht Ihre Retrieval-Pipeline zum Injection-Vektor. Siehe unseren Leitfaden zur Prompt-Injection-Prävention für Verteidigungsstrategien.

Wie man das tatsächlich behebt

Der Instinkt ist, die Daten vor der Indexierung in die Vektordatenbank zu bereinigen. Dokumente säubern, PII entfernen, Secrets rauswerfen, dann indexieren. Und das hilft — Sie sollten unbedingt auditieren, was in Ihrer Vektordatenbank ist.

Aber Pre-Indexierungs-Bereinigung hat echte Grenzen. Dokumente ändern sich. Neue Datenquellen kommen hinzu. PII-Erkennung ist nicht perfekt, und was als sensibel gilt, hängt vom Kontext ab. Sie können nicht garantieren, dass Ihre Vektordatenbank nie sensible Daten enthält, besonders wenn Ihre Wissensbasis wächst.

Der robustere Ansatz ist, eine Erkennungsschicht zwischen Retrieval und LLM-Aufruf einzubauen. Das ist die zentrale architektonische Erkenntnis: Ihre RAG-Pipeline hat einen Engpass, durch den alle abgerufenen Daten fließen, bevor sie die externe API erreichen. Genau dort platzieren Sie Ihre Sicherheit.

Stellen Sie es sich als zwei komplementäre Strategien vor:

Bereinigen, was reingeht. Auditieren Sie Ihre Vektordatenbank. Wissen Sie, was indexiert ist. Entfernen Sie Dokumente, die nicht dort sein sollten. Klassifizieren Sie Quellen nach Sensitivität und überlegen Sie, ob alle im selben Index sein müssen. Wenn Ihre HR-Dokumente nicht von Ihrer kundenorientierten KI durchsuchbar sein müssen, indexieren Sie sie nicht.

Scannen, was rausgeht. Unabhängig davon, wie sauber Ihre Quelldaten sind: Inspizieren Sie jeden zusammengestellten Prompt, bevor er Ihre Infrastruktur verlässt. Erkennen Sie PII, Secrets und sensible Muster im tatsächlichen Inhalt, der gleich an den LLM-Provider gesendet wird. Das fängt alles ab — einschließlich Daten, von denen Sie nicht wussten, dass sie da sind, Daten, die nach Ihrer letzten Bereinigung hinzugefügt wurden, und Daten, die erst in Kombination sensibel wirken (wie ein Name neben einer Kontonummer).

Die zweite Strategie ist die, die tatsächlich skaliert, weil sie nicht von perfekter Upstream-Datenhygiene abhängt. Ihre Retrieval-Logik kann sich ändern, Ihr Dokumentenkorpus kann wachsen, neue Datenquellen können angebunden werden — und die Erkennungsschicht fängt weiterhin sensible Inhalte an dem Punkt ab, an dem sie Ihre Infrastruktur verlassen würden.

Für die konkreten Mechanismen zur Erkennung und Behandlung von PII, sobald Sie sie gefunden haben, siehe Sensible Daten in LLM-API-Aufrufen schützen — dort wird die gesamte Pipeline von Audit bis Durchsetzung behandelt.

Warum ein Proxy besser ist als RAG-Code zu modifizieren

Sie könnten PII-Erkennungslogik in Ihre RAG-Pipeline einbauen. Nach dem Retrieval, vor der Prompt-Zusammenstellung, jeden Chunk durch einen Scanner laufen lassen und sensible Inhalte herausfiltern.

Es funktioniert, technisch gesehen. Aber es ist ein Wartungsalbtraum.

Ihre Erkennungslogik ist jetzt an Ihren RAG-Code gekoppelt. Jeder Retrieval-Pfad braucht die gleichen Prüfungen. Wenn Sie mehrere RAG-Pipelines haben — verschiedene Apps, verschiedene Modelle, verschiedene Dokumentenspeicher — duplizieren Sie die Erkennungslogik überall. Wenn Sie eine neue Erkennungsregel hinzufügen, deployen Sie jeden Service. Wenn Sie ein False Positive finden, beheben Sie es in jeder Codebasis.

Ein Proxy-Ansatz umgeht all das. Sie setzen eine Erkennungsschicht auf Netzwerkebene — zwischen Ihrer Anwendung und der API des LLM-Providers. Jede Anfrage passiert sie, egal welche RAG-Pipeline sie generiert hat, welche Retrieval-Strategie verwendet wurde oder an welches Modell sie geht.

Der Proxy inspiziert den zusammengestellten Prompt — den finalen Payload, der gesendet werden soll. Er sieht das vollständige Bild: die abgerufenen Chunks, den System-Prompt, die Nutzeranfrage, alles. Die Erkennung läuft auf der gesamten Anfrage, nicht auf einzelnen Chunks isoliert. Das ist wichtig, weil manche PII-Muster erst im Kontext erkennbar werden.

Und weil es auf Netzwerkebene ist, fassen Sie Ihren RAG-Code gar nicht an. Ihre Retrieval-Logik bleibt sauber. Ihre Prompt-Zusammenstellung bleibt sauber. Sicherheit wird auf Infrastrukturebene gehandhabt.

Mit Grepture sieht die Integration so aus:

import Grepture from "@grepture/sdk";
import OpenAI from "openai";

const grepture = new Grepture({
  apiKey: process.env.GREPTURE_API_KEY,
  proxyUrl: "https://proxy.grepture.com",
});

const openai = new OpenAI({
  ...grepture.clientOptions(),
  apiKey: process.env.OPENAI_API_KEY,
});

// Ihre RAG-Pipeline ändert sich überhaupt nicht
const chunks = await vectorStore.similaritySearch(userQuery, 5);
const context = chunks.map((c) => c.pageContent).join("\n\n");

const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    { role: "system", content: `Antworte basierend auf diesem Kontext:\n\n${context}` },
    { role: "user", content: userQuery },
  ],
});

Drei Zeilen Setup. Ihre Vektordatenbank-Abfrage, Ihre Prompt-Zusammenstellung, Ihr OpenAI-Aufruf — alles unverändert. Aber jetzt fließt jede Anfrage durch Greptures Proxy, wo Erkennungsregeln auf PII, Secrets und sensible Muster scannen, bevor die Daten OpenAI erreichen.

Wenn Sie Mask-and-Restore-Regeln konfigurieren, wird erkannte PII vor dem Verlassen Ihrer Infrastruktur durch Tokens ersetzt, und die Originalwerte werden in der Antwort wiederhergestellt. Das LLM sieht nie die echten Daten. Ihre Nutzer bekommen trotzdem natürliche, personalisierte Antworten.

Derselbe Proxy deckt auch Ihre Nicht-RAG-LLM-Aufrufe ab. Chat Completions, Function Calling, Streaming — alles, was durch den OpenAI-Client geht. Ein Integrationspunkt, konsistenter Schutz über Ihren gesamten KI-Traffic.

Das ist die Architektur, die wirklich im großen Maßstab funktioniert: RAG-Logik auf Retrieval-Qualität fokussiert halten und Sicherheit auf der Netzwerkebene durchsetzen, wo man sie einheitlich erzwingen kann. Ihre Vektordatenbank wird weiter wachsen, Ihre Retrieval-Strategien werden sich weiterentwickeln, und der Proxy fängt weiterhin sensible Daten ab — egal was sich Upstream ändert.