Is a RAG system subject to the EU AI Act?

Three attachment points decide almost every practical question. The first is whether what you have is an AI system as the Regulation defines it — a machine-based system that infers, from input, how to generate outputs such as predictions, content or recommendations. A retrieval pipeline whose last step is a language model producing text sits inside that definition without much argument.

The second is intended purpose. The obligations that bite hardest are reserved for uses listed as high-risk, and those are described by what the system decides about people — access to employment, creditworthiness, essential services, and similar — or by its role as a safety component in a regulated product. An assistant that answers “which version of this circular is in force” for a professional who then decides is a very different object from one that scores an applicant, even if the code is nearly identical.

The third is role. Provider and deployer carry different duties, and an organisation frequently occupies both at once: provider of the assistant it built, deployer of that assistant in its own operations, and customer of a general-purpose model provider upstream. Roles can also shift — putting your name on a system, or changing its intended purpose, can make you its provider.

For the non-high-risk case, which is most internal knowledge assistants, the practical requirements are lighter than the discourse suggests but they are not zero. Transparency obligations apply where people interact with an AI system or where content is generated — a user should not have to guess. AI literacy expectations apply to the people operating it. And nothing in the Act displaces the GDPR: if personal data is in the index, it is a processing operation with a lawful basis, a retention period and a data subject who has rights over it.

For the high-risk case the architecture is the compliance work. Risk management, data governance over training and input data, technical documentation, logging, human oversight and post-market monitoring are all properties a system either has by construction or does not have at all. Retrofitting an audit log onto a system that was not built to keep one is, in practice, a rebuild — which is why the classification question belongs at the start of a project rather than at the end of it.

Retrieval changes where the risk sits. A model that hallucinates is a familiar problem; a retrieval layer that confidently returns a superseded document is a worse one, because the output is well-formed, sourced, and wrong in a way that looks right. Systems in regulated environments therefore have to be able to state not just what they answered but which version of which document the answer stood on, and whether that version was in force on the date of the question.

The second RAG-specific point is the index itself. Whatever the classification, an index built from documents nobody filtered is a data protection problem before it is an AI problem. The cheapest control in this entire field is excluding personal data at ingestion rather than trying to suppress it at answer time — it is the design decision behind the Federfarma deployment, where personal data is never indexed at all.

The third is model substitution. If the generation step is an external endpoint, a change of model behind it changes the behaviour of your system. Whatever your classification, you need to know which model answered, when, and with what configuration — which is an architectural requirement long before it is a regulatory one.

It does not tell you your classification. That depends on the intended purpose you actually declare, the sector you operate in, the deployment context and, for some sectors, product legislation that sits alongside the AI Act. It is established through the procedures the Regulation sets out, not by a consultant's opinion and not by a deployment topology.

What is worth saying plainly: nobody can certify your compliance in a sentence, and a supplier who offers to is telling you something about the supplier. The deliverable that has value is a signed statement of what you have, what you are missing and in what order to close the gap — with the architecture described precisely enough that your lawyers can work from it.