Cohere API Data Privacy: Private Deployments, Retention, and Why Your Embedding Index Is a Copy of Your Corpus (2026)

Cohere is the provider on this list most often selected by teams whose procurement process has real teeth, largely because private and VPC deployment options let you answer where does the data go with a straight architectural answer rather than a contractual one. That strength makes it worth spending this guide's attention somewhere else: on embeddings and retrieval, which is what those same teams are usually building, and which is where a well-run privacy programme most often has an unexamined gap.

The short version

If your requirement is that data never leaves your boundary, take the private or VPC deployment path and make it an architectural fact rather than a promise. Then classify your vector store as what it is -- a derived copy of the source corpus, in scope for the same access control, retention schedule and deletion obligations. Do not treat embeddings as anonymisation. And redact at the boundary regardless, because it is the one control that holds across every deployment mode.

A note on scope. This guide is about the data you send and what happens to it -- a different concern from prompt injection, which is about untrusted input coming the other way, and from credential handling, which is about who can make the call at all. It is also not legal advice: it is the set of questions an engineer should be able to answer before a lawyer is asked anything, and the code changes that make those answers short.

The Four Questions That Actually Decide It

Most privacy conversations about an LLM API sprawl because they mix four separate questions that have four separate sources of truth. Separate them and the work becomes tractable, because each one has a specific document or a specific code change attached.

Question	Where the answer lives	What to do with it
Training use -- can my content improve the service?	Current terms and DPA, for your tier	Save a dated copy; enable any opt-out as a deployment step with an owner
Retention -- how long does the request body exist?	DPA, not the dashboard	Make your privacy notice agree with the number; design so the window does not matter
Sub-processors -- who else touches it?	Published sub-processor list	Subscribe to change notifications; mirror the list in your own data map
Residency -- which jurisdiction ran the inference?	The endpoint and deployment, not the company address	Re-verify on every tier, region or platform change

Three of those four are answered by reading a document someone else wrote, which means they can change without you doing anything. Only the fourth column contains work you control -- and there is a fifth question, absent from every vendor document, that you control entirely: what did you send in the first place.

Redact at the Boundary, Not in the Postmortem

The highest-leverage control here is unglamorous and takes an afternoon: route every outbound Cohere call through one internal client, and make that client the only place in your codebase that knows how to build a request. Give it four jobs. Pseudonymise identifiers -- names, emails, account numbers, internal ids -- swapping in per-request tokens and keeping the mapping in your own database so you can re-substitute in the response. Drop payloads nobody meant to send, particularly whole file bodies that reached the prompt because passing them through was easier than extracting the three fields the feature needs. Cap size, since an unbounded prompt is both a cost bug and a disclosure bug. And reject patterns your policy forbids outright, loudly, in tests.

What makes this worth doing first is that it is the only control in this guide that survives everything else changing. Terms get revised, tiers get migrated, endpoints move region, sub-processor lists grow. A prompt that never contained a customer's name is unaffected by all of it, and a retained log full of pseudonyms is a much smaller conversation in a security review than a retained log full of customers.

Then apply the same discipline to your own systems, because this is where teams that did everything else right still end up with the data. Application logs, exception trackers and distributed traces routinely capture full request bodies by default. A provider with impeccable retention practices does not help you when the same prompts sit in three internal tools with a longer retention window and a wider access list than the provider has. Scrub at the logging layer, and write a test that fails if a known sentinel value reaches your log sink.

Six Ways This Goes Wrong, All Returning 200

Symptom	HTTP	Usual cause	Fix
Full customer record pasted into a prompt template	200	Prompt built by string interpolation over a database row	Build requests through one boundary client that pseudonymises identifiers before serialisation
Prototype on a free key pointed at production data	200	Free and evaluation tiers can reserve broader rights than paid tiers	Separate keys per environment; block production data sources from non-production keys
Full prompts and responses in your own error tracker	200	Default exception capture serialises the whole request object	Scrub request bodies at the logging layer; assert on it in a test
Attachment or document body forwarded wholesale	200	Upload path passes the file through untouched to save an extraction step	Extract only the fields the feature needs; cap payload size at the boundary
Residency claim in the data map no longer true	200	Tier, region or deployment changed without a code change	Re-verify processing region per endpoint on every plan or platform change
Deletion request cannot be satisfied	200	No mapping from a user to what was sent or derived	Pseudonymise at the boundary and keep the mapping; cascade deletion to derived stores

Every row returns a successful response. That is the whole difficulty of this subject: there is no error to alert on, no retry to write, no status page to check. The only detection mechanism is a control that runs before the request leaves.

The Cohere Trap: Embeddings Are a Copy, Not an Anonymisation

There is a persistent intuition that a vector is safe because it is not readable -- a list of floating point numbers that no human can eyeball back into a sentence. It is a bad intuition, and it fails in two independent ways. First, embeddings preserve semantic content by design, which is exactly why retrieval works: nearest-neighbour search over your index will happily surface the sensitive passage in response to a query about its subject, no inversion required. Second, research on embedding inversion has repeatedly shown that meaningful text can be reconstructed from vectors, particularly with access to the same model. Neither of these is exotic. Both are enough that a regulator will treat an index built from personal data as personal data.

So classify the vector store properly and the rest follows mechanically. It inherits the classification of the corpus it was built from. It needs the same access controls as the source documents, because a retrieval endpoint with weaker authorisation than the document store is a lateral path around your permissions -- one of the most common real defects in production RAG systems, where a chat interface cheerfully retrieves passages the asking user could never open directly. It needs a retention schedule. And it needs to be enumerated in your data map alongside the database it was derived from, not treated as cache.

Deletion is where this becomes concrete, and it is worth working out before someone asks. When a user exercises erasure, deleting the source row is not the end of the job: the vectors derived from that row still sit in the index, still match queries about that person, and still return their content. That means every chunk needs a durable link back to its source record so deletion can cascade, and it means re-embedding after a model change is a data migration with a privacy dimension rather than a background job. Design the cascade at the same time as the ingestion pipeline; retrofitting it into a live index is significantly harder than building it in.

What to Record

Keep four things where an auditor, a customer's security team or your future self can find them in a minute: the dated copy of the terms and DPA you relied on; the tier, endpoint and model identifiers you actually call, since those are what your residency and sub-processor answers are keyed to; the redaction rules your boundary client enforces, with the tests that prove it; and the retention windows for every store that holds a copy -- the provider's, yes, but also your logs, your traces and any derived index.

What none of that gives you is a timeline of Cohere's own behaviour, because your logs only contain your traffic. That gap matters more than it looks: when something goes wrong, the first hour is spent establishing whether the problem was yours or the provider's, and an independent record answers it immediately instead of by reconstruction.

Frequently Asked Questions

Are embeddings personal data under GDPR?

Treat them as personal data whenever they were derived from personal data, and you will be right in every case that matters. Embeddings are not anonymisation: they preserve the semantics of the source text by design, nearest-neighbour search over the index surfaces the original passages in response to queries about their subject, and published research on embedding inversion has shown that meaningful text can be reconstructed from vectors. Anonymisation, legally, is a high bar meaning the data can no longer be attributed to a person -- a representation that reliably retrieves the person's own text does not clear it. The practical consequence is simple: your vector store inherits the classification, the access controls, the retention schedule and the deletion obligations of the corpus it was built from.

Does Cohere train on data sent through the API?

Read the current terms and data processing addendum for your specific tier and deployment, since hosted API, private and VPC deployments can carry materially different commitments, and free or evaluation tiers frequently differ from paid ones. Where an opt-out or zero-retention arrangement exists, treat enabling it as a deployment step with a named owner rather than an intention. And keep a dated copy of the terms you relied on -- compliance evidence has to show what was true when the data was sent, not what the page says today.

Does a private or VPC deployment remove the privacy work?

It removes one question decisively and leaves the rest. Running inference inside your own boundary is the strongest available answer to where is my data processed, and it is worth the cost when your customers' contracts demand it. What it does not do is handle lawful basis, notices, subject access and erasure, or -- most importantly for the kind of system usually built on Cohere -- the classification and access control of the vector index and document store you built inside that boundary. A private deployment protects the inference path. It offers nothing at all against a retrieval endpoint that lets one tenant's query surface another tenant's chunks.

How do I honour a deletion request for data that has been embedded?

Plan the cascade during ingestion, because retrofitting it is the expensive version. Every chunk in the index needs a durable reference to the source record it came from, so that erasing the record can delete or tombstone the derived vectors in the same transaction or the same job. Without that link you cannot prove deletion, and the index will keep returning the person's content to any query about them. Include the vector store in the same data map entry as its source, give it a retention schedule, and remember that re-embedding after a model change is a data migration with a privacy dimension rather than a background maintenance task.

Should I redact text before embedding it?

Usually yes, and it costs less retrieval quality than teams expect. Names, emails, account numbers and internal identifiers are rarely what makes a passage retrievable -- the meaning is -- so pseudonymising them before embedding leaves the semantic content intact while sharply reducing what a leaked index or a successful inversion actually yields. Do the redaction in the same boundary client that handles your completion calls, so there is one implementation and one test suite, and keep the mapping in your own database for re-substitution after retrieval.

Can one tenant's query retrieve another tenant's documents?

It happens more often than anyone would like, and it is the defect worth auditing first in any production RAG system. The pattern is that permissions were enforced in the document application but not in the retrieval layer, so the chat interface performs a similarity search across the whole index and returns passages the asking user could never open directly. Enforce tenant and permission filters inside the vector query itself rather than filtering results afterwards, test it with a deliberately adversarial query from a low-privilege account, and treat a retrieval endpoint as a data-access endpoint with the same review a document API would get.

Related Guides

Retrieval Can Degrade Without Erroring, and Your Logs Will Not Say So

When embedding or rerank calls start failing intermittently, a RAG pipeline usually answers anyway -- from thinner context, with no error to catch. API Status Check probes api.cohere.ai and the rest of your stack independently and alerts on latency and errors, so a provider degradation surfaces as an alert rather than as a slow drift in answer quality.

Start Your Free Trial →