A 2025 IBM Cost of a Data Breach Report found that 97 percent of organizations that had an AI-related security incident lacked proper access controls on the AI system involved, and 63 percent had no AI governance policy at all. Retrieval-Augmented Generation, or RAG, is where that gap shows up fastest, because a RAG system does not just generate text. It queries a live knowledge base, a vector database, and often internal documents on every single request.
Most AI governance checklists were written for model training and never touch the retrieval layer. This one does. It covers the three places RAG governance actually breaks: the data going in, the retrieval happening at query time, and the output reaching the user, mapped to ISO/IEC 42001, the EU AI Act, and NIST AI RMF.
Why RAG Systems Need a Governance Layer Model Governance Does Not Cover
Model governance asks whether a model was trained responsibly. RAG governance asks a different question: whether the system is retrieving the right information, from an approved source, and putting it in front of the model without exposing anything it should not. Those are not the same problem, and a control set built for one does not automatically cover the other.
A RAG pipeline has three governance surfaces that a standalone LLM deployment does not. The first is the data source layer: the documents, databases, and feeds that get ingested and indexed. The second is the retrieval layer: the vector search, ranking, and filtering logic that decides what the model actually sees for a given query. The third is the output layer: what the model does with retrieved content, whether it cites sources correctly, and whether it stays grounded in what was retrieved instead of drifting into confabulation. Each layer has its own failure modes and needs its own controls.
Skipping this distinction is the most common gap governance teams walk into. An organization completes a model-level risk assessment, documents the foundation model’s card, and considers the AI system reviewed. Then the RAG layer sitting on top of that model, connected to a document repository nobody classified and a vector index nobody is monitoring, never gets assessed at all.
Data Source Governance: Approval, Classification and Ingestion Controls
Every document, database, or feed that feeds a RAG knowledge base should go through an approval step before it is indexed. Ungoverned ingestion is how sensitive HR records, unredacted legal contracts, or draft financial data end up retrievable by any user who phrases a query the right way.
Under the EU AI Act’s Article 10, high-risk AI systems that use data-driven techniques must apply governance and management practices to their data sets covering origin, collection process, and preparation steps, and the data itself must be relevant, sufficiently representative, and as free of errors as possible. Article 10 was written with training, validation, and testing data sets in mind. Whether a RAG knowledge base, which is queried at inference time rather than used to train the model, falls squarely inside that definition is a genuinely open interpretive question and legal counsel should weigh in before an organization takes a firm compliance position either way.
What is not in question is that the underlying expectation, that the data an AI system relies on is sourced, classified, and quality-checked, applies in substance to a RAG corpus regardless of how the classification question resolves.
A practical ingestion control set covers four things: a documented approval step before any new source is indexed, a data classification tag applied at the document or field level, a defined refresh cadence appropriate to how fast the source changes, and a removal or de-indexing process for documents that are revoked, expired, or superseded.
Static archives can refresh monthly or quarterly. Pricing tables, policy documents, and anything tied to a regulatory deadline need weekly or even daily refresh cycles, because a RAG system is only as current as its last successful index run.
Vector Database and Embedding Layer Controls
The vector database is the part of a RAG stack that governance frameworks written before 2023 have no language for, and it is also where a surprising share of production incidents originate. Two failure modes show up repeatedly: embedding model drift, where documents indexed under one embedding model version are queried against a newer version and the similarity scores stop meaning what they used to, and index staleness, where the underlying source document changed but the vector index was never refreshed, so retrieval confidently returns outdated content.
Embedding space mismatch is a specific version of the drift problem worth naming on its own. If an embedding model is upgraded mid-ingestion cycle without re-indexing everything already loaded, the old and new vectors are, in practical terms, speaking two different mathematical languages, and similarity search across them degrades in ways that are hard to detect until a user reports a wrong answer.
Governance controls for this layer should require a documented embedding model version tied to every index, a re-indexing trigger whenever that version changes, periodic retrieval-quality testing using a fixed set of representative queries rather than only synthetic benchmarks, and integrity monitoring for the index itself, since a compromised or poisoned vector store can silently corrupt every answer built on top of it. Backup and rollback capability for the vector store matters here too. If a corpus is found to contain unauthorized or poisoned content, the response should be a revert to a known-good index state, not a manual document-by-document cleanup under deadline pressure.
Retrieval Layer Access Controls and Least-Privilege Design
Retrieval-time access control is the single most commonly missed piece of RAG governance, because it is easy to secure a document repository and then connect a RAG system to it with a single service account that can read everything. At that point, document-level permissions the organization spent years building are meaningless, because the retrieval layer ignores them.
The fix is retrieval that is identity-aware and permission-scoped, not just system-scoped. A query from a given user should only be able to retrieve chunks the requesting user is independently authorized to see, enforced at query time, not filtered after the fact in the model’s output. This is the least-privilege principle applied to a retrieval pipeline instead of a file system, and it needs to be designed in from the start, because retrofitting row-level or document-level permission checks into an existing vector index is a materially harder engineering problem than building it in from day one.
NIST AI 600-1, the Generative AI Profile companion to NIST AI RMF 1.0, calls out exactly this exposure under its information security and data privacy risk categories, noting that retrieval-augmented systems introduce additional privacy surface because they query databases containing sensitive records at inference time, and recommending runtime access controls for retrieval systems specifically, not just for the underlying data store.
Prompt injection is the other risk that concentrates at this layer: a malicious or malformed document sitting in the knowledge base can carry instructions that, once retrieved, attempt to redirect the model’s behavior. Sanitizing and validating retrieved content before it reaches the model’s context window is part of retrieval governance, not a separate security workstream bolted on afterward.
Retrieval controls should also account for malicious instructions embedded in documents or other retrieved content, making prompt injection governance an important part of RAG risk management.
Output Controls: Grounding, Citation and Hallucination Monitoring
RAG reduces hallucination, it does not eliminate it. The retriever can pull the exactly right passage and the generator can still distort a date, invent a detail, or blend two unrelated sources into a confident-sounding but wrong answer. Governance at the output layer exists because grounding is a tendency built into the architecture, not a guarantee enforced by it.
Three controls matter most here. First, citation enforcement: every factual claim in a RAG output should be traceable to a specific retrieved passage, and the system should be able to show that trace on demand, not just produce plausible-looking footnotes. Second, groundedness or faithfulness scoring: an automated check, run continuously in production and not only during pre-launch testing, that flags outputs which drift from what was actually retrieved.
Third, staleness detection: because a technically accurate retrieval of an outdated document produces a wrong answer that looks exactly like a right one, output monitoring needs to check not just whether an answer matches its source, but whether that source is still current.
Article 15 of the EU AI Act requires high-risk AI systems to achieve an appropriate level of accuracy and to be resilient against errors, faults, and inconsistencies, with accuracy metrics disclosed in the instructions for use. Article 14 requires human oversight measures proportionate to the system’s risk.
For a RAG system feeding decisions that affect people, that translates into a defined human review point before a retrieved-and-generated answer is acted on, not an assumption that grounding alone is sufficient oversight.
Mapping RAG Controls to ISO 42001, the EU AI Act and NIST AI RMF
Most published RAG guidance treats compliance as a single line item: “governance and compliance,” addressed in one paragraph. Reviewing the current top-ranking content on this topic, none of it maps RAG-specific controls to all three major frameworks at the clause level. The table below does that, so a governance team can trace a single control, retrieval access enforcement, for example, to its ISO clause, its EU AI Act article, and its NIST AI RMF subcategory in one place instead of maintaining three separate mapping documents.
| RAG Control Area | ISO/IEC 42001:2023 | EU AI Act | NIST AI RMF |
|---|---|---|---|
| Data source approval & classification | Clause 8.1 (operational planning); Annex A.7, Data for AI systems | Article 10(2)(b), data collection & origin | GOVERN 4.1; MAP 2.3 |
| Data quality & representativeness | Annex A.7 | Article 10(3), quality criteria | MEASURE 2.1; MAP 3.4 |
| Vector database / embedding integrity | Annex A.7, Annex A.9 | Article 15, accuracy & robustness | MEASURE 2.5; MEASURE 2.7 |
| Retrieval-layer access controls | Clause 8.2; Annex A.6 | Article 10(2), data governance; GDPR Art. 25/32 where personal data is involved | GOVERN 4.2; MANAGE 2.3 |
| Output grounding & citation | Clause 9.1, monitoring & measurement | Article 13, transparency | MEASURE 2.6; MEASURE 3.3 |
| Hallucination & faithfulness monitoring | Clause 9.1; Clause 10.1, improvement | Article 15, accuracy & robustness | MEASURE 2.7; MANAGE 4.1 |
| Human oversight of RAG outputs | Clause 8.1 | Article 14, human oversight | GOVERN 3.2; MANAGE 2.2 |
| Audit trail & logging | Clause 9.2, internal audit | Article 12, record-keeping | GOVERN 1.2; MANAGE 4.2 |
Annex A sub-clause numbers are marked for editorial verification against the licensed ISO/IEC 42001:2023 text before this table is treated as a final compliance reference. The clause-level structure and framework-to-framework alignment are accurate; the specific sub-clause citations should be confirmed by a team with access to the standard.
RAG systems should be tested before approval using LLM evaluation evidence that demonstrates retrieval quality, groundedness, and output reliability.
RAG Governance Checklist: A Step-by-Step Control List
The following consolidates the controls above into a sequence a governance or engineering team can work through directly. Each item notes the framework it primarily traces to.
- Document and approve every data source before it is indexed into the RAG knowledge base. [ISO 42001 Annex A.7; EU AI Act Art. 10(2)(b)]
- Apply data classification tags at the document or field level, including any personal or sensitive data. [EU AI Act Art. 10(2); NIST GOVERN 4.1]
- Set a refresh cadence per source based on how frequently the underlying content changes. [ISO 42001 Clause 8.1]
- Record the embedding model version tied to every vector index and re-index on version change. [NIST MEASURE 2.5]
- Run periodic retrieval-quality tests against a fixed set of representative queries, not only synthetic benchmarks. [NIST MEASURE 2.1]
- Enforce identity-aware, permission-scoped retrieval so users only retrieve chunks they are independently authorized to see. [EU AI Act Art. 10(2); NIST GOVERN 4.2]
- Sanitize and validate retrieved content for injected instructions before it reaches the model context window. [NIST AI 600-1, Information Security]
- Require citation enforcement so every factual claim traces to a specific retrieved passage. [EU AI Act Art. 13]
- Run continuous groundedness or faithfulness scoring in production, not only at pre-launch testing. [ISO 42001 Clause 9.1; NIST MEASURE 2.7]
- Check retrieved sources for staleness, not just for topical match, before generation. [ISO 42001 Clause 8.1]
- Define a human review point for any RAG output that feeds a decision affecting a person. [EU AI Act Art. 14]
- Log every query, retrieved source set, and generated output with enough detail to reconstruct an answer during an audit. [EU AI Act Art. 12; ISO 42001 Clause 9.2]
- Maintain a rollback or restore capability for the vector store in case of corpus poisoning or corruption. [NIST MANAGE 4.1]
Audit Evidence and Continuous Monitoring for RAG Systems
A control that exists but produces no evidence is indistinguishable, to an auditor, from a control that does not exist. RAG systems generate an unusually large amount of potential evidence, every query, every retrieved chunk, every citation, every human review decision, but only if that evidence is captured deliberately rather than left to whatever the vector database’s default logging happens to be.
A minimal evidence set an audit or certification review will ask for includes: the source approval record for every document in the knowledge base, the classification tags applied at ingestion, the embedding model version history, retrieval-quality test results over time, groundedness scores on production traffic, human review logs where oversight was triggered, and query and response logs with enough retention to reconstruct what a user saw on a given date. Article 12 of the EU AI Act requires high-risk systems to automatically log events across their lifecycle sufficient to identify situations that may present a risk or lead to a substantial modification, which for a RAG system means the log has to capture the retrieval step, not just the final generated response.
Most teams building this for the first time try to assemble it manually across spreadsheets and screenshots when an audit is announced, which is roughly the same failure mode as trying to reconstruct compliance evidence for any other AI system after the fact.
Govern365.ai‘s audit evidence management module was built for exactly this pattern: it captures source approval, classification, and retrieval-quality evidence continuously as part of normal operation, so the evidence already exists when an auditor asks for it instead of needing to be reconstructed under deadline pressure.
Frequently Asked Questions
Is a RAG system automatically high-risk under the EU AI Act?
Not automatically. Risk classification under the EU AI Act depends on the system’s use case and where it falls under Annex III, not on whether it uses RAG as an architecture. A RAG-based hiring tool or credit decision system would likely be high-risk; a RAG-based internal documentation assistant likely would not. Classify by use case first, then apply RAG-specific controls regardless of the outcome.
Does EU AI Act Article 10 apply to a RAG knowledge base?
This is genuinely unsettled. Article 10 was written for training, validation, and testing data sets, and a RAG corpus is typically queried at inference time rather than used to train the model. Legal counsel should assess applicability for a specific system. The underlying data governance expectations apply in substance either way.
What is the difference between RAG governance and model governance?
Model governance evaluates how a model was trained and evaluated. RAG governance evaluates the data sources feeding the knowledge base, the access controls at the retrieval layer, and whether generated output stays grounded in what was retrieved. A model-level review does not automatically cover any of the retrieval-specific risks.
How often should a RAG vector index be refreshed?
It depends on how frequently the underlying source documents change. Fast-moving content, pricing, policy, or regulatory material, may need daily or weekly refresh cycles. Static archives can refresh monthly or quarterly. The refresh cadence should be documented per source, not applied as one blanket rule across the whole knowledge base.
Can RAG eliminate AI hallucination?
No. RAG reduces hallucination risk by grounding responses in retrieved documents, but the generator can still distort, misinterpret, or blend retrieved content incorrectly. Continuous groundedness or faithfulness monitoring in production is necessary because grounding is a tendency the architecture encourages, not a guarantee it enforces.
What access controls does a RAG retrieval layer need?
Retrieval should be identity-aware and permission-scoped, meaning a user can only retrieve chunks they are independently authorized to see, enforced at query time. A single service account with broad read access to the underlying repository defeats document-level permissions the organization already has in place.
What audit evidence does a RAG system need to produce?
At minimum: source approval records, classification tags, embedding model version history, retrieval-quality test results, production groundedness scores, human review logs, and query and response logs with sufficient retention. EU AI Act Article 12 requires this level of automatic logging for high-risk systems specifically.
How does NIST AI 600-1 address RAG-specific risk?
NIST AI 600-1, the Generative AI Profile, identifies retrieval-augmented systems as introducing additional privacy surface because they query databases containing sensitive records at inference time, and it recommends runtime access controls for retrieval systems specifically, alongside its broader guidance on confabulation and information security risk.
Conclusion
A RAG system fails governance in one of three places: an unapproved data source gets indexed, the retrieval layer ignores permissions the organization already built, or an ungrounded output reaches someone who needed a verifiable answer. Each of those is a specific, controllable failure, not an inherent property of the architecture. Start with the checklist above at whichever layer your last incident or audit finding pointed to, and build outward from there.
Govern365.ai maps each of these controls to ISO 42001, the EU AI Act, and NIST AI RMF automatically, and keeps the audit evidence current as your RAG systems change. Start your 14-day free trial and see your RAG systems mapped to all three frameworks in one dashboard.
