Open Weights, Distributed Power. What Happens to Governance After a Frontier Model Can Be Copied
An API model has a centre. An open-weight model has descendants. Once frontier weights can be copied, the provider can no longer guarantee one update, one monitoring regime or one red button. Governance does not disappear. It moves to every operator, derivative and deployment.
COMMENTARY — GOVERNANCE / OPEN-WEIGHT POWER
Series: China’s Open-Weight Statecraft — Article 2
Claim status: Empirical record and institutional analysis
Research current to: 1 August 2026Evidence boundary: This article does not claim that open-weight models are ungovernable, that every downloaded copy can be operated by every user, or that all forms of central control disappear after release. It makes a narrower claim: once model weights have been copied and can be run independently, the original provider can no longer guarantee a universal rollback, update, monitoring regime or shutdown across all existing deployments. Governance does not vanish. It becomes distributed.
An API model has a centre.
An open-weight model has descendants.
That is the most important political difference between the two forms of access. It is not simply that one is closed and the other is open. It is that they place control in different locations.
When an organisation accesses an AI system through an application programming interface, the model remains on infrastructure controlled by its provider. The user can send requests and receive outputs, but does not possess the model itself. The provider controls the endpoint, the active version, the access conditions, the monitoring system and, ultimately, the ability to suspend the service.
When an organisation downloads the weights, something more consequential happens. The model can be preserved, copied, adapted, fine-tuned and operated on infrastructure outside the original provider’s direct control. The provider may still influence later versions, official distribution channels, commercial terms and the surrounding ecosystem. It no longer controls every running instance of the capability.
The model has crossed from service into possession.
That transition redistributes more than software. It redistributes the ability to decide where the system runs, what safeguards surround it, which version survives, who monitors it, who can modify it and who can stop it.
The central red button does not simply disappear.
It breaks into many local switches — held by actors who may not know one another, may operate under different laws and may have no common procedure for using them.
API access is permissioned use
A frontier model delivered through an API can be widely available without being operationally decentralised.
The provider can decide which countries receive access, which accounts are suspended, which uses violate policy, what rate limits apply and which model version answers a request. It can monitor patterns of use, introduce new safeguards, patch vulnerabilities and replace a model behind the endpoint without asking each customer to reinstall it.
This control can be intrusive or beneficial.
It can allow a private company to impose rules on millions of users without democratic oversight. It can make institutions dependent on a vendor that can change prices, terms or availability. It can create a private regulatory layer in which access to an important capability depends on decisions made inside one company.
The same concentration also enables coordinated intervention. If a serious flaw is discovered, the provider can update the hosted system. If a use becomes dangerous, an account or capability can be restricted. If a model must be withdrawn, one operator can remove the active version from the service.
This is not necessarily a perfect kill switch. A model may already have influenced downstream decisions, generated reusable material or been integrated into complex workflows. The provider may lack legal authority over every customer action. But there remains a technical centre from which access can be altered.
The hosted model has a switch because the provider still holds the machine.
Weight access is capability possession
Open-weight access changes the relationship.
The International AI Safety Report defines open-weight models as systems whose parameters are available for download. Once downloaded, the weights can be studied, modified, shared and operated on the downloader’s own computers or cloud infrastructure. The report emphasises that this form of release supports research and innovation, especially for actors with fewer resources, but also makes provider monitoring and universal mitigation much harder.
The distinction can be stated plainly:
An API user receives answers. A weight holder receives an asset from which answers can be generated.
The asset may be extremely difficult or expensive to operate. Possessing a frontier-scale model does not automatically provide the accelerators, energy, networking, serving software or specialised personnel required to run it effectively.
But practical difficulty is different from provider permission.
An organisation with sufficient infrastructure no longer has to ask the original developer each time it uses the model. It can preserve a particular version even after the provider has moved on. It can place the model behind its own API, integrate it into a private system, fine-tune it for a particular task or modify its refusal behaviour.
That is a real transfer of operational authority.
Kimi K3 makes the distinction concrete
Moonshot AI describes Kimi K3 as an open-weight, 2.8-trillion-parameter mixture-of-experts model with 104 billion activated parameters and a one-million-token context window. The company has released the model weights and associated materials under the Kimi K3 Licence and provides instructions for serving the model through tools such as vLLM and SGLang.
The licence permits users to copy, modify, publish, distribute, fine-tune and create derivative works, subject to stated conditions. It also imposes additional obligations on sufficiently large model-as-a-service businesses and requires prominent Kimi K3 attribution in certain high-scale commercial products.
This illustrates an important separation:
- Moonshot can retain legal influence through the licence.
- It can retain ecosystem influence through documentation, official updates and certified partners.
- It can retain commercial influence through hosted services and agreements.
- It does not retain a technical ability to reach every lawfully or unlawfully retained copy and remotely replace or deactivate it.
A licence can define what a user is permitted to do.
It is not a remote control.
This matters because public debate often treats legal rules, distribution controls and technical stoppability as though they were the same thing. They are not. A user may violate a licence and remain technically able to operate the model. A repository may remove the original files while copies remain on local storage or are redistributed elsewhere. A safer version may be released without every operator adopting it.
After distribution, compliance and control separate.
The red button becomes a network
The phrase “AI kill switch” suggests one system, one operator and one decisive intervention.
Open weights break that picture.
Once copies are operated independently, there is no longer one running system to stop. There are multiple deployments, potentially using different hardware, configurations, fine-tunes, system prompts, tool permissions and external safeguards.
One operator may use the original model.
Another may quantise it.
A third may fine-tune it for a local language.
A fourth may remove refusal behaviour.
A fifth may integrate it into an autonomous workflow.
A sixth may provide it through a commercial API under a different name.
The original weights remain historically related, but the governance object has multiplied.
The International AI Safety Report therefore states that public release of weights is irreversible in a specific sense: there is no way to implement a wholesale rollback of all existing copies. Hosting platforms can remove the model from prominent repositories and make access less convenient, but a motivated actor can retain, rehost or privately transfer a copy that has already been downloaded.
The UK AI Security Institute reaches the same conclusion. Open-weight models can support independent research, wider testing and reduced market concentration, but they can also be modified arbitrarily, used outside provider oversight and spread irreversibly. External safeguards can be disabled, while safety fine-tuning may be undone using relatively small amounts of additional training data.
The correct conclusion is not that no one can stop an open-weight model.
Every local operator can potentially stop its own deployment.
A cloud provider may suspend infrastructure. A government may seize equipment or prohibit a particular use. A platform may remove a repository. An organisation may disconnect an agent from tools. A regulator may order a public agency to halt a system.
What no longer exists is a guaranteed universal provider stop covering every copy.
The stop becomes plural, local and uneven.
Four forms of control must be separated
After open-weight release, the question “who controls the model?” becomes too crude. At least four different forms of control have to be examined.
1. Source control
The original developer controls the official repository, documentation, future versions and public account of what the model is.
It can publish evaluations, identify vulnerabilities, release improved versions and announce that a particular version should no longer be used.
Source control creates authority over the recognised lineage.
It does not guarantee authority over every descendant.
2. Distribution control
Repositories, model hubs, cloud marketplaces and communications platforms control the easiest routes through which most users discover and obtain models.
Removing a model from a major hub can meaningfully slow adoption and block casual users. It can also prevent official one-click deployments.
Distribution control is therefore real.
It is not equivalent to recall once independent copies exist.
3. Infrastructure control
Cloud providers, chip manufacturers, data-centre operators, network providers and governments controlling energy or advanced compute can influence whether large models can be operated at useful scale.
This layer is particularly important for Kimi K3. Legal possession of the weights does not eliminate the substantial infrastructure required to serve a 2.8-trillion-parameter model efficiently. The release distributes the model more widely than an API would, but does not distribute frontier compute equally.
Infrastructure may therefore recreate central chokepoints beneath decentralised weights.
The provider’s switch weakens while the cloud’s switch, the chip supplier’s switch or the state’s switch becomes more important.
4. Deployment control
The organisation that operates a particular copy determines its effective configuration:
- which weights and quantisation are used;
- which fine-tunes are applied;
- which tools the system may call;
- what data it can access;
- which actions require approval;
- what monitoring surrounds it;
- who can interrupt it.
This is where abstract model capability becomes institutional power.
A downloaded model does not decide anything merely because it exists. It begins to co-decide when a deployer places it inside a workflow that ranks, filters, recommends, routes or executes.
Open-weight governance therefore has to follow the model downstream.
Power moves away from the provider in two directions
Open weights redistribute power beneficially.
Researchers can inspect models more deeply than black-box API access permits. Smaller companies and public institutions can avoid complete dependence on a single provider. Sensitive data can remain inside local infrastructure. Countries can adapt models to local languages, laws and administrative contexts. Organisations can preserve a stable version rather than being forced to accept every vendor update.
This can increase competition, scientific scrutiny, resilience and local capacity. The UK AI Security Institute explicitly recognises that open-weight systems support open research, widespread red-teaming and reduced market concentration.
But power also moves away from the provider’s safety and accountability mechanisms.
The same operator who can adapt the model for a neglected language may remove safeguards. The same institution that can protect sensitive data from a foreign API may operate the system beyond external scrutiny. The same local control that enables technological sovereignty may allow a deployment to persist after serious flaws are discovered.
The point is not that one side cancels the other.
The point is that both arise from the same technical fact: the provider no longer controls the only executable copy.
The copy also copies the flaws
A hosted provider can update the central system when a vulnerability, bias or dangerous behaviour is identified.
An open-weight developer can release an improved version, publish a patch or recommend that users migrate. It cannot guarantee migration.
A downstream operator may not know that a problem exists. It may lack the technical capacity to implement the update. It may have fine-tuned the model so extensively that replacing it is expensive. It may depend on behaviour that the safer version removes. It may deliberately retain the vulnerable or less restricted version.
The International AI Safety Report notes that downstream systems inherit model flaws, including vulnerabilities to adversarial attacks and possible abilities to circumvent monitoring. Unlike a hosted provider, the original developer cannot universally roll out a fix to all open-weight copies.
This changes the meaning of maintenance.
For an API system, patching can be a provider operation.
For an open-weight ecosystem, patching becomes a coordination problem.
Someone must identify affected versions, notify operators, verify updates, preserve evidence about modified descendants and determine what should happen when an operator refuses or fails to update.
Software supply chains already face similar problems. Frontier models intensify them because the artefact is not only code. It is a general capability that can be fine-tuned, embedded and given new permissions after release.
The provider is replaced by a chain of deployers
Closed-model governance concentrates responsibility but can make it opaque.
Open-weight governance distributes responsibility but can make it disappear between actors.
The original developer may say it only released the base model.
The fine-tuner may say it only adapted the model.
The cloud provider may say it only supplied infrastructure.
The application company may say it only built the interface.
The customer organisation may say it relied on the vendor.
The employee may say the system recommended the action.
The human approver may say the model had already ranked the options.
Each statement can be partly true.
Together they can produce a decision for which no participant accepts the whole chain.
This is a distinctively synthocratic problem. Humans and organisations remain formally responsible at every layer, while the practical work of shaping the decision becomes distributed across a model lineage, infrastructure stack and deployment workflow.
The problem is not that responsibility has vanished.
It is that responsibility has been divided more finely than the affected person’s ability to reconstruct it.
Governance must move before release
A controlled API permits some governance after deployment because the provider retains the ability to modify access and update the active system.
Open-weight release makes the pre-release decision more consequential.
Once the weights have spread, some remedies become unavailable. Evaluation after release can still identify problems and improve future versions, but it cannot recreate the control that existed before distribution.
The UK AI Security Institute therefore lists full-access audits, adversarial fine-tuning evaluations, staged deployment, documentation, provenance methods and — for models judged sufficiently dangerous — not releasing the system with open weights among the available risk-management approaches. It also stresses that current techniques do not provide hard guarantees.
This does not imply that every powerful model should remain closed.
It implies that release format is itself a governance decision.
The question is not only:
Is the model safe enough today?
It is also:
What powers, modifications and deployments become permanently reachable after this release, and which interventions will no longer be available?
For open weights, admissibility has to assess not only the model as tested by its developer, but the model as it may exist after copying and modification.
Governance must also follow every consequential deployment
Pre-release review is necessary but insufficient.
A model that is admissible for independent research may not be admissible for automated welfare decisions. A model that is acceptable as a locally hosted writing assistant may require different conditions before it can rank job applicants, access industrial systems or execute external actions.
The release decision concerns whether the capability may enter broad circulation.
The deployment decision concerns whether a particular version may enter a particular decision chain.
These are different gates.
A serious open-weight governance system therefore requires two records:
The Release Record should identify what the developer released, under which licence, after which evaluations, with which known limitations and with what evidence about modifiability and downstream risk.
The Deployment Record should identify which exact version an institution is operating, how it has been modified, what infrastructure it uses, what authority it receives, which safeguards surround it, who is accountable and who can stop that deployment.
Without the first, society cannot assess the original transfer of capability.
Without the second, an affected person cannot determine what actually acted in their case.
A distributed stop needs distributed interruption rights
The loss of one central red button does not mean that governance should attempt to recreate one omnipotent authority.
A single universal switch held by a government, cloud provider or model developer would create its own concentration of power. Whoever could deactivate every copy could also decide which institutions, countries or political groups retain access to an increasingly important capability.
The better objective is not one button.
It is a documented distribution of interruption rights.
The original developer should be able to issue a verified critical warning and withdraw official distribution.
Model hubs should be able to suspend downloads while preserving an evidence record.
Cloud providers should be able to isolate deployments that violate defined legal or security conditions.
Local operators should be able to halt a particular system and disconnect its tools.
Regulators should be able to suspend consequential uses within their jurisdiction.
People affected by a decision should have a route to freeze and challenge the use of the system in their own case.
These are not identical powers. They operate at different levels and require different standards of evidence.
The important condition is that no consequential deployment depends on one unreachable actor holding the only effective stop.
The Institute’s existing work distinguishes the existence of an off-switch from genuine stoppability: a stop becomes accountable only when the relevant parties can reach it before an irreversible action and are permitted to use it.
Open weights make that distinction unavoidable.
The Open-Weight Deployment Record
Before an institution places an open-weight model inside a consequential workflow, it should be able to answer eight questions.
Which model do we actually possess?
Record the original release, checksum, weight format, quantisation and version. “Kimi K3” is not sufficiently precise once multiple variants and derivatives exist.
Who modified it?
Every fine-tune, merge, safety adjustment, system-prompt layer and tool integration should be attributable to an actor and date.
What evidence travelled with it?
The deployment should preserve the model card, licence, evaluation results, known limitations, security notices and provenance information current at the time of adoption.
What did not travel with it?
The record should identify missing training information, unavailable evaluations, unknown data sources and unverified producer claims.
Where does it run?
The operator should name the hardware, cloud dependencies, serving framework, data location and upstream services required to keep the deployment functioning.
What may it do?
Its authority should be expressed operationally: read, retrieve, rank, recommend, draft, call tools, alter records, communicate externally or execute.
Who receives critical updates?
There should be a named process for vulnerability notices, model advisories, safer replacements and decisions not to migrate.
Who can stop this copy?
The record should distinguish who can halt the local model, suspend tool access, freeze an individual decision, disconnect infrastructure and prohibit the use institutionally.
If these questions cannot be answered, the organisation may possess the weights without possessing control.
Copying a model does not create sovereignty
Open weights are often discussed as a route to sovereign AI.
They can be an important component of sovereignty because they reduce dependence on a provider’s API and make local operation possible.
But sovereignty is not a file.
A country or institution may hold the weights while depending on foreign accelerators, foreign fabrication, foreign cloud services, externally maintained serving engines, imported technical expertise and updates produced by the original developer.
The Synthocracy Institute’s existing analysis describes sovereignty as a stack rather than a download. The distinction is especially important for very large models such as Kimi K3: the weights may travel more easily than the infrastructure needed to operate them at scale.
Open weights weaken one dependency.
They may expose others.
This is why the geopolitical effect of Chinese open-weight models cannot be measured only by download counts. The deeper question is which actors can turn possession into sustained operation — and which Chinese, American or global infrastructure layers remain necessary after the model has been downloaded.
The new question is who controls each copy
Under API access, governance can focus heavily on the provider.
Who sets the rules? Who monitors use? Who controls the model version? Who can withdraw access?
After open-weight release, those questions remain relevant but are no longer sufficient.
Governance must ask:
- Who controls this particular copy?
- Which lineage produced it?
- Which safeguards remain?
- Which operator gave it authority?
- Which infrastructure sustains it?
- Which update channel reaches it?
- Who can stop its actions?
- Who answers to the people affected?
The original developer remains important.
It is no longer the whole governance map.
This is the central institutional consequence of open weights. Power does not move from one company into an abstract public domain. It moves into a chain of repositories, infrastructure providers, fine-tuners, governments, companies, research institutions and local operators.
Some of those actors gain freedom.
Some gain responsibility.
Some gain power without yet being recognised as governors.
The model can be copied. Accountability cannot be assumed to follow
The strongest argument for open weights is that capability should not remain enclosed inside a few private laboratories.
The strongest warning is that once capability leaves those laboratories, the controls and records built around it do not automatically travel with equal strength.
A model can be copied in hours.
An accountability system cannot.
It must be designed, documented, adopted, maintained and enforced across every consequential deployment. It must survive fine-tuning, redistribution, version drift and institutional handoffs. It must provide local stoppability without creating one global sovereign over every copy.
That is the governance challenge created by Kimi K3 and the open-weight frontier.
The central switch is no longer the whole story.
The story is what replaces it.
Open weights distribute intelligence, but they also distribute the authority to configure, deploy and embed that intelligence in the decisions that organise social life.
After the weights are released, the question is no longer simply whether the original developer can press the red button.
The question is whether every consequential copy has an identifiable operator, a reconstructable history, a bounded authority and a stop that someone accountable can actually reach.
Martin Novak is the founder of the Synthocracy Institute. Insight 01 · Admissibility & Evidence · Synthocracy Institute · operating internationally
Synthocracy Institute
contact@synthocracyinstitute.com
synthocracyinstitute.com
