The EU AI Act and Knowledge-Base Assistants: What Actually Applies

Most knowledge-base assistants built on retrieval-augmented generation (RAG) fall into the EU AI Act's minimal or limited-risk category, which means a transparency notice rather than a full conformity assessment. But that isn't automatic: how the assistant is used, not just how it's built, determines the obligations. This article walks through the risk tiers, the cases where a document Q&A tool could tip into high-risk territory, and what the Act leaves entirely untouched.

What the EU AI Act Regulates, in Plain Terms

The EU AI Act is a product-safety-style regulation. Instead of banning AI outright, it sorts AI systems into risk tiers and attaches obligations to each tier. It applies to providers (the organization that builds or substantially modifies an AI system) and deployers (the organization that uses it to serve its own users or customers), and it has extraterritorial reach similar to the GDPR: if your assistant's output reaches people located in the EU, the Act can apply even if your company is based in the United States. If you need a refresher on how RAG assistants actually work before mapping obligations onto them, see What Is RAG (Retrieval-Augmented Generation)? A Practical Guide and the AI and LLM Glossary for Professionals for the vocabulary regulators and lawyers use.

The Four Risk Tiers, and Where RAG Assistants Usually Land

The Act sorts AI systems into four tiers. A knowledge-base assistant that answers questions from an internal handbook, a product manual, or a public FAQ almost always sits in the bottom two tiers, unless it is deployed inside one of the sensitive use cases listed in Annex III of the regulation.

When a Knowledge-Base Assistant Could Be Classified as High-Risk

The content being retrieved rarely drives the classification; the use case does. A help-desk bot answering questions from a return policy is low-risk. The same technology, pointed at resumes to help decide who gets an interview, is a different animal.

Annex III use cases to watch

• Employment: screening, shortlisting or evaluating candidates, or monitoring employee performance based on retrieved HR records.
• Access to essential services: assistants that help decide eligibility for credit, insurance pricing or public benefits.
• Education: tools that assess students or control access to educational institutions based on retrieved records.
• Law enforcement, migration and justice: assistants that support decisions in these domains, even indirectly.
• Critical infrastructure: safety components in energy, water or transport systems.

Deployer vs provider obligations

If you build the assistant yourself, you are the provider and carry the heaviest obligations in a high-risk scenario: a risk management system, technical documentation, logging capable of reconstructing how an answer was produced, and human oversight mechanisms. If you simply deploy a knowledge-base product that someone else built, you are usually a deployer with lighter but still real duties: using the system as intended, monitoring its outputs, and keeping records. Teams building assistants for HR, legal or compliance workflows specifically should read RAG for Legal, HR and Compliance Teams: Use Cases, Pitfalls and a Safe Rollout Plan before wiring a retrieval assistant into anything resembling an Annex III decision.

Transparency Obligations That Apply Almost Always (Article 50)

Even outside the high-risk tier, Article 50 of the Act imposes a baseline transparency duty on systems intended to interact directly with natural persons: people must be informed they are talking to an AI system, unless that is obvious from context. For a knowledge-base assistant this typically means a short, persistent notice near the chat interface (something as simple as "Answers are generated by AI from the documents in this knowledge base") and, where the assistant produces summaries or paraphrased text rather than verbatim quotes, a clear indication that the content is AI-generated.

This is also where good RAG design and legal compliance overlap. An assistant that cites the exact passages it used, rather than producing an unsourced paragraph, makes the "this is AI, and here is where it came from" disclosure much easier to satisfy honestly, and it gives users a way to verify the answer themselves. On Kopik, every answer in the default mode comes with cited passages from the source documents, which is also the practical habit described in Document Q&A With Citations: How to Check an AI Answer.

What the AI Act Does Not Cover

It's just as important to know the boundaries of the regulation, because a lot of what people assume falls under the AI Act actually belongs to other laws.

• Document storage and retention. The Act regulates the AI system's behavior, not how long you keep the underlying PDFs or who can access them. Data protection law (GDPR, and for US companies, state privacy statutes) governs that.
• Copyright in the source material. Using copyrighted documents to ground an assistant's answers raises copyright questions that the AI Act does not resolve; that sits with national copyright law and the EU's text-and-data-mining exceptions.
• General-purpose model obligations. If you build a RAG assistant on top of a third-party language model, the heavier transparency and documentation duties for general-purpose AI models fall on the model provider, not on you, in most cases.
• Purely internal R&D and testing. Systems not yet placed on the market or put into service for real users are generally outside scope until deployment.
• Personal data handling specifics. The Act doesn't replace GDPR's rules on lawful basis, data minimization or cross-border transfer; those still apply in full to whatever documents you index. See GDPR and RAG: What to Check Before You Put Documents Into a Knowledge Base for that separate checklist.

A Practical Compliance Checklist for RAG Assistants

1. Inventory every assistant in use across the company, including ones built by individual teams without central IT involvement (so-called shadow AI).
2. For each one, write down who uses it, what decisions (if any) its answers feed into, and whether any Annex III use case is even loosely involved.
3. Classify each assistant into a risk tier and document the reasoning, even for the minimal-risk ones; a one-paragraph justification is enough and saves time if a regulator or a customer later asks.
4. Add a visible AI-disclosure notice to any assistant that talks directly to employees, customers or the public.
5. Prefer architectures that cite sources rather than freely paraphrase, so users and auditors can trace every answer back to a document. See How to Evaluate a RAG System: Retrieval Metrics, Faithfulness and Citation Accuracy for how to measure this.
6. Keep logs of queries and answers for high-traffic or high-stakes assistants, with retention periods aligned to your data protection policy rather than kept indefinitely by default.
7. Review vendor contracts for AI tools to confirm who holds provider obligations and who holds deployer obligations; this is often unclear in off-the-shelf SaaS agreements.
8. Revisit the classification whenever the assistant's scope changes, for example when an internal FAQ tool gets repurposed to help screen job applicants.

None of this requires a new engineering team. Most of the checklist above is documentation and interface work layered on top of a retrieval pipeline you may already have, or could build in an afternoon. Kopik lets you create a knowledge base from PDFs, Word files or Markdown, choose between a cited-answer mode and a raw-passages-only mode, and keep the base private so only your own API keys can query it, which simplifies both the transparency notice and the data-governance side of the analysis above.

Keeping This Current

The AI Act's obligations phase in over several years: prohibited practices became applicable in February 2025, obligations for general-purpose AI model providers in August 2025, and most high-risk system requirements in August 2026, with an extended transition to August 2027 for high-risk AI embedded as a safety component in products already regulated under other EU product-safety law. If your assistant touches any Annex III use case, confirm the current applicability date for your specific category before assuming you have more runway than you actually do.