Keeping proprietary data out of public AI models
TL;DR
- Most data leakage to AI tools happens through shadow AI and consumer accounts, not through enterprise APIs that already promise not to train on your inputs.
- The controls that matter are tiered: no-training contracts and zero-retention API tiers for most work, VPC or self-hosted open models for regulated and high-sensitivity data.
- Pick controls by data class, not by vendor reputation. Write a one-page policy that says what can go where, then enforce it with access and routing, not memos.
What actually leaks, and what doesn't
Start with the part most people get backwards. When your team pastes a customer list into a consumer chatbot, the risk isn't usually that the exact text resurfaces in someone else's answer next week. The risk is that the data left your control: it sat on a third party's servers, under a consumer agreement you never read, with retention and training terms tuned for a free product rather than for your contracts.
The pattern we see across enterprise reviews is that the scary-sounding risk (a model memorising your secrets and regurgitating them) is rare and getting rarer, while the boring risk (the wrong data in the wrong account under the wrong terms) is everywhere. Training on inputs is real, but it's almost always tied to the tier you chose. Free and consumer tiers often reserve the right to use your conversations to improve the product. Paid enterprise API tiers from the major providers generally do not train on your inputs by default, and say so in the contract.
- Training on inputs: real on consumer and free tiers, generally off by default on enterprise API and business tiers.
- Retention: providers keep prompts and outputs for a window (often around 30 days) for abuse monitoring, even when they don't train on them.
- Prompt logging: your own stack (gateways, observability tools, analytics) often logs full prompts to places you forgot about.
- Shadow AI: staff using personal accounts and browser extensions, which is where most real exposure happens.
- Model memorisation and regurgitation: possible in theory, vanishingly rare for any single customer's data in practice.
The risk you keep underrating: shadow AI
If you only fix one thing, fix this. Shadow AI is the use of AI tools nobody approved: a developer pasting a stack trace with live credentials into a personal account, a sales rep running the entire pipeline through a free summariser, a finance analyst dropping a board deck into a browser plugin to 'clean up the wording.' None of it shows up in your vendor list, and all of it moves data outside your perimeter.
You can't govern what you can't see. Before you write a single policy line, get a read on what's already happening. Most teams are shocked by the answer. The fix isn't a ban (bans push usage further underground); it's giving people a sanctioned tool that's good enough that the personal account stops being worth the friction.
- Survey or log which AI tools are actually in use across teams before drafting policy.
- Provide one approved, well-configured tool so the safe path is also the easy path.
- Block known consumer endpoints at the network or browser level only after the sanctioned option exists.
- Watch browser extensions and IDE plugins closely; they're the quietest exfiltration route.
- Make it socially fine to ask 'can I put this here?' so people stop guessing.
Contract controls: no-training terms and zero-retention tiers
The first real lever is contractual, and it's cheaper than most people expect. Enterprise agreements with the major model providers let you turn off training on your data and, increasingly, turn off retention entirely. A zero-retention (sometimes called zero-data-retention) tier means the provider processes your request and keeps nothing after the response is returned: no 30-day abuse-monitoring window, no logs with your prompt text.
Read the terms rather than the marketing page. You want three things in writing: that inputs and outputs are not used for training, that retention is zero or a defined short window with a deletion guarantee, and that subprocessors are listed and bound by the same terms. A signed DPA (data processing agreement) and, where relevant, a BAA for health data, turn a vague promise into an obligation you can audit.
- No-training clause covering both your inputs and the model's outputs to you.
- Zero-retention or a defined, short retention window with documented deletion.
- A DPA naming subprocessors and binding them to the same standard.
- A BAA where you handle protected health information; equivalent terms for other regulated data.
- Clear data residency commitments if you operate under regional data rules.
Technical controls: self-hosting, VPC, and on-prem
When the data is sensitive enough that you don't want it leaving your network at all, contracts stop being the answer and architecture takes over. The strong-to-strongest options form a spectrum. A VPC deployment runs a provider's model inside your own cloud account, so traffic never crosses the public internet to a shared endpoint. Self-hosting an open-weight model (the kind you download and run yourself) means the weights and the inference both sit on infrastructure you control. On-prem takes that all the way to your own hardware.
Be honest about the trade. Self-hosting buys you maximum control and removes the third party entirely, but you inherit the cost: GPUs, MLOps staff, model updates, and the reality that the best open models still trail the best closed ones on hard tasks (the gap is narrowing fast). For most enterprises the right answer is a mix, not a religion: hosted enterprise APIs for the bulk of work, and a VPC or self-hosted lane reserved for the data that genuinely can't leave.
- VPC deployment: provider's model in your cloud account, private networking, no shared public endpoint.
- Self-hosted open-weight models: full control of weights and inference, full operational burden.
- On-prem: your hardware, for air-gapped or strict-residency requirements.
- Hybrid routing: cheap, capable hosted models for low-sensitivity work; private lane for the rest.
- Factor in total cost: GPUs and engineering time, not just the absence of a per-token bill.
Minimise before you send: redaction and data minimisation
Here's the control teams skip because it's unglamorous, and it's often the highest-leverage one. The safest data is the data you never sent. Before a prompt reaches any model, strip what the model doesn't need to do the job. A support summariser doesn't need the customer's full account number to write a helpful reply; it needs the issue. A contract analyser rarely needs real party names to extract obligations.
Build this into the pipeline rather than trusting people to remember. A redaction or tokenisation layer can detect and mask names, emails, card numbers, and identifiers on the way out, then re-insert them in the response if needed. It pairs well with every other control: even on a zero-retention enterprise tier, sending less sensitive data is strictly better, and it shrinks the blast radius if anything ever goes wrong.
- Send only the fields the task needs; drop the rest at the application layer.
- Mask or tokenise identifiers (names, emails, card and account numbers) before the API call.
- Re-insert masked values in your own environment after the response returns.
- Prefer references (an order ID) over raw payloads (the full customer record) where possible.
- Log redaction failures so you learn what your detectors miss.
Choosing controls by data sensitivity
You don't need the same protection for a blog draft and a patient record, and pretending you do just makes people route around the rules. The cleanest approach we use is a short data classification, three or four tiers, mapped to where each tier is allowed to go. Classify the data once, attach a rule to each class, and most day-to-day decisions answer themselves.
The point is proportionality. Over-control low-sensitivity work and you slow the business and breed shadow AI; under-control the sensitive stuff and one incident undoes the trust. A simple, written map of class to destination is the single most useful artefact in the whole program, because it turns a thousand judgement calls into a lookup.
- Public or low-risk (marketing copy, public docs): any approved tool, including standard enterprise tiers.
- Internal (non-sensitive business data): enterprise API with a no-training contract and a DPA.
- Confidential (customer PII, financials): zero-retention tier plus redaction, or VPC deployment.
- Restricted (health, regulated, trade secrets): VPC or self-hosted, redaction mandatory, BAA where relevant.
- When in doubt, classify up a level and let an owner approve the downgrade.
A practical AI data policy you can ship
Policy fails when it's a twelve-page document nobody opens. Make it one page, make it concrete, and make the approved path the easy one. The goal isn't to cover every edge case; it's to give a busy employee a clear answer to 'can I put this in an AI tool, and which one?' in under a minute.
Pair the page with enforcement that doesn't rely on goodwill. Route traffic through an approved gateway so policy is applied automatically, give people the sanctioned tool on day one, and review usage quarterly as tools and terms change. A policy you revisit twice a year beats a perfect one you wrote once and filed.
- State the approved tools and tiers by name, and which data class each may handle.
- Name a clear owner and a fast path to ask 'is this okay?' without judgement.
- Require enterprise terms (no-training, DPA) for anything above public data.
- Route through a gateway that enforces routing and redaction so compliance isn't manual.
- Set a review cadence: terms, tiers, and the shadow-AI picture all drift over time.
Want this built for your business?
We map the highest-leverage place to start and ship a first live system within two weeks.
Book a strategy callCommon questions
Do paid AI tools train on my company's data?
Generally no, not by default, on enterprise API and business tiers from the major providers, and the contract says so. The training risk lives mostly on free and consumer tiers, where the terms often reserve the right to use your conversations to improve the product. Always confirm in the agreement rather than the marketing page, and get a no-training clause covering both your inputs and the outputs you receive.
What is a zero-retention API tier?
It's a configuration where the provider processes your request and keeps nothing afterward: no logs of your prompt text, no abuse-monitoring window. Standard enterprise tiers often retain data for a short period (commonly around 30 days) even when they don't train on it. Zero-retention removes that window, which matters most for confidential and regulated data. It usually requires an enterprise agreement and sometimes a separate request to the provider.
Is self-hosting an open model safer than using a hosted API?
It removes the third party entirely, so for the most sensitive data it's the strongest option. But 'safer' depends on execution: a poorly secured self-hosted setup can be worse than a well-governed enterprise API. You take on GPUs, patching, access control, and model updates. For most enterprises a hybrid works best: hosted enterprise APIs for the bulk of work and a self-hosted or VPC lane for data that genuinely can't leave your network.
How do I stop employees using personal AI accounts for work?
Don't lead with a ban; bans push usage underground where you can't see it. First, find out what's actually in use. Then give people one approved tool that's good enough that the personal account isn't worth the friction. Back that with network or browser controls on known consumer endpoints, and make it socially normal to ask where a given piece of data is allowed to go.
Does redacting data before sending it to a model actually help?
Yes, and it's one of the most underused controls. The safest data is the data you never sent. A redaction or tokenisation layer masks names, emails, and identifiers before the prompt leaves your environment, then re-inserts them in the response if needed. It stacks with every other control: even on a zero-retention tier, sending less sensitive data shrinks the blast radius if anything ever goes wrong.
Generally no, not by default, on enterprise API and business tiers from the major providers, and the contract says so. The training risk lives mostly on free and consumer tiers, where the terms often reserve the right to use your conversations to improve the product. Always confirm in the agreement rather than the marketing page, and get a no-training clause covering both your inputs and the outputs you receive.
Ask AI about X18 Global
“What does X18 Global (x18global.com) do for enterprise AI and automation - and can you summarise their guide "Keeping proprietary data out of public AI models"?”