A few clients sent me the same CNBC clip (ref) this week: Palantir CEO Alex Karp saying that OpenAI and Anthropic are taking proprietary company data from the businesses that pay them. The clip traveled because it hit a real anxiety. Within a day or two, people were asking whether they should pull ChatGPT or Claude out of their company and rebuild everything on private infrastructure. Some had already seen quotes in the five figures, which in most cases would be an expensive way to solve the wrong problem.
If you run a business, the concern makes sense. A lot of the value in a company is not sitting in one clean document marked "trade secrets." It is pricing judgment, client context, internal process, sales history, exception handling, and all the small decisions your team has learned by doing the work. If a vendor were taking that material and using it to build products for your competitors, you would be right to be furious.
Before spending money, though, it helps to separate three different questions. What do your AI vendor's commercial terms actually allow? What are your employees doing in personal or unofficial tools? And which categories of information are too sensitive for shared AI tools no matter what the vendor promises?
For the major AI providers, the first dividing line is not cloud versus private infrastructure. It is consumer terms versus commercial terms.
On the commercial side, the major providers put the important promise in writing. OpenAI says it does not use business data (ref) from ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu, ChatGPT for Healthcare, ChatGPT for Teachers, or the API to train or improve its models by default. Anthropic says the same for Claude for Work, Claude Gov, and the Anthropic API (ref): commercial inputs and outputs are not used to train its models by default.
Those promises do not eliminate the need to read the contract, but they do change the starting point. A paid business product, under commercial terms, is not the same thing as dumping company material into a public training set. The contract still matters because "we do not train on your data" is narrower than "we never store your data," "no human can ever review it," or "every feature has identical terms." The service still has to process a prompt to answer it, and some data may be retained for abuse monitoring, support, logs, or product features. Feedback buttons, shared links, connectors, retention settings, and admin controls can all change the answer in specific cases.
Those details belong in the contract. A CNBC clip is not enough reason to assume the worst, and a sales email is not enough reason to assume the best.
In the companies we see, the more common exposure comes from personal accounts and unofficial tools. If employees are using free or personal AI accounts for work, the company has a different problem from the one Karp was describing. Consumer products do not give you the same default protections, admin controls, retention settings, or company-level governance. Depending on the product and the settings, personal chats may be eligible for model improvement, stored longer than you expect, or handled under terms your company never approved. The details live in each vendor's consumer controls and policies, including OpenAI's data-use page (ref) and Anthropic's consumer training page (ref).
What people call shadow AI is often just the browser tab someone opened because the approved workflow was missing, slow, blocked, or annoying. It is a client document pasted into a personal account at 9 p.m. because nobody gave the team a sanctioned tool. It is a random Chrome extension, a free PDF summarizer, or a one-off "AI assistant" that looked harmless enough in the moment.
A better first investment is usually a sanctioned setup people can actually use: a real commercial plan, SSO, admin controls, sensible sharing defaults, a decision on feedback features, and a written rule for what can go into the tool and who decides when the answer is unclear. Policies only hold when the approved path is easier than the workaround.
The more expensive reaction is to move everything into your own cloud account. For many companies, that means AWS Bedrock, using Claude or another model through AWS instead of through the model provider's own app.
Bedrock can be a good product for the right problem, especially if you are building your own software on top of a model, need tighter AWS-native controls, want regional data handling, or have security requirements that fit Bedrock's architecture. AWS says Bedrock prompts and outputs are not used to train base models (ref), and that third-party model providers do not receive customer prompts or completions.
Where companies get into trouble is treating that as an automatic upgrade for every team using ChatGPT or Claude. Bedrock is an infrastructure product. It gives you access to a model inside AWS, but it does not give your staff the app experience they already know. Projects, shared context, familiar workflows, polished UX, and ordinary user adoption either disappear or become your responsibility.
The economics change too: a flat per-seat product becomes usage-based infrastructure, which can be cheaper for some teams and more expensive for others, and the company takes on new work around identity, logging, routing, prompt management, evaluation, support, training, and the internal app people will actually use.
A common failure mode is spending a lot of money to make the tool safer while making it worse for the people using it. Adoption falls, and the work moves back to email, spreadsheets, personal accounts, or nothing at all. The company paid for control and lost the value.
Private infrastructure is the right answer for some data and some workflows, but it is not the default answer to "are they training on our data?" If your commercial contract already says no, Bedrock may only move you from one no-training setup to another while taking away the product experience your team was using.
There is still a category of information that needs stricter treatment. Every business has a small set of data that is the business: unreleased patent material, acquisition plans, source code under unusual obligations, regulated records, credentials, deeply sensitive client files, or anything where disclosure would be catastrophic. If that material needs a model, design the workflow on purpose. Use zero-retention terms, private infrastructure, a carefully scoped internal tool, or no model at all.
Patent work deserves its own caution. If you are dealing with patentable material, ask your patent attorney before disclosing it to any AI system. Whether a confidential disclosure to a processor creates a problem (ref) depends on the jurisdiction, the agreement, and the facts. Do not let a blog post decide that for you.
For ordinary business use, the useful work is vendor review and internal cleanup. Ask vendors direct questions and make them point to the governing terms. Do you train on our inputs or outputs? Which products does that answer cover? Are we the controller and you the processor (ref), or is the relationship different? Where is the data processed and stored? How long is it retained? Can your staff or contractors review it? Can the model provider underneath you see it? What happens when we leave? Which features change the answer?
Then ask the same questions internally. Which AI tools are employees using? Are they on company accounts or personal accounts? Are browser extensions allowed? Are shared links enabled? Is anyone using free tools for client documents? Do people know what counts as sensitive data? Do they know who to ask before guessing?
The internal answers are often worse than the vendor answers, but they are also easier to fix. If your team is using consumer accounts, move them onto commercial accounts. If your policy is vague, make it specific. If the approved tool is harder than the workaround, make the approved tool easier. If a category of data is too sensitive for shared AI, keep it out and build a narrower path for it.
Karp raised a concern worth taking seriously. The part to avoid is letting a broad warning turn into a rushed infrastructure project. For most companies, the first move is not to spend fifty thousand dollars replacing a product the team already knows how to use. The first move is to understand the terms, close the personal-account gap, and separate normal business use from data that needs a purpose-built path.
General guidance, not legal advice. For contracts, regulation, patents, or sector-specific obligations, talk to your attorney.