Where does your AI's memory actually live?

Look at what accumulates in an AI memory after three months of real use: client names, contract terms, salary discussions, the architecture of systems you are responsible for, the medical detail you mentioned once to explain a deadline slip. It is not a cache. It is a dossier, and you built it by being useful to yourself.

Now answer three questions about it. Which country is that data in? Who can read it? What happens to it if the company folds next year? Most memory products do not make those answers easy to find, and a few genuinely cannot answer the first one.

What the GDPR actually says (and does not)

The GDPR does not ban storing data outside Europe, and anyone selling you "EU hosting or you are illegal" is overselling. What it requires is a lawful basis, purpose limitation, security appropriate to the risk, and — when personal data leaves the EEA — a valid transfer mechanism with safeguards that actually hold up.

That last part is where it gets awkward. In Schrems II the Court of Justice struck down Privacy Shield and made clear that a contractual clause does not help if the destination country's surveillance law overrides it. The EDPB's follow-up recommendations pushed controllers toward supplementary technical measures, which in practice often means: keep it in Europe, or encrypt it so the provider cannot read it.

Two consequences that matter when you choose a memory service:

• If you are a company processing client data, the memory store is a sub-processor. You need a DPA, and you need to know where it runs — not for purity, because your own customers will ask.
• If you are an individual, none of this is a legal obligation for you. It is still the difference between data under EU jurisdiction and data under someone else's.

"GDPR compliant" is a claim, not a certificate

There is no GDPR certification body issuing badges. When a vendor writes "GDPR compliant" on a pricing page, that is a self-declaration. It might be entirely true. It is not evidence.

SOC 2 and ISO 27001 *are* audited, and worth something — but they audit whether a company does what it says it does, not where your bytes are or whether the answer suits you. A SOC 2 Type 2 report and US-only hosting can coexist perfectly.

So ignore the badges and ask for specifics:

1. In which country are the production database and its backups? Name the provider and the region.
2. Who has technical access to the plaintext, under what process, and is that access logged?
3. Is there a DPA I can sign, and does it list sub-processors?
4. How is tenant isolation enforced — by application code, or by the database?
5. Encryption at rest: is it disk-level, or can the provider not read my rows at all? These are very different guarantees.
6. If I leave: export format, deletion timeline, and does deletion include the backups?

A vendor who cannot answer six factual questions about their own infrastructure has told you something useful.

The isolation question nobody asks

Multi-tenant services keep customers apart in one of two ways. Either the application code filters by customer on every query, or the database itself refuses to return another tenant's rows.

The first is normal and works — until one query in ten thousand forgets the filter. That class of bug is behind a good share of the "we saw another user's data" incidents you have read about. The second costs more to build and fails closed: a missing filter returns nothing rather than someone else's memories.

It is a fair question to ask, and the answer tells you how the team thinks about the failure mode.

Zero-knowledge: useful, rare, and widely misdescribed

The strongest possible answer is that the provider holds no key and mathematically cannot read your data. Very few memory products offer it, for a boring reason: semantic search needs to compute over content. You can encrypt blobs the server cannot read, but then something has to do the embedding and the ranking, and that something needs the plaintext — on your device, or not at all.

So when you see "end-to-end encrypted" on a memory service that also does semantic search server-side, read it closely. Often it means TLS in transit and encryption at rest with a provider-held key. That is a reasonable design. It is not zero-knowledge, and the two get conflated constantly — including, to be blunt, in marketing copy across this whole category.

What we do, and what we don't

Pryzm runs on Hetzner in Germany. The volume holding the database is encrypted at rest at the block level. Each customer gets their own PostgreSQL schema and role, so isolation is enforced by the database engine rather than by our application code. Backups stay in the EU. Jurisdiction is European, and there is no US parent company in the chain.

What we do not claim: zero-knowledge. Technical administrative access to the servers exists — you cannot operate a database you can never touch — and it is restricted and logged. Our sealed mode, where we hold no key, is announced and not shipped; we label it that way on the site and we will keep labelling it that way until it ships.

If you would rather trust no provider at all, several self-hostable memory servers are good and free, and we list them in our comparison of the alternatives. Running your own is the strongest answer to this entire article.