Why We Store Vectors, Not Your Documents Is Almost Never True

Ask an AI vendor what happens to the documents you upload and you'll often hear some version of this: "We don't store your documents. We turn them into vectors, lists of numbers, so they can be searched." It's comforting. It suggests your content went through a one-way door and came out as pure mathematics. The person saying it usually isn't lying. In nearly every retrieval system, though, the statement is false, and understanding why changes the questions you should ask. You can check it yourself in about two minutes.

What happens to an uploaded file

A retrieval pipeline does four things with a file:

1. It extracts the text.
2. It splits the text into chunks, usually a few hundred words each, since a whole document is too large to hand to a model.
3. It embeds each chunk, converting it into a list of numbers that roughly captures what the chunk is about.
4. It stores the chunks so they can be searched.

Embedding is what makes search function. Your question gets embedded as well, and the system looks for chunks whose numbers sit nearest to the question's numbers.

Now the step people leave out. After the right chunk is found, the system needs the real words back. It must place that passage in the prompt so the model can answer from it, and it must show you the passage as a citation. An embedding can do neither, since you can't turn it back into the passage it came from. What it captures is meaning in rough form, with no way to rebuild the wording, so the text has to stay on file. Maybe not the original file, but definitely the text.

What it looks like in a database

The table where chunks live is dull, which is exactly the point, because nearly every retrieval product has one shaped like this:

create table document_chunks (
  id           uuid primary key,
  document_id  uuid not null,
  chunk_index  integer not null,
  content      text not null,      -- the passage, as text
  embedding    vector(1024),       -- the numbers, alongside it
  metadata     jsonb
);

Look at two columns. content holds your words, and embedding holds the numbers. Both are stored side by side.

The chunks are also kept in order with an index, so a full document can be rebuilt from them, and features such as "show me the whole file" depend on exactly that. A fair description of what a retrieval product holds is therefore your text in pieces, plus numbers that make the pieces findable, and not your original file.

Why the soothing version gets repeated

Rarely out of dishonesty. Usually it's one of three things.

The speaker means the file. Many products really do delete the uploaded PDF once extraction finishes. That's a worthwhile practice, and "we don't store your documents" is acceptable shorthand for it when everyone knows what's meant. The trouble is that the listener understood something far stronger.

Embeddings sound irreversible, so people assume the text is gone. Inverting an embedding is indeed hard. But the numbers being hard to reverse tells you nothing about whether the words were retained, and in a retrieval system they were, because the product would stop working otherwise.

Nobody asked the follow-up. "We store vectors" ends the conversation on a pleasant note. The useful question isn't whether vectors are stored. It's what else sits in that row.

A two-minute check

Any vendor can be tested this way, and you needn't be technical.

Ask where the quoted text comes from when the product shows a citation. If they can display the passage, they hold the passage, because it can't be coming from anywhere else.

Ask whether staff with production access can read the text of a document you upload. With nearly any retrieval product the truthful reply is yes, constrained by permissions and audit logs. If a vendor claims no, press for the mechanism. A believable one involves encryption keys that vendor never holds. Embeddings don't count.

Ask what exactly gets deleted when you delete a document. You want to hear that the chunks go, along with their embeddings.

These aren't traps. They produce an accurate picture in place of a comfortable one.

What to ask for instead

Once you accept that the text is stored, "is our content really in there?" stops being the point. These questions matter more:

• Who can reach it? Access should be granted per project or per document, not per company.
• What left the system? Which passages went out in a model call, and what was masked before they did?
• What gets deleted, and when? Does deletion cover derived data, or only the original upload?
• Is the encryption claim being read correctly? Encryption at rest guards against a stolen disk or leaked storage layer. It says nothing about whether the vendor itself can open your text, and a vendor who lets you assume otherwise has misled you by omission.

All of these can be answered and verified, and they're what really protects a document. "It's just numbers" protects nothing, since it was never the mechanism doing the protecting.

What a straight answer sounds like

A vendor with nothing to hide would say something like this: the text is stored, in a content column next to the embedding. The original file is wiped once extraction is done, as no later step touches it. When someone attaches a file to a single chat, only its text is retained, never the file, and that text is dropped along with the conversation. Personal data such as email addresses and phone numbers is masked by default before anything is sent to a model. And yes, the vendor can read the stored text, which a good security page states outright.

That last part matters. The alternative is a sentence a reviewer can disprove with one query, and a vendor caught being soothing on an easy question won't be believed on a hard one.

The short version

Hardly any retrieval product turns documents into numbers and then throws the words away, since answering you means getting the words back. So find out where a citation's wording originates, then evaluate the vendor by who gets access, what is masked and how deletion works. A slogan about vectors tells you little.