Your embeddings are your data: five questions for sovereign AI search

When an organisation assesses an AI search or assistant project, the data-residency conversation usually starts with documents. Where are the source files stored? Do they leave our environment? Who can read them?

Those are the right first questions. They aren't the last ones. AI search systems create new data from your documents: embeddings, indexes, extracted entities and relationships, cached chunks and logs. That derived data is built from your contracts, tickets, case notes and policies. It's your data too.

"Stored as vectors" doesn't automatically mean de-identified

It's tempting to treat embeddings as an abstract mathematical representation, too far removed from the original text to matter. Research suggests otherwise.

Third-party research (Morris et al., "Text Embeddings Reveal (Almost) As Much As Text", EMNLP 2023) showed that, in a lab setting with repeated query access to the embedding model, short passages could often be rebuilt exactly from their embeddings. The researchers conclude that embeddings should be treated with the same precautions as raw data. OWASP also lists embedding inversion as a risk for LLM applications (OWASP Top 10 for LLM Applications 2025, LLM08: Vector and Embedding Weaknesses).

The conditions matter: results vary with the model, the passage length and what access an attacker has. But the direction is clear. If your documents are sensitive, their embeddings deserve the same handling.

Five questions to ask of any AI search stack

These are questions for risk, data and platform leads to put to vendors, integrators and internal teams. They aren't legal advice. Your obligations depend on your sector and jurisdiction.

1. Where do the embeddings, indexes and relationship data physically live?

Not just the documents. Ask for the region, provider and storage service for each derived artefact, including backups and replicas.

2. Who can query them, and are document access rules carried through?

If a user can't open a document, should they be able to retrieve a passage from it through search? Access rules can be lost when documents are indexed unless they're attached on purpose. Ask how permissions are represented in the index and enforced at query time.

3. What actually happens when a record is deleted?

A delete that returns no error may not mean the data is physically gone. Ask how a delete reaches vectors, index structures, extracted relationships, caches, replicas and backups, and how long each one takes.

4. How many systems hold a copy?

A typical stack can hold derived data in a vector store, a graph store, a search index, a cache and an observability tool. Each is a system to assess, secure and include in incident response. Fewer systems generally means a smaller review.

5. Can it run where your data has to live?

For some organisations, in-region cloud is enough. For others, data must stay on their own hardware or within a particular jurisdiction's infrastructure. Ask whether the search stack can run self-hosted, what it needs to do so, and which features are only available in the vendor's own cloud.

Why this is getting more attention

Several things are converging. AI search is moving from pilots into production, which brings it into scope for formal security and privacy reviews. Boards and executives are increasingly accountable for how AI systems use data.

The practical consequence is that derived data needs a place in your data inventory, your retention schedules and your vendor assessments, alongside the source documents.

Design principles that help

• Inventory derived data. List every artefact your AI search system creates and where each one lives.
• Minimise copies. Every additional store that holds embeddings or relationships adds to what has to be assessed.
• Attach permissions at ingest. Carry document-level access information into the index rather than reconstructing it later.
• Test deletion end to end. Delete a test document and check it's gone from every store, not just the primary one.
• Prefer deployment options you control for sensitive corpora. Self-hosting puts the infrastructure decisions, and the evidence your auditors will ask for, in your hands.

Common questions

Are embeddings personal information? That depends on what was embedded and on the law that applies to you, so take advice for your situation. The research above is a good reason to handle embeddings of sensitive text as carefully as the text itself.

Does self-hosting solve data sovereignty on its own? No. It gives you control over where data lives and who operates the infrastructure. You still need access controls, deletion processes and monitoring that work across every store.

What should go in a vendor assessment? Every derived artefact, where it's stored, who can access it, how it's deleted and how long backups keep it.

Where CEREBRAL fits

CEREBRAL is the vector + graph database for AI search. It's built to keep vectors and relationships in one engine that runs where your data has to live: self-hosted on your own servers or in the cloud you choose, as a Docker image or inside your existing Postgres. One engine means fewer systems holding derived data.

We're early, and we'll be straightforward about it: CEREBRAL isn't yet certified against a formal framework (no SOC 2, IRAP or ISO 27001), and we won't imply otherwise. Self-hosting is designed to keep your data in your infrastructure.