On 24 July, a coalition led by NVIDIA published a letter arguing that open-weight models had become a matter of American technological leadership. It began with 25 organizations. Within days, the list had grown to more than 130, spanning model builders, cloud providers, chipmakers, enterprise software companies, investors, and open-source institutions.
Three days after the letter, NVIDIA announced the Open Secure AI Alliance. Its founding group includes Microsoft, IBM, Red Hat, Cloudflare, CrowdStrike, Hugging Face, Mistral, Palantir, Salesforce, ServiceNow, and dozens of others. The stated ambition is not simply to release more models. It is to develop an open defense stack for agents, including identity, isolation, model formats, scanning, secure coding, logs, and evaluation.
NVIDIA has an obvious commercial interest in an abundant model ecosystem. More models consume more compute. That makes the company an interested party, not an unreliable one.
Huang argues that open models strengthen safety, cybersecurity, innovation, and national sovereignty.
Jensen Huang
The coalition is pointing at something larger than a licensing debate. AI is beginning to separate into two markets: the models themselves, which will multiply and change quickly, and the business systems built around them, which must endure.
The strategic question is no longer which model wins.
It is whether your company can choose.
Open weights are good
The case for open-weight models starts with competition.
When capable models can be downloaded, adapted, evaluated, and run on infrastructure chosen by the customer, no single provider gets to define the price, the acceptable use policy, the deployment geography, or the pace at which everyone else may innovate. Startups can build without training a frontier model from scratch. Researchers can examine behavior that an API does not expose. Companies with genuine data-residency requirements can keep inference inside an environment they control.
Open weights also give buyers leverage. A credible alternative changes a negotiation even when it is never deployed. It places a ceiling on dependence and gives the customer somewhere to go if a provider changes its price, removes a feature, narrows an acceptable-use policy, or simply falls behind.
This is how healthy technology markets develop. A strong open layer prevents the entire application economy from becoming a collection of tenants on three private platforms.
There is an important distinction in the language. Open weights are not automatically open source. The weights are the numerical parameters produced by training. A genuinely open-source AI system may also provide code, documentation, license freedoms, and enough information about the data and training process to study or reproduce meaningful parts of the system. The Open Source Initiative makes that distinction explicitly. A downloadable model may give you considerable control without giving you complete transparency.
That limitation does not make open weights unimportant. It makes precision important.
Open weights do not guarantee independence. They make independence possible.
Good does not mean harmless
Once capable weights are released, the original developer cannot recall every copy or guarantee that its safeguards remain intact. A company running those weights also assumes work that a hosted provider was doing on its behalf: serving, patching, monitoring, access control, incident response, and policy enforcement.
Anthropic's response to the NVIDIA letter is more nuanced than the argument around it sometimes suggests. The company says that open-weight models without dangerous capabilities are a public good and rejects a categorical ban. It also argues that sufficiently capable open and closed models should face safety testing, and disputes the assumption that wider access will always help defenders more than attackers. That is a legitimate disagreement about where risk changes at the frontier, not an argument against every open model.
The Hugging Face security incident shows both sides at once. During its response to an autonomous intrusion, Hugging Face reported that hosted commercial models blocked some legitimate forensic work under their cyber policies. The company then ran the open-weight GLM 5.2 on its own infrastructure and used it to analyze more than 17,000 recorded actions. The local model gave defenders control at the moment they needed it. The same lack of external control is what worries people when the operator is an attacker.
The conclusion is not that open is safe and closed is dangerous, or the reverse. The conclusion is that the deployment model moves responsibility.
If you choose open weights, you gain authority. You also inherit the obligations that authority carries.
Choice is not a procurement feature
Most companies describe themselves as model-agnostic because an engineer could replace one API call with another. That is a very low bar.
The real dependency accumulates elsewhere. Business knowledge gets embedded in a provider's assistants. Workflow logic is written around proprietary tool-calling behavior. Prompts remain scattered across applications. Evaluation consists of asking a few employees whether the new output “looks better.” Permissions live inside third-party dashboards. Logs capture the answer but not the action that produced it.
By the time the company wants to move, the model is no longer a component. It is a load-bearing wall.
Open weights do not fix that architecture. Downloading a model into the same tightly coupled system merely changes whose hardware is running the dependency.
Real choice has to be designed before it is needed.
An AI-native company should have a durable operating layer above the models it uses. That layer contains the company's memory, its agent roles, its reusable skills, its connectors to business systems, its security controls, and its measures of good performance.
The models sit beneath it. Some will be closed frontier systems. Some will be open weights running through a managed provider. Some may run locally for privacy, latency, or continuity. Smaller specialist models will handle work that does not justify frontier cost.
The company should be able to route among them without changing the way the business understands itself.
The portability test
Model portability is easy to claim and surprisingly easy to test. A company that wants the architecture of choice should be able to answer the following questions with evidence.
1. Can your company brain outlive the provider?
Institutional knowledge, customer context, operating procedures, decisions, and long-term memory should live in systems the company controls. The model receives the relevant context for a task. It does not become the only place that context exists.
This usually means a governed knowledge layer with explicit sources, ownership, update rules, retention policies, and retrieval interfaces. A conversation history exported from a vendor is not a company brain.
2. Are agents defined by their jobs or by their models?
An agent should be a role with instructions, tools, permissions, success criteria, and escalation rules. “Our Claude agent” or “our GPT agent” is already a warning that the provider has leaked into the design.
Define the capability first. Then let an orchestration layer assign an appropriate model based on the task, risk, cost, latency, and required context.
3. Do tools and connectors have stable contracts?
Models should not hold direct, improvised access to the CRM, accounting platform, inbox, or production database. Put those capabilities behind explicit tool contracts with typed inputs, narrow outputs, and controlled credentials.
Standards such as MCP can help at the interface boundary, but adopting a protocol is not the same as achieving portability. The important test is whether a second model can use the capability without rewriting the underlying business integration.
4. Is workflow logic separate from model behavior?
Approvals, retries, state transitions, deadlines, and exception handling belong in deterministic workflow code. Do not hide them inside a prompt and hope the next model interprets them the same way.
The model should exercise judgment where judgment adds value. The workflow should remain responsible for what must happen every time.
5. Can you compare models on your own work?
Public benchmarks cannot tell you whether a model reconciles your invoices correctly, follows your intake policy, cites the right contract clause, or knows when to ask a person.
Maintain a representative evaluation set built from real tasks and known edge cases. Score task completion, factual accuracy, policy compliance, latency, cost, escalation behavior, and downstream rework. Run the same evaluation when a promising model appears. That turns model selection from enthusiasm into procurement.
6. Do identity and permissions belong to the company?
The model should never be the authority. Agents need distinct identities, least-privilege access, short-lived credentials, approval thresholds, and an audit trail that records actions as well as answers.
Those controls must survive a model change. If changing providers requires rebuilding the permission system, the company does not own its control plane.
7. Are instructions treated as operating assets?
Prompts, policies, examples, skill definitions, and routing rules should be versioned, reviewed, and tested. They encode how the company wants work performed. Leaving them scattered across individual tools is the AI equivalent of keeping the operating manual in an employee's private notebook.
Model-specific optimizations are reasonable. They should sit behind an adapter, not spread through the entire business system.
8. Have you actually changed the model?
Portability that has never been exercised is an aspiration.
Choose one meaningful workflow and run it against a second provider or an open-weight alternative. Measure what breaks. The first drill will expose hidden assumptions in tool schemas, context windows, structured outputs, safety behavior, latency, and evaluation coverage.
You do not need to migrate the business. You need to prove that migration is a capability.
The architecture becomes the advantage
The largest model will continue to change. So will the cheapest, the fastest, the most private, and the one your team prefers. Open-weight releases will improve. Closed providers will answer them. Specialist models will outperform both on narrow work. Regulation and procurement rules will shift underneath all of them.
Trying to select one permanent winner is not strategy. It is a bet against the rate of change.
The better strategy is to make models compete for a place inside an operating system the company owns.
That is the deeper value of open weights. They do not require every business to build a GPU cluster or fine-tune its own model. They create a credible right to exit. They make a plural market possible. They ensure that a company with the right architecture can choose a closed frontier model today, an open model tomorrow, and a combination of both when the work demands it.
An AI-native company is not one that uses the most AI. It is one whose knowledge and capabilities become more valuable as the model market changes.
Own the brain. Own the tools. Own the controls. Let the models compete.
