When a product "reads" your documents, it cuts them into pieces, turns each piece into a list of numbers, and keeps both. This issue explains what those numbers are, how long they are kept, and whether the law still sees a person in them.

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/

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

Start here

You have a forty-page bundle: a contract, a chain of emails, two notices. You upload it to an AI product and ask a plain question: what did the other side say about the delivery date?

The answer comes back with the right passage. It is from page thirty-one, and page thirty-one does not use the words "delivery date". It says the goods would arrive "in the first week after the monsoon closure lifts."

How did it find a passage that shares none of your words?

It did not read the forty pages the way you would. Before you asked anything, the product had cut the bundle into short pieces and turned each piece into a long list of numbers. When you asked your question, it turned your question into a list of numbers too, and looked for the pieces whose numbers sat closest to yours.

That list of numbers is called an embedding. This issue is about what it is, where it is kept, how long it is kept after you delete the file, and whether a list of numbers made from your client's documents is still your client's personal data.

The last question is the one lawyers will be asked. There is a document everyone cites to answer it, and it turns out to be about something else. That comes near the end.

What Part 3 left open

Part 3 listed the places a product keeps what you give it. The third was search across your past chats, the fourth files and connected apps, and it defined retrieval in one line: search a store of material, pick out what looks relevant, paste it into the window. It promised that how that search actually works would come later. This is later.

Two terms carry over from the earlier parts.

THE MODEL is the next-word predictor from Part 1. It keeps nothing between turns.

THE CONTEXT WINDOW is the text the model is given for a single reply, and the only thing it can see. Part 3 showed that the window is finite, and that the longer it gets, the less reliably the model uses what is in it.

That finite window is the whole reason retrieval exists. Anthropic's engineering team puts the line at roughly five hundred pages: "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt that you give the model, with no need for RAG or similar methods." (A token is a word or a piece of a word. OpenAI's own pricing example assumes about 800 tokens to a page.)

Beyond that, the product has to choose which few passages the model will see. Claude's help centre describes projects on its paid plans switching over automatically: "When your project knowledge approaches the context window limit, Claude will automatically enable RAG mode". It adds that Claude then "intelligently searches and retrieves only the most relevant information needed to answer your questions."

Only the most relevant information. Keep those words in mind. They mean the model answers from the passages the search picked, not from the whole document.

Four new terms, in the order the machine uses them

1. The chunk

The product first cuts your document into pieces. The trade word is chunk. OpenAI's default is stated exactly: "every file is indexed by being split up into 800-token chunks, with 400-token overlap between consecutive chunks." That is roughly a page at a time, each piece overlapping half of the one before it so that no sentence is cut off at a seam.

2. The embedding

Each chunk is then handed to a second, specialised model, an embedding model, which turns it into numbers.

"An embedding is a vector (list) of floating point numbers. The distance between two vectors measures their relatedness. Small distances suggest high relatedness and large distances suggest low relatedness." — OpenAI, Vector embeddings

"Vector" is just the mathematical word for an ordered list of numbers. The list is long. OpenAI's smaller model produces, by default, 1,536 numbers for every chunk. Google describes the same step in terms a lawyer will want to underline: its embedding model "is only intended to transform the format of your input data into a numerical representation."

Transform the format. Google sets this against "generative AI models that create new content". On the vendor's own description, an embedding creates nothing new. It is a representation of your text, in another format.

The numbers are not random. They are arranged so that pieces of text that mean similar things end up with similar numbers. Anthropic's documentation: "Text embeddings are numerical representations of text that enable measuring semantic similarity." ("Semantic" means "to do with meaning".)

3. The vector store

The numbers have to be kept somewhere, so that they can be searched every time you ask a question. That place is called a vector store, or vector database. OpenAI calls its vector stores "indices for your data": the index at the back of a book, rebuilt so that it can be searched by meaning.

"When you add a file to a vector store it will be automatically chunked, embedded, and indexed." — OpenAI, Retrieval

Here is the fact most explanations skip. The store does not keep the numbers alone. It keeps your words next to them. OpenAI's pricing for its vector stores is charged on "the size of parsed chunks and their corresponding embeddings", which means the chunks of text and their numbers, stored together. A search returns "the relevant chunks, similarity scores, and file of origin." Germany's data protection authorities, describing the same design, say the vectors "wurden zusammen mit den Chunks in der Vektordatenbank gespeichert", that is, stored together with the chunks in the vector database.

So a store built this way, having "read" your forty pages, holds the forty pages again: cut into overlapping pieces, each piece filed next to its list of numbers.

4. Semantic search

Now the search itself. Your question goes through the same embedding model and becomes a list of numbers. The store looks for the chunks whose numbers are closest to it, and those chunks are pasted into the model's context window alongside your question.

OpenAI gives a small example of why this beats looking for matching words. The question is "When did we go to the moon?"

(OpenAI's figures: word overlap measured by "intersection over union"; meaning measured by "cosine similarity" between the two lists of numbers.) In OpenAI's words: "Notice how the most relevant result contains none of the words in the search query."

That is your page thirty-one. The monsoon sentence shares none of your words and sits close to your question in meaning.

One question, start to finish

Put the four terms together and this is what happens, in the order the vendors describe it. Anthropic's engineering team lays out the preparation as three steps:

"Break down the knowledge base (the “corpus” of documents) into smaller chunks of text, usually no more than a few hundred tokens; Use an embedding model to convert these chunks into vector embeddings that encode meaning; Store these embeddings in a vector database that allows for searching by semantic similarity." — Anthropic, Introducing Contextual Retrieval

and then the moment you ask:

"At runtime, when a user inputs a query to the model, the vector database is used to find the most relevant chunks based on semantic similarity to the query. Then, the most relevant chunks are added to the prompt sent to the generative model."

In order:

1. You upload. The product receives the file.
2. It cuts. The file becomes overlapping chunks, roughly a page each.
3. It converts. Each chunk becomes a list of numbers.
4. It files. Numbers and chunks go into the store, together, and stay there until someone deletes them.
5. You ask. Your question becomes a list of numbers.
6. It matches. The store returns the chunks nearest your question.
7. It pastes. Those chunks, and only those, go into the context window with your question.
8. The model answers, from what was pasted.

Steps 2 to 4 happen once, when the document goes in. Steps 5 to 8 happen every time you ask. The model never sees the store. It sees only what step 6 picked.

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

Two consequences for how you use it

One — it can miss the exact thing you asked for. Search by meaning is good at paraphrase and weak at precise strings. Anthropic's engineers say so plainly: "While embedding models excel at capturing semantic relationships, they can miss crucial exact matches." The older word-matching technique they pair it with is "particularly effective for queries that include unique identifiers or technical terms."

For a lawyer, the unique identifiers are the things that matter most: a section number, a clause number, an exhibit mark, a case citation, a date. A search that is looking for meaning can pass over "clause 14.3(b)" for a chunk that merely talks about termination in general. When the exact words matter, ask with the exact words, and then check the passage it relied on.

Two — if the search did not pick it, the model never saw it. The answer is written from the chunks placed in the window at step 7. If the decisive paragraph was not among them, the model did not weigh it and then reject it. It never had it. A confident answer that ignores page thirty-one may simply be an answer that was never shown page thirty-one. Nothing on the screen will tell you which chunks were used unless the product shows its sources, so where it shows them, read them.

The European Data Protection Supervisor, which oversees the EU's own institutions, raises the law-firm case directly. In its note on retrieval, it warns that if a firm uses such a system "to assist lawyers by retrieving case law, statutes and precedents, the retrieval of outdated or incorrect precedents could result in legal advice that suggests a less stringent strategy than is necessary."

Where the numbers live, and for how long

Part 3 was about the gap between deleting a conversation and deleting what the product learned from it. The index opens a second gap of the same kind, between deleting a file and deleting what was built from it.

Google's developer documentation states it in one line:

"There is no Time To Live (TTL) for embeddings; they persist until manually deleted, or when the model is deprecated. Files, however, are deleted after 48 hours." — Google, Gemini API, File search

And again, more fully: "While raw files uploaded through the File API are deleted after 48 hours, the data imported into a File Search store is stored indefinitely until you manually delete it."

On Google's developer platform, the file goes in two days. What was built from it stays until someone deletes it.

OpenAI's platform documentation sets out the same split in a table. Making an embedding and keeping one are listed as different things:

(The same table lists a separate 30 days of "abuse monitoring retention" for both.)

The same page adds, of vector stores and related objects: "Objects that are not deleted via the API or dashboard are retained indefinitely." Vector stores are also not eligible for OpenAI's "Zero Data Retention" arrangement. OpenAI does offer a clock: a store can be set to expire, and "once a vector store expires, all associated vector_store.file objects will be deleted." But someone has to set it.

Deletion is not instant either. "Removing files from a vector store is eventually consistent, and search results may still include content from a removed file for a short period." And a deleted store is not gone at once: OpenAI says such objects are "deleted from our servers 30 days after you delete them via the API or the dashboard."

What the consumer pages say, and what they do not. On the consumer side, OpenAI's help pages describe what happens to your files and projects. Files in a chat are kept "up to the retention period of the corresponding chat". Deleting a project "permanently removes its chats and instructions, along with files stored only in the project. Files saved separately in Library are not deleted." None of the consumer help pages read for this issue, OpenAI's or Anthropic's, describes the search index as a separate record, and none uses the word "embedding". What they build behind the file, and how that is deleted, is not something those pages explain.

These pages change. Check them before relying on them. Every quotation above was read first-hand on 22 September 2026, and checked again on 27 September 2026, the day this issue went out. The page dates are listed under Sources, as read at the end of this issue.

Can the numbers be turned back into the words?

This is where the legal question begins. If a list of numbers were a one-way street, so that nobody could get the text back out of it, there would be a decent argument that the numbers on their own tell you nothing about anyone.

In 2023 a team at Cornell tested exactly that, and published the result:

"…a multi-step method that iteratively corrects and re-embeds text is able to recover 92% of 32-token text inputs exactly." — John X. Morris, Volodymyr Kuleshov, Vitaly Shmatikov and Alexander M. Rush, Text Embeddings Reveal (Almost) As Much As Text (EMNLP 2023)

Thirty-two tokens is a sentence or two. On a set of hospital clinical notes, with realistic stand-in names in place of the real ones, the same method "is able to recover 94% of first names, 95% of last names, and 89% of full names." The authors' conclusion is that "embeddings should be treated with the same precautions as raw data."

Read that result with its conditions, because they matter to the legal analysis:

• It was short text. The 92% figure is for passages of 32 tokens. The authors note that their model "has more trouble exactly recovering longer texts, but still is able to get many of the words."
• The attacker needed two things: the numbers, and the ability to send text to the same embedding model and get its numbers back.
• The headline figures come from an open research model. The 92%, and the names from the clinical notes, were recovered from GTR-base (2021). Against OpenAI's commercial model, text-embedding-ada-002, the same method recovered 61% of 32-token passages exactly, and 8% of passages up to 128 tokens long. OpenAI now lists that model behind its newer "-3" models. Newer models have not been shown to be safe; this paper simply did not test them.
• It is research, not a ruling. No court or regulator has adopted its figures.

The authors say why they ran it. Businesses increasingly send their embeddings to specialised outside database services, in which "the data owner only sends embeddings of text data … to the third party service, and never the text itself." The comfort in "we only share the vectors, never the text" is exactly what this study tested.

Where the law grips

Each regime below asks, in its own words, one question: can someone be identified from this, or through it? The answer for an embedding depends on who is holding it, what they are holding it with, and which statute is asking.

Europe: identifiable by anyone with the means

"‘personal data’ means any information relating to an identified or identifiable natural person… an identifiable natural person is one who can be identified, directly or indirectly…" — Article 4(1), GDPR

Recital 26 tells you how to decide whether someone is identifiable: "account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly," considering "the available technology at the time of the processing and technological developments."

Two things follow before any court is consulted. First, the stores the vendors describe hold the chunks of text next to the numbers. A store that holds a client's own sentences is holding information relating to the people those sentences are about, and the numbers filed beside them do not change that. Second, for numbers held alone, "the available technology" and "technological developments" now include published methods for turning numbers back into text.

The Court of Justice has said that the answer can differ depending on who holds the data, in a line of cases that runs back to Breyer (2016). Its most recent statement came on 4 September 2025, in EDPS v SRB (Case C-413/23 P), where the Court held that pseudonymised data "must not be regarded as constituting, in all cases and for every person, personal data", "in so far as pseudonymisation may, depending on the circumstances of the case, effectively prevent persons other than the controller from identifying the data subject in such a way that, for them, the data subject is not or is no longer identifiable."

But the Court put a limit on that in the paragraph before: "in so far as it cannot be ruled out that those third parties have means reasonably allowing them to attribute pseudonymised data to the data subject, such as cross-checking with other data at their disposal, the data subject must be regarded as identifiable." And for the organisation that did the pseudonymising, which usually holds the extra information needed to identify the person, the data stay personal.

Two cautions about that judgment. It was decided under the regulation that governs the EU's own institutions, the GDPR's twin, whose definitions mirror the GDPR's, and not under the GDPR itself. And it says nothing about embeddings, AI or search. It tells you how to ask the question. It does not answer it for vectors.

The citation everyone reaches for, and why it does not answer this

Ask how European data protection law treats AI, and the answer usually cites the European Data Protection Board's Opinion 28/2024, adopted on 17 December 2024. It is an important document. It is not about search indexes.

Its own words set its scope: "the scope of this Opinion only covers the subset of AI models that are the result of a training of such models with personal data." It is about models, meaning the trained machine from Part 1: when a model trained on personal data can be called anonymous, when legitimate interest can justify developing and deploying one, and what follows if the training was unlawful. Search the full text for "retrieval", "embedding", "vector" or "index", and none of the four appears.

What the Opinion says about models is striking: that training data "may still remain ‘absorbed’ in the parameters of the model, namely represented through mathematical objects", and may be "extractable." It is tempting to carry that across to embeddings, since both are information represented as numbers. But an index of your documents is not a trained model. It is closer to a filing system: each entry was made from one specific chunk, is stored beside that chunk, and can be found and deleted on its own. Citing the Opinion for an index cites it for something outside the scope it set itself.

The same caution applies to a paper often cited for the opposite conclusion. In July 2024 the Hamburg data protection authority argued that a large language model does not itself store personal data. It too used the word "embeddings", but for the model's internal workings, and it set the rest of the system aside in terms: its analysis does "not evaluate the processing activities in the entire AI system." It named retrieval as one of those other components. The same paper offers the cleanest analogy for our question: "a library card, even if it only displays a series of digits, can be personal data", if the person behind the number can be found through the library's records.

The regulator text that is on point

One regulator text does address this directly. In October 2025 Germany's Datenschutzkonferenz, the joint conference of the country's federal and state data protection authorities, published guidance on retrieval systems, stating that its "Fokus" is "Systemen mit Embeddings und Vektordatenbanken": systems with embeddings and vector databases. Three passages matter (the guidance is in German; the translations are this issue's own):

"…so werden unter anderem personenbezogene Daten aus den Referenzdokumenten durch das Embedding-Modell verarbeitet und in einer Vektordatenbank gespeichert." — personal data from the source documents are processed by the embedding model and stored in a vector database.

"…stehen Betroffenen … in Bezug auf … die Referenzdokumente und die Vektordatenbank die Rechte aus Art. 15 ff. DSGVO zu, soweit hierbei personenbezogene Daten verarbeitet werden." — data subjects have their GDPR rights, from access onwards, in relation to the source documents and the vector database, insofar as personal data are processed there.

"Diese Einträge sind direkt adressierbar und damit auch personenbezogene Daten gezielt löschbar." — these entries are directly addressable, and so personal data can be deleted in a targeted way.

Note what the guidance treats as the object: the vector database as a whole, which on its own description stores each chunk together with its vector. It does not decide whether a bare list of numbers, held with no text, is personal data by itself. It is guidance, not law, and it binds no one outside Germany. It is also, as far as this issue could find, the only regulator text that addresses whether a document search index holds personal data, and it treats the index as a place where personal data live and where data subjects' rights run.

California: whatever format it takes

"“Personal information” means information that identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household." — California Civil Code §1798.140(v)(1)

Reasonably capable of being associated with. In 2024 California added a paragraph about the forms that information can take. Assembly Bill 1008, approved by the Governor on 28 September 2024, added that personal information "can exist in various formats", including "Abstract digital formats, including compressed or encrypted files, metadata, or artificial intelligence systems that are capable of outputting personal information."

The list does not mention embeddings, and it is expressly "not limited to" the items it names. Put it beside Google's description of an embedding as a transformation of "the format of your input data", and the point makes itself: on California's text, a change of format is not a change of category. To escape the definition, California requires more than a change of format. Information is only "deidentified" if it "cannot reasonably be used to infer information about, or otherwise be linked to, a particular consumer," and the business holding it has taken reasonable measures to ensure it cannot be associated with a consumer or household, has publicly committed not to re-identify it, and has bound its recipients by contract to do the same.

India Desk

The Act names the index. Section 2(x) of the Digital Personal Data Protection Act, 2023 defines "processing" as a list of operations on digital personal data, "such as collection, recording, organisation, structuring, storage, adaptation, retrieval, use, alignment or combination, indexing, sharing…". The GDPR's list has "retrieval" and "adaptation" but not indexing. The Indian Act names it. Cutting a client's documents into chunks, converting them and filing them in a store is, on the words of s.2(x), storage, adaptation and indexing of whatever personal data those documents contain. That is so however the resulting numbers are later classified.

The definition reaches "in relation to". Personal data is "any data about an individual who is identifiable by or in relation to such data" (s.2(t)). Not only data that identifies someone by itself, but data in relation to which someone is identifiable. An entry in a store that sits next to the chunk it was made from, and points back to the file it came from, is a strong candidate on those words.

The Act has no exit for "we changed its form". The words anonymise, pseudonym, de-identify, derived, infer, embedding and vector appear nowhere in the Act, and nowhere in the DPDP Rules, 2025. India has no statutory category of anonymised or de-identified data at all. The only question is s.2(t). Where the Rules do mention transformed data, they treat it as a way of protecting personal data, not of leaving the Act. Rule 6(1)(a) lists among security safeguards "securing of personal data through encryption, obfuscation, masking or the use of virtual tokens mapped to that personal data."

So the Indian question is narrower than the European one, and harder to escape. There is no Recital 26, no recipient-by-recipient analysis of the kind the Court of Justice adopted, and no deidentification safe harbour of the kind California offers. There is only whether an individual is identifiable by or in relation to the data, applied to a store that, as the vendors describe it, keeps the text beside the numbers.

Global: one question, three phrasings

Europe asks whether anyone could identify the person with the means reasonably likely to be used, and asks it holder by holder, a line of cases that runs from Breyer in 2016 to EDPS v SRB in September 2025. California asks whether the information is reasonably capable of being associated with a consumer, in whatever format it now takes. India asks whether the person is identifiable by or in relation to the data, and has named indexing as processing.

None of the three statutes mentions embeddings. One German guidance note addresses the index directly and treats it as holding personal data. And in the stores the vendors describe, the question in its hardest form, a list of numbers with nothing beside it, rarely arises, because the store keeps the words right next to the numbers.

What to do next

Three things for yourself.

1. Read "it has read my document" as "it has indexed my document." Each upload can leave two things behind: the file, and the chunks and numbers built from it. Deleting one is not proof that the other has gone. Where the product lets you see and delete uploaded files, projects and library items separately, delete each.
2. When the exact words matter, search with the exact words. A section number, a clause reference, a date, a party's name: ask for the string itself, then open the passage the answer relied on. Search by meaning is built to find paraphrase, and its makers say it "can miss crucial exact matches."
3. Treat a confident answer as an answer from some of the document. The model saw the chunks the search picked, not the bundle. If the answer ignores something you know is in there, it may never have been shown it. Ask about that page directly.

Three things before a client builds a product that searches its users' documents.

4. Put the index on the data map as its own store. What it holds (chunks of text and their numbers), where it is hosted, which vendor runs it, what its retention setting is, and who can query it. A data map that lists "uploaded files" and stops there has left out a second copy.
5. Make deletion reach the index, and test it. Delete a document and then search for a sentence from it. The vendors' own documentation warns that removal can be "eventually consistent" and that stores are kept "until deleted" unless an expiry is set. Germany's regulators, in their guidance, treat the entries as "direkt adressierbar", directly addressable, which makes "we could not find it in the index" a weak answer to an erasure request.
6. Do not describe vectors as anonymous. Not in the privacy notice, not in the vendor contract, not in the data protection impact assessment. The published research shows short text can often be rebuilt from its numbers by an attacker who also has access to the embedding model, and the Court of Justice has said that data remain personal for a recipient who can link them back.

Two things about what goes in.

7. Minimise before indexing, not after. The German guidance says that where personal data are not needed, they should be "zu entfernen oder zu anonymisieren": removed or anonymised before documents are cut into chunks. Taking a name out of a document before it is indexed is much easier than finding every chunk and vector it ended up in afterwards.
8. Remember what the index cannot fix. Retrieval changes what the model is shown. It does not change what the model already learned in training. The German authorities make the same point: whatever the advantages of a retrieval system, "bleiben die Probleme bei der Datenlöschung im Sprachmodell bestehen". The problems of deleting data from the language model itself remain.

If you have come in at Part 4, the three 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/

PRACTITIONER'S VERDICT

What to tell a colleague this week. 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, so that it can search by meaning. That makes it good at paraphrase and weak at exact references, and it means the model answers from the passages the search picked, not from the whole document. The store is a second copy. On the vendors' own developer documentation it is kept "until deleted", and in one case "indefinitely" after the file itself has gone. Is a list of numbers personal data? In the stores the vendors describe, the question barely arises, because the words are stored right beside the numbers. For numbers held alone, published research shows short text can be rebuilt from them. European law asks who could identify the person and with what means, holder by holder. California's statute says personal information can exist in various formats, including compressed or encrypted files, and the list is open. India names indexing as processing and has no anonymisation exit at all. The document most people cite, EDPB Opinion 28/2024, is about trained models, not search indexes. The regulator text that is on point is Germany's, from October 2025, and it treats the index as a place where personal data are stored and where data subjects' rights run.

WHERE WE ARE GOING

Next — Part 5: the full loop. What happens, step by step, each time a product goes back to the store to answer a question, and why every one of those searches is a fresh act of processing.

Sources, as read

• OpenAI, developer documentation: Vector embeddings, Retrieval, File search, Data controls in the OpenAI platform (no date shown on the pages). Help Center: File Uploads FAQ ("Updated: 10 days ago"), Projects in ChatGPT ("Updated: 2 days ago").
• Anthropic: Embeddings, Claude Platform Docs (no date shown); Introducing Contextual Retrieval (published 19 September 2024); Claude Help Center, Retrieval augmented generation (RAG) for projects ("Updated over a week ago").
• Google, Gemini API: Embeddings and File search (both "Last updated 2026-09-17 UTC" when read on 22 September; on 27 September File search showed "Last updated 2026-09-23 UTC", with every quotation used here unchanged).
• Study: John X. Morris, Volodymyr Kuleshov, Vitaly Shmatikov and Alexander M. Rush, Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023 (arXiv:2310.06816).
• Europe: Regulation (EU) 2016/679 (GDPR), Articles 4(1) and 4(2), Recital 26 · Court of Justice, Breyer, Case C-582/14, judgment of 19 October 2016 · Court of Justice, EDPS v SRB, Case C-413/23 P, judgment of 4 September 2025 · EDPB, Opinion 28/2024, adopted 17 December 2024 · Datenschutzkonferenz, Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode, Version 1.0, October 2025 · Hamburg Commissioner for Data Protection and Freedom of Information, Discussion Paper: Large Language Models and Personal Data, July 2024 · EDPS, TechSonar, Retrieval-augmented generation (RAG).
• California: Civil Code §1798.140, as amended by Assembly Bill 1008 (Statutes of 2024, chapter 802).
• India: Digital Personal Data Protection Act, 2023, sections 2(t) and 2(x) · Digital Personal Data Protection Rules, 2025, Rule 6(1)(a).

Vendor pages were read first-hand on 22 September 2026 and re-checked on 27 September 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 (15 pages, 3 figures, page-numbered) https://wolfgangrush.github.io/assets/The-Primer-Part-04-2026-09-27.pdf

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