RAG Access Evidence Becomes an Operating Standard

RAG access evidence is becoming an operating standard. AWS has announced two APIs and console support for Amazon Bedrock Knowledge Bases that let teams inspect and analyse document permissions in a knowledge base. This is not a convenience feature: with production AI answers, teams need to establish whether a document was correctly unavailable or whether an access permission was configured incorrectly.

The answer is not the only thing that needs evidence

RAG systems combine language models with enterprise knowledge. In practice, two different failures occur: an agent may find content that a user should not see. Or it may fail to find an expected document even though that document is relevant to the business task. In the chat, both cases initially look alike: the answer appears incomplete or surprising.

AWS names the new functions CheckIngestedDocumentAcl and GetIngestedDocumentAcl. According to the announcement, the first verifies a specific user’s access to an ingested document. The second returns the ACL attached to the document. This makes it possible to distinguish a retrieval-quality issue from a data-ingestion issue or an access-control rule.

The access path is an audit object

For DACH organisations, the operating rule is simple: do not assess a RAG answer solely by its wording. Assess its access path as well. For every critical use case, at least four pieces of information should be traceable:

• Identity: Which user or service account made the request?
• Source decision: Which documents were considered, returned or excluded?
• Permission: Which ACL or policy explains that decision?
• Point in time: Which data and permission version applied when the answer was generated?

This aligns with a core principle in the EU AI Act: for high-risk AI systems, Article 12 requires technical capability for automatic event logging throughout the system lifecycle. Not every internal knowledge base automatically qualifies as a high-risk AI system. The principle remains useful: traceability does not come from a retrospective screenshot, but from technical logs.

Start with an access test suite

Create ten to twenty test cases for one selected RAG workflow: allowed documents, deliberately excluded documents, changed permissions and outdated content. Run them again with every change to a connector, index or identity provider. Measure answer quality, source coverage and access correctness separately.

A knowledge base then becomes more than a search source for a chatbot. It becomes a controllable enterprise system whose knowledge boundaries remain explainable.