Each time you ask a question, the product goes back to the store, picks a few passages, and hands them to the model. This issue follows one question around that loop, stop by stop, and explains why the law treats every pass as processing in its own right.

Where we've been - Part 1 — It predicts the next word. That is the whole machine. A language model guesses the next word, then does it again. There is no step in that loop where it consults a source. → https://buttondown.com/the_desk/archive/it-predicts-the-next-word-that-is-the-whole/ - Part 2 — Where your draft actually goes. Which account you were logged into decides whether your text is used for training, and whether any processor relationship exists at all. → https://buttondown.com/the_desk/archive/where-your-draft-actually-goes/ - Part 3 — What "delete" actually deletes. The conversation, the product's notes about you, and your files are separate records, each with its own delete button. → https://buttondown.com/the_desk/archive/what-delete-actually-deletes/ - Part 4 — Your document, as a list of numbers. When a product "reads" a document, it cuts it into pieces, turns each piece into a list of numbers, and stores the pieces and the numbers together. → https://buttondown.com/the_desk/archive/your-document-as-a-list-of-numbers/

This issue assumes you know nothing about how these systems work. Every term is explained before it is used.

Start here

A firm has spent a year loading its old files into an AI product: advice notes, contracts, pleadings, and the correspondence around them. On Monday a junior lawyer asks it a question: have we ever advised a contractor on delay caused by late access to the site?

The answer is fluent. Under it sit three passages the product says it relied on. Two come from old precedents. The third comes from an advice note written for a different client, in a dispute the junior was never staffed on. It names the site manager who was dismissed over the delay.

Nobody uploaded anything on Monday. Nothing was trained. The files had been in the product for months. So what happened on Monday?

A search happened. The product took the question, turned it into a search of everything the firm had loaded, picked a handful of passages, and handed them to the model along with the question. On Tuesday, when someone else asks something else, it will do all of that again from the beginning.

That loop is called retrieval-augmented generation, usually shortened to RAG. Part 4 described what is kept. This issue describes what is done with it: one question, followed around the loop, stop by stop.

The lawyer's question comes near the end. When those files were opened, each client was told what its information was for. Every time the product goes back to the store, it is using that information again. Is it still using it for the thing the client was told?

What Part 4 left open

Part 4 ended with eight steps and one sentence about them: steps 5 to 8 "happen every time you ask." It then treated those four steps as simple. You ask, it matches, it pastes, the model answers. The vendors' own documentation shows that more happens in between, and each extra step is a place where your question, or your client's document, goes somewhere.

Three terms carry over.

THE MODEL is the next-word predictor from Part 1. It keeps nothing between turns. Part 1 said of the model's own loop that there is no step in it where it consults a source.

THE CONTEXT WINDOW is the text the model is given for a single reply, and the only thing it can see.

THE STORE is what Part 4 described: your documents, cut into pieces called chunks, each chunk filed next to a list of numbers that stands for its meaning.

Retrieval-augmented generation is the arrangement that adds the missing step. It does not change the model. It puts a search in front of it.

The name, and the idea behind it

The name comes from a 2020 research paper by a team at Facebook AI Research, University College London and New York University. They described "models which combine pre-trained parametric and non-parametric memory for language generation."

Those two phrases are the whole design.

Parametric memory is whatever the model absorbed in training. Part 1 called the billions of numbers adjusted during training the model's parameters. Whatever the model "knows" is held there, and nowhere you can point to.

Non-parametric memory is a store of text that sits outside the model and can be searched. In the paper's words: "We refer to the document index as the non-parametric memory."

The authors had two reasons for building it this way, and both matter to a lawyer. For a model that relies on training alone, they wrote, "providing provenance for their decisions and updating their world knowledge remain open research problems." An outside store answers both. It can show where an answer came from, and it can be changed. Their store, they said, is "(i) human-readable, lending a form of interpretability to our model, and (ii) human-writable, enabling us to dynamically update the model’s memory by editing the document index."

That second property is why Part 4 could say that an entry in the store can be found and deleted, while what a model learned in training cannot easily be. It has a consequence the paper did not need to spell out. If the knowledge lives outside the model, the model has to be handed it. Every time.

One caution about the paper. The 2020 system also trained its search component and its model together. Most products today do not. They search, paste and generate. The name stayed.

One question, six stops

What follows is the order of events when you press Enter, as the vendors and one regulator describe it. Not every product makes every stop. Each stop is documented by at least one of them.

Stop 1. The question is rewritten

The text you typed is not always the text that is searched. OpenAI's developer documentation offers builders "a setting to automatically rewrite your queries for optimal performance", and shows what that looks like:

The trade word for the text that is actually sent to the search is the query. On that platform the rewriting is something the builder switches on, and the rewritten version is recorded: "The rewritten query will be available in the result’s search_query field."

In many products the model itself decides whether to search at all. OpenAI's documentation describes what is returned "When this tool is called by the model". Claude's help centre tells users of its projects feature: "you'll see Claude using a project knowledge search tool when it needs to find relevant information from your uploaded content." (A tool, here, is a function the product lets the model trigger. A later part of this series is about them.)

So the first thing that happens to your question is that the product decides what your question is.

Stop 2. The question becomes numbers

Part 4 explained that each chunk is turned into a list of numbers, called an embedding. The same now happens to the question. Google's documentation: "When you make a query, it's also converted into an embedding." Germany's data protection authorities describe the same step: "wird auch die Eingabe mit Hilfe desselben Embedding-Models in einen Anfragevektor überführt", that is, the input too is converted into a query vector by the same embedding model.

So your question is sent to the embedding model, and the embedding model need not belong to the company whose model writes the answer. Anthropic's documentation says so of itself: "Anthropic does not offer its own embedding model."

A question put to a firm's documents is rarely neutral. What did we tell the hospital about the consultant's dismissal? names a client, a matter and a person. That sentence has now been processed by a second system.

Stop 3. The filter

Before the search runs, the product can narrow what is searched. The labels it uses are called metadata: facts attached to each file, such as its date, its author, the matter it belongs to, or who is allowed to see it. OpenAI says filters let a builder "target files based on their attributes before performing semantic search." Google says metadata is "useful when you have multiple documents in a File Search store and want to search only a subset of them."

This is also where access rights are enforced, if they are enforced anywhere. Microsoft says of its workplace assistant: "Microsoft Copilot only surfaces organizational data to which individual users have at least view permissions." Its index, it says, "only surfaces the results to a user if the user already has access to the content controlled by role-based access control."

There is a reason the wall has to stand here and not further on. The German authorities put it plainly:

"Im Vergleich dazu kann im Sprachmodell (LLM) selber nicht gesteuert werden, auf welche Informationen bestimmte Nutzer Zugriff haben dürfen und auf welche Informationen kein Zugriff bestehen darf." — By comparison, it cannot be controlled within the language model itself which information particular users may have access to and which they may not.

Once a passage is in the context window, the model will use it. It has no idea who is asking.

And the filter can only enforce the permissions it is given. Microsoft again: "It's important to note that indexing data doesn't change access permissions to content". A folder that was shared too widely five years ago has been protected, until now, mostly by the fact that nobody knew to look in it. A search by meaning finds it. Microsoft's own word for the underlying problem is "oversharing". The European Data Protection Supervisor describes the same effect: "RAG should be seen as a mechanism that allows users to retrieve information from systems where access is normally restricted, and where sensitive data could be inadvertently exposed, whether by accident or deliberate action."

Stop 4. The search and the shortlist

Now the search itself, which Part 4 covered: the store returns the chunks whose numbers sit closest to the question's. OpenAI's file search works "through semantic and keyword search", by meaning and by matching words.

What Part 4 did not say is how few passages survive. On OpenAI's retrieval service, "A response will contain 10 results maximum by default, but you can set up to 50". A builder can also set a minimum score, and OpenAI is candid about the cost: a higher threshold "will limit the results to more relevant chunks, though it may exclude some potentially useful ones."

Many systems then add a second pass. A reranker is another model whose only job is to read each candidate passage beside the question and give it a score. Anthropic's engineers describe the steps: "Perform initial retrieval to get the top potentially relevant chunks (we used the top 150)", then "give each chunk a score based on its relevance and importance to the prompt, then select the top-K chunks (we used the top 20)". Those numbers are from their own tests, not a product setting. They add: "There are several reranking models on the market. We ran our tests with the Cohere reranker."

Count the models. One turned the question into numbers. One scored the candidates. One will write the answer. A single question can pass through three models, and nothing requires that one company run all three.

Stop 5. The paste

The passages that survive are added to the question. Anthropic: "Add the top-K chunks to the prompt to generate the response." Microsoft numbers the steps of its own sequence, and the third is: "Copilot sends the modified prompt to the Large Language Model (3)". The German guidance calls the result the erweiterte Anfrage, the augmented request. This is the "augmented" in the name.

This is the moment your client's words reach the model. It is also the moment they are copied a third time. Part 4 counted two copies: the file, and the chunks in the store. The augmented request is a third, and it is kept under the rules for conversations, not the rules for the store.

Microsoft says so in terms: "the information contained within your prompts, the data they retrieve, and the generated responses are processed and stored". The stored record "includes the user's prompt and Copilot's response, including citations to any information used to ground Copilot's response."

OpenAI's developer platform says that "the Responses API has a 30 day Application State retention period by default" (the Responses API is its main interface for building these products), and that its abuse monitoring logs "may contain certain customer content, such as prompts and responses", and are "retained for up to 30 days". OpenAI's page does not say in terms that retrieved passages are logged. It says prompts are. In a retrieval answer, the passages are part of the prompt.

Stop 6. The answer, and the citations under it

The model writes its answer from the augmented request. Many products then show which passages were used. OpenAI's file search returns the model's reply "along with the file citations." Google says a response "may include citations that specify which parts of your uploaded documents were used to generate the answer. This helps with fact-checking and verification."

Two details. First, a citation is not the same as being shown what the search found. OpenAI: "While you can see annotations (references to files) in the output text, the file search call will not return search results by default." The builder has to ask for them.

Second, the passages do not bind the model. The German guidance notes that, depending on how a system is designed, a model can tend "insbesondere bei widersprüchlichen Inhalten das Wissen aus den Trainingsdaten wiederzugeben und die Inhalte aus den Referenzdokumenten zu verwerfen": particularly where contents conflict, to repeat what it learned in training and discard what the reference documents say.

And then it starts again

The model keeps nothing between turns. The next question makes all six stops again. The German authorities say it in one sentence:

"Die erweiterte Anfrage wird jedes Mal neu aus der Datenquelle erstellt." — The augmented request is created anew each time from the data source.

Some products go round more than once for a single question. The same guidance mentions systems that "iterativ mehrere Anfragen an den Retriever schicken", which send several requests to the search component, one after another.

In order:

1. It rewrites. The product, often the model itself, decides whether to search and what to search for.
2. It converts. The query becomes a list of numbers.
3. It filters. Labels and permissions narrow what may be searched.
4. It shortlists. The store returns candidates, a second model may score them, and a few survive.
5. It pastes. The survivors are added to your question and sent to the model. A copy is kept with the conversation.
6. It answers, and may show where it looked.

(The PDF edition of this issue draws the loop as a diagram — link at the end.)

Two consequences for how you use it

One — a citation shows where it looked, not that it read it right. Anthropic's documentation makes a precise promise about its citation feature: "citations are guaranteed to contain valid pointers to the provided documents." A valid pointer means the passage exists. It does not mean the passage supports the sentence it sits under.

Researchers at Stanford and Yale tested that gap on commercial legal research tools built on retrieval. Their definition is the one a lawyer would use: "we define a hallucination as a response that contains either incorrect information or a false assertion that a source supports a proposition." They found:

"…the AI research tools made by LexisNexis (Lexis+ AI) and Thomson Reuters (Westlaw AI-Assisted Research and Ask Practical Law AI) each hallucinate between 17% and 33% of the time." — Magesh, Surani, Dahl, Suzgun, Manning and Ho, Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools (preprint, 30 May 2024)

Read that result with its conditions:

• The tools were tested as they stood in 2024. The figures are from the preprint of 30 May 2024. The study was later published in the Journal of Empirical Legal Studies (2025).
• The questions were built to be hard. There were over 200 of them, on United States law. The authors say their figure "is not meant to be an unbiased estimate of the (unknown) population-level rate of hallucinations in legal AI queries, but rather to assess whether hallucinations have in fact been solved by RAG, as claimed."
• Retrieval reduced the problem. The same abstract says hallucinations "are reduced relative to general-purpose chatbots".
• It is research, not a ruling. No court or regulator has adopted its figures.

Their account of where it goes wrong is the useful part. "Many failures in the three systems stem from poor retrieval", they write, and "retrieval itself often requires legal reasoning." A passage can be genuine and still be the wrong authority, because it is for "the wrong jurisdiction, wrong statute, wrong court, or has been overruled." Their conclusion is measured. Such tools have value, "particularly when used as the first step of legal research rather than the last word."

Two — your question is a record too. It was rewritten, converted, scored against passages, pasted into a prompt and stored with the answer. On the German authorities' reading, data subjects' rights run "in Bezug auf den Eingabeprompt und die Ausgabe", in relation to the input prompt and the output, as well as the documents and the store. Put into the question box only what you would be content to find in the file.

When the store is a graph

Search by meaning finds passages that resemble the question. It is poor at questions that need facts joined up across many documents. Microsoft's documentation for one alternative says the ordinary approach "struggles to connect the dots."

The alternative is to have a model read every chunk in advance and build a map. The map is called a knowledge graph: a set of named things, and the links between them. Microsoft Research published the method in 2024 under the name GraphRAG. Its paper describes the first step: "the LLM is prompted to extract instances of important entities and the relationships between the entities from a given chunk. Additionally, the LLM generates short descriptions for the entities and relationships." ("LLM", for large language model, is the trade term for what this series calls the model.)

An entity, in the project's documentation, is one of the "people, places, events" found in the text. The system can also extract claims, which are "statements about entities which may be time-bound." It then merges everything said about each entity into one description, by "asking the LLM for a short summary that captures all of the distinct information from each description."

For a lawyer, the important sentence is the paper's own account of what those summaries are: "meaningful summaries of concepts that, in the case of relationships and claims, may not be explicitly stated in the text."

So an index of this kind is no longer only a copy of your documents. It holds new sentences about named people, written by a model, which the documents themselves may never have stated. A store of chunks can be wrong only in what it retrieves. A graph can be wrong in what it says.

This is one published method, not a description of any product you are using, and no regulator text read for this issue addresses it. But where a system is built this way, what it has written about a person is something the organisation now holds about that person.

Where the law grips

Each stop has a name in the definition

"‘processing’ means any operation or set of operations which is performed on personal data… such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination…" — Article 4(2), GDPR

Part 4 was about the first half of that list: recording, organisation, structuring, storage, adaptation. The loop is the second half. The search is retrieval and consultation. The paste is use and, where the model is run by another company, disclosure by transmission. A graph that joins what several documents say about one person is alignment or combination. Where the documents contain personal data, each stop is an operation the Regulation names.

Europe: every later use is "further processing", and the test is purpose

"collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes" — Article 5(1)(b), GDPR, the principle of "purpose limitation"

The Court of Justice applied that principle to a second database in Digi (Case C-77/21, 20 October 2022). After a server failure in April 2018, a Hungarian telecoms company copied the personal data of about a third of its private customers into a test database, and then left it there. In September 2019 an "ethical hacker" got into it. The data had been collected to perform the customers' contracts. Was the copy a breach of purpose limitation?

The Court held, first, that "the recording and storage, by the controller, in a newly created database, of personal data stored in another database constitutes ‘further processing’ of those data." It then defined the word:

"…any processing of personal data which is subsequent to the initial processing constituted by the initial collection of those data constitutes ‘further’ processing of those data, regardless of the purpose of that further processing."

And it said when the hard question arises. Compatibility has to be assessed "only if the purposes of that further processing are not identical to the purposes of the initial collection." If they differ, Article 6(4) lists what to weigh: the link between the two purposes, the context in which the data were collected, the nature of the data, the consequences for the people concerned, and the safeguards in place. The Court summed those criteria up as "the need for a specific, logical and sufficiently close link" between the old purpose and the new use.

On the facts, the Court did not rule the copy out. Testing and fixing the subscriber database was closely linked to performing the contracts. What it did rule out was keeping the copy "for longer than is necessary for the conducting of those tests and the correction of those errors." A second copy lives only as long as its own purpose does.

Two cautions. Digi is about a copied customer database. It says nothing about AI or search, and applying it to a document store is this issue's reading, not the Court's. And it does not mean that each search needs a new legal basis. Recital 50 of the GDPR says that where the further processing is compatible, "no legal basis separate from that which allowed the collection of the personal data is required."

What Digi gives is the method. Building the store is further processing. So is every search of it. Where a search serves the purpose the data were collected for, the compatibility question does not arise. Where it serves a different one, the compatibility test is asked of that search. The junior's question on Monday drew on a file opened to advise one client, in order to advise another. That is the point at which Digi tells you to stop and ask.

The regulator text on point

Part 4 introduced the guidance on retrieval systems published in October 2025 by Germany's Datenschutzkonferenz, the joint conference of the country's federal and state data protection authorities. Its section on purpose limitation gives the practical answer. Where staff use one system for different purposes, they must be given different roles, and (the translations are this issue's own):

"Es muss sichergestellt werden, dass die Mitarbeitenden vor der Abfrage die für den Verarbeitungszweck korrekte Rolle erhalten." — It must be ensured that, before the query, staff are given the role that is correct for the purpose of the processing.

Before the query. A person who uses the system for more than one purpose must be given the role that fits the purpose before the search is run. The guidance adds that purpose limitation in the store "lässt sich durch eine Mandantentrennung oder funktionale Trennung der Daten technisch umsetzen": it can be implemented technically, by keeping each tenant's data apart or by separating the data by function.

It also names a risk that no setting removes:

"Gleichzeitig stellt die Verwendung eines RAG-Systems eine Bedrohung für die Zweckbindung dar." — At the same time, the use of a RAG system is a threat to purpose limitation.

The threat it has in mind is specific. When passages are handed to the model, they may be linked with whatever personal data the model absorbed in training, and a link of that kind "ggf. nicht in der Ausgabe des RAG-Systems erkennbar ist", may not be recognisable in the output.

The limits are the ones Part 4 stated. This is guidance, not law. It binds no one outside Germany. It covers systems built on embeddings and vector stores, and says in terms that other designs are not dealt with.

California: each use, measured against the purpose

"A business’ collection, use, retention, and sharing of a consumer’s personal information shall be reasonably necessary and proportionate to achieve the purposes for which the personal information was collected or processed, or for another disclosed purpose that is compatible with the context in which the personal information was collected, and not further processed in a manner that is incompatible with those purposes." — California Civil Code §1798.100(c)

Use sits in that sentence beside collection and retention, and each is measured against the purpose. California writes one condition into the sentence itself: the other purpose has to be a disclosed one.

India Desk

The Act names the stops. Section 2(x) of the Digital Personal Data Protection Act, 2023 lists the operations that count as processing: "collection, recording, organisation, structuring, storage, adaptation, retrieval, use, alignment or combination, indexing, sharing, disclosure by transmission…". Part 4 pointed to indexing. The loop is retrieval, use, alignment or combination and disclosure by transmission.

The purpose is fixed by the notice. A notice must tell the individual "the personal data and the purpose for which the same is proposed to be processed" (s.5(1)(i)). The Act then defines its own term: "“specified purpose” means the purpose mentioned in the notice given by the Data Fiduciary to the Data Principal" (s.2(za)). Consent "shall signify an agreement to the processing of her personal data for the specified purpose and be limited to such personal data as is necessary for such specified purpose" (s.6(1)).

The Act's own illustration is a telemedicine app that also asks for the phone's contact list. Because the contact list "is not necessary for making available telemedicine services, her consent shall be limited to the processing of her personal data for making available telemedicine services." Where the basis is not consent but voluntary provision, the anchor is the same. Processing is allowed "for the specified purpose for which the Data Principal has voluntarily provided her personal data" (s.7(a)).

There is no compatibility test. Europe lets a controller argue that a new use is compatible with the old purpose. California allows another disclosed, compatible purpose. The Indian Act has neither. The words compatible, incompatible and further processing appear nowhere in the Act, and nowhere in the DPDP Rules, 2025. On the text, a search that serves a purpose outside the notice has to find its own footing: its own consent, one of the legitimate uses in section 7, or an exemption in section 17. One of those exemptions will matter to litigators. Chapter II (apart from two sub-sections of section 8), Chapter III and section 16 do not apply where "the processing of personal data is necessary for enforcing any legal right or claim" (s.17(1)(a)).

Accuracy is tied to use. Where personal data is likely to be "used to make a decision that affects the Data Principal" or "disclosed to another Data Fiduciary", the fiduciary "shall ensure its completeness, accuracy and consistency" (s.8(3)). A retrieval system that feeds a decision is using a chunk, and a chunk is by design a fragment of a document. Whether the personal data in that fragment is complete is a question the Act asks.

The Rules expect a record of access. Rule 6 of the DPDP Rules, 2025 lists minimum security safeguards. It comes into force eighteen months after the Rules were published. Two of its safeguards describe Stop 3 and Stop 5: "appropriate measures to control access to the computer resources" (r.6(1)(b)), and "visibility on the accessing of such personal data, through appropriate logs, monitoring and review" (r.6(1)(c)). The fiduciary must also, "for enabling the detection of unauthorised access, its investigation, remediation to prevent recurrence and continued processing in the event of such a compromise, retain such logs and personal data for a period of one year" (r.6(1)(e)), unless another law requires otherwise. In a retrieval system, each search that returns personal data is an access to it.

Global: one loop, three ways of asking

Europe says every use after collection is further processing, and asks whether its purpose is the same as the original one or compatible with it. California measures each use against the purpose collected for, or another disclosed and compatible one. India fixes the purpose in the notice, names retrieval and use as processing, and has no compatibility test at all.

None of the three statutes mentions retrieval systems. One judgment, about a copied customer database, supplies the method. One German guidance note supplies the engineering answer: settle the purpose before the query, and keep the data apart. The common point is that the test does not attach to the store alone. It attaches to each use of it.

What to do next

Three things for yourself.

1. Open the passage under the answer. A citation proves where the product looked. Whether the passage says what the answer says, for the right jurisdiction and the right court, is still yours to check.
2. Treat your question as part of the file. It is rewritten, converted, scored and stored with the answer. Do not put into it a name or a fact you would not record on the matter.
3. Ask what the product is allowed to search. If it searches across a whole organisation, an answer may rest on a file you were never meant to open, and a colleague's answer may rest on yours.

Five things before a client builds or buys one.

4. Write down the purpose of each store, and who may ask it what. The German guidance puts the role before the query. One store for everything, open to everyone, turns every search into a purpose question.
5. Fix the permissions before the documents are indexed. The index does not change who can see what. It makes what they can already see far easier to find.
6. Map every stop a question makes. Which model converts it, which scores the candidates, which writes the answer, who runs each, in which country, and how long each keeps what it was sent.
7. Ask whether the system records which passages answered which question. Without that record, a request for access to the prompt and the output cannot be answered in full, and nobody can show who was shown what. The record is itself personal data, with its own retention period.
8. If the index is a graph, treat what it wrote as new data. Ask who checks the descriptions it generated about named people, how they are corrected, and whether they are deleted when the source document is.

If you have come in at Part 5, the four issues before it are free, need no account, and take under half an hour each:

• Part 1 — It predicts the next word. That is the whole machine. → https://buttondown.com/the_desk/archive/it-predicts-the-next-word-that-is-the-whole/
• Part 2 — Where your draft actually goes. → https://buttondown.com/the_desk/archive/where-your-draft-actually-goes/
• Part 3 — What "delete" actually deletes. → https://buttondown.com/the_desk/archive/what-delete-actually-deletes/
• Part 4 — Your document, as a list of numbers. → https://buttondown.com/the_desk/archive/your-document-as-a-list-of-numbers/

PRACTITIONER'S VERDICT

What to tell a colleague this week. A product that answers from your documents searches them again for every question. It may rewrite the question first, turn it into numbers, filter by permissions, shortlist a handful of passages, and paste them into the prompt it sends to the model. Up to three models can touch one question, and the question, the passages and the answer are then stored together as a conversation. Access control has to happen at the search, because the model cannot tell who is asking. A citation under the answer shows where the product looked, not that it read the passage correctly: a 2024 study by researchers at Stanford and Yale, using questions built to be hard, found that retrieval-based legal research tools each hallucinated between 17% and 33% of the time. Is each search a fresh act of processing? It is processing by name: retrieval and use are in the GDPR's definition and in India's. The Court of Justice has said that any processing after collection is "further processing", and that the compatibility test is asked when the purpose differs. That does not mean a new legal basis for each search. It means the purpose is tested at each use, not once when the store is built. California measures each use the same way. India has no compatibility test at all: the purpose is the one in the notice. The German regulators' practical answer is to settle the purpose before the query, and to keep the data apart.

WHERE WE ARE GOING

Next — Part 6: showing the model versus teaching it. Retrieval shows the model your documents, one question at a time. The other route is to train the model on them, which is called fine-tuning. What each does with your client's data, and why deletion is workable in one and contested in the other.

Sources, as read

• OpenAI, developer documentation: Retrieval, File search, Data controls in the OpenAI platform (no date shown on the pages).
• Anthropic: Introducing Contextual Retrieval (published 19 September 2024); Citations and Embeddings, Claude Platform Docs (no date shown); Claude Help Center, Retrieval augmented generation (RAG) for projects ("Updated over 3 weeks ago").
• Google, Gemini API: File search ("Last updated 2026-09-23 UTC").
• Microsoft: Data, Privacy, and Security for Microsoft Copilot (last updated 18 August 2026); Semantic indexing for Microsoft Copilot (last updated 23 April 2026); GraphRAG project documentation, Welcome and Dataflow (no date shown).
• Studies: Patrick Lewis and others, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 (arXiv:2005.11401) · Darren Edge and others, From Local to Global: A Graph RAG Approach to Query-Focused Summarization (arXiv:2404.16130, first posted April 2024; quoted from the revised version of 19 February 2025) · Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning and Daniel E. Ho, Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools (arXiv:2405.20362, 30 May 2024; later published in the Journal of Empirical Legal Studies, vol. 22, 2025).
• Europe: Regulation (EU) 2016/679 (GDPR), Articles 4(2), 5(1)(b) and 6(4), Recital 50 · Court of Justice, Digi Távközlési és Szolgáltató Kft. v Nemzeti Adatvédelmi és Információszabadság Hatóság, Case C-77/21, judgment of 20 October 2022 · Datenschutzkonferenz, Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode, Version 1.0, October 2025 · EDPS, TechSonar, Retrieval-augmented generation (RAG).
• California: Civil Code §1798.100(c).
• India: Digital Personal Data Protection Act, 2023, sections 2(x), 2(za), 5(1), 6(1), 7(a), 8(3) and 17(1)(a) · Digital Personal Data Protection Rules, 2025, Rules 1(4) and 6(1).

Vendor pages were read first-hand on 3 October 2026 and re-checked on 4 October 2026. Translations from the German are this issue's own.

This issue is written for lawyers and is general in nature. It is not legal advice and no lawyer-client relationship arises from reading it.

Every statutory reference and every date in this issue was checked against at least two independent sources before it went out. Vendor terms were read first-hand on the dates stated. Where a claim could not be verified to that standard it does not appear, or it is stated as an absence of record rather than as a fact. The archive, and everything else I have been building, is at wolfgangrush.github.io

This issue as a PDF (14 pages, page-numbered, with the loop drawn as a figure) https://wolfgangrush.github.io/assets/The-Primer-Part-05-2026-10-04.pdf

Every free document — no email wall https://wolfgangrush.github.io/resources/