Private AI storage is achievable, but only if one control is done properly: enterprise key custody covering both your primary data and everything the AI model derives from it. Encryption alone doesn’t cut it. Neither does trust a vendor’s compliance badge. You need documented key ownership, GDPR-aligned governance under the EU AI Act, and enforced retention rules at the storage layer itself.

---

TL;DR:

• Proper AI storage privacy requires controlling encryption keys and model artifacts, not just relying on encryption or vendor compliance badges.
• Regulated workloads demand custody of keys for all derived data, including embeddings, checkpoints, and outputs, with regular rotation.
• GDPR and the EU AI Act mean models trained on personal data can still contain sensitive information, requiring documented assessments and specific data governance.
• Immediate action steps include mapping data flows, controlling key custody, enforcing audit trails, and revising vendor contracts to restrict model training on your data.
• Embeddings, prompt logs, and retrieval indexes pose additional privacy risks, necessitating controls like tokenization, retention policies, and staff awareness to prevent leaks.

---

Table of Contents

• What “AI saugyklos privatumas” actually requires
• How GDPR and the EU AI Act change what “private” means
• Practical checklist: what to do this quarter to reduce privacy risk
• The AI-specific risks: embeddings, RAG indexes and prompt logs
• Done’s perspective: implementing GDPR-aware private AI storage for SMBs
• Where the conventional advice falls short
• How Done can help with a private AI storage audit
• Sources

What “AI saugyklos privatumas” actually requires

AI storage privacy isn’t a single setting you flip on. It’s a stack of controls, each covering a different failure mode. The industry term for this discipline is AI data governance, and it covers everything from encryption to who can query your vector database at 2am.

Here’s what actually matters, based on how Scality’s guidance on AI storage for sensitive data frames the problem: basic encryption is assumed, not impressive. What separates a genuinely private setup from a vulnerable one is what happens to the keys and the artifacts your AI model creates along the way.

• Encryption in transit and at rest is the baseline. If a vendor can’t confirm this, stop the conversation there.
• Key custody and rotation must extend beyond source data to embeddings, checkpoints and model outputs. Scality’s own position is blunt: for regulated workloads, key custody for derived artifacts matters more than the encryption itself, because a single compromised key can expose both live data and historic embeddings if rotation isn’t per-artifact.
• Classification and tagging at ingestion means every file gets a sensitivity label the moment it enters storage, so access decisions get evaluated on every read, not just at upload.
• Immutable audit trails enforced through Object Lock or WORM (write once, read many) storage stop anyone, including an admin under pressure, from quietly deleting evidence after an incident.
• Access control and least privilege, backed by role-based permissions and monitored privileged sessions, close the gap that most breaches actually exploit: someone with more access than their job needs.

Pro Tip: Ask your AI vendor one question before anything else: “Where do the encryption keys for our embeddings live, and who can rotate them?” If they can’t answer in under thirty seconds, that’s your answer about how seriously they take custody.

How GDPR and the EU AI Act change what “private” means

Regulators no longer accept “the data is anonymised” as a closed case. The European Data Protection Board’s opinion on AI models makes clear that a model trained on personal data can still retain information that legally counts as personal data, buried in its parameters. Deciding whether a model is genuinely anonymous requires a detailed, documented assessment, not a footnote in a privacy policy.

That has practical consequences for anyone storing data that feeds an AI system:

• Pseudonymisation reduces risk but rarely satisfies GDPR on its own once a model has ingested the underlying data.
• The EU AI Act’s Article 10 imposes data governance duties on training datasets, meaning you need documented provenance, quality checks and bias review, not just a folder of files.
• A Data Protection Impact Assessment (or the newer PDAV framework some Lithuanian legal commentators recommend) should capture exactly which storage systems hold training data, who can access derived artifacts, and how retention is enforced.
• Vendor contracts (your DPA) need explicit clauses: no training on your data by default, defined data residency, and audit rights you can actually exercise.

Some legal commentary, including Allaw’s argument for multidisciplinary data protection teams, suggests a single data protection officer can no longer keep up with AI Act monitoring obligations alone. For most SMEs, that means either building a small internal team or leaning on outside specialists for the technical review a DPIA now demands. Our practical guide to GDPR AI compliance walks through what that documentation should look like in practice.

Practical checklist: what to do this quarter to reduce privacy risk

You don’t need a six-month programme to materially cut your exposure. These six steps, done in order, close most of the gaps we see in client audits.

1. Run a data-flow inventory. Map every place personal or commercially sensitive data enters your AI pipeline, and classify it at the point of ingestion, not after the fact.
2. Move key custody to an enterprise HSM or KMS. Stop relying on a vendor’s default key management. Insist on keys you control, with rotation schedules that cover derived artifacts as well as source data.
3. Tokenise or pseudonymise before any external model call. If data leaves your infrastructure to reach a third-party API, it should already be stripped of direct identifiers.
4. Set Object Lock and immutable audit logging on any storage bucket touching sensitive or regulated data, so retention policies can’t be quietly bypassed.
5. Rewrite your vendor DPAs. Ban training on your data by default, or require an explicit, configurable opt-in with a paper trail.
6. Run a DPIA, then stress-test it. Membership-inference and extraction tests reveal whether your model actually leaks training data, not just whether your paperwork says it shouldn’t.

Pro Tip: Do steps 2 and 4 first. They’re the two controls that stop a breach turning into a regulatory finding, and both can usually be implemented without touching your AI vendor contract at all.

Our AI data privacy guide for SME leaders breaks these steps down further for non-technical managers who need to brief a board on progress.

The AI-specific risks: embeddings, RAG indexes and prompt logs

Most privacy checklists were written for files and databases, not for the artifacts an AI system generates as it runs. That gap is where the real exposure sits.

Vector embeddings and RAG (retrieval-augmented generation) indexes need the same custody as your source data, arguably more, because they’re rarely treated with the same caution. An embedding can be reversed to reconstruct fragments of the original text under the right conditions, a technique known as model inversion. The Cloud Security Alliance’s AI data security guidance maps controls specifically for this, recommending dedicated defences for prompt injection, model inversion, federated learning governance and shadow AI detection, alongside the standard DSP-01 through DSP-24 storage controls most security teams already know.

RAG pipeline hygiene matters just as much as the underlying storage. Tokenise inputs before retrieval, apply filters that limit what a query can pull back, and keep context windows small and auditable rather than dumping entire document sets into a single prompt.

Prompt logs deserve their own retention policy: redact identifiers, set a hard expiry, and make sure someone can audit who read them. Differential privacy, where a calibrated amount of statistical noise is added to protect individual records, is a genuine option here too. Procurize’s work on differential privacy for automated pipelines found epsilon budgets around 0.45 to 0.5 preserved usable functionality while meaningfully limiting leakage, though it requires ongoing monitoring of cumulative epsilon rather than a one-off setup.

One more thing worth flagging: employees pasting confidential data into consumer AI chat tools, so-called shadow AI, is an active and underestimated leak point. Anonym points to local masking tools, similar in spirit to OpenAI’s Privacy Filter, a model built to detect and mask personal data before it ever leaves a device, as a practical countermeasure alongside staff training and DLP monitoring for prompts.

Done’s perspective: implementing GDPR-aware private AI storage for SMBs

We build private, on-premise and hybrid AI deployments for clients in legal, finance, accounting and healthcare, sectors where “the vendor says it’s compliant” isn’t an acceptable answer. That means running the audit, setting up key custody, and training the team who’ll operate the system daily.

A pattern we’ve seen repeatedly: a client runs an audit, discovers their embeddings had no rotation policy at all, applies Object Lock and enterprise key management, and their next external security review comes back with a measurably shorter list of findings. The fix isn’t glamorous. It’s mostly paperwork and configuration.

Contract terms we push clients to insist on with any AI vendor:

• A written no-training clause, or an explicit, revocable opt-in
• Enterprise key custody, not vendor-managed keys by default
• Audit rights you can actually exercise, not just a promise of one
• Defined data residency and breach notification timelines in the SLA

Our guide on protecting confidential data in AI workflows covers the technical setup in more depth.

Where the conventional advice falls short

Most guidance on this topic treats encryption as the finish line. It isn’t. Encryption protects data sitting still; it does nothing once that data has been absorbed into a model’s weights or scattered across a thousand vector embeddings. That’s the gap the EDPB is now pointing directly at, and it’s the gap that catches SMEs who bought an “AI-ready” storage product and assumed the label meant something.

The second overrated idea is that pseudonymisation solves the legal problem. It reduces risk, but a model trained on pseudonymised data can still leak identifying detail through inference, which is precisely why the EDPB insists anonymity claims need documented assessment rather than a checkbox.

What actually moves the needle, in order: key custody for derived artifacts, immutable audit logging, and a DPIA that includes real extraction testing rather than a policy document nobody has stress-tested. Everything else, the dashboards, the certifications, the vendor marketing pages, is secondary. If you can only fix one thing this year, fix custody. It’s the control that determines whether a breach stays contained or becomes a regulatory finding with your company’s name on it.

— Thomas

How Done can help with a private AI storage audit

Reading a checklist is one thing. Implementing key custody, Object Lock and a working DPIA alongside a business you’re already running is another. This is where we spend most of our time with clients.

Done has been building GDPR-aligned AI deployments since 2014, across more than 350 client projects, many in sectors where data sovereignty isn’t optional. We handle the AI consulting, the private and on-premise deployments, KMS and HSM setup, DPIA support, and the staff training that makes all of it stick once we’re gone.

A first engagement is deliberately small: a short gap audit against the controls covered here, a risk-prioritised roadmap so you know what to fix first, and a fixed-cost proposal with no surprises. No setup fees, no long lock-in. If you want to know exactly where your current AI storage setup stands against GDPR and the EU AI Act, book a short audit through our AI consulting services for SMBs and we’ll tell you plainly what needs fixing and what already works.

Sources

• EDPB opinion on AI models and anonymisation (2024/2025)
• Data security within AI environments — Cloud Security Alliance
• AI storage for sensitive data: what to know — Scality
• Introducing OpenAI Privacy Filter

Recommended

• AI data privacy: a practical guide for SME leaders
• GDPR AI compliance: a practical guide for European SMEs
• Private AI deployment: an honest guide for SMBs
• AI and GDPR: A clear guide for European business owners