Data Security for AI Workloads

An AI workload moves data through more places than the application it replaces. Documents become embeddings. Prompts carry customer records into a model’s context. Conversations land in logs. Fine-tuning can leave traces of data in model weights. Each copy has its own storage, its own access path and, often, no named owner.

Data security programs built around databases, file shares and SaaS stores do not cover those copies by default. The classification exists for the source system. The vector index built from it has none.

This article follows the data through the AI lifecycle. The model supply chain and the risks of staff pasting data into AI tools are separate problems, covered in the related pieces.

Where the data actually sits

The retrieval problem most programs miss

Retrieval-augmented generation is the most common way enterprises connect a model to their own data, and it is where access control most often breaks.

The pattern is simple. A team indexes a document store so an assistant can answer questions about it. The indexing job runs under a service account with broad read access. Every document, whatever its original permissions, goes into one index. A user then asks a question, and the assistant retrieves and summarizes content the user was never allowed to open. Nothing was hacked. The permission model was left behind at indexing time.

Encryption does not fix this. Encrypting the vector database protects the disk. It does nothing about who is allowed to retrieve from it. Embeddings are derived from the source content and deserve the same classification as the content.

The control is authorization at retrieval, using the identity of the person asking, not the identity of the application. That has costs: permission data has to stay in sync with the source, and filtering adds latency. If an index cannot enforce the source permissions, limit it to a population cleared for everything inside it. That is a smaller assistant, and the honest alternative.

What the guidance says

NSA, CISA and partner agencies published a joint information sheet on securing the data used to train and operate AI systems. It names three data risk areas: the data supply chain, maliciously modified data, and data drift. Of its ten practices, these matter most for the stages above:

• Track data provenance and verify sources.

• Protect integrity in storage and transfer, including digital signatures on original data.

• Classify data by sensitivity and give AI outputs the classification of their inputs.

• Encrypt at rest and in transit, and protect data in use with trusted infrastructure.

• Delete securely, including cryptographic erase, before systems are reused or retired.

• Reassess risk continuously rather than once at launch.

The OWASP Top 10 for LLM Applications describes the same exposure from the application side. Its entries on sensitive information disclosure, data and model poisoning, and vector and embedding weaknesses line up with the stages in the table. This is guidance and community research, not settled standard. Use it as a baseline to test against your own architecture.

Keys, retention and deletion

Customer-managed keys let you separate data domains. If a dataset, its derived index and its fine-tuned model are encrypted under one dedicated key, destroying that key retires every copy held under it. That is a practical form of deletion for data that is otherwise hard to find and erase.

The limit matters. Copies in logs, caches and backups encrypted under other keys are not covered. Map where copies live before promising deletion to a regulator or a customer.

Retention needs the same attention. Prompts and conversation history accumulate quietly. Decide how long they are kept, who can read them and whether the provider may use them for its own purposes. For a third-party service, the answer is in the contract and the product settings, not in the marketing page.

Where to start

1. Map the data flows. For each AI system, list the data it touches and every place a copy lands: indexes, caches, logs, fine-tuned models, vendor-held data.

2. Classify the copies. Give indexes, logs and model artifacts the classification of the data behind them, and a named owner.

3. Fix retrieval authorization for any assistant that indexes internal content. Start with the ones that index HR, legal, finance or customer records.

4. Set retention for prompts, outputs and logs, and check vendor terms on retention and reuse.

5. Add provenance and integrity checks to training and fine-tuning data.

6. Use dedicated keys per data domain where deletion or separation matters.

For leadership, the decision is who owns AI data stores. Data owners know the source systems. Platform teams run the indexes. Without a named owner for each copy, nobody answers the question a regulator or customer will ask: where is our data in this system?

Use this to strengthen protection of critical data: choose the AI system that touches your most sensitive data and trace every copy it creates. The first map is usually the most revealing.

Sources

• NSA, CISA and partner agencies, AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems. Joint cybersecurity information sheet. media.defense.gov

• OWASP GenAI Security Project, OWASP Top 10 for LLM Applications. https://genai.owasp.org/llm-top-10/

• NIST, AI Risk Management Framework and the Generative AI Profile. nist.gov