Nobody Told Legal About Your RAG Pipeline — And That's a Problem

The Scene Playing Out Across Europe Right Now

An AI team at a mid-sized financial services firm spends three months building a RAG pipeline. It indexes internal contracts, policy documents, and client correspondence. The system works well — response times are fast, the answers are accurate. The team demos it to senior leadership. Leadership is impressed. The rollout begins.

Nobody told legal.

Six months later, a regulator asks the company to demonstrate what AI systems it operates that process personal data. The legal team is handed a list that includes a system they have never heard of, running on infrastructure they have never reviewed, sending data to a cloud LLM provider that no Data Processing Agreement covers.

This scenario is not hypothetical. According to InformationWeek's 2026 analysis of enterprise AI deployments, it is the most common governance failure pattern in enterprise RAG rollouts today.

Why It Keeps Happening

RAG systems are built by engineering teams optimising for retrieval performance, answer quality, and user experience. Data governance is optimised for defensibility, documentation, and legal accountability. These two teams rarely share a vocabulary, and they almost never share a gate.

The result: AI systems that work technically and fail legally. Not because anyone made a bad decision, but because nobody made the decision at all.

The problem is structural. RAG pipelines sit at the intersection of three organisational functions — IT, information governance, and legal — but they are almost always built inside a fourth: the AI team. Which means the people accountable for data protection obligations are the last to know the system exists.

What Legal Doesn't Know — But Needs To

When a document enters a RAG pipeline, it goes through a series of transformations that have significant legal implications:

Ingestion and chunking. The document is split into fragments, typically 200–500 words each. At this stage, metadata — who created the document, what classification it carries, whether it's subject to a legal hold — is frequently stripped or not carried forward.

Embedding. Each chunk is converted into a vector representation by an embedding model. This model may be local, or it may be a cloud API. If it's a cloud API, the document content has already left your network before retrieval even begins. Most legal teams don't know this step exists.

Storage. The vectors are stored in a vector database. If this database is cloud-hosted, your document content — in a form that can be reconstructed — lives on third-party infrastructure indefinitely, unless explicit deletion is implemented.

Retrieval and inference. When a user asks a question, the system retrieves relevant chunks and sends them to a language model. If the language model is cloud-hosted, those chunks — which may contain personal data, confidential business information, or legally privileged content — transit a third-party API on every single query.

Each of these steps creates obligations under GDPR. Almost none of them are visible to the teams responsible for meeting those obligations.

The Three Risks That Surface Unexpectedly

1. The Deletion Request You Can't Fulfil

Under GDPR Article 17, individuals have the right to erasure. When an employee leaves, a client terminates a relationship, or a data subject exercises this right, you must be able to delete their personal data from your systems.

In a traditional document management system, deletion is straightforward. In a RAG pipeline, it is not. The personal data exists in at least three places: the original document, the chunks stored in the vector database, and potentially the inference logs from every query that retrieved those chunks. Deletion requires coordinated action across all of them — and most RAG systems have no mechanism for this.

If the pipeline used a cloud embedding API, the data may also exist in the provider's own logs. Whether those logs are retained, and for how long, depends on terms your legal team has never read.

2. The Audit Trail That Doesn't Exist

Regulators increasingly expect organisations to explain not just what AI systems they operate, but how a specific output was produced. Which documents informed a particular answer? Which version of those documents? Were they the most current versions available at the time?

Standard RAG architectures don't store this information. The retrieval happens, the chunks are passed to the model, the answer is generated, and the context is discarded. There is no trail connecting output to source to document owner.

Under the EU AI Act — fully enforceable from August 2026 — AI systems that make or support consequential decisions must be able to provide this kind of explanation. "We don't know exactly which documents informed that output" is not a compliant answer.

3. The Data Processing Agreement That Was Never Signed

If your RAG pipeline routes data through a cloud LLM provider, that provider is a data processor under GDPR. A Data Processing Agreement is mandatory. It must specify what data is processed, for what purpose, under what retention terms, and with what sub-processors.

Most organisations using cloud-hosted AI APIs signed a standard developer agreement. That is not a DPA. The distinction matters: without a valid DPA, the data transfer is unlawful regardless of whether anything bad actually happened with the data.

The EU AI Act reinforces this. Deployers — the companies using AI systems, not just the companies building them — now carry documentation obligations. If your vendor doesn't have a DPA in place, the regulatory exposure is yours, not theirs.

The Meeting You Need to Have

The conversation between your AI team and your legal team shouldn't wait for an audit trigger. It should happen before a RAG system goes into production, and it should cover a short list of specific questions:

What data does this system ingest, and does it include personal data? Most enterprise document sets do. Contracts contain client names. HR policies contain employee information. Meeting notes contain both.

Where does data go after ingestion — and who is responsible for each step? Map the full pipeline: embedding model, vector database, retrieval system, LLM API. Identify who hosts each component and what agreements govern each relationship.

Can we fulfil a deletion request? If someone's personal data is in the pipeline today, describe the steps required to remove it completely. If you can't answer that question, you have a compliance gap.

What does our audit trail look like? If a regulator asks what document informed a specific AI output six months from now, what can you show them?

Have we done a DPIA? Under GDPR, a Data Protection Impact Assessment is required for processing that is "likely to result in a high risk" — which AI processing of personal data at scale almost certainly qualifies as.

None of these questions are hostile. They're the minimum a legal team needs to assess whether a system can run safely.

How Architecture Changes the Conversation

The reason this conversation is so difficult for most organisations is that the answers depend entirely on where the data goes — and in cloud-dependent RAG pipelines, the honest answer is often: we don't fully know.

An on-premise RAG architecture changes this fundamentally. When the embedding model, vector database, and retrieval engine all run inside your own infrastructure, the answers become simple:

• Data doesn't leave the network. There are no third-party processors to identify.
• Deletion is a database operation under your control.
• The audit trail is in your own logs.
• There is no cloud API to sign a DPA with.

This doesn't remove all obligations — you're still responsible for securing the system, managing access, and documenting your processing. But it removes the class of problems that arise from not knowing what your vendor does with your data, because your vendor doesn't have your data.

For organisations in regulated industries — financial services, healthcare, legal, pharmaceuticals — this isn't a nice-to-have. It's the difference between a system that can go into production and one that can't.

The Practical Step

If your organisation already has a RAG system running, or is evaluating one, the governance conversation is worth having now rather than later. The questions above are a starting point. The goal isn't to stop AI projects — it's to make sure the people accountable for legal and data protection have the information they need to do their job.

If they don't know the pipeline exists, they can't do that. And when the audit comes — and in 2026, it increasingly will — that gap becomes your organisation's problem, not your AI team's.

---

KADARAG's on-premise architecture keeps all document processing — embedding, retrieval, and inference — inside your own infrastructure. Legal teams get a clean answer to every data governance question. Schedule a demo to see how it works.