There is a catchy claim going around. Anthropic sells models to companies, learns from their data and product ideas, then enters those same markets. Once open-weight models become strong enough, customers leave and Anthropic's valuation falls apart.
That is the claim. I do not think the public evidence gets us there yet.
Public information does show Anthropic moving from the model layer into applications. Some of those products now overlap with workflows served by Claude customers. This creates trust problems and makes dependence on a single provider riskier. It still does not prove that Anthropic is collapsing. We would need customer losses, renewal data, revenue mix, and margins to make that case.
My view is that companies do not need to spend much time predicting whether Anthropic wins or loses. They need to work out whether they can leave if the relationship stops making sense.
What the Claude Design and Figma case tells us
On April 14, 2026, Anthropic executive Mike Krieger resigned from Figma's board. Figma's Form 8-K confirms the date and says the resignation was not caused by a disagreement over Figma's operations, policies, or practices.
Three days later, Anthropic launched Claude Design. It can create designs, prototypes, slides, and one-pagers. Part of that work overlaps with Figma.
The timeline is enough for a partner to ask hard questions. It is not proof that Anthropic used Figma's confidential data. Saying that nobody would believe Anthropic is an expression of doubt, not evidence. Figma's share-price movement cannot be attributed entirely to Claude Design without a proper event study either.
The practical issue is platform risk. When one company controls the underlying capability, usage pricing, and end-user products, its relationship with application companies is no longer a simple supplier relationship. A supplier today may become a competitor in the next product cycle.
Data leakage, model training, and product insight are different things
Treating every closed API as proof that customer data is used for training sends the discussion in the wrong direction.
Anthropic's policy for commercial products says inputs and outputs from Claude for Work and the Anthropic API are not used for model training by default. Explicit feedback, bug reports, or a voluntary training program create different data paths.
Consumer accounts follow different rules. In its August 2025 terms update, Anthropic explained that Free, Pro, and Max users can choose whether to contribute data for training. Claude Code sessions tied to those accounts are included when that setting is enabled.
An enterprise security review cannot stop at asking whether training happens. Account type, actual contract terms, retention, feedback, third-party connectors, logs, cross-border processing, administrator settings, and zero-data-retention eligibility all matter. A no-training promise does not mean an integrated system has no leakage path.
Product insight is another question. A vendor may see which workflows are growing through sales calls, support work, usage patterns, and public market activity without training on customer content. That may not breach a contract, but it changes how a company should think about the relationship.
Four risks that need a price
Data is only one of them.
- Data and intellectual property: where prompts, code, documents, caches, tool calls, and logs go; who can read them; how long they stay.
- Product overlap: whether information separation, interface stability, and pricing protection still hold when the supplier begins selling a similar workflow.
- Usage and budget swings: agents expand context and call tools on their own. TechCrunch reported that Uber used its full 2026 AI budget in four months. That alone is a good reason for finance and engineering teams to check how they measure cost.
- Toolchain lock-in: proprietary prompt caches, conversation state, tool protocols, evaluation data, and team habits can make a switch expensive even when the model call looks portable.
How much these risks matter depends on the workload. A low-sensitivity internal tool with a manual fallback and a small bill does not need three model providers just to make the architecture look good. A system that supports a core product, handles proprietary data, or cannot tolerate a long outage should prepare for a provider switch.
Private deployment is not a free escape
Two questions need clear answers. Does owning the server mean electricity is the only cost? Does private deployment remove data-leakage risk?
No to both.
The full bill includes GPU depreciation, facilities, networking, storage, spares, monitoring, engineering time, software licenses, upgrades, and idle capacity. An API may still be cheaper for a workload that runs only a few hours each day. Stable workloads with high utilization and batch-friendly tasks have a better chance of spreading the cost of owned hardware.
Private deployment brings control and responsibility back together. Misconfigured access, leaked operations credentials, exposed networks, supply-chain vulnerabilities, retained logs, and internal privilege abuse do not disappear.
The NVIDIA and Palantir approach shows another option. Nemotron open models can run on customer infrastructure, be adjusted with customer data, and leave the resulting weights under customer ownership. This proves that a controlled deployment can be built. It does not mean every open model is cheaper or better for every task.
Companies need an AI plan they can exit
Should everything go to a managed API, or should everything run privately? There is no single answer. Splitting by need is more realistic.
Low-sensitivity tasks with changing capability requirements and uncertain volume can start on frontier APIs. High-sensitivity tasks, stable usage, workloads that can tolerate more latency, or work with strict regulatory requirements can be tested on open-weight models, dedicated cloud environments, or owned infrastructure. Both paths should use the same standards. Otherwise the comparison does not tell you much.
A company can start with a few practical steps:
- Classify data and tasks into content that must stay on the internal network, content allowed in a controlled service, and content approved for a public API.
- Build an internal evaluation standard and record task success, human correction time, latency, retries, and the full cost.
- Keep prompts, tool definitions, and core workflows in the company's repository. Put a thin adapter around model calls without hiding every provider-specific capability.
- Set usage limits by team, application, and task. Measure what each type of business work costs instead of watching only the total token count.
- Run a small provider-switch exercise on a schedule that matches the company's risk and cost. Record the engineering time and quality change when one real task moves away from the current provider.
This work will not remove provider risk. It helps a company calculate the problem instead of making decisions based on the mood of the latest headline.
What would change the current view
It is too early to say that Anthropic's crisis has already begun. Sustained customer losses, lower renewal rates, or deeper competition with core customers would change that assessment.
A company's own observations are more useful: whether contracts and data policies change, whether switching takes more engineering time, how far open-weight models lag on internal tests, and what each successful task actually costs.
Anthropic has to answer whether it can keep its lead. Whatever the answer, a company should not ask a provider to hold its only exit plan.
Continue the conversation
If you are evaluating AI providers, private deployment, or a multi-model setup, prepare current request volume, data classification, latency requirements, task acceptance criteria, and monthly cost. Those details are more useful than picking a model name first.