The Conventional Wisdom
Download the weights and you're free. That's the promise driving enterprise AI strategy in 2026: escape vendor lock-in, control costs, own your data path, and run the model on your terms. Open-weight models like Kimi K3 seem to deliver exactly that. No metered API calls. No forced upgrades. No provider deciding when your validated model gets deprecated.
The pitch is compelling because it's partly true. You do gain meaningful control when you self-host. But the governance community has started treating "open weights" as synonymous with "independence," and that's where the logic breaks down.
Why We Disagree
Open weights shift dependencies, they don't eliminate them. You're trading one set of constraints for another, often without recognizing what you've taken on.
Consider what actually happens when you download a frontier model. You've acquired the trained parameters but not the training data, the full code that produced them, or the decisions that shaped what went into them. The Open Source Initiative's definition requires training data, training and runtime code, and model parameters. Most "open" releases deliver only the last item. You get the finished product without the recipe.
That matters because your model risk framework still needs answers to questions the weights can't answer. What data sources introduced demographic skew? Which filtering decisions shaped the model's behavior on edge cases? What does "frontier-level performance" actually mean when the evaluation suite isn't disclosed? You're responsible for the model's outputs, but you're governing a system whose provenance you can't fully trace.
The dependency doesn't end there. Nvidia's reported US$12.9 billion pursuit of Hugging Face exposes the infrastructure layer underneath the weights. The models may stay downloadable, but the platform that distributes them, the libraries that run them, and the tooling that makes them usable all sit somewhere. If that layer consolidates, you've escaped the API provider only to depend on whoever controls the distribution channel.
The Evidence
Look at what enterprises actually need to operationalize an open-weight model:
Inference infrastructure that scales. Cloud providers supply this, and the same hyperscalers who offer proprietary APIs also rent you the compute to run open weights. You've changed vendors, not eliminated the dependency.
Evaluation pipelines you can defend. SR 11-7 requires ongoing performance monitoring and validation evidence. An API provider maintains safeguards and can patch vulnerabilities in real time. Download the weights and those responsibilities transfer to you. You need the expertise to test the model, the capacity to maintain it, and the documentation to prove you did both.
Security controls that account for persistent risk. The UK AI Security Institute notes that once weights circulate, safeguards can be altered through fine-tuning and copies persist indefinitely. Your threat model changes when the model lives on your infrastructure. So does your incident response plan.
Governance functions that used to live with the provider. Who decides when to update the model? Who validates the fine-tuned version? Who owns the decision when the model produces a harmful output? These questions don't disappear when you self-host. They become yours.
The financial case is real but incomplete. DeepSeek's pricing ranges from US$0.22 to US$1.32 per million tokens depending on caching and peak demand, roughly 11 to 23 times cheaper than GPT-5.5. At enough volume, self-hosting makes economic sense. But that calculation only works if you account for the full cost: not just compute, but the engineering, evaluation, security, and governance capacity you're now building in-house.
What to Do Instead
Treat open weights as a dependency shift, not dependency elimination. Your governance framework should answer these questions before you commit:
Can you trace the model's provenance well enough to meet your risk tier? If you're deploying in a regulated context, "we downloaded the weights" won't satisfy your auditors. You need to know what the model was trained on, or you need to accept that you're governing a system with an unauditable foundation.
Do you have the capacity to validate and maintain the model yourself? This isn't just a technical question. It's about whether your team can perform ongoing performance monitoring, document validation evidence, and respond when the model fails. If that capacity doesn't exist, self-hosting transfers risk you can't manage.
What happens when the platform underneath the weights changes ownership? Hugging Face hosts the models and maintains the libraries most developers use to run them. If Nvidia's acquisition closes, does your dependency profile change? Does your data residency strategy still hold? These aren't hypothetical concerns, they're infrastructure governance questions that belong in your vendor risk assessment.
What does your threat model look like when the model persists on your infrastructure? Safeguards you can't update, vulnerabilities you can't patch centrally, and copies you can't revoke all change your security posture. Your red teaming and robustness testing need to account for that.
Build the governance capacity before you take on the responsibility. Open weights give you control, but control without capacity is just unmanaged risk. If you're moving model operations in-house, your risk function needs to move with it.
When the Conventional Wisdom Is Right
Open weights do deliver independence in specific, important ways.
Data sovereignty is real. Self-hosting keeps prompts and outputs on your infrastructure instead of passing through a provider's API. For regulated institutions handling sensitive data, that's not a nice-to-have, it's often a requirement.
Version control matters. An API model can be repriced, revised, or retired on the provider's timeline. A self-hosted model stays fixed. If you've spent months validating a specific version, you can keep running that version instead of migrating when the provider decides to upgrade.
Cost control becomes possible at scale. When you're processing enough tokens, converting metered API costs into infrastructure spending changes the economics. You're trading operational expense for capital expense, and you're doing it on your terms.
The conventional wisdom gets these benefits right. What it misses is that the benefits come with new obligations, and those obligations require capabilities most organizations haven't built yet. Open weights are a tool for independence, not a guarantee of it. Whether they make you more independent depends entirely on whether you're prepared to govern what you've downloaded.
