Secure enterprise RAG: architecture, data leaks and the EU AI Act
Talking about secure enterprise RAG in 2026 is no longer a technical matter of choosing a vector database and embeddings. It is a matter of governance, of data leaks and of EU AI Act compliance. Retrieval Augmented Generation architectures have become the workhorse for connecting LLMs with corporate knowledge, and they are also the main vector for exposing confidential information when implemented without a defensive design from the outset.
What we mean by secure enterprise RAG
A secure enterprise RAG system is one that combines retrieval of internal information with an LLM’s response generation while guaranteeing: source traceability, access control inherited from the original repository, no leakage to the external model and documentary compliance with the EU AI Act and the GDPR. In other words, it is not enough for it to “work well” in a demo: it has to survive an audit.
Recommended architecture of a secure enterprise RAG
The pilots that have gone into production without trouble share an architectural pattern that can be summed up in six layers. I describe them in order of data flow:
- Governed ingestion layer: only classified documents enter, with confidentiality labels and an owner.
- Preprocessing pipeline with optional PII anonymisation and redaction of sensitive fields.
- Vector store with permissions inherited from the original document (row-level security or metadata filters).
- Orchestrator that validates the user’s identity and restricts retrieval to documents they have access to.
- LLM run in a controlled environment: either on-premise or in an EU region with a no-training contract.
- Audit layer that logs prompts, retrieved sources and the response for later review.
If this architecture connects with internal systems, it is also worth reviewing the discipline of MCP in enterprise projects to avoid an unnecessary attack surface.
The most common data-leak risks
I have audited RAGs in production that leaked confidential information through subtle, repeated errors. The most frequent are: indexing documents without respecting the source repository’s permissions, using a provider’s embeddings without an adequate contract, not applying per-user filtering in the vector query, and allowing the LLM to summarise fragments the user would not have direct access to.
EU AI Act compliance in RAG systems
A corporate RAG normally falls into the limited-risk category, but it can escalate to high-risk when used in HR, scoring, administrative decisions or essential services contexts. The key obligation is transparency: the user must know they are interacting with AI, the sources must be citable and there must be traceability in the event of a review request. This ties in with the discipline of AI asset inventory, which is also required.
Quick checklist before going to production
- Document permissions inherited in the vector database.
- Encryption in transit and at rest across all layers.
- A contract with the LLM provider that prohibits the use of data for training.
- Logs of prompts and responses with a defined retention period.
- A deletion policy and the right to be forgotten over vectorised fragments.
- Prompt injection and data exfiltration tests carried out and documented.
Before putting a RAG into production it is wise to measure its behaviour rigorously, and not just by intuition. Applying benchmarks, red teaming and quality metrics lets you know whether the system responds accurately and whether it withstands manipulation attempts. How to set up that battery of tests I explain step by step in my guide on enterprise AI model evaluation, a stage I consider essential for any serious deployment.
Conclusion: security as a competitive advantage
A secure enterprise RAG is neither slower nor more expensive, it is simply one that survives the first audit. Starting the design with the governance layer and not with the vector store saves months of rework. If you are designing or auditing a corporate RAG and want a second opinion, tell me about the case.
If you are interested in enterprise AI architecture, expand with MCP in enterprise projects: architecture, governance and risks and the case of an IT project using artificial intelligence.
Do you have to apply this under DORA, NIS2 or ENS? Tell me about it.
Book 20 minutes