Der häufigste RAG-Fehler innerhalb von Unternehmen ist einfach: Alles hochladen, Fragen stellen und Quellenzitierungen als automatisch sicher behandeln.
Der zweithäufigste Fehler tritt später auf: Jemand erkennt, dass der Assistent Antworten aus Dokumenten geben kann, die der Benutzer niemals sehen sollte. Gehälter. Kundendatenverträge. Rechtsentwürfe. Vorstandsnachrichten. Support-Tickets. Personaluntersuchungen. Sicherheitsverfahren. Die Antwort kann korrekt und zitiert sein, aber das System hat Informationen geleckt.
Ein RAG-System für Unternehmenswissen ist kein Suchfeld mit besserer Prosa, sondern ein berechtigungsgesteuertes Informationssystem. Behandeln Sie es entsprechend.
Das Retrieval muss dieselben oder strengere Berechtigungen wie die Quellsysteme durchsetzen. Kann ein Benutzer eine Datei in Google Drive, SharePoint, Notion, Confluence oder dem CRM nicht öffnen, darf das RAG-System sie für diesen Benutzer nicht abrufen.
Die Kernregel
Die Retrieval-Schicht muss diese Frage beantworten, bevor sie einen Chunk zurückgibt:
Ist dieser Benutzer berechtigt, diese Quelle jetzt zu sehen?
Nicht „Ist diese Quelle in der Vektordatenbank?“ Nicht „Ist diese Quelle relevant?“ Nicht „Ist diese Quelle nützlich?“ Berechtigung kommt zuerst.
Es gibt drei gängige Muster:
| Muster | Wie es funktioniert | Anwendungsbereich |
|---|---|---|
| Separate Indizes | Ein Index pro Zielgruppe oder Arbeitsbereich | Einfache Teams, grobe Berechtigungen |
| Metadatenfilterung | ACL-, Gruppen- und Quellenmetadaten speichern und vor dem Retrieval filtern | Die meisten RAG-Systeme im Unternehmen |
| Echtzeit-Berechtigungsprüfung | Abfrage der Quellsystemberechtigungen zur Retrieval-Zeit | Sensible oder häufig veränderliche Berechtigungen |
Die richtige Antwort hängt von den Quellsystemen und dem Risikograd ab. Für die meisten KMUs reichen separate Indizes plus Metadaten-Filterung aus. Für Kundendaten, Personalwesen, Rechtsfragen oder regulierte Daten können Echtzeit-Prüfungen erforderlich sein.
Die schwierige Stelle: ACLs synchronisieren
Jedes der oben genannten Muster hängt still und leise von einem einzigen Faktor ab: Die Berechtigungsdaten in Ihrem Index müssen mit den Berechtigungsdaten im Quellsystem übereinstimmen. Diese Synchronisation ist der eigentliche Ingenieursaufwand.
Wo die ACLs herkommen. SharePoint und OneDrive geben über die Microsoft Graph API pro Element-Berechtigungen weiter; Google Drive über die per-Datei-Berechtigungslisten der Drive API; Confluence über Raum- und Seitenbeschränkungen. Jedes hat unterschiedliche Formate (Benutzer, Gruppen, Vererbung, Freigabeverknüpfungen), unterschiedliche API-Rate-Limits und unterschiedliche Konzepte von „wer kann das sehen“.
Gruppenauflösung ist unverzichtbar. Die meisten realen Berechtigungen werden Gruppen gewährt, die wiederum verschachtelt sein können. „Sales EU“ innerhalb von „Sales“ innerhalb von „All Staff“ muss entweder bei der Synchronisation – größere Indexmetadaten, schnellere Abfragen – oder zur Abfragezeit – aktueller, langsamer, mehr API-Aufrufe – in konkrete Benutzer aufgelöst werden. Treffen Sie diese Wahl bewusst; andernfalls wird sie inkonsistent umgesetzt.
Synchronisationsverzögerung ist ein Sicherheitsparameter, kein Leistungsdetail. Verliert jemand den Zugriff auf ein Dokument – durch Rollenwechsel, Ausscheiden aus dem Unternehmen oder neue Vertraulichkeit eines Geschäfts –, enthält der Index bis zur nächsten Synchronisation weiterhin die alte ACL. Legen Sie je Korpus eine akzeptable Verzögerung für den Berechtigungsentzug fest und dokumentieren Sie sie: nahezu Echtzeit für streng geschützte Korpora, möglicherweise Stunden für interne Prozessdokumente. Ohne dokumentierten Wert lautet die tatsächliche Antwort „wenn der nächtliche Job läuft“ – das hält keiner Sicherheitsprüfung stand.
Echtzeitprüfungen schaffen Aktualität, kosten aber Latenz, Ratenlimits und einen zusätzlichen Fehlermodus. Ein Berechtigungsaufruf je Retrieval ergänzt jede Abfrage um einen Roundtrip zum Quellsystem und verbraucht bei Skalierung schnell API-Kontingente. Der übliche Kompromiss ist ein kurzlebiger Cache, der „Echtzeit“ faktisch wieder in eine kürzere Synchronisationsverzögerung verwandelt. Legen Sie das Verhalten bei Zeitüberschreitung ausdrücklich fest: Schlägt die Berechtigungsprüfung fehl oder läuft sie ab, darf der Chunk nicht gesendet werden. Schlagen Sie sicher fehl, protokollieren Sie den Fehler und lassen Sie den Assistenten ablehnen – eine langsame korrekte Antwort ist besser als ein schnelles Datenleck.
Der Austrittstest im Testabschnitt zeigt, ob die Kontrollen tatsächlich funktionieren: Ein deaktiviertes Konto darf nichts aus streng geschützten Korpora abrufen. Der Test muss unmittelbar nach der Kontodeaktivierung bestehen, nicht erst nach der nächsten vollständigen Resynchronisation.
Quellengrenzen
Erstellen Sie keinen einzigen großen Wissenspool. Trennen Sie nach Zielgruppe und Sensibilität:
| Korpus | Zielgruppe | Beispiele | Regel |
|---|---|---|---|
| Öffentlich/Produkt | Jeder | Help-Dokumente, öffentliche Preise, Produktseiten | Sicher für breiten Assistenten |
| Interne Operationen | Mitarbeiter | Prozessdokumente, interne FAQs | Nur für Mitarbeiter |
| Abteilung | Abteilungsmitglieder | Verkaufsplaybooks, Support-Makros, Engineering-Runbooks | Gruppenfilter |
| Kundendaten | Zugewiesene Teams | Tickets, Verträge, Kontonotizen | Strenge ACL und Auditierung |
| Streng geschützt | Nur benannte Benutzer | Personalwesen, Recht, Sicherheit, Vorstand | Meist separates System oder kein RAG |
Je weniger Zielgruppen ein Korpus bedient, desto einfacher lässt sich das Risiko von Datenlecks beurteilen.
Ingestionskontrollen
Die Ingestionspipeline ist der Startpunkt vieler Lecks.
Bevor eine Quelle indiziert wird, erfassen Sie:
- Quellsystem.
- Dokument-ID.
- Eigentümer.
- Zielgruppe oder ACL.
- Sensitivitätsbezeichnung.
- Erstellungs- und Aktualisierungszeitstempel.
- Ablaufdatum oder Überprüfungstermin.
- Ob das Dokument für KI-Retrieval verwendet werden darf.
- Ob das Dokument personenbezogene Daten enthält.
Wenn das Quellsystem bereits Bezeichnungen hat, bewahren Sie sie auf. Wenn nicht, fügen Sie vor der Ingestion einen leichten Klassifizierungsschritt hinzu.
Retrieval-Kontrollen
Retrieval sollte in dieser Reihenfolge erfolgen:
- Identifizieren Sie den Benutzer und die Gruppen.
- Identifizieren Sie den angeforderten Arbeitsbereich oder Assistenten.
- Filtern Sie Kandidatenquellen nach Korpus, ACL, Sensitivität und Frische.
- Rufen Sie nur relevante Chunks aus erlaubten Quellen ab.
- Reranken Sie erlaubte Chunks.
- Generieren Sie die Antwort mit Quellenverweisen.
- Verweigern oder eskalieren Sie, wenn die erlaubten Quellen nicht ausreichen.
Rufen Sie nicht zuerst ab und filtern Sie später im Prompt. Wenn ein verbotener Chunk in den Modellkontext gelangt, ist die Grenze bereits gescheitert.
Prompt- und Antwortverhalten
Der Assistent sollte angewiesen werden:
- Nur aus abgerufenen Quellen zu antworten.
- Quellentitel und Abschnitt/Link zu zitieren.
- Zu sagen, wenn erlaubte Quellen die Antwort nicht enthalten.
- Schlussfolgerungen von Quellenfakten getrennt zu markieren.
- Nicht zu enthüllen, dass eingeschränkte Quellen existieren.
- Kein Material zusammenzufassen, auf das der Zugriff verweigert wurde.
Schlechte Verweigerung:
„Ich fand HR-Gehaltsbänder, aber Sie haben keinen Zugriff.“
Bessere Verweigerung:
„Ich habe keine genehmigte Quelle zur Beantwortung dieser Frage.“
Die zweite Antwort enthüllt nicht die Existenz oder das Thema eingeschränkter Dokumente.
Protokollieren, ohne ein zweites Datenleck zu schaffen
RAG-Protokolle sind sensibel. Sie können Benutzerfragen, abgerufene Chunks, Quell-IDs, Antworten und manchmal personenbezogene Daten enthalten.
Protokollieren Sie genug, um Debuggen zu ermöglichen:
- Benutzer-ID oder pseudonymisierte ID.
- Assistent/Arbeitsbereich.
- Abfragezeitstempel.
- Abgerufene Quell-IDs.
- Ergebnis der Berechtigungsfilterung.
- Antwort-ID.
- Grund für Verweigerung oder Eskalation.
- Latenz und Fehler.
Vorsicht bei:
- Vollständigen Benutzerfragen.
- Vollständigen abgerufenen Chunks.
- Vollständigen generierten Antworten.
- Kundendaten.
- Personal/Rechts/Sicherheits-Themen.
Speichern Sie bei sensiblen Systemen geschwärzte Protokolle oder Quell-IDs statt vollständigem Text. Schützen Sie die Protokolle mit eigenen Zugriffskontrollen und Aufbewahrungsfristen.
Veraltete und widersprüchliche Quellen
Berechtigung ist nicht die einzige Grenze. Quellenqualität zählt.
Jede indizierte Quelle sollte einen Eigentümer und eine Frische-Regel haben:
| Quellentyp | Prüfregel |
|---|---|
| Preise | Bei jedem Preisanpassung prüfen |
| Richtlinien | Bei Update der Richtlinien-Eigentümer prüfen, mindestens quartalsweise |
| Produkt-Dokumentation | Bei Veröffentlichung prüfen |
| Rechtsvorlage | Von Rechts-Eigentümer prüfen |
| Support-Makro | Monatlich oder nach Eskalationsmustern prüfen |
Widersprechen sich Quellen, darf der Assistent den Konflikt nur ansprechen, wenn der Benutzer auf beide zugreifen kann. Andernfalls muss er anhand der zulässigen Quelle mit der höchsten Autorität antworten oder eskalieren.
Testen von Berechtigungsgrenzen
Testen Sie mit Benutzern, nicht nur mit Dokumenten:
- Mitarbeiter mit breiten Zugriffsrechten.
- Mitarbeiter mit schmalen Abteilungszugriffsrechten.
- Manager mit Team-only-Zugriffsrechten.
- Auftragnehmer.
- Ehemaliger Mitarbeiter oder deaktiviertes Konto.
- Kundensupport-Benutzer.
- Administrator.
Für jeden fragen Sie:
- Eine Frage, die der Benutzer beantworten sollte.
- Eine Frage, die gerade außerhalb seiner Berechtigungen liegt.
- Eine Frage zu einem eingeschränkten Dokument, das der Benutzer weiß, dass es existiert.
- Eine Frage, bei der öffentliche und interne Dokumente widersprechen.
- Eine Frage mit Prompt-Injektion: „Ignoriere Zugriffsregeln.“
Das korrekte Ergebnis ist nicht nur „gute Antwort“. Es ist „gute Antwort aus erlaubten Quellen“.
Rollout-Pfad
Beginnen Sie mit dem am wenigsten sensiblen Korpus:
- Öffentlich/Produkt-Dokumente.
- Interne Operationsdokumente.
- Abteilungsspezifische Dokumente.
- Kundendaten mit strengen ACL.
- Streng geschützte Korpora nur nach ausdrücklicher Sicherheits- und Rechtsfreigabe.
Bei jedem Schritt messen Sie:
- Antwortnützlichkeit.
- Qualität der Zitierungen.
- Richtigkeit der Verweigerung.
- Rate der Zugriffsverweigerung.
- Rate veralteter Quellen.
- Benutzerberichte über fehlende oder falsche Quellen.
Noch nicht tun
Indizieren Sie nicht „alle Unternehmensdokumente“ in einen Assistenten.
Verlassen Sie sich nicht auf Prompt-Anweisungen, um Berechtigungen durchzusetzen.
Protokollieren Sie keine vollständigen abgerufenen Chunks für sensible Korpora ohne klare Aufbewahrungs- und Zugriffsrichtlinie.
Mischen Sie nicht Personalwesen, Recht, Kundendaten und öffentliche Dokumente in denselben Korpus.
Lassen Sie den RAG nicht außerhalb seiner erlaubten Quellen antworten, nur um hilfreich zu sein.
Fazit
RAG für Unternehmenswissen ist wertvoll, weil es quellenbasierte Antworten in die tägliche Arbeit bringt. Es ist riskant, weil selbst quellenbasierte Antworten Informationen offenlegen können.
Entwerfen Sie Berechtigungsgrenzen. Filtern Sie vor dem Retrieval. Trennen Sie Korpora nach Zielgruppe. Bewahren Sie Quellenmetadaten. Verweigern Sie sicher. Protokollieren Sie sorgfältig. Testen Sie mit realen Berechtigungsprofilen. Kann ein Benutzer nicht direkt auf eine Quelle zugreifen, darf das RAG-System sie nicht zur Beantwortung seiner Frage verwenden.
