Should You Feed Your Company Secrets to an LLM?

A friend shared a LinkedIn post the other day with a blunt warning: don’t hand over your proprietary data and trade knowledge to an LLM. This came from a discussion at the investor huddle at MASHUP26. Venture capitalists and angels in the room agreed that AI is essential to move faster, but that investors should not rely on LLMs to analyse, qualify or review startup applications, pitch decks and the like.

“Don’t feed your private data to an LLM” is like saying “don’t put your money in a bank.” Which bank? Under which country’s laws? Insured how? The better answer to “is it safe to send confidential data to an AI?” is it depends, and the things it depends on are knowable. This post is my attempt to lay them out for a non-technical audience, particularly investors, who see other people’s most sensitive material for a living.

TL;DR

• The blanket “never” is wrong, and “sure, paste it in ChatGPT” is worse. It depends on which tool you use and how you use it.
• Treat the data by level. Company IP needs no-training and controlled retention. Regulated customer data needs contract and feature checks. Defence and intelligence need sovereign control of the operator, compute and jurisdiction. That is not something a SaaS setting can provide.
• The question that actually threatens your IP is not “do they store it” but “do they train on it?” If your trade knowledge becomes part of a model other people query, you have a problem. If it doesn’t, storage is a smaller risk.
• Training defaults split mostly along consumer versus business, not free versus paid. Consumer apps, including paid ones like ChatGPT Plus, Claude Pro and Grok, may learn from your conversations unless you change a setting. Business and API tiers generally have better default settings, but product exceptions matter: Labs models, SaaS dashboard toggles and feedback buttons can change the answer.
• Zero Data Retention (ZDR) is a nice-to-have that shrinks the breach and subpoena surface. It is rarely a hard requirement, and it is not absolute: caching and per-model exceptions leave data around longer than you’d think.
• A Canadian datacentre helps with residency. If a U.S. company operates it, U.S. law may still reach data the company controls.
• For investors: use a business or enterprise tier, check the training setting, and know who else touches the data. A blanket ban just pushes your team to paste decks into their personal account instead.

Match the bar to the data

Not all confidential data deserves the same answer.

1. Public or low-sensitivity data. Published research, marketing copy, open-source code, generic summaries. Any tool works. The only thing to watch is not pasting a secret in by reflex.
2. Company IP and ordinary business confidentials. Pitch decks, cap tables, board notes, unreleased roadmaps, source code and sales data. The main risk is training leakage plus casual over-sharing. Subpoena risk exists, but it usually exists inside your business already. In Oracle v. Google, the court ordered Google to produce Tim Lindholm’s Java email and all nine auto-saved drafts (!) The evidence came from Google’s own systems, before AI-provider retention entered the picture. Use a business, enterprise or API tier where no-training is the default, keep retention short, control access, and scope connectors. Add ZDR for the most sensitive documents once those basics are covered.
3. Customer data under a sector law. Health, finance, education, children and government data add a compliance layer. In the U.S., health means HIPAA and a Business Associate Agreement (BAA). Canada does not have one HIPAA equivalent; health privacy is mostly a federal/provincial patchwork: PIPEDA where it applies, plus provincial laws like Ontario’s PHIPA, Alberta’s HIA, and Quebec’s Act respecting health and social services information. For this tier, “no training” is not enough. Check the contract, sub-processors, audit logs, residency, and the exact model, endpoint, tool and connector you plan to use.
4. Military, intelligence and national-security use. The bar here is sovereign control of the operator, compute, network and model supply chain, plus the legal reach over whoever runs it. Dedicated defence tiers do exist: Anthropic’s Claude Gov models are “deployed by agencies at the highest level of U.S. national security,” and ChatGPT Gov runs in Azure Government for frameworks like IL5, CJIS and ITAR. They are U.S.-operated by design: the DoD’s cloud rules restrict IL4/IL5 operator access to U.S. persons, and the stack still sits under U.S. law. That is genuine sovereign infrastructure for the United States, but for a Canadian buyer it is still a U.S.-operated service a U.S. court can reach. The provider’s own posture is leverage too: in early 2026 the Pentagon moved to designate Anthropic a supply-chain risk and pull Claude from its systems after Anthropic limited military use. The open-weight route trades provider-access risk for two others: model behaviour, since the leading open models are from China-based labs with documented political censorship, and supply chain, since a base model can carry hidden triggers that survive fine-tuning. Canada’s own path is Canadian-governed compute under SCIP or open weights you host yourself, and putting controlled technical data in a foreign-operated cloud can itself be a regulated export. For real-time intelligence, I would not treat ZDR or Canadian at-rest residency as close to enough.

The due-diligence checklist

When someone says “sending data to an LLM is risky,” they usually collapse five different questions into one.

1. Training: does the provider learn from it?

This is the one that threatens your IP. If a provider trains on your inputs, your confidential deck or data model can influence the next generation of the model that anyone else can then query. Retention affects breach and subpoena exposure; training affects whether your competitive knowledge leaks into a shared model.

The line that matters is consumer versus business more than free versus paid. A paid ChatGPT Plus or Claude Pro subscription is still a consumer product, and those can use your conversations for training (!) unless you opt out (!!) in settings. Upgrading to a pricier consumer plan doesn’t turn training off; a business or API tier does. This is also true of LinkedIn BTW.

• Consumer tiers (free and paid alike) generally train by default, and you have to turn it off. OpenAI’s own opt-out page confirms Free, Go, Plus and Pro use conversations to train its models unless you switch it off.
• Business, enterprise and API tiers are generally the safer surface. The large cloud/frontier providers tend to make no-training contractual there: OpenAI states plainly that API data is not used to train its models unless you opt in. Google draws the same line: the free Gemini API tier may use prompts to improve its products, paid Cloud Billing does not.

Product exceptions matter. Mistral’s API docs say API data isn’t used for training, but its Labs models may train unless ZDR is active. Cohere’s SaaS Platform has a dashboard opt-out for training rather than a blanket no-training default. Read the terms for the specific product, not just the company name.

I’m describing the major providers’ current defaults. Smaller vendors vary, defaults change, and a “thumbs up” on a consumer chat can re-authorise training of that one conversation even after you opt out. Read the terms for the specific tier you’re on, and don’t assume paying bought you privacy.

2. Retention and caching — do they keep it?

Zero Data Retention (ZDR) is the promise that the provider does not store your prompts or the model’s answers after your request finishes. Data that is never stored can’t be leaked in a breach, handed to a subpoena, or read by a curious employee. Retention is attack surface, and less of it is better.

Statefulness is separate from training. xAI’s Responses API, for example, stores previous prompts, reasoning content and model responses on xAI servers by default for 30 days so you can continue a conversation. You can set store: false, or use enterprise ZDR. That’s a feature with a retention consequence.

ZDR is rarely a hard requirement. If a provider doesn’t train on your data and deletes it on a sane schedule, most of the risk is already handled, and ZDR trims what’s left. It also isn’t absolute:

• Per-model exceptions. Anthropic now requires 30 days of retention for its most capable “Mythos-class” models, on every platform, even for ZDR customers, so it can catch misuse. The data isn’t used for training and access is logged, but “zero” quietly became “thirty” for that tier.
• Caching keeps data around, and ZDR doesn’t fully stop it. To cut cost and latency, providers automatically cache parts of your prompt. That cache is storage. OpenAI keeps cached prefixes for up to 24 hours; Anthropic keeps them 5 minutes to an hour. Turning on ZDR narrows the window rather than closing it: OpenAI’s ZDR projects default to the shorter in-memory cache, but its newest models require the 24-hour cache even for ZDR customers.
• Some features are incompatible with ZDR or a regulated workflow. OpenAI’s data controls table lists endpoints that keep application state and are not ZDR-eligible. Its Web Search is a good example: live web search is not HIPAA eligible and is not covered by a BAA; offline or cache-only web search can be BAA-eligible only from a ZDR-enabled project within a ZDR organization. For regulated customer data in Canada, do the same endpoint-by-endpoint review instead of relying on the provider logo.

So read the specific policy for the specific model and feature you’re using. “Zero” is often “nearly zero,” and the gap can matter if your threat model is strict.

3. The personal account is the risky surface

The surface that bites is the personal consumer account people reach for without thinking: the free app, or a personal Plus, Pro or Max subscription. Two things make it risky. First, memory features quietly retain context across conversations. Second, the training default, which leans the wrong way. OpenAI’s and Google’s consumer apps default that sharing on and make you opt out. Anthropic now asks consumer users to choose whether their chats train Claude, and if you allow it, retention extends to five years. Either way, the setting is easy to click through without reading.

The organisational tiers are the safer ground, but “business tier” isn’t one thing. A business or enterprise chat workspace (ChatGPT Enterprise, Claude for Work, Gemini for Workspace) and the raw API both default to no training, yet they differ on everything else. The API is stateless, with short abuse-log retention and an optional ZDR. A business chat workspace keeps conversation history your admins can see, plus memory and connectors. Same answer on training, different answers on retention and on who can read it. Match the surface to the data.

So the case the LinkedIn post gets right is the personal account. Pasting a confidential deck there, with training or memory on, is the genuinely risky move, and a paid Plus or Pro subscription doesn’t change that if you opted in. A business or enterprise deployment with training off carries far less risk.

4. Who else touches it, sub-processors!

The provider is rarely the only party in the chain. Analytics vendors, logging tools and infrastructure partners all sit near your data. OpenAI’s worst incident of 2025 wasn’t a model leak, it was a breach at Mixpanel, a third-party analytics vendor, which exposed API account names and emails, no chat logs. It’s a clear reminder that the weak link is often a sub-processor.

This is where the privacy policy earns its keep. It should tell you who the sub-processors are and what they can see. Resellers make this worse: a router like OpenRouter or Vercel’s AI Gateway is only as private as the backend it routes to, and every hop is another place data can rest, log or leak. If sovereignty matters, shorten the chain.

5. Residency and jurisdiction: where it runs, whose law reaches it

Data residency lets you pin where your data is stored, and sometimes processed, for example inside Canada. It matters for privacy law (Quebec’s Law 25, PIPEDA) and latency. “Available in Canada” often means less than it sounds:

And residency is only worth anything if the model you want actually runs in-region. I listed each provider’s Canadian catalogue with their own CLIs, and the picture is depressing:

• OpenAI direct offers Canadian residency for data at rest only; the inference still defaults to the U.S.
• Google Vertex AI has a Montréal region, but my capture shows only Gemini 2.5 Pro and Flash there; Toronto has none. For this post’s standard of current frontier models, Gemini 2.5 is unusably old. Current Gemini simply isn’t available for in-region inference in Canada.
• AWS Bedrock serves 29 models in Montréal (ca-central-1) against 121 in its main U.S. region, but the current frontier is present, all of it Anthropic: the full recent Claude line (Opus, Sonnet, Haiku, Fable). Claude in Canada means Bedrock.
• Azure AI Foundry has the deepest coverage: 244 models in Canada Central, more than its own East US region, including the full current OpenAI line (the GPT-5 family). No Claude, though. GPT in Canada means Azure.

Cerebras is worth watching here. It announced Montréal inference capacity, and Saskatchewan announced a Bell AI Fabric project where Cerebras and CoreWeave are tenants. This weakens the lazy assumption that Canadian AI infrastructure must be slow. It does not prove that a Cerebras API customer can force Canadian routing or Canadian residency for a given request.

So your model choice quietly picks your cloud, and one of the three big providers can’t keep current-model inference in Canada at all. Deep coverage isn’t the same as a strong security record, either: the cloud with the most Canadian models here also carries the weakest track record.

Residency also doesn’t answer the harder question of jurisdiction. Under the U.S. CLOUD Act, American authorities can compel a U.S.-incorporated company to produce data it controls, even if that data physically sits in a datacentre in Montréal. Provincial law, including Law 25, can’t override U.S. jurisdiction over an American company. Storing your bytes in Canada does not put them beyond the reach of a foreign government if the company holding them is foreign. For a sovereignty assessment, identify the legal entity operating the service and the governments that can compel it. For the stricter version, Canada’s own AI compute program defines sovereign AI compute as a Canadian-located, Canadian-governed system where data residency, operational control and decision-making authority stay in Canada. For businesses, that means Canadian-operated infrastructure or open models you run on infrastructure you control if foreign legal compulsion is in scope. Everything else is a spectrum of how much you trust the operator and its home government.

The provider landscape

Most serious providers now offer a no-training path. Don’t stop at the provider name. The defaults differ across consumer chat, business chat, APIs, routers, “preview” models and private deployments.

The last two, OpenRouter and Vercel, are routers rather than model operators, and their no-training and ZDR behaviour is a setting you turn on. They’re a convenient way to enforce one policy across many models at once, but they add a hop, and you inherit both their posture and their backend’s.

Trust is the part you can’t configure

I care about the operator’s security record as much as its settings. The provider has to keep keys, logs, analytics vendors, support tooling and IAM policies under control.

My bias is that I spent 16 years at Google, I know a bit about its internal security. I trust Google’s security engineering, and Amazon’s, more than most. Both have deep, boring security cultures, the kind you want.

• Microsoft is the cautionary tale. After the Storm-0558 breach, where a China-based group forged authentication tokens with a stolen signing key and read email at some two dozen organisations including the U.S. State Department, the U.S. Cyber Safety Review Board concluded the intrusion “should never have happened” and that Microsoft’s “security culture was inadequate and requires an overhaul.” A low-tech password-spray by a Russian group into Microsoft’s own corporate email followed shortly after.
• OpenAI’s worst 2025 incident was the Mixpanel sub-processor breach above: real, but a vendor problem, not a model leak.
• Google Cloud had a Vertex AI flaw disclosed by Palo Alto’s Unit 42 where overly broad default permissions could be abused to exfiltrate data. I didn’t find a public customer-data breach tied to it.

These were stolen keys, sloppy vendors and provider-side permission mistakes: operational security failures, not “the AI ate our secrets.” That should reframe what you worry about.

The smaller, inference-only players? Time will tell. Lower maturity usually means less security investment, which warrants a few harder questions before you trust them with anything sensitive.

So, go slow to go fast

The “go slow to go fast” framing in that LinkedIn post is right, even if the blanket ban isn’t. Ban AI outright and your team doesn’t stop using it. They paste the deck into their personal ChatGPT account, where the defaults are worst. A ban you can’t enforce is worse than a policy you can.

What I’d actually do, whether you’re a founder guarding your IP or an investor handling other people’s:

Connected tools deserve their own line in the policy. An MCP server, Slack app, Notion AI connector, Google Drive connector, GitHub app or code interpreter changes the data flow. OpenAI’s data controls say data sent to MCP servers or over third-party network connections is subject to those services' own retention and residency policies; the ChatGPT Slack app can search Slack content the user can access and may take actions when enabled. Slack’s native AI says customer data stays in Slack-controlled infrastructure and is not used to train LLMs, but that’s Slack’s product, not a blanket promise for every AI app inside Slack. Notion says Notion AI does not use Customer Data to train models by default, but its connectors can ingest external apps and store embeddings for search. None of these integrations are ZDR by definition. Treat integrations as sub-processors plus permissions: approve them, scope them, log them.

1. Keep confidential material out of personal consumer accounts, free or paid. Prefer a business, enterprise or API tier where no-training is contractual. If it’s a toggle, make it an admin-controlled setting.
2. Check your settings. Turn off training. On consumer tiers the default often works against you. Memory is tricky because it’s genuinely useful. Many chat products now have an “off-the-record” mode.
3. Read the sub-processor list. Know who else touches the data. This is what the privacy policy is for.
4. Pin the product surface, not the brand. “Mistral” or “xAI” is not specific enough. Name the workspace, API endpoint, model, connector and retention mode.
5. Use ZDR selectively. For everyday use, no-training plus settings you control is enough. ZDR is worth adding for genuinely sensitive workloads, but it isn’t free: it trims prompt caching, so long tool-call chains recompute and cost more. Reserve it for the data that warrants the overhead. Nearly no product offers ZDR, only APIs.
6. Match the deployment to the data. Public research: any tool is fine. A term sheet, a cap table, an unreleased data model: no training at minimum, and if the CLOUD Act is in your threat model, a Canadian-controlled operator, which sadly generally mean to to host a model yourself.
7. Require evidence for residency. A Canadian datacentre announcement is not a routing guarantee. Ask for the model, endpoint, region and contract language.
8. Give your team a sanctioned path, with models that are good enough for the work. If the official account only exposes cheap weak models (hello Copilot) while personal accounts have frontier models, people will route around you.

For the specific worry in that investor room, should a VC run a founder’s confidential deck through an LLM, my answer is: yes, with training off, on a business or enterprise account, and without unmanaged connectors. How you configure it decides the risk more than which tool you pick.

The founders you’re funding already use these tools! The useful question isn’t whether your portfolio touches AI, but whether they touch it on a personal account or a business one.

I write from a security and engineering background, not a legal one. Think I got a provider detail wrong? Want to talk to me? Tell me on Bluesky or Twitter or email me.