RAG and the EU AI Act: when a RAG system is high-risk AI

Planning a RAG system and unsure what the AI Act requires? WZ-IT builds RAG systems with source citations, permission checks and traceable logging, as a RAG Proof of Value or as an internal assistant on your own infrastructure, see AI solutions. Book a meeting

Anyone planning a RAG knowledge base soon runs into the question of whether the system falls under the high-risk rules of the EU AI Act. The short answer: in most cases, it does not. An assistant that searches manuals, policies, contracts or procedural instructions and answers with a reference is an AI system with transparency obligations under Regulation (EU) 2024/1689, but not a high-risk system.

The long answer depends on three points that most write-ups leave out: classification follows the intended purpose, not the technology; a general assistant can become high-risk through the way it is used; and whoever builds a RAG system is its provider. This article classifies RAG against Article 6, Annex III and Article 25, lists the deadlines after the Digital Omnibus and shows which logging and source citations make sense.

All information is based on the text of the regulation and documents from the Council and the Commission, as of September 2026. The article describes the technical implementation and is not legal advice.

Table of contents

1. The short answer in one table
2. A RAG system is an AI system, not a new AI model
3. The intended purpose decides, not the technology
4. Annex III: where RAG becomes a high-risk system
5. The exception under Article 6(3)
6. Provider or deployer of your own RAG system
7. Deadlines after the Digital Omnibus
8. What already applies to every RAG system
9. Logging and source citations
10. A checklist for RAG projects
11. Our approach at WZ-IT
12. Further guides

The short answer in one table

The areas come from Annex III of the AI Act. Where an Annex III area is involved, the exception under Article 6(3) may apply; see below.

A RAG system is an AI system, not a new AI model

RAG (retrieval-augmented generation) combines a search over your own documents with a language model that writes an answer from the retrieved passages. The technical side is explained in What is RAG.

The AI Act distinguishes two concepts that matter here:

Under Article 3(1), an AI system is a machine-based system that infers from its input how to generate outputs such as content, recommendations or decisions. A RAG system that generates answers with a language model meets this definition. A plain full-text search without a generative model is a different case; the Commission guidelines on the AI system definition set out the criteria.

RAG does not make you a model provider. The GPAI obligations in Chapter V apply to the developer of the model. RAG does not change the model weights; it only adds context to the query. According to the Commission guidelines for GPAI providers, a downstream actor becomes a model provider only if it modifies a model using more than one third of the original training compute. That concerns extensive retraining, not RAG.

The intended purpose decides, not the technology

Article 6 provides two routes to high-risk classification:

• Paragraph 1: the AI system is a safety component of a product under Annex I, or is itself such a product, for example in medical devices or machinery, and the product requires a third-party conformity assessment.
• Paragraph 2: the AI system is listed in Annex III.

For RAG knowledge bases, only paragraph 2 is relevant in practice. Annex III does not describe technologies but intended purposes: systems "intended to be used" for one of the listed tasks. What counts is the intended purpose under Article 3(12), meaning the use specified by the provider in the instructions for use, promotional materials and technical documentation.

It follows that the same RAG system, with the same model and the same index, can be non-high-risk in one setting and high-risk in another. An assistant that explains HR policies is uncritical. The same assistant matching applications against a job profile and producing a ranking falls under point 4 of Annex III.

Annex III: where RAG becomes a high-risk system

Annex III covers eight areas. For RAG systems, these uses are the most relevant:

The remaining areas (biometrics, critical infrastructure, law enforcement) rarely concern RAG knowledge bases but should be checked by authorities with security tasks.

Two misconceptions that come up often:

1. "Public administration is high-risk." Annex III does not list administration in general. A RAG system that caseworkers use to search decrees, technical reports and procedural instructions is not a high-risk system. It is different if the system is intended to evaluate a person's eligibility for a benefit. How a public authority builds a RAG knowledge base is covered in RAG knowledge base in the public sector.
2. "Legal research is high-risk." Point 8(a) covers systems used by or on behalf of a judicial authority, as well as alternative dispute resolution. A RAG system for a company's legal department or for a law firm does not fall under this wording.

The underestimated case is the open assistant. A chat assistant over the entire document base can be used for any purpose. If someone uses it specifically for an Annex III purpose, Article 25(1)(c) applies: anyone who modifies the intended purpose of a system not classified as high-risk, including a general-purpose AI system, so that it becomes high-risk, is considered the provider of a high-risk system. A usage policy that excludes such purposes, and a permission structure that keeps personnel files out of the general index, are therefore part of the classification. How permissions are enforced in a RAG system is explained in RAG permissions.

The exception under Article 6(3)

Not every system in an Annex III area is high-risk. Under Article 6(3), such a system is not considered high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights and does not materially influence the outcome of decision-making. This is the case where one of the following conditions is met:

The examples are orientation aids, not binding classifications. Two limits always apply:

• Profiling stays high-risk. If the system performs profiling of natural persons, it is a high-risk system regardless of the conditions.
• The assessment must be documented. Under Article 6(4), the provider documents its assessment before putting the system into service and provides it to authorities on request. It also registers the system in the EU database under Article 49(2). The Digital Omnibus reduced the information required but kept the registration (recital 22 of the Omnibus text).

Under Article 6(5), the Commission was to provide guidelines with practical examples by 2 February 2026. On 19 May 2026 it published draft guidelines on high-risk classification; the consultation ran until 23 July 2026. As of September 2026, no final version has been adopted.

Provider or deployer of your own RAG system

The role determines which obligations apply. The definitions in Article 3:

• Provider (point 3) is whoever develops an AI system or has it developed and places it on the market or puts it into service under its own name, whether for payment or free of charge.
• Deployer (point 4) is whoever uses an AI system under its authority, except in the course of a personal non-professional activity.
• Putting into service (point 11) explicitly includes supply "for own use".

For RAG, this means:

For an internal RAG system, being the provider is the normal case. For a system that is not high-risk, it means limited obligations: the notice under Article 50(1) and, where applicable, the marking under paragraph 2. How the role affects labelling is covered in AI labelling obligation under Article 50. An overview of all roles and risk levels is given in EU AI Act for companies.

The Omnibus adds a more specific duty to cooperate along the value chain: if a system becomes the high-risk system of a new provider under Article 25(1), the initial provider must, among other things, make technical documentation available and inform the new provider about known limitations and failure modes, unless it has clearly excluded such a change of purpose.

Deadlines after the Digital Omnibus

The legislative procedure is complete:

Sources: Council note of 22 June 2026, Regulation (EU) 2026/1744 on EUR-Lex.

The application dates relevant to RAG systems under the amended Articles 113 and 111:

The Commission's AI Act Service Desk confirms these dates. For high-risk systems put into service before 2 December 2027, the amended Article 111(2) applies: the regulation applies only once they undergo significant changes in their design, but systems intended for use by public authorities must comply by 2 August 2030. The path to the postponement and the high-risk obligations in detail are covered in EU AI Act: high-risk obligations postponed to December 2027.

What already applies to every RAG system

Regardless of the high-risk question, three rules of the AI Act apply to every RAG system used in a professional context:

AI literacy (Article 4). Since 2 February 2025, providers and deployers must take measures on the AI literacy of their staff. The Omnibus rewrote Article 4: providers and deployers must take measures to support the development of AI literacy of their staff, and the obligation expressly does not require them to guarantee any specific level of AI literacy of any individual (Omnibus text, point 5). The obligation therefore remains. For a RAG system, this includes making sure users know that answers are generated from retrieved passages, can be wrong and should be checked against the source.

Transparency (Article 50). Since 2 August 2026, a system that interacts directly with people must be designed so that they know they are communicating with an AI. This includes internal assistants. The obligation falls on the provider, which for your own RAG system means you. Infringements of Article 50 can be fined under Article 99(4) with up to EUR 15 million or 3 % of worldwide annual turnover; for SMEs the lower amount applies.

Prohibited practices (Article 5). Rarely relevant to knowledge bases. Article 5 becomes relevant if a system is meant to recognise emotions in the workplace, which is prohibited.

In addition, the GDPR applies, and where employee data is processed, co-determination rights of works councils. The AI Act does not regulate whether a RAG system may process personal data.

Logging and source citations

Under the AI Act, logging is mandatory only for high-risk systems:

For a RAG system that is not high-risk, the AI Act imposes no logging obligation, and it contains no obligation to cite sources at all. Both are nevertheless at the core of a reliable RAG operation, for three reasons:

1. Demonstrating the classification. Anyone relying on Article 6(3), or arguing that an assistant is not used for Annex III purposes, needs data on actual use.
2. Making answers verifiable. Source citations are the mechanism by which a person checks a RAG answer. For high-risk systems, human oversight under Article 14 is mandatory, and oversight without a reference is hardly possible.
3. A later move into Annex III. If the system is extended and falls under Annex III from 2 December 2027, logging must already be in place.

Compared with a plain chat, RAG needs additional fields so that an answer can be reconstructed later:

Retention periods and the handling of personal data in logs follow the GDPR. Pseudonymised user IDs and a defined deletion period are the usual approach. A self-hosted solution for this is described in LLM observability with Langfuse. How to measure the quality of answers and retrieved passages is explained in RAG evaluation.

A checklist for RAG projects

Classifying a RAG project comes down to five questions. The result belongs in the project documentation.

If the answer to question 3 is clearly outside Annex III, the RAG system is not a high-risk system. If it remains open because the assistant is available for any purpose, restricting data sources, user group and purpose is more effective than retrofitting high-risk documentation. Legally uncertain cases should have steps 3 and 4 clarified with legal counsel.

Our approach at WZ-IT

We build RAG systems so that their classification under the AI Act can be read from the architecture. The legal assessment stays with your legal counsel; we provide the technical basis for it.

1. Define the intended purpose. Knowledge domain, user group and excluded purposes are documented before the build. The RAG Proof of Value starts with a scoped knowledge base and agreed reference questions.
2. Permissions before retrieval. The index inherits the permissions of the source systems, so personnel or case files do not surface in the general assistant.
3. Sources in every answer. Answers show document, passage and version, as with the Knowledge Navigator. What is not in the knowledge base is not answered.
4. Logging and measurement. Queries, retrieved passages, document versions and model versions are stored traceably, for example with Langfuse, and answer quality is measured against reference questions.
5. Operation under your control. Model and index run on your own hardware with the AI Cube or on a managed GPU server from WZ-IT with an NVIDIA RTX PRO 4000 Blackwell (24 GB) or RTX PRO 6000 Blackwell (96 GB). Support, consulting and implementation by WZ-IT.

Further guides

• EU AI Act: high-risk obligations postponed to December 2027, the high-risk obligations in detail.
• AI labelling obligation under Article 50, notice and marking depending on your role.
• RAG knowledge base in the public sector, building and running it in public administration.
• European LLM APIs compared, model access without US providers.
• RAG evaluation, reference questions and metrics for acceptance.
• RAG permissions, how permissions are enforced in retrieval.
• AI solutions at WZ-IT, overview of services and operating models.

Building a RAG system with a traceable classification? We define intended purpose, permissions, source display and logging, and run the system on your hardware or on a managed GPU server from WZ-IT. Book a meeting

Sources

• Regulation (EU) 2024/1689 (AI Act) on EUR-Lex
• Regulation (EU) 2026/1744 (Digital Omnibus on AI) on EUR-Lex
• Council of the EU, PE-CONS 30/26: text of the Digital Omnibus on AI
• Council of the EU, note 10752/26 on adoption of the Digital Omnibus
• AI Act Service Desk: Annex III
• AI Act Service Desk: Article 3, definitions
• AI Act Service Desk: Article 6, classification rules for high-risk AI systems
• AI Act Service Desk: Article 25, responsibilities along the AI value chain
• AI Act Service Desk: Article 26, obligations of deployers
• AI Act Service Desk: Article 86, right to explanation
• AI Act Service Desk: FAQ including the Digital Omnibus
• European Commission: draft guidelines on high-risk classification
• European Commission: guidelines for providers of GPAI models
• European Commission: guidelines on the AI system definition