Data Governance as the Foundation of Enterprise RAG Systems
Here is a test that quickly shows whether an enterprise AI assistant is ready for real-world operation. Two employees with different access rights are given the same question about bonus calculation rules. The system must return only the permitted, up-to-date version of the document to each user and show the source. If one user sees an outdated policy, another sees confidential data, and a repeated query cannot be reproduced, the problem occurred even before the response was generated.
This scenario demonstrates a fundamental architectural problem: perceiving a large language model (LLM) as a reliable knowledge repository. In industrial RAG (Retrieval-Augmented Generation) systems, the model acts as a processor and natural language interface. The actual source of answers remains the enterprise systems. If, during the retrieval stage, the system extracts outdated or confidential data, the model will generate a correspondingly incorrect response. Therefore, the quality of answers depends not only on the model, but also on the rules of data preparation and selection.
Retrieval Architecture and Limits of Model Responsibility
To build a secure architecture, it is necessary to separate training data and retrieval data. Training data is used to create the model, integrating into its weights. Retrieval data is a dynamic array of corporate documents that the RAG system accesses in real time during query processing. A vector database searches for semantically similar text fragments, but without proper configuration, it does not take into account the context of who exactly is making the query.
According to the practical recommendations of OWASP (Top 10 for LLM Applications), instructions in the system prompt cannot be the sole mechanism for restricting access to confidential information. Such systems remain vulnerable to prompt injection attacks, where a user manipulates the query to bypass restrictions. Security must be implemented at the application software level. The application must filter out vectors of documents that the user does not have permission to view before these fragments enter the context window of the LLM.
Data Provenance Tracking and Access Control
To ensure transparency in data pipeline operations, architects use information provenance tracking tools. For example, the open standard OpenLineage collects metadata about which tasks were run and how data moved between systems. It records the technical transformation path: from reading a file from ERP to saving it in a vector database. This helps reconstruct the data path to the search index, but does not automatically show which fragment became the basis for a specific response.
However, technical monitoring does not replace business data governance. OpenLineage shows the movement of information, but does not independently establish data owners or enforce access policies. To build a reliable data perimeter, it is advisable to use platforms with built-in security mechanisms. For example, the low-code platform UnityBase, which is the technological foundation of IQusion solutions (including Megapolis.DocNet and Scriptum.DMS systems), provides Row-Level Security and audit logging. This creates a technical capability to filter documents according to user permissions at the platform level before the information is passed into the data preparation pipeline for the language model.
Regulatory Frameworks and Risk Management
Requirements for data governance in AI systems are gradually being formalised at the legislative level. The EU Artificial Intelligence Act (EU AI Act), which entered into force in 2024, provides for the application of most rules from 2 August 2026 (with certain exceptions). Article 10 of this document establishes requirements for data governance, including collection, preparation, and compliance assessment, but these rules are mandatory solely for systems classified as high-risk.
Regardless of the legal classification of the system, NIST offers a voluntary AI risk management framework. The NIST AI Risk Management Framework (AI RMF 1.0) organises risk management around four continuous processes: Govern, Map, Measure, and Manage. Its profile for generative AI (NIST AI 600-1) separately addresses governance, content provenance, pre-deployment testing, and incident reporting. According to these documents, risk management is an ongoing lifecycle that requires documenting the limits of system knowledge and regular auditing.
Enterprise Content Preparation Pipeline
Artificial intelligence models update quickly. Transitioning between LLMs still requires integration adaptation and re-testing. However, the data preparation perimeter is usually more expensive to change: it links sources, metadata, access rights, and the document lifecycle.
In an industrial system, connecting the model is just one of the components. A fully-fledged pipeline includes a raw data collection pipeline, its parsing, semantic splitting (chunking), and storage in a vector database. Correct chunking must preserve logically related parts of the document; its parameters need to be verified on documents of a specific subject area. It is this infrastructure layer that is responsible for ensuring that during retrieval, the system finds relevant text fragments rather than random keyword matches.
Assessing Data Infrastructure Readiness
Before transitioning from testing to industrial operation of RAG systems, it is advisable to conduct an audit of the current data architecture. The matrix below contains basic criteria for verification.
| Assessment Vector | Readiness Criterion | Implementation Mechanism |
|---|---|---|
| Provenance | Ability to determine the primary source of each text fragment used by AI. | Preserving document identifiers in the metadata of the vector store. |
| Relevance | The system distinguishes document versions and excludes outdated fragments from search. | A synchronisation pipeline that responds to document status change events. |
| Access Rights (RLS/ACL) | Restricting access to vectors works independently of model instructions. | Row-Level Security in the database, integrated with corporate IAM. |
| Reproducibility | The ability of the system to repeat the data processing workflow for auditing. | Recording the technical path of data transformation (data lineage). |
| Audit Log | User queries and provided answers are recorded for analysis. | Event logging with security context capture. |
Frequently Asked Questions
Does RAG technology eliminate language model hallucinations?
No, RAG technology reduces the risk of hallucinations by providing the model with relevant context from corporate sources, but does not eliminate them completely. To ensure accuracy, it is necessary to implement primary source verification mechanisms at the application software level.
Why should user access rights not be restricted via the LLM system prompt?
According to OWASP recommendations, system prompts are vulnerable to prompt injection attacks. A user can formulate a query to bypass model instructions. Access control must be implemented at the application level before information is passed to the context window.
Do the requirements of Article 10 of the EU AI Act apply to all corporate chatbots?
No, Article 10 of the EU Artificial Intelligence Act establishes mandatory data governance requirements solely for systems classified as high-risk. For other systems, these rules are not mandatory, although they can serve as a guideline for building architecture.
