AI Data Security and Compliance Basics

AI data security starts with understanding where information goes, who can access it and what the provider may retain. Use this guide to frame a technical and contractual review of your workflow.

AI data security: what actually happens to your data

When your application calls a hosted model, the text you send travels to the provider, the provider processes it, and a response comes back. The questions that matter are what happens in between and afterwards: does the provider retain it, for how long, who can see it, and does it train future models on it.

However, the answers differ sharply between the consumer and enterprise tiers of the same provider. For example, consumer chat products have historically trained on user input by default. Data-use policies, retention controls and agreement availability vary by provider, endpoint, product tier and eligibility. Verify the terms that apply to the exact service before sending business data. Same brand, materially different contract.

In short, this distinction is the entire practical security conversation for most organizations, and it is the one teams most often skip.

The contract terms to check

Get these in writing before you send anything sensitive:

• Training exclusion. Explicit contractual confirmation that the provider does not use your inputs and outputs to train models.
• Retention period. How long the provider stores inputs, and whether zero retention is available. Many providers retain briefly for abuse monitoring, so know the number.
• Data residency. Which region processes the request. This matters for GDPR and also for certain U.S. state and sector rules.
• Subprocessors. Who else touches the data. A consultancy using a model provider means at least two parties in the chain, so your agreements need to cover both.
• Breach notification. Timeline and mechanism, consistent with your own obligations.
• BAA or DPA availability. Required for protected health information and for European personal data respectively.

In practice, these six terms decide most AI data security questions before any engineering begins. If a provider cannot answer one of them clearly, therefore, treat that gap as a finding.

AI data security controls that matter more than model choice

1. Send the minimum

   Strip or tokenize identifiers that the task does not require. A classification task rarely needs a name, an address and an account number attached. In fact, this is the single most effective control available.

2. Enforce permissions before retrieval

   In any RAG system, filter documents by the requesting user’s access rights before they reach the model. Filtering after generation is not a control but a hope. Our explainer on what RAG is covers how retrieval works.

3. Log the whole path

   Input, retrieved context, model response, action taken. Required for audit and indispensable for debugging. Where regulation requires, however, log the reference rather than the raw sensitive payload.

4. Isolate by tenant and environment

   Development should never use production data unmasked. This is ordinary practice that AI projects routinely violate because realistic test data is convenient.

5. Set an egress policy

   Decide which categories of data may reach an external model at all, write it down, and enforce it in code rather than in a policy document nobody reads.

That is also why a short written AI use policy matters. It should name the approved tools, the categories of data that must never go into them, and who to ask when unsure. Because staff follow rules they can remember, keep it to one page. Then review it whenever you add a tool or change provider, so AI data security keeps pace with what people actually use.

Risks that are specific to AI applications

Traditional application security still applies, but AI systems add a few new ways for data to leak. For example, the OWASP Top 10 for LLM Applications is a useful reference list for your engineers. In our reviews, these are the issues we check first.

• Instructions hidden in content. For instance, a retrieved document or an incoming email can contain text that tries to redirect the model. So treat all retrieved content as untrusted input.
• Sensitive data in outputs. A model can repeat whatever reaches its context, so the permission filter has to run first.
• Over-permissioned tools. When an assistant can call systems, give it only the actions the task needs, with read-only access wherever possible.
• Logs that hold too much. Debug logs, for example, often capture full prompts. Consequently, they need the same access controls and retention rules as the source data.

How we run an AI data security review

We run this review before any build starts, and it usually involves your IT, legal and operations leads together.

• Map the data flow. First, we draw every hop from source system to model and back, including logs and backups.
• Classify what travels. Next, we tag each field by sensitivity and ask whether the task truly needs it.
• Check the terms. Then we confirm the six contract terms for the exact tier and endpoint you will use, since terms vary within one brand.
• Design and test the controls. After that, we build minimization, permission filtering and logging, and we test them with deliberately awkward cases.
• Write it down. Finally, we document the flow and controls, so your next audit starts from evidence rather than memory.

A checklist before go-live

Then use this table as a final gate before launch. If any row lacks evidence, hold the launch until it has some.

Keep this evidence together with your other security documentation. As a result, answering an auditor or a customer security questionnaire becomes a matter of sending files rather than reconstructing decisions. Also revisit the table whenever you change provider, tier or data sources, because each change can reopen a settled question.

Do you need to self-host?

Running open-weight models on your own infrastructure removes the third-party processing question entirely, and for a small set of organizations, classified work, certain financial and defense contexts, it is the only acceptable answer.

For everyone else, however, it is usually the wrong trade. You take on GPU cost, model maintenance, security patching and an accuracy gap against frontier models, in exchange for a risk that an enterprise agreement already addresses. Therefore, decide this on your regulatory obligations rather than general unease. In short, self-hosting can strengthen AI data security in narrow cases, but it should not be the default.

For implementation support, explore our AI security consulting or discuss your workflow in a free consultation.

For a structured approach to AI risks and evaluation, consult the NIST AI Risk Management Framework.