When a company's confidential data is processed by an AI system risks appear at every stop along the pipeline. Compliance for retrieval-augmented generation is thornier than for traditional databases because RAG inherently lacks an audit trail. A single query reads, retrieves, and summarizes across multiple sources within seconds, while regulations like GDPR and HIPAA require companies to account for where personal data is stored and how it is used. Once the system surfaces personal data in an answer where it should not appear, demonstrating compliance after the fact is often extremely difficult.
The following breakdown examines risks by the four "states" of data. These four states — at rest, in transit, in use plus logs, and residency plus access — reflect generally accepted security concepts, though organizing them as a four-item checklist is this guide's framing, not an official classification from any compliance standard such as ISO 27001 or SOC 2.
Data at rest
Data at rest appears in vectors and original-text chunks in the vector database, model weights after fine-tuning, logs, and backups. Primary risks: original text often sits in plaintext scattered across multiple locations; vectors have been demonstrated to be reversible back to original text, with short text fragments recovered at a high success rate, and newer methods do not even require training specifically against the target embedding model; OWASP explicitly recommends treating a vector-only leak the same as a plaintext leak — "stored as vectors" does not mean "de-identified"; weights memorize training data and are difficult to selectively delete. Mitigations include encryption at rest with customer-managed keys, strict access controls, and ensuring data can be fully deleted.
Data in transit
Data in transit appears across every transmission within the system. RAG is inherently distributed — a single query triggers multiple internal transfers: query sent to vector database, document chunks retrieved, chunks forwarded to model. The most critical of these is the complete prompt being sent to a cloud-hosted model. Primary risks: TLS (the padlock in the browser bar) only prevents third-party eavesdropping mid-transit — it does not keep the content confidential from the recipient. Using a public cloud-hosted model means the confidential original text genuinely leaves the company's boundary and is processed by another company. Mitigations include self-hosting or using inference services meeting data sovereignty requirements, redacting before sending, and clearly defining which data must never leave the boundary.
Data in use plus logs
Data in use plus logs appears in the KV cache held temporarily during inference and the complete prompt and response recorded by the logging platform. Primary risks: the most easily overlooked yet highly risky — logs are a persistent plaintext copy of confidential content; if the contract permits, they may also be used for training or retained long-term. Mitigations include redacting before logging, setting maximum retention periods (for example, 30 days), and contractually specifying usage restrictions.
Residency plus access
Residency plus access appears as the physical location of each storage and inference component (which country, which legal jurisdiction) and access controls when RAG retrieves original documents. Primary risks: cross-border transfers may violate local regulations; unauthorized retrieval — the moment a document is converted into vectors and indexed, its original access permissions are stripped away; without explicitly re-attaching them, the system will retrieve and include content the user has no right to view. Mitigations include ensuring storage locations are compliant, binding every chunk to the source document's permission list (ACL) at indexing time, and filtering by querying the user's identity in real time during retrieval.
Three counterintuitive points worth calling out separately
Deletion is often an illusion. For performance reasons, vector databases default to "soft deletion" at the metadata layer — an API returning no error is taken as successful deletion, but the data may still physically exist. This is the same pain point as "weights are difficult to selectively delete," manifesting at a different storage layer — and GDPR Article 17 requires true, complete deletion.
Redaction is not as simple as blacking things out. Naive redaction destroys semantics: if you simply strip out names or account numbers, the model also loses the information it needs to produce a useful answer. For example, "Customer ___'s account ___ was double-charged" leaves the model with a broken sentence it cannot properly process. The correct approach is context-preserving tokenization rather than brute-force removal: replace "John Smith" with [NAME_1] and the specific account number with [ACCOUNT_1], producing "Customer [NAME_1]'s account [ACCOUNT_1] was double-charged." The sensitive values are hidden from the model, but the role information — "there is a name here," "there is an account number here" — is preserved, so the model can still follow the sentence structure and produce a useful answer, instead of staring at a bunch of blanks.
Permissions are lost by default. Documents from Confluence, SharePoint, or an internal wiki — once converted into vectors, their original access controls no longer travel with them. This is precisely why "binding ACLs" must be done as an explicit additional step — it does not happen automatically.
Two conclusions most worth remembering
The single most sensitive action across the entire pipeline is the moment confidential content is assembled into a complete prompt and sent to a cloud-hosted model — this is the point at which data truly leaves the company's control.
The single most easily overlooked risk point is the logging system — all the attention goes to "is the database secure" while forgetting that the logs also contain a complete plaintext copy of every conversation.
What a managed cloud model actually retains
MaaS (Model-as-a-Service) refers to cloud-hosted models accessed via network calls, as opposed to self-hosted deployments. What it actually retains is a key compliance question: weights are read-only — the content of your queries does not get written into the model's parameters or change the model itself. "The model has its own storage" is a common misconception — unless the provider deliberately uses conversations for subsequent training, which is a separate matter.
Prompt caching is an easily overlooked short-term landing point: if the provider enables cross-request prompt caching, a portion of the request content resides briefly in their infrastructure in the form of KV cache. This is not the same as training or long-term retention, but strictly speaking, inference is not entirely stateless.
What is actually retained long-term is logs (complete Q&A plaintext), abuse-detection records, and (when the contract allows) data used for training — whether it is retained, and for how long, depends on contract terms and technical settings.
Zero Data Retention (ZDR) is a contract clause that, once signed, disables the persistent retention described above. But you should verify whether it covers infrastructure-level short-term residency like prompt caching, to avoid leaving a gap. OpenAI's documentation notes that, at least for some models, organizations with ZDR enabled default to keeping the cache in memory only, without the extended 24-hour retention option.
Take OpenAI as an example: its API has defaulted to not training on customer data since March 2023, but every API call still generates "abuse-monitoring logs" that may include prompts and responses, retained for up to 30 days; excluding this requires applying for Zero Data Retention and getting OpenAI's advance approval. So "won't train on your data" and "won't retain your data" are two separate questions — ask about them separately when evaluating a provider.
Measured recovery risks
Research demonstrates that text embeddings reveal nearly as much as text itself. On one model, 32-token text is recovered exactly 92% of the time; on another, 32-token recovery is 60.9%, dropping to 8.0% at 128 tokens; 89% of patient full names could be recovered from clinical-note fragments. These findings reinforce the importance of treating vector storage with the same care as plaintext storage.
What this means for development teams
Teams building RAG systems should treat the four data states as a checklist for threat modeling. Encryption, access controls, and clear data-retention policies must cover each state, not just the ones that feel most immediate. Redaction strategies should preserve semantics through context-preserving tokenization. ACLs from source documents must be explicitly bound at indexing time, not assumed to travel with vector representations. And the logging system should be treated as a persistent plaintext copy of every conversation, with retention and usage governed by contract terms.
The most sensitive moment in the pipeline is when a complete prompt containing confidential content is assembled and sent to a cloud-hosted model. At that point, data has left the company's control. Logging systems should receive the same attention as the vector database, because they contain a full plaintext record of every interaction..Provider contracts should be read carefully to distinguish between "won't train on your data" and "won't retain your data" — these are two separate questions with different implications for compliance.