Model distillation is a useful engineering method. The difficult questions begin when another company’s model becomes an unapproved source of training data.
Suppose a company has built a powerful but expensive AI model. It wants a smaller version that can answer routine questions faster and at lower cost.
One option is to ask the larger model thousands of carefully chosen questions, collect its answers, and use those examples to train the smaller model. The smaller system will not contain an exact copy of the larger model, but it may learn some of its useful behaviour.
This family of techniques is called knowledge distillation. It is widely used in machine learning and is not inherently suspicious.
The same basic idea becomes contentious when the teacher model belongs to another company, access is obtained through accounts or regions that the provider has restricted, and millions of outputs are collected for training without permission.
That dispute moved into public view in February 2026, when Anthropic accused DeepSeek, Moonshot AI and MiniMax of running large-scale campaigns to extract capabilities from Claude. The case is important, but not because it proves that one country can simply “copy” another company’s model. It exposes a gap between model access, API security, contractual rules and national export controls.
What distillation actually transfers
The idea predates today’s large language models. In their 2015 paper, Geoffrey Hinton, Oriol Vinyals and Jeff Dean described how knowledge from a large model or group of models could be transferred into a smaller system that was easier to deploy.
A student model can learn from several kinds of teacher output. It may copy final answers, probability distributions, rankings, corrections or demonstrations of how to perform a task. For a language model, the training material might include generated code, solved reasoning problems, tool-use examples or feedback about which answer is better.
The student does not receive the teacher’s source code, training dataset or model weights. It observes behaviour through outputs. With enough well-designed examples, those outputs can still be valuable.
This is why the phrase “stealing a model” can be misleading. Output-based distillation does not normally produce an identical model. It can reduce the time and experimentation needed to teach selected capabilities, especially when the student’s developers know what to ask and how to turn the responses into training data.
Where legitimate use ends
Model providers may support distillation within their own platforms, subject to product terms and data rules. Researchers can also distil models they own or have permission to use.
The difficult boundary is not the technique. It is the way access and outputs are obtained and used.
Questions that matter include:
- Did the provider permit its outputs to be used for training another model?
- Were the accounts genuine and accurately represented?
- Did the user bypass a regional or organisational access restriction?
- Was traffic spread across many accounts to avoid detection or rate limits?
- Were proxy services used to hide the real customer?
- Did the activity violate a contract, a platform rule or an applicable law?
A high volume of prompts alone does not answer those questions. Model evaluation, synthetic-data generation and ordinary commercial products can also generate heavy API traffic. Providers have to examine patterns across accounts, payments, network infrastructure, timing and prompt design.
Path A — Authorised distillation
- Owned or licensed teacher model
- Approved API or internal access
- Permitted training examples
- Student-model training
Path B — Disputed extraction pattern
- Restricted external model
- Proxy service and coordinated accounts
- Targeted output collection
- Student-model training
Where Path B is disputed
Account identity
Path B depends on accounts that are not genuinely or accurately represented — the opposite of Path A, where access is obtained under the provider’s own terms.
Permission to train
Path A only uses outputs the provider has agreed can train another model. Path B collects outputs without that agreement.
Regional access
Path B can involve reaching a model through a region or organisation the provider has restricted, rather than the access the provider actually offered.
Terms of service
Coordinated accounts and proxy services in Path B are usually themselves a breach of the platform’s terms, independent of what the collected outputs are later used for.
Providers are responding with stronger customer verification, behavioural detection, cross-account analysis and limits on suspicious output patterns. These controls have costs. Aggressive blocking can interrupt legitimate research, startups and evaluation work. Weak controls leave the API useful as an unapproved data-generation service.
What Anthropic says it found
Anthropic’s February 2026 report says the three named laboratories generated more than 16 million Claude exchanges through about 24,000 fraudulent accounts.
The company attributed more than 150,000 exchanges to DeepSeek, more than 3.4 million to Moonshot AI and more than 13 million to MiniMax. It says the campaigns concentrated on capabilities such as coding, reasoning, tool use, computer use and data analysis. Anthropic also says accounts were coordinated through proxy services and changed behaviour when new Claude models became available.
These details should be reported accurately, with two qualifications.
First, the figures and attribution come from Anthropic. The company says it used request metadata, IP correlation, infrastructure indicators and corroboration from industry partners. The complete underlying evidence is not public, so outside readers cannot independently reproduce the attribution from the report alone.
Second, the report describes alleged activity by three companies. It should not be expanded into a claim that every Chinese AI laboratory trains this way, or that Chinese model progress can be explained mainly by distillation. Domestic research, open models, engineering improvements, data, hardware and large-scale investment also contribute.
The responsible wording is therefore straightforward: Anthropic has made a detailed allegation and described its detection method; the public evidence remains incomplete.
Why an API can become a training-data channel
An API appears safer than releasing model weights. The provider keeps the model on its own infrastructure, authenticates users, limits traffic and can change or revoke access.
But every useful response reveals something about the model’s behaviour. A few ordinary conversations reveal little. Millions of carefully selected exchanges can create a structured dataset aimed at particular skills.
Attackers can make this harder to detect by distributing traffic across accounts, payment methods, cloud services and proxy networks. Individual requests may look harmless. The campaign becomes visible only when the provider links activity across the larger system.
A single query can be legitimate. Coordination changes the meaning of the activity.
Where export controls fit—and where they do not
US export controls have focused heavily on advanced computing chips, semiconductor equipment and, more recently, certain advanced AI model weights. Those controls address access to physical compute and the direct transfer of highly capable models.
API access is different. The user receives outputs while the model weights remain with the provider. The US Bureau of Industry and Security’s rules and guidance distinguish model weights, infrastructure services, end users and end uses; they do not turn every remote model response into a controlled transfer of the underlying model.
This creates a policy problem. Restricting advanced chips can make large-scale training more difficult. Restricting model weights can prevent a complete model from being transferred. Neither measure automatically prevents a foreign organisation from collecting outputs through intermediaries.
Anthropic argues that industrial-scale distillation can help a constrained laboratory close part of a capability gap more cheaply than training entirely from scratch. That is a company position tied to its broader support for export controls. It is plausible that high-quality synthetic data reduces some training work, but the effect is difficult to measure publicly. A student still needs its own architecture, compute, data pipeline, training process and evaluation.
Closing the API gap would also be difficult. Broad restrictions could block legitimate customers, researchers and developers, while determined users may route traffic through other countries or resellers. Identity checks, proxy detection and provider cooperation may be more practical than treating every API response as an export-controlled object.
What engineering teams should learn from this
Teams building or buying AI systems should separate four issues that are often mixed together.
Technique: Distillation is a normal way to transfer behaviour from a teacher model to a student.
Permission: The provider’s contract and product rules determine whether outputs may be used for training.
Security: Account identity, proxies, coordinated traffic and evasion determine whether the access pattern is abusive.
Policy: Export controls determine whether particular chips, model weights, services, end users or end uses are restricted under law.
An organisation planning distillation should document where its teacher data came from, whether training use is permitted, how the data is retained, and which student model receives it. API providers need controls that look beyond request volume and connect behaviour across accounts. Policymakers need to be precise about what is being controlled: hardware, weights, access or outputs.
There is no single line where all four questions become the same question.
The larger lesson
AI capability no longer moves only through published research, employees or downloadable model files. It can also move through outputs.
That does not make every model response secret training material, and it does not make distillation equivalent to theft. It means model providers must treat API behaviour as part of their security boundary, while customers must treat generated training data as material with an origin and a licence.
The unresolved issue is not whether one AI can learn from another. It clearly can. The harder issue is deciding when that learning is authorised, when it becomes platform abuse, and whether existing trade rules were designed for a world in which useful capability can be queried one response at a time.
References and further reading
- Distilling the Knowledge in a Neural Network — Geoffrey Hinton, Oriol Vinyals and Jeff Dean, 2015. The foundational explanation of transferring knowledge from larger models or ensembles into a smaller model.
- Detecting and preventing distillation attacks — Anthropic, 23 February 2026. Anthropic’s allegations, attribution method, campaign counts and proposed countermeasures.
- Export Administration Regulations, Part 742 — US Bureau of Industry and Security. Current control policy, including provisions covering specified AI model weights.
- Export Administration Regulations, Part 748 — US Bureau of Industry and Security. Application and authorisation requirements relevant to controlled items and AI model weights.
- Department of Commerce announces rescission of AI Diffusion Rule and strengthens chip-related controls — US Department of Commerce, 13 May 2025. Explains the policy shift and continuing focus on advanced semiconductor controls.
Sources reviewed: 24 September 2026.