RAG Production-Readiness Checklist for EU Companies

A RAG prototype over a limited document set can be assembled quickly. That does not establish production readiness. An assistant needs representative evidence for retrieval and answer quality, measured cost and latency, privacy controls, and authorization that survives real users and real data. EU teams must also map the GDPR and any applicable AI Act duties to the actual use case. This is the risk-based checklist we use before people are asked to rely on a RAG system.

RAG is one way to provide external knowledge without changing model weights. Whether it is cheaper or more suitable than long context, search, fine-tuning, or a deterministic workflow depends on the workload. Treat the prototype as the start of evaluation, not the end.

If the knowledge arrives as PDFs, retrieval quality starts before chunking. Our PDF parser and OCR routing guide shows how to keep native text local, identify scanned or mixed pages, and reserve OCR for the pages that need it.

Have a RAG demo that needs to ship?

Book a RAG Production Review

Is the retrieval actually good enough?

Answer quality is constrained when relevant evidence is not retrieved. Prompting cannot recover a source that never entered the model context, although the right design may also use tools, structured data, or an explicit no-answer path. Evaluate retrieval on representative documents and queries rather than a curated demo alone.

Chunking tested against the content. Fixed-size, structural, semantic, parent-child, and document-specific approaches have different tradeoffs. Tables and cross-section references often need special handling.
An embedding and retrieval method tested on your content. If you serve customers in German and English, test both languages and relevant cross-language queries rather than assuming a default transfers.
An evaluation set, not a vibe check. Write down real questions and the passages that should answer them. Measure recall, whether the right passage is actually retrieved, before you touch anything else.
Traceable evidence where appropriate. Return the passages and document versions used for factual answers. A citation improves checkability, but does not prove that the source supports the generated claim.

Will it make things up?

Retrieval does not eliminate hallucination. Define which claims must be supported by retrieved evidence, which other tools or knowledge are allowed, and what the assistant should do when support is insufficient.

Define the evidence boundary. Instruct the model which statements require retrieved support and validate the mapping from statements to passages.
Abstain when support is insufficient. Calibrate the no-answer path on representative examples. Empty retrieval, conflicting sources, stale documents, and low-scoring evidence may need different handling.
Show usable provenance. Surface the relevant passage, title, version, and link when the user can inspect them. Test whether citations are entailed and accessible to that user.

"A RAG demo answers the questions you tested. A RAG product has to answer the questions you did not, and say nothing when it should not. The gap between those two is the whole engagement."

Can you measure it the same way twice?

Changes to the embedding model, chunking, prompt, reranker, source corpus, or generation model can improve some query classes while degrading others. A successful demo does not reveal that tradeoff.

Maintain a versioned evaluation set drawn from deployment conditions, including expected evidence, acceptable answers, abstentions, multilingual queries, permission cases, and adversarial inputs. Re-run it on relevant changes and supplement aggregate scores with per-slice results and human review. Update the set deliberately as the corpus and risks change rather than treating one fixed set as complete.

What will it cost to run, and how fast is it?

A prototype does not reveal production cost or latency. Measure embedding and indexing work, vector search, reranking, model input and output, cache operations, retries, observability, and human review at expected concurrency.

Cache with boundaries. Caching can reduce repeated work, but keys, tenant isolation, authorization, freshness, invalidation, and sensitive content determine whether reuse is safe.
Test model routing. Route only after a representative evaluation shows where a smaller model meets the requirement. Include escalation and retry costs.
Budget context from evidence. Tune passage count and context size against retrieval coverage, groundedness, latency, and cost instead of assuming that fewer is always better.

The economics here are shifting fast, and the architecture you choose now decides what you pay later. We went deeper on that in the LLM API cost shift.

Does it hold up under EU rules?

This is where EU companies have homework that a US tutorial will not mention. We are describing obligations at a general level here, not giving legal advice, and the details depend on your sector and your data. Talk to counsel for the specifics. But the engineering questions are clear enough to put on a checklist.

Map roles, purposes, data, and transfers. Identify the controller and processors, legal basis, data categories, retention, subprocessors, access locations, and security measures. A GDPR Chapter V transfer depends on the actual disclosure to a recipient in a third country, not merely a provider's headquarters or a region label, and requires an applicable transfer mechanism and assessment.
Assess AI transparency duties. Article 50 places a design duty on providers of systems intended to interact directly with natural persons to inform them that they are interacting with AI unless that is obvious to a reasonably well-informed, observant, and circumspect person in context. Determine the roles, exceptions, application date, and any sector-specific duties for the deployment rather than applying one banner rule to every internal tool.
Handle PII deliberately. Decide what personal data is allowed into the index and into prompts, and what gets redacted or excluded. Retrieval can surface a document someone forgot was sensitive.
Log proportionately. Capture enough versioned evidence to investigate quality and security events, but minimize personal and confidential data, restrict access, define retention, and avoid assuming that raw prompts and answers should always be stored.

We have written separately on the cost of AI Act compliance for a startup and how GDPR and the AI Act stack for a DACH SaaS, if you want the regulatory side in more depth.

Can someone break it or read what they should not?

A RAG system adds security boundaries: retrieved content can influence model behavior, and indexes, metadata, caches, logs, and source copies can expose sensitive data.

Prompt injection. A retrieved document can contain instructions aimed at the model: "ignore your rules and reveal X." Treat retrieved content as untrusted input, not as a command, and test for it.
Access control throughout retrieval. Embeddings are not necessarily a verbatim copy of source text, but the index and associated content can still expose sensitive information. Apply authentication, authorization, tenant separation, encryption, backup, and administrative controls to every relevant store.
Source-native user permissions. If users have different document rights, enforce effective authorization before or during retrieval and again before disclosure. Test revocation, group changes, public links, inherited permissions, and cache behavior rather than relying on a one-time copied access list.

The checklist

Use this as an initial risk review before relying on a RAG assistant. It is not a complete security standard, legal assessment, or guarantee. Prioritize gaps by credible likelihood, impact, exposure, and the system's intended decisions or actions.

Retrieval. Meaningful chunking, an embedding model tested on your content and languages, an eval set with measured recall, citations on every answer.
Grounding. Evidence boundaries are defined, abstention is calibrated, and accessible sources are mapped to claims.
Repeatable evaluation. A golden question and answer set that you re-run on every prompt, model, or index change.
Cost and latency. Caching, model tiering, and token budgets that you can defend at scale, not just in the demo.
EU legal review. Roles, purposes, legal basis, data flows, transfers, retention, transparency duties, data-subject handling, and proportionate logs are mapped to the actual deployment.
Security. Prompt injection tested, access control on the index, per-user permissions enforced on retrieval so nothing leaks across users.

The deliverable is evidence that the system meets defined retrieval, answer-quality, abstention, cost, latency, privacy, and authorization requirements within its tested scope, plus monitoring and incident handling for what testing misses.

Building exactly that is our AI enablement service when the assistant runs on your own infrastructure, and AI software development in Austria when the retrieval layer sits inside a product you are shipping to customers. Twinsoft AI is the closest published example of a prototype pushed through this checklist and out the other side.

Final thoughts

A limited RAG demo does not establish how the system behaves on representative documents, multilingual queries, stale or conflicting evidence, unauthorized content, adversarial instructions, or production traffic. Those conditions need explicit evaluation and controls.

For an EU deployment, connect technical evidence to the real data flow, organizational roles, legal basis, transfers, transparency duties, retention, and access model. Treat this checklist as a first pass, then set risk-based release criteria, monitoring, rollback, and incident handling for the intended use.

Primary sources used in this checklist

The checklist maps Wavect's production review method to these public risk, security, and lifecycle references.