---
title: "RAG-Zugriffsnachweis wird zum Betriebsstandard"
description: "AWS erweitert Bedrock Knowledge Bases um ACL-Debugging. Warum RAG-Systeme nicht nur Antworten, sondern den Zugriff auf jede Quelle nachweisen müssen."
date: 2026-09-10
lang: de
tags: [aws-bedrock, rag, governance, dsgvo, news]
author: "thinkai.at"
canonical: https://thinkai.at/blog/rag-zugriffsnachweis-knowledge-base/
---

# RAG-Zugriffsnachweis wird zum Betriebsstandard

**RAG-Zugriffsnachweis** wird zum Betriebsstandard. AWS hat für Amazon Bedrock Knowledge Bases zwei APIs und eine Console-Unterstützung angekündigt, mit denen Teams Dokumentberechtigungen in einer Knowledge Base prüfen und analysieren können. Das ist kein Komfort-Feature: Bei produktiven KI-Antworten muss sich zeigen lassen, ob ein Dokument zu Recht nicht gefunden wurde – oder ob eine Berechtigung falsch konfiguriert ist.

## Nicht nur die Antwort braucht einen Beleg

RAG-Systeme verbinden Sprachmodelle mit Unternehmenswissen. In der Praxis treten dabei zwei unterschiedliche Fehler auf: Ein Agent kann Inhalte finden, die für den jeweiligen Nutzer nicht bestimmt sind. Oder er findet ein erwartetes Dokument nicht, obwohl es fachlich relevant wäre. Beide Fälle sehen im Chat zunächst gleich aus: Die Antwort wirkt unvollständig oder überraschend.

AWS nennt dafür die neuen Funktionen `CheckIngestedDocumentAcl` und `GetIngestedDocumentAcl`. Die erste prüft laut Ankündigung den Zugriff eines bestimmten Nutzers auf ein ingestiertes Dokument. Die zweite liefert die am Dokument hinterlegte ACL. Damit lässt sich erstmals gezielt unterscheiden: Ist die Retrieval-Qualität das Problem, die Datenaufnahme oder die Zugriffsregel?

## Der Zugriffspfad ist ein Prüfobjekt

Für DACH-Unternehmen folgt daraus eine einfache Betriebsregel: Beurteilen Sie eine RAG-Antwort nicht nur anhand ihres Textes. Prüfen Sie auch den Zugriffspfad. Pro kritischem Use Case sollten mindestens vier Informationen nachvollziehbar sein:

- **Identität:** Welcher Nutzer oder welches Servicekonto stellte die Anfrage?
- **Quellenentscheidung:** Welche Dokumente kamen in Betracht, welche wurden geliefert oder ausgeschlossen?
- **Berechtigung:** Welche ACL oder Richtlinie begründete die Entscheidung?
- **Zeitpunkt:** Welche Daten- und Berechtigungsversion galt zum Zeitpunkt der Antwort?

Das passt zu einem Grundgedanken des EU AI Act: Für Hochrisiko-KI-Systeme verlangt Artikel 12 technische Möglichkeiten zur automatischen Ereignisprotokollierung über den Lebenszyklus. Nicht jede interne Knowledge Base ist dadurch automatisch ein Hochrisikosystem. Der Maßstab ist dennoch nützlich: Nachvollziehbarkeit entsteht nicht aus einem nachträglichen Screenshot, sondern aus technischen Protokollen.

## Starten Sie mit einer Zugriffstest-Suite

Legen Sie für einen ausgewählten RAG-Workflow zehn bis zwanzig Testfälle an: erlaubte Dokumente, bewusst ausgeschlossene Dokumente, geänderte Berechtigungen und veraltete Inhalte. Führen Sie diese Fälle bei jeder Änderung an Connector, Index oder Identity-Provider erneut aus. Messen Sie dabei getrennt Antwortqualität, Quellenabdeckung und Zugriffskorrektheit.

Dann wird eine Knowledge Base nicht bloß zur Suchquelle für einen Chatbot. Sie wird zu einem kontrollierbaren Unternehmenssystem, dessen Wissensgrenzen erklärbar bleiben.

## Quellen

- [AWS — Bedrock Knowledge Bases: Debugging document-level access control](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-knowledge-base-debugging-document-access-control/)
- [EUR-Lex — Regulation (EU) 2024/1689, Article 12: Record-keeping](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng)