The open-weight wave: DeepSeek V4 and Kimi K3 risk

The last week of July 2026 is one of the largest concentrations of open-model releases in the industry’s history. DeepSeek V4 moves to stable availability (and 24 July is the deadline to retire legacy model names in the API), while Kimi K3 weights are due to be published on 27 July. For IT teams this is not just exciting news but a concrete risk decision: when and how to let open models into the organisation.

What exactly is happening

Two things coincide:

• DeepSeek V4 — a model available in preview since April (Pro and Flash variants) enters its stable phase. An operational note: 24 July 2026 is the deadline to retire legacy model aliases (including deepseek-chat and deepseek-reasoner) — after that date they stop working, so pipelines referencing old names must be updated. We covered the model’s technical side in DeepSeek V4: 1.6T MoE, CSA/HCA, Muon.
• Kimi K3 — the weights of a powerful model (2.8 trillion parameters) enter public circulation on 27 July. We discussed the model and its risks in Kimi K3: architecture and enterprise risk.

Why open weights are not just an opportunity

Open, capable models have real advantages: control over deployment, no sending data to an external API, and the ability to fine-tune. But “open weights” also raise questions you do not ask of a closed API:

• Provenance. Where does the model come from and under what rights? That question became hot after the distillation allegations around Kimi K3. Contested legal status is a risk, not just trivia.
• Licence. “Open” does not always mean “free for commercial use with no restrictions.” Read the terms, do not assume them.
• Supply-chain security. Downloading weights means introducing a component from outside — the same discipline applies as for any dependency: from where, in what version, with what checksum.
• Updates and support. A model you run yourself will not patch itself. Responsibility for its lifecycle passes to you.

How to approach adoption

1. Treat the model as a supply-chain dependency. Record the source, version, licence and weight checksums. This is your “SBOM for models.”
2. Separate experiment from production. Test in an isolated environment before connecting the model to company data and tools.
3. Assess provenance deliberately. Especially in a regulated sector, ask whether a model’s contested legal status is an acceptable risk.
4. Plan for swappability. Build an architecture where the model can be replaced without rewriting the application — your emergency exit.
5. Do not skip deployment security. An open model still needs access control, least privilege and monitoring — like any element of AI and LLM security in business.

The bottom line

Late July’s open-weight wave is an opportunity, but also a test of process maturity. The difference between a company that adopts safely and one that lets in an uncontrolled component lies in the evaluation process: provenance, licence, isolation, swappability. If you want to shape an open-model adoption policy, get in touch.

Sources: DeepSeek API — V4 release notes, Build Fast with AI — 23 July 2026.