--- title: "RAG Production-Readiness Checklist for EU Companies" canonical: https://wavect.io/blog/rag-production-readiness-checklist-eu/ language: en description: "A RAG demo over your docs is easy; a trustworthy, GDPR- and AI-Act-defensible RAG assistant is not. The checklist Wavect runs before one ships." image: "https://wavect.io/img/blog/headers/header_rag-production-readiness-checklist-eu.png" --- [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 8 min read · 08 Jun 2026 Last reviewed August 7, 2026 [**Next**](/blog/why-ai-agent-projects-get-cancelled/) # RAG Production-Readiness Checklist for EU Companies TL;DR A RAG demo over your own documents is an afternoon of work; the hard part is everything after it, and in the EU the system also has to be defensible under GDPR and the AI Act without a cloud bill that quietly doubles. The checklist covers retrieval quality with a real evaluation set, grounding and refusal behavior, repeatable evals, cost and latency budgets, EU compliance, and security including prompt injection and per-user permissions on retrieval. A RAG demo over your own documents is one of the easiest wins in AI. Point a retriever at your wiki, wire it to a model, and you have something that answers questions in an afternoon. The hard part is everything after the demo. A demo that impresses a meeting is not the same as an assistant your employees or customers can rely on, and in the EU it has to be that and defensible under GDPR and the AI Act, without a cloud bill that quietly doubles every quarter. This is the checklist we work through before a RAG system goes from interesting to trusted. None of this is an argument against RAG. It is the cheapest way to give a model your knowledge without retraining anything. It is an argument for treating the demo as the start of the work, not the end of it. If the knowledge arrives as PDFs, retrieval quality starts before chunking. Our [PDF parser and OCR routing guide](/blog/pdf-inspector-ocr-routing/) shows how to keep native text local, identify scanned or mixed pages, and reserve OCR for the pages that need it. ## Is the retrieval actually good enough? Everything downstream depends on the model getting the right passages. If retrieval is weak, no amount of prompt tuning saves you, because the model is answering from the wrong source or from nothing. This is the part demos skip, because on a handful of clean documents almost any setup looks fine. - **Chunking that respects meaning.** Splitting on a fixed character count tears sentences and tables apart. Chunk on structure, headings, sections, logical units, so a retrieved passage is a complete thought. - **An embedding model that fits your content.** The default is rarely the best for your domain or your languages. If you serve customers in German and English, test that retrieval works in both, not just the one you demoed in. - **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. - **Citations returned with every answer.** The system should hand back which documents it used. This is what makes answers checkable and, later, what makes the whole thing auditable. ## Will it make things up? A model with retrieval still [hallucinates](/glossary/hallucination/) if you let it. The discipline of [RAG](/glossary/rag/) is to keep the model on a short leash: answer from the retrieved context, and only from it. - **Answer only from retrieved context.** Instruct the model to ground every claim in the passages it was given, and not to fill gaps from its general training. - **Refuse when the context is thin.** If retrieval comes back empty or weak, the right answer is "I do not have that," not a confident guess. A system that refuses well is more trustworthy than one that always answers. - **Show the sources.** Surface the citations to the user. It lets them verify, and it changes behaviour: people trust a system more when they can see where the answer came from, and less blindly. ![Christof Jori](/img/team/christof.webp) "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? The thing that quietly kills RAG projects is that every change feels like progress and nobody can prove it. You swap the embedding model, tweak a prompt, reindex, and the demo still works, so you ship it. Then a class of questions silently gets worse. Build a golden question and answer set: a fixed list of real questions with the answers and sources you expect. Re-run it on every change, a new prompt, a new model, a reindex, and compare. It does not need to be fancy. It needs to be the same every time, so a regression shows up as a number going down instead of a complaint three weeks later. ## What will it cost to run, and how fast is it? A RAG demo serving one person is free in all the ways that matter. A RAG assistant serving a company is a recurring bill that scales with usage, and latency that users feel on every query. Both are design decisions, not afterthoughts. - **Cache what repeats.** Many questions are asked over and over. Caching retrieved context and frequent answers cuts both cost and latency. - **Tier your models.** Not every query needs the largest model. Route simple questions to a smaller, cheaper one and reserve the big model for the hard cases. - **Budget your tokens.** Stuffing twenty passages into every prompt is slow and expensive and often makes answers worse. Retrieve fewer, better passages. 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](/blog/llm-api-costs-2026-architecture-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. - **Know your data flows.** Under GDPR you have to know where personal data goes. If your documents or user questions contain personal data and your model or vector store sits outside the EU, that is a transfer you have to be able to justify. Data residency is a design choice you make early, not a setting you flip late. - **Be transparent that it is AI.** The AI Act expects users to know when they are interacting with an AI system rather than a human. For an assistant, that generally means telling people plainly. - **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 for audit.** Keep a record of what was asked, what was retrieved, and what was answered. You will want it to debug, to improve, and to answer the question "why did it say that" when someone asks. We have written separately on the cost of [AI Act compliance for a startup](/blog/eu-ai-act-compliance-cost-startup/) and how [GDPR and the AI Act stack](/blog/gdpr-ai-act-stacking-dach-saas/) 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 has two security problems most demos never face: the model can be manipulated through its inputs, and the index becomes a new place sensitive data lives. - **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 on the index.** The vector store is now a copy of your knowledge. It needs the same access controls as the source systems, not weaker ones because it is "just embeddings." - **Per-user document permissions.** This is the one that bites hardest. If a user can only see certain documents, retrieval must respect that on every query, so the assistant never surfaces a passage from a document that user was never allowed to read. A RAG system that ignores permissions is a data leak with a friendly chat interface. ## The checklist Run this before you let anyone rely on a RAG assistant. If any line makes you hesitate, that is the line to fix first. 1. **Retrieval.** Meaningful chunking, an embedding model tested on your content and languages, an eval set with measured recall, citations on every answer. 2. **Grounding.** Answers come only from retrieved context, the system refuses when unsure, sources are shown to the user. 3. **Repeatable evaluation.** A golden question and answer set that you re-run on every prompt, model, or index change. 4. **Cost and latency.** Caching, model tiering, and token budgets that you can defend at scale, not just in the demo. 5. **EU compliance.** Known data flows and residency, transparency that it is AI, deliberate PII handling, audit logging. 6. **Security.** Prompt injection tested, access control on the index, per-user permissions enforced on retrieval so nothing leaks across users. The deliverable is not a slideshow about RAG. It is a system that retrieves the right thing, refuses when it should, costs what you budgeted, and does not leak. Building exactly that is our [AI enablement service](/services/ai-enablement/) when the assistant runs on your own infrastructure, and [AI software development in Austria](/ai-software-development-austria/) when the retrieval layer sits inside a product you are shipping to customers. [Twinsoft AI](/case-studies/twinsoft-ai/) is the closest published example of a prototype pushed through this checklist and out the other side. ## Final thoughts A RAG demo is easy because it skips the parts that are hard: weak retrieval hides behind clean test documents, hallucinations hide behind questions you already know the answer to, and the cost, compliance, and permission problems do not show up until real people and real data arrive. None of that disappears. It just waits for production, when it is most expensive to discover. If you are an EU company moving a RAG assistant from a demo to something people rely on, work the checklist before you ship. The retrieval, grounding, and per-user permission lines are where trust is won or quietly lost, and they are far cheaper to get right before launch than to explain after an incident. ## You may also like.. [**RAG vs Fine-Tuning vs Long Context** When to retrieve, when to fine-tune, and when to just send a long context, and how to pick without burning a quarter on the wrong one.](/blog/rag-vs-finetune-vs-longcontext-2026/) [**Wavect vs Dotbite** A fair comparison of two Austrian software shops, and which one fits a founder-led AI build versus a Vienna custom-software project.](/compare/wavect-vs-dotbite/) ## Primary sources used in this checklist The checklist maps Wavect's production review method to these public risk, security, and lifecycle references. - [NIST Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) - [OWASP Top 10 for LLM Applications 2025](https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/) - [AWS Well-Architected ML design principles](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/design-principles.html) Agent engineering ## Continue through this cluster [Start with the cornerstone**Graph Engineering for AI Agents: When Does a Knowledge Graph Pay Off?**](/blog/graph-engineering-ai-agents/) - [Hark Handoff Review: The Agent That Actually Clicks](/blog/hark-handoff-computer-use-agent-review/) - [Meta Muse Code Pricing: Is the Contributor Tier Safe for Client Code?](/blog/meta-muse-code-pricing-contributor-tier/) - [PII Redaction Before LLM Prompts: A Practical Pipeline](/blog/pii-redaction-before-llm-prompts/) - [Agent Reach Review: Costs, Security and Real Limits](/blog/agent-reach-open-source-review/) - [Cloudflare Wallets for AI Agents: What Is Live?](/blog/cloudflare-wallets-ai-agents/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/team/christof-jori/) [Christof Jori](/team/christof-jori/) https://linkedin.com/company/wavect 8 min read · 08 Jun 2026 Last reviewed August 7, 2026 [**Next**](/blog/why-ai-agent-projects-get-cancelled/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/rag-production-readiness-checklist-eu/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/rag-production-readiness-checklist-eu/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "A RAG demo over your own documents is an afternoon of work; the hard part is everything after it, and in the EU the system also has to be defensible under GDPR and the AI Act without a cloud bill that quietly doubles. The checklist covers retrieval quality with a real evaluation set, grounding and refusal behavior, repeatable evals, cost and latency budgets, EU compliance, and security including prompt injection and per-user permissions on retrieval.", "articleBody": " Blog overview/AI and agents/Agent engineering RAG Production-Readiness Checklist for EU Companies TL;DR A RAG demo over your own documents is an afternoon of work; the hard part is everything after it, and in the EU the system also has to be defensible under GDPR and the AI Act without a cloud bill that quietly doubles. The checklist covers retrieval quality with a real evaluation set, grounding and refusal behavior, repeatable evals, cost and latency budgets, EU compliance, and security including prompt injection and per-user permissions on retrieval. A RAG demo over your own documents is one of the easiest wins in AI. Point a retriever at your wiki, wire it to a model, and you have something that answers questions in an afternoon. The hard part is everything after the demo. A demo that impresses a meeting is not the same as an assistant your employees or customers can rely on, and in the EU it has to be that and defensible under GDPR and the AI Act, without a cloud bill that quietly doubles every quarter. This is the checklist we work through before a RAG system goes from interesting to trusted. None of this is an argument against RAG. It is the cheapest way to give a model your knowledge without retraining anything. It is an argument for treating the demo as the start of the work, not the end of it. 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. Is the retrieval actually good enough? Everything downstream depends on the model getting the right passages. If retrieval is weak, no amount of prompt tuning saves you, because the model is answering from the wrong source or from nothing. This is the part demos skip, because on a handful of clean documents almost any setup looks fine. Chunking that respects meaning. Splitting on a fixed character count tears sentences and tables apart. Chunk on structure, headings, sections, logical units, so a retrieved passage is a complete thought. An embedding model that fits your content. The default is rarely the best for your domain or your languages. If you serve customers in German and English, test that retrieval works in both, not just the one you demoed in. 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. Citations returned with every answer. The system should hand back which documents it used. This is what makes answers checkable and, later, what makes the whole thing auditable. Will it make things up? A model with retrieval still hallucinates if you let it. The discipline of RAG is to keep the model on a short leash: answer from the retrieved context, and only from it. Answer only from retrieved context. Instruct the model to ground every claim in the passages it was given, and not to fill gaps from its general training. Refuse when the context is thin. If retrieval comes back empty or weak, the right answer is \"I do not have that,\" not a confident guess. A system that refuses well is more trustworthy than one that always answers. Show the sources. Surface the citations to the user. It lets them verify, and it changes behaviour: people trust a system more when they can see where the answer came from, and less blindly. \"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? The thing that quietly kills RAG projects is that every change feels like progress and nobody can prove it. You swap the embedding model, tweak a prompt, reindex, and the demo still works, so you ship it. Then a class of questions silently gets worse. Build a golden question and answer set: a fixed list of real questions with the answers and sources you expect. Re-run it on every change, a new prompt, a new model, a reindex, and compare. It does not need to be fancy. It needs to be the same every time, so a regression shows up as a number going down instead of a complaint three weeks later. What will it cost to run, and how fast is it? A RAG demo serving one person is free in all the ways that matter. A RAG assistant serving a company is a recurring bill that scales with usage, and latency that users feel on every query. Both are design decisions, not afterthoughts. Cache what repeats. Many questions are asked over and over. Caching retrieved context and frequent answers cuts both cost and latency. Tier your models. Not every query needs the largest model. Route simple questions to a smaller, cheaper one and reserve the big model for the hard cases. Budget your tokens. Stuffing twenty passages into every prompt is slow and expensive and often makes answers worse. Retrieve fewer, better passages. The", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "citation": [ { "@type": "WebPage", "name": "NIST Generative AI Profile", "url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf" }, { "@type": "WebPage", "name": "OWASP Top 10 for LLM Applications 2025", "url": "https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/" }, { "@type": "WebPage", "name": "AWS Well-Architected ML design principles", "url": "https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/design-principles.html" } ], "dateModified": "2026-08-07", "datePublished": "2026-06-08", "description": "A RAG demo over your own documents is an afternoon of work; the hard part is everything after it, and in the EU the system also has to be defensible under GDPR and the AI Act without a cloud bill that quietly doubles. The checklist covers retrieval quality with a real evaluation set, grounding and refusal behavior, repeatable evals, cost and latency budgets, EU compliance, and security including prompt injection and per-user permissions on retrieval.", "headline": "RAG Production-Readiness Checklist for EU Companies", "image": "https://wavect.io/img/blog/headers/header_rag-production-readiness-checklist-eu.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/rag-production-readiness-checklist-eu/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/rag-production-readiness-checklist-eu/", "wordCount": 1983 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/ai-agents/", "name": "AI and agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/agent-engineering/", "name": "Agent engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/rag-production-readiness-checklist-eu/", "name": "RAG Production-Readiness Checklist for EU Companies | ", "position": 5 } ] } ```