Retrieval-Augmented Generation has become one of the most practical ways to bring generative AI into enterprise environments. Instead of asking a model to rely exclusively on what it learned during training, the system retrieves information from an organisation’s own knowledge base and provides that evidence as context for the response.
The prototype is usually straightforward. Documents are parsed, divided into chunks, embedded, indexed and retrieved when a user asks a question. A capable model turns the retrieved passages into a fluent answer, often with citations. In a controlled demonstration, the result can look production-ready surprisingly quickly.
It rarely is.
The difficult part of production RAG is not generating an answer. It is establishing that the system retrieved the right information, from the authoritative source, under the correct permissions, at the correct point in time — and that the organisation can reconstruct what happened when an answer is challenged.
For general enterprise knowledge this determines whether users trust the platform. For government, financial services, healthcare, industrial operations or critical infrastructure, it can become a security, continuity and governance requirement.
When a RAG application produces an incorrect answer, the language model is often blamed first. In practice, the failure may have occurred long before inference.
Consider an operating procedure that has been revised several times. The controlled document-management system contains the current version, while an old copy remains in a project archive, a presentation summarises an earlier version and meeting minutes contain a discussion of the proposed change. Semantic retrieval can reasonably judge all of them to be relevant.
If the obsolete document is ranked above the authoritative one, a strong model can produce an exceptionally convincing answer from the wrong evidence.
This is why production evaluation has to distinguish between retrieval correctness, context correctness and generation correctness. Did the platform retrieve the authoritative source? Did it preserve enough surrounding information for that source to be interpreted correctly? Were contradictory or superseded documents recognised? Only after those questions have been answered does it make sense to evaluate the model’s reasoning.
A single aggregate “answer quality” score hides too much. A retrieval failure requires a different engineering response from a hallucination, and both are different again from a stale-data or permission failure.
The consequence also matters. Retrieving an outdated cafeteria policy is inconvenient. Retrieving an obsolete isolation procedure for an industrial environment or a superseded regulatory instruction belongs to an entirely different risk class.
Real organisational knowledge does not arrive as clean paragraphs.
It arrives as complex PDFs, tables, spreadsheets, scanned documents, engineering drawings, presentations, email threads, contractual annexes and duplicated exports from systems that were never designed for AI retrieval. In regulated environments, the information may also carry an owner, approval state, retention requirement, confidentiality level, jurisdiction and validity period.
Flattening all of this into anonymous text fragments destroys relationships that may be essential to interpretation.
A production ingestion architecture should therefore preserve provenance before generating embeddings. A paragraph should remain associated with its section, the section with its document, and the document with its version, source, owner and authority. A retrieved table row should retain the headers that give its values meaning. A contractual clause should retain the agreement and version to which it belongs. A superseded procedure should not compete equally with the approved current version merely because the language is semantically similar.
This is also why there is no universally correct chunk size. Fixed-size chunks are convenient implementation units, but they are rarely the natural units of organisational knowledge. Structural parsing, hierarchical retrieval, metadata, source weighting and reranking can matter substantially more than whether the vector database receives blocks of 600 or 900 tokens.
The real objective is not to create better embeddings. It is to preserve enough of the information architecture that the retrieval system can reason about authority as well as similarity.
The most serious RAG failure is not always an inaccurate answer. It can be an accurate answer delivered to an identity that should never have been able to retrieve the underlying information.
This becomes difficult when one AI knowledge layer spans document management, SharePoint, project repositories, CRM systems, ticketing platforms, databases and operational systems. Each source can carry a different entitlement model. A user may be permitted to see one business unit but not another, one project but not another, or information up to one classification level but no further.
Those restrictions cannot be applied only after the model generates its response. If unauthorised information has already entered the model context, the relevant security boundary has already been crossed.
Identity and authorisation therefore need to propagate into the retrieval path itself. Depending on the environment, that can involve source ACLs, role or attribute-based access control, tenant isolation, security classifications and service-to-service identities. Where an entitlement cannot be established reliably, failing closed may be more appropriate than silently widening the search scope.
The same concern applies to personal information. If a European RAG system processes personal data, the fact that the information was transformed into embeddings or supplied temporarily to a model does not in itself remove data-protection obligations. GDPR remains concerned with the processing of information relating to identifiable individuals, so the complete retrieval and inference flow needs to be considered rather than only the primary repository.
Security governance around the platform can be structured through standards such as ISO/IEC 27001, while ISO/IEC 42001 introduces a management-system framework specifically for organisations developing, providing or using AI. ISO/IEC 23894 complements this with guidance for integrating AI-specific risk management into organisational processes. These standards do not certify the correctness of an individual RAG answer; their value is in creating repeatable governance around the system that produces it.
RAG also creates a security characteristic that conventional search systems did not have in the same form: retrieved text can influence the behaviour of the application consuming it.
A malicious document can contain instructions intended to manipulate the model. A compromised webpage can tell an agent to disregard previous rules, disclose additional information or invoke a tool. The attacker no longer needs to place the malicious instruction directly into the chat interface; it can arrive indirectly through a source the AI was asked to trust.
This turns prompt injection into a broader systems-security issue.
The right defence is not simply a stronger system prompt. The architecture should assume that retrieved information may be hostile. Tool authority should be enforced outside the model. Sensitive operations should pass through deterministic policy controls. Source provenance and trust should remain visible. An agent receiving information from an untrusted source should not suddenly gain a new capability because the text told it to.
The principle is an old one expressed in a new environment: untrusted input should not become trusted control logic.
Most teams benchmark how rapidly they can ingest new information. Production systems also have to demonstrate how reliably information stops being retrievable.
Policies are replaced. Contracts expire. Permissions are revoked. Employees change teams. A government document can be reclassified. Records can reach the end of their retention period. A technical procedure can be withdrawn immediately after an incident.
If the source system changes while the retrieval index remains unchanged, the AI platform begins creating a parallel and increasingly inaccurate version of organisational reality.
The engineering challenge is therefore continuous synchronisation. Updates should be idempotent, document identity stable, deletion reliable and version transitions explicit. The retrieval layer should be reconcilable against systems of record so that missing updates can be detected instead of remaining silently embedded in the index.
The acceptable delay depends on consequence. A marketing document can tolerate a different freshness objective from a privileged-access change or security procedure. Production RAG therefore needs differentiated freshness and revocation requirements rather than one universal indexing SLA.
A RAG service can depend on an identity provider, source repositories, document parsers, embedding infrastructure, a vector store, reranking, model inference, policy services and observability. Making the application servers highly available does not make this chain resilient.
The more useful architecture question is what happens when one of those assumptions disappears.
If the preferred model becomes unavailable, can a lower-capability model maintain an acceptable restricted service? If vector retrieval fails, can an approved lexical or hybrid-search path still return authoritative evidence? If the identity service is degraded, can the system preserve existing secure sessions without widening access? If indexing falls behind, does the application tell operators that the knowledge state is stale rather than continuing as though nothing happened?
For organisations in NIS2 scope, this kind of thinking maps naturally onto the Directive’s risk-management requirements, which encompass incident handling, business continuity, disaster recovery, supply-chain security, secure acquisition and development, vulnerability handling, access control and other technical and organisational measures. The European framework explicitly treats cybersecurity through an all-hazards, risk-based approach rather than as vulnerability scanning alone.
Where the service supports an entity covered by the Critical Entities Resilience framework, the analysis broadens further. CER addresses the resilience of entities delivering essential services and looks beyond cyber incidents alone to the ability to prevent, protect against, respond to, resist, mitigate and recover from disruption.
That does not mean every RAG application should be designed as critical infrastructure. It means the resilience model should follow the consequence of the function the system supports.
When an expert challenges a production answer, “the model generated it” is not a sufficient explanation.
The engineering team should be able to reconstruct which identity submitted the request, how that request was transformed for retrieval, which permission and metadata filters were applied, which sources were eligible, which passages were retrieved, how they were ranked, which model configuration was used and which evidence supported the final response.
If the system can take action, the trace should continue through policy decisions, tool calls, parameters and resulting external state.
This level of observability changes the way AI incidents are handled. A parsing failure can be distinguished from a ranking failure. Stale knowledge becomes separable from model reasoning. An entitlement error becomes clearly different from a hallucination. Once those failure classes are visible, improvement can become systematic rather than anecdotal.
Evaluation should follow the same principle. Test sets should include normal questions, ambiguous questions, superseded information, conflicting evidence, restricted documents and adversarial content. More importantly, failures should be weighted by consequence. A system supporting a safety- or mission-relevant process should not be accepted because a broad average score looks good.
A production RAG platform is therefore not a chatbot with a vector database attached.
It is a controlled knowledge-access architecture spanning ingestion, search, identity, authorisation, information governance, AI risk management, observability and operational resilience. The language model remains an important component, but many of the failures that matter most occur before the model receives context or after it has produced an answer.
The threshold between demonstration and infrastructure is reached when the organisation can answer a harder question than “does it work?”
It should be able to explain why this identity received this information, from this version of the evidence, through this authority path; what prevents a compromised source from becoming a control instruction; how quickly revoked knowledge disappears; how the service behaves when one of its dependencies fails; and how an operator can reconstruct the complete decision afterwards.
That is what makes a RAG system trustworthy in production.
We partner with organisations expanding into the GCC, Central Asia and Africa.
Book a 30-minute callWe use it to understand your objective, the target market and the constraints. You get two or three slots back within one working day.