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

What actually happens to your data

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

The answers differ sharply between the consumer and enterprise tiers of the same provider. 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.

This distinction is the entire practical security conversation for most organisations, and it is the one most often skipped.

The contract terms to check

Get these in writing before anything sensitive is sent:

  • Training exclusion. Explicit contractual confirmation that your inputs and outputs are not used to train models.
  • Retention period. How long inputs are stored, and whether zero retention is available. Many providers retain briefly for abuse monitoring; know the number.
  • Data residency. Which region processes the request. This matters for GDPR and 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, and both need to be covered.
  • 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.

Architectural controls that matter more than model choice

  1. Send the minimum

    Strip or tokenise identifiers that the task does not require. A classification task rarely needs a name, an address and an account number attached. 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, it is a hope.

  3. Log the whole path

    Input, retrieved context, model response, action taken. Required for audit and indispensable for debugging. Log the reference, not the raw sensitive payload, where regulation requires.

  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.

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 organisations, classified work, certain financial and defence contexts, it is the only acceptable answer.

For everyone else 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. Decide this on your regulatory obligations, not on general unease.

Frequently asked questions

Is it safe to send customer data to an AI provider?
On an enterprise tier with a signed agreement, no training on your data and defined retention, it is comparable to any other cloud processor you already use. On a consumer tier, treat it as publication. The tier and the contract are the whole answer.
Does SOC 2 cover AI use?
SOC 2 covers your controls, so it covers how you handle data in AI workflows as much as anywhere else. Auditors increasingly ask specifically about AI vendors, data flows and staff usage policy, so document those before the audit rather than during it.
What about the EU AI Act if we are U.S. based?
It applies if you place systems on the EU market or your outputs are used there. Most business automation falls into lower-risk categories with transparency obligations rather than heavy requirements, but classification should be checked deliberately rather than assumed.
Can we prevent staff using unapproved AI tools?
Partially, through network controls and policy, but enforcement alone has a poor record. The durable fix is providing a sanctioned tool that is fast enough that the workaround has no appeal.

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.