AI and Data Privacy: Using Models Without Leaking Secrets

Every prompt is a data transfer

The moment an employee pastes a contract, a customer record, or a block of source code into an AI model, that text crosses a boundary. It leaves systems you control and lands in an environment governed by a vendor's terms, retention schedule, and sub-processors. People do not experience it that way — a chat box feels private, like a scratchpad. But a prompt to a hosted model is a data transfer to a third party, and it deserves the same scrutiny you would apply to uploading that same file to any outside service.

This is a narrower problem than "AI governance" in general. It is specifically about confidentiality: what happens to the data you send, who can see it, how long it persists, and what you can do to keep the sensitive parts from ever leaving your boundary. The controls are concrete, and most of them are things a well-run security program already knows how to do.

What a hosted model actually does with your input

Before you can manage the risk you have to know the mechanics. When a prompt reaches a third-party model, several things can happen to it — and the defaults differ enormously between plans.

• Training use. The single biggest privacy question is whether your input is used to improve the vendor's future models. If it is, fragments of your data can influence weights that other customers query. Enterprise and API tiers typically exclude customer content from training by contract; free consumer tiers frequently reserve the right to use it unless you opt out — and most employees never do.
• Retention. Even when data is not used for training, it is usually stored for a period — commonly to detect abuse or meet legal-hold obligations. Retention windows range from zero-retention options on some enterprise plans to 30 days or longer on standard tiers. Anything retained is anything that can be subpoenaed or breached.
• Human review. Some vendors allow staff or contractors to read a sample of conversations for safety tuning and quality. That means a human you have never met may read what your employee typed.
• Sub-processors. The model provider rarely runs everything itself. Cloud hosting, content moderation, and analytics may involve downstream companies, each an additional party with access.
• Logging and telemetry. Prompts and outputs land in application logs, observability pipelines, and support tooling — surfaces that outlive the conversation and are often less protected than the model itself.

Figure: privacy holds only when access control and encryption follow the data across the boundary — not just up to it.

None of these are hypothetical harms. They are ordinary properties of any hosted service. The reason AI feels riskier is volume and sensitivity: models invite people to paste exactly the material — full documents, raw records, entire code files — that a cautious employee would never email outside the company.

Enterprise tiers exist for exactly this reason

The gap between a consumer account and an enterprise agreement is not cosmetic; it is the whole privacy story. Before approving any model, get answers to these in writing — from the contract or data processing addendum, not the marketing page:

1. Is customer content excluded from training? You want an unambiguous "no training on your data" commitment, not a toggle buried in settings.
2. What is the retention period, and can it be zero? Shorter is safer; a zero-retention or ephemeral option is the gold standard for sensitive workloads.
3. Is there human review of inputs, and can it be disabled?
4. Where is the data processed and stored? Region matters for data residency and for regulations that restrict cross-border transfer.
5. Who are the sub-processors, and are they disclosed and contractually bound?
6. Will the vendor sign a DPA — and a BAA if you handle PHI? No BAA means the tool cannot legally touch health data, full stop.

The practical failure is not that enterprise terms are unavailable. It is that employees reach for the free consumer app because it is one click away, while the approved, contractually protected tier requires a login they never set up. Close that convenience gap or people route around it.

Keep the crown jewels inside your boundary

For your most sensitive data, the strongest control is architectural: do not send it to an outside model at all. Two patterns make that practical without giving up the capability.

• Private or self-hosted models. Open-weight models running inside your own cloud tenant or data center mean no prompt ever leaves your boundary. For regulated data, trade secrets, and anything under HIPAA or export control, this removes the third-party question entirely — you are now protecting your own infrastructure, which you already know how to do.
• Retrieval-augmented generation with access control. Rather than pouring your documents into a model, keep them in a governed store and retrieve only the relevant passages at query time. Done right, retrieval enforces the same permissions the user already has, so the assistant can never surface a document the person asking is not entitled to read. Data privacy survives because your content stays in a system you control and inherits its access rules instead of being flattened into a model that answers anyone.

Designing this well — where inference runs, how retrieval respects permissions, what leaves the boundary and what never does — is the core of an enterprise AI practice rather than an afterthought bolted onto a chatbot.

Minimize and redact before anything leaves

Whatever tier you use, send the model less. Most tasks do not need real identifiers to produce a useful answer, and every field you strip is a field that cannot leak.

• Field minimization. Pass only the data the task genuinely requires. A model summarizing a support ticket rarely needs the customer's full account number or home address.
• Redaction and tokenization. Replace names, government IDs, card numbers, and account references with placeholders before the prompt goes out, then map them back in your own environment after the response returns. The model reasons over structure without ever seeing the raw identifier.
• Synthetic and sample data for testing. When building and demoing AI features, use manufactured records. Real production data has no business in a prototype.

Minimization is the cheapest privacy control there is: data you never transmit needs no contract, no retention promise, and no trust in a stranger's logging hygiene.

Put the AI egress path under DLP

The controls above assume people follow the rules. Data loss prevention is how you cover the cases where they do not. Route AI traffic through the same inspection layer — a secure web gateway or SASE broker — that already governs email and file uploads, so a prompt carrying PII, PHI, cardholder data, source code, or credentials is inspected on the way out and blocked or warned exactly like any other risky egress. The point is uniformity: a generative-AI destination should not be a special unmonitored channel that your classification policy happens to ignore. Our data loss prevention practice extends existing data-type policies to cover AI endpoints so the safe behavior is enforced, not merely requested. Inline warnings that let an employee self-correct also double as just-in-time training — people learn where the line is at the moment it matters.

Consent, legal basis, and the paper trail

Privacy is a legal obligation before it is a technical one, and AI does not pause it. Feeding regulated or personal data to an unvetted model can itself be the violation — no breach required.

• Legal basis and notice. Under GDPR, CCPA/CPRA, and similar regimes, personal data sent to a model is still processing that needs a lawful basis, and your privacy notice should reflect that an AI vendor may act as a processor.
• Contracts, not assumptions. The DPA, and a BAA where health data is involved, is what makes the vendor a bound processor rather than an uncontrolled recipient.
• Fold it into existing evidence. Treat AI data flows as part of your security compliance program so an auditor sees one controlled process — data types, destinations, terms, and DLP enforcement — instead of an unmanaged exception discovered during the assessment.

Use the models, keep the secrets

You do not have to choose between AI's productivity and your confidentiality obligations. Be deliberate about the boundary: know what each tier does with your data, keep the most sensitive material on private or retrieval-based architecture, minimize and redact what you do send, enforce it with DLP on the AI egress path, and rest it all on real contracts and consent. Together, those controls let people use capable models on real work without turning every prompt into an uncontrolled disclosure.

intSignal helps enterprises adopt AI without leaking secrets — privacy risk assessment of current AI usage, private and RAG architecture that keeps data in your boundary, redaction and DLP on the AI egress path, and vendor terms mapped to your compliance obligations. Talk to our team and put a privacy boundary around your AI before the next paste becomes the next incident.