The Weights Are Free. The Obligations Are Not.

Moonshot AI released Kimi K3 on 16 July 2026 and published the weights eleven days later, a 2.8 trillion parameter mixture of experts model with a 1 million token context window, native vision and a checkpoint shipped in MXFP4 alongside a serving path in vLLM. Coverage focused on the size, which is understandable given it is the largest open weight release to date, and on the benchmark placement, where it lands in the same conversation as the closed frontier models rather than a tier below them. The detail that matters more for anyone running an AI feature in production is quieter than either. Until this year, choosing open weights meant accepting a capability discount in exchange for control. That trade has narrowed to the point where it is now a genuine architectural option rather than a hobbyist one, and it arrived in the same weeks that OpenAI cut GPT-5.6 Luna by roughly 80 per cent to 0.20 US dollars per million input tokens, Gemini 3.7 Flash halved, and DeepSeek V4 Flash settled at 0.14. Hosted inference has never been cheaper and self hosting has never been more capable, which means the decision is now a real one for a lot of teams that previously did not have to make it.

Start with the iron, because the romance of running your own model tends to survive right up until someone prices it. The published checkpoint is roughly 594 GB in its native MXFP4 form. The vLLM recipe starts at eight GB300 class NVIDIA accelerators or eight AMD MI355X, and serving real production traffic with reasonable concurrency is estimated closer to 1,680 GB of usable VRAM, with production guidance pointing at 64 or more accelerators once you account for headroom, replicas and failure domains. Blackwell class capacity currently runs from about 2.25 US dollars per GPU hour on a 36 month reserved commitment to roughly 5.50 on specialist clouds and past 14 on large cloud on demand list rates. Break even against an API therefore depends almost entirely on utilisation, and the honest version of the calculation includes the engineer who keeps the cluster alive, not just the instance line. Teams that run steady, high volume, latency tolerant workloads can make the numbers work. Teams with spiky traffic almost never can, and should stop reading the hardware guides and go back to the API.

The part that gets missed is not financial at all. When you call a hosted endpoint you are a customer, and a great deal of assurance arrives with that status without anyone having to build it. There is a SOC 2 Type 2 report you can file in your evidence library, a data processing agreement your legal team already negotiated, a subprocessor list, a published incident process, a status page, a security contact who answers, a model card someone else wrote, and an evaluation regime someone else ran. None of it is perfect and plenty of it is thin, but it exists and it is attributable to a party that is not you. Pull a checkpoint onto your own cluster and every one of those artefacts either disappears or becomes yours to produce. That is the actual trade. The weights are free in the sense that you do not pay for them, and expensive in the sense that you have quietly taken delivery of a role.

ISO 42001 makes the role explicit, which is why it is the right lens here rather than an afterthought. The standard organises obligations around where you sit in the AI value chain, and it distinguishes between an organisation that develops or provides an AI system and one that merely deploys somebody else, with materially different expectations attached to each. Serving your own model moves you along that chain. The intended use statement, the documented limitations, the evaluation records against the uses you actually ship, the human oversight design, the incident and malfunction handling, the impact assessment on affected parties: these stop being questions you answer about a vendor and become documents you author about yourself. Most organisations that have been through an ISO 42001 readiness exercise answered the provider questions with a variation of we consume a third party model, and that answer is no longer available once the checkpoint is on your hardware.

The regulatory version of the same point has sharper edges and a shorter fuse. Under the EU AI Act, obligations attach to the provider of a general purpose AI model, and a downstream party that substantially modifies such a model can itself become the provider of that modified model, with the technical documentation, copyright policy and training data disclosure obligations that follow. Fine tuning is the trigger most teams will hit first, and it is worth saying plainly that fine tuning does not feel like a legal event when you are doing it. It feels like a configuration change, a training run, a slightly better eval score on a Friday. Nobody files anything. If your organisation sells into the European Union, or serves European users, the difference between deploying an open weight model as published and shipping a modified derivative of it is a difference in who the regulator considers responsible, and it should be a decision someone makes deliberately with a record attached rather than one that emerges from an experiment.

Then read the licence, before the platform team pulls the checkpoint rather than after. Open weight is not a synonym for open source, and the current generation of releases has settled into a pattern of a permissive base with conditions bolted on for specific commercial uses. The Kimi K3 terms are described as a modified MIT licence, with additional conditions that bite on large managed service operators and very large commercial products. Whether those conditions apply to you depends on facts your legal team can establish in an afternoon and your engineers will not think to ask about, particularly the question of whether you are consuming inference internally or reselling it as part of a product. This is the same class of problem that source available database licences created for a previous generation of infrastructure teams, and it produced the same failure mode, which was adoption first and a licence review some months later when a customer questionnaire asked an awkward question.

The supply chain controls are more familiar and, for once, that is genuinely good news, because a model checkpoint is a large binary artefact retrieved from a repository over the network and the discipline for that already exists. Pin by digest rather than by a mutable tag or branch, verify the published hashes on retrieval, mirror the artefact into infrastructure you control instead of pulling from a public hub at deploy time, prefer safetensors style formats over anything that deserialises arbitrary code, and record the provenance of what you are actually serving so that the answer to which weights are in production is a lookup rather than an investigation. ISO 27001 Annex A already covers supplier relationships and ICT supply chain security, and the controls read perfectly sensibly when the supplier is a model repository. SOC 2 change management applies to swapping a checkpoint exactly as it applies to shipping code, and a model change that alters system behaviour for customers without a change record is a finding waiting to be written up, whether the model came from an API or a GPU in a rack.

None of this will show up in your compliance platform, and the reason is structural rather than a missing integration. Vanta, Drata, Secureframe, Sprinto and Thoropass build continuous monitoring on systems that emit records a connector can subscribe to, which means the identity provider, the device fleet, the cloud accounts, the code hosting platform and the ticketing system. A cluster of accelerators serving a checkpoint emits nothing any of those connectors reads, and the licence position, the provider determination and the weight provenance record are documents rather than telemetry. That does not make them optional, it makes them manual controls with a named owner and a review cadence, and the practical failure is not that the control is hard but that nobody assigns it, because the dashboard stays green and green reads as covered.

So here is the exercise, and it is a morning rather than a project. Search the estate for the markers that indicate open weights are already in play, from_pretrained calls, references to a model hub, vLLM or Ollama or llama.cpp in a Dockerfile, GPU instance types in Terraform, and a checkpoint path in an inference service. Expect to find more than you predicted, including at least one experiment that quietly became a dependency. For each hit, answer three questions and write the answers down: are we the provider or the deployer of this model under ISO 42001 and under the EU AI Act, have we modified it in any way that changes that answer, and does the licence permit what we are actually doing with it. Then decide, once and deliberately, which systems belong on a hosted API and which justify the cluster, because the price war has made the API case stronger for most workloads while the capability jump has made the self hosted case real for a few. The pattern underneath is the one this industry keeps relearning with cloud, with containers, with open source packages, with MCP servers and now with weights. A genuinely useful capability arrives, adoption runs ahead of the governance around it, and the reckoning lands as an audit question about something that was installed eighteen months earlier by someone who has since moved on.