The EU AI Act and Knowledge-Base Assistants: What RAG Builders Need to Know
If your organisation builds or buys a retrieval-augmented generation (RAG) assistant that answers questions from your own documents, the EU AI Act may apply to you, even if you're based in the UK and simply serve EU customers or staff. Most document Q&A assistants sit in the lower risk tiers (transparency obligations, not the heavy high-risk regime), but the classification depends on what the assistant is used for, not on the fact that it uses retrieval. This article sets out, in plain terms, what's likely in scope, what's clearly excluded, and what you can do this quarter to prepare. It is not legal advice.
The EU AI Act in one paragraph
Regulation (EU) 2024/1689, generally known as the EU AI Act, entered into force on 1 August 2024 and is being phased in over several years: prohibited practices and AI literacy duties from 2 February 2025, governance rules and obligations for general-purpose AI models from 2 August 2025, and the bulk of the remaining provisions, including transparency rules and the high-risk regime for the systems listed in Annex III, from 2 August 2026 (with a further extension to 2 August 2027 for high-risk AI embedded as a safety component in certain regulated products). The Act is risk-based: it doesn't regulate 'RAG' or 'chatbots' as a category, it regulates what an AI system does and who it affects. A document search assistant that answers policy questions sits in a very different risk bracket to one that screens job applicants.
Does it apply to a UK organisation at all?
The Act has extraterritorial reach similar to UK GDPR. Article 2 brings in providers and deployers established outside the EU if the output of their AI system is used within the EU, or if they place the system on the EU market. In practice: a UK consultancy selling a knowledge-base assistant to clients in France or Germany, or an EU subsidiary of a UK group using an internal assistant, is very likely in scope for at least the transparency layer. A UK-only tool used solely by UK staff on UK data is not directly caught by the EU AI Act, though the UK's own regulators (the ICO on data protection, sector regulators on AI use within their remit) still apply. If you handle personal data in either case, treat the AI Act and UK GDPR as two separate checklists rather than one: see our UK GDPR and RAG checklist for the data protection side specifically.
Risk categories and where a RAG assistant usually sits
The Act sorts AI systems into four broad tiers. Understanding which one your assistant falls into is the single most useful exercise before any formal compliance work.
EU AI Act risk tiers
| Risk tier | Examples | Typical obligations |
|---|---|---|
| Unacceptable (prohibited) | Social scoring, manipulative subliminal techniques, most real-time biometric identification in public | Banned outright, with narrow exceptions |
| High-risk | AI used in recruitment, credit scoring, access to essential services, law enforcement, migration, medical devices, critical infrastructure | Risk management system, data governance, logging, human oversight, technical documentation, conformity assessment |
| Limited risk (transparency) | Chatbots, assistants that interact directly with people, content that could be mistaken for human-made | Disclose that people are interacting with AI; label AI-generated content in some cases |
| Minimal risk | Internal document search, spam filters, most productivity tools | No specific obligations beyond general law (GDPR, consumer law, etc.) |
Most internal knowledge-base assistants, the kind that answer 'what does our expenses policy say about mileage' or 'summarise clause 4.2 of this contract', fall into the minimal risk or limited risk tiers. They retrieve and present existing text; they don't autonomously decide who gets hired, who gets a loan, or who gets flagged to a regulator. The classification changes sharply once the assistant's output starts to materially influence a decision about a person in one of the Annex III categories.
Transparency obligations: what Article 50 actually asks for
Article 50 sets out transparency duties for AI systems that interact directly with natural persons. The core requirement is simple: people must be informed they are dealing with an AI system, unless this is obvious from the context. For a knowledge-base assistant embedded in a support portal or an internal intranet, this typically means a clear label ('AI assistant, answers generated from our documentation') rather than anything architecturally complex. A second strand covers AI-generated or manipulated content that could pass as human-made; for a document Q&A tool returning sourced answers to factual questions, this is rarely the binding constraint, but it's worth checking if your assistant also drafts customer-facing copy.
This is also where good RAG design and legal compliance happen to line up. An assistant that shows the passages it drew on, rather than presenting an answer as an opaque pronouncement, makes the 'you are talking to an AI, and here is where this came from' message self-evident. On Kopik, answers in grounded mode come back with cited source passages by default rather than as an unexplained block of text, which is useful both for user trust and for the kind of audit trail a compliance team will eventually ask for. If you want to go deeper on verifying those citations rather than trusting them blindly, see how to check an AI answer's citations and how RAG systems are evaluated for faithfulness.
When could a knowledge assistant tip into high-risk?
The Annex III list is specific: employment and worker management (including recruitment screening and decisions about promotion or termination), access to essential private and public services (including credit scoring), education and vocational training access, law enforcement, migration and border control, and administration of justice, among others. A knowledge-base assistant that simply explains an HR policy to staff, the kind of use case we cover in our piece on turning a staff handbook into a queryable knowledge base, is informational and sits well away from this list. The same underlying technology used to automatically shortlist or reject candidates based on their CVs would be a different product entirely, and squarely inside the high-risk category, with obligations around risk management, data governance, logging, human oversight and a conformity assessment before deployment.
Not legal advice
This article explains the general shape of the EU AI Act as it stands today and is not a substitute for advice from a qualified lawyer familiar with your specific use case, sector and the jurisdictions you operate in. Classification under the Act depends on facts (who uses the system, for what decision, with what consequences) that only you can assess properly.
What's clearly outside the Act's scope
It's worth being equally clear about what the Act does not reach, since over-engineering compliance for a low-risk internal tool wastes time better spent elsewhere.
- AI systems developed purely for research and not placed on the market or put into service.
- Systems used for a purely personal, non-professional activity.
- Military, defence and national security uses, which are outside the Act's scope entirely.
- Free and open-source AI components, with specific carve-outs removed for general-purpose models presenting systemic risk.
- Most retrieval tools that surface existing company documents for a human to read and decide on, as opposed to tools that make or substantially shape a decision about a person automatically.
It's also worth separating the AI Act from data protection law. Even a minimal-risk assistant that processes personal data (employee records, customer correspondence) still needs a lawful basis, a retention policy and appropriate security under UK GDPR; the AI Act and data protection law are complementary, not substitutes for one another. Our AI and LLM glossary is a useful reference if terms like 'general-purpose AI model' or 'deployer' versus 'provider' trip you up when reading the regulation itself.
Practical steps you can take now
You don't need a finished legal opinion to start reducing risk. A short internal exercise covers most of the ground.
- Map every AI-powered assistant in use, who built it, who queries it, and whether any EU users or EU market activity is involved.
- For each one, check it against the Annex III high-risk list: does its output influence a decision about employment, credit, essential services, or similar? If not, you're very likely in the limited or minimal risk tier.
- Add a visible, plain-language AI disclosure wherever the assistant interacts directly with people, even internally.
- Prefer grounded answers with visible source citations over free-form generation; it supports transparency obligations and makes faithfulness easier to check, as covered in faithfulness and citation metrics for RAG.
- Keep a log of questions and answers for traceability, particularly for any assistant touching HR, finance or customer complaints.
- Keep a human in the loop for anything that could be read as a decision about a person, rather than letting the assistant's output flow straight into an action.
- Review your data protection position separately using a checklist built for UK GDPR, since it covers ground the AI Act doesn't.
If you're setting up a new assistant, the access model you choose also matters for scope and exposure. A private knowledge base created at create a knowledge base, queried only by your own team through API keys, is a very different risk profile to a public assistant answering questions from anyone, listed in a catalogue like the Kopik base directory. Neither choice removes the need to classify the use case correctly, but a private, internal-only deployment with a clear audience is usually the simplest starting point while the 2026 obligations bed in.
Building with compliance in mind from day one
The practical lesson from the Act's structure is that transparency and traceability aren't bolted on afterwards easily if your assistant was built to hide its reasoning. Grounded answers with cited passages, query logs, and a clear boundary between 'the assistant explains policy' and 'the assistant decides an outcome' are good engineering practice regardless of regulation, and they happen to map closely onto what the Act asks for at the transparency tier. If you're exposing a knowledge base to other tools rather than a chat window, the same principle applies: an MCP server or REST API documented at the Kopik developer docs should return sources alongside answers so that whatever client consumes it (a support agent, an internal tool, an AI agent calling it through MCP) can show its working. For the broader question of why agents calling into a knowledge base need a source they can trust rather than a model's unverified memory, see why AI agents need reliable knowledge sources.
Build a grounded, citation-first knowledge base
Start with a private base for internal use, or publish one in the catalogue once you're ready. Answers come with sourced passages by default, which makes transparency and audit trails far easier to produce.
A short glossary of terms you'll meet
Reading the regulation itself, or summaries of it, is easier once a handful of terms are clear: 'provider' is whoever develops the AI system or has it developed and places it on the market; 'deployer' is whoever uses it under their own authority (most companies buying a RAG tool are deployers, not providers); 'general-purpose AI model' refers to the underlying foundation models, which carry their own separate obligations from the system built on top of them. If any of this terminology is new, our AI and LLM glossary for professionals covers the wider vocabulary you'll run into across AI Act commentary, vendor contracts and internal policy documents.
None of this replaces proper legal advice once you've identified a use case with any genuine ambiguity, particularly anything touching employment decisions, credit, or regulated services. But for the large majority of knowledge-base assistants, used to help people find and understand information that already exists in company documents, the realistic outcome is a transparency label and a sensible logging habit, not a conformity assessment.
Frequently asked questions
Does the EU AI Act apply to a UK company that doesn't sell into the EU?
If your assistant is used entirely within the UK, with no EU customers, EU staff or EU market activity, the EU AI Act doesn't directly apply, though UK data protection law and sector regulators still do. Once EU users or an EU subsidiary are involved, the Act's extraterritorial scope is likely to bring you in, at least at the transparency tier.
Is a RAG chatbot automatically classed as high-risk under the EU AI Act?
No. Most document Q&A assistants fall into the limited risk (transparency) or minimal risk tiers. High-risk classification depends on the use case, specifically whether the system's output materially influences decisions in areas like employment, credit, essential services or law enforcement, as listed in Annex III, not on the fact that it uses retrieval or a language model.
What transparency obligations apply to an AI assistant that answers questions from documents?
Under Article 50, people interacting with the assistant generally need to be told they're dealing with an AI system, unless this is already obvious. For most internal or customer-facing document assistants, a clear on-screen label is sufficient; there's no requirement to disclose the underlying model or vendor.
Does using retrieval-augmented generation reduce compliance risk compared to a plain chatbot?
RAG doesn't change your legal risk tier by itself, but grounding answers in cited source passages makes it much easier to demonstrate transparency, accuracy and traceability if you're ever asked to justify an answer, which is practically useful regardless of which obligations formally apply.
What happens if an organisation ignores the EU AI Act's requirements?
Penalties under the Act are tiered by severity, with the highest fines reserved for prohibited practices and serious high-risk non-compliance, and lower caps for breaches of transparency or other administrative obligations. Enforcement responsibility sits with national market surveillance authorities designated in each EU member state.
Do open-source or self-hosted models change the analysis?
The Act's obligations generally attach to the AI system and its use case, not to whether the underlying model is open-source or commercial. Open-source general-purpose models have specific carve-outs from some provider obligations, but a deployer building a high-risk application on top of an open-source model still carries deployer obligations.
Get the Kopik newsletter
New knowledge bases, RAG guides and product news. One email every week or two, unsubscribe in one click.
By subscribing you agree to receive our newsletter. We never share your address.