- Microsoft and NVIDIA argue that open or closed weights do not decide an AI system's risk. The model, its use, its deployment and its safeguards do.
- Running your own model deployment can mean taking on controls that a managed service would otherwise provide.
- Leaders should ask which team owns each risk, which layer holds the control, and when it is next reviewed.
The label is not the risk
Food safety is not settled by the quality of the ingredients alone. It depends on the kitchen, the staff and the checks before the plate leaves. Microsoft and NVIDIA make a similar case about AI models.
Microsoft and NVIDIA have co-published a paper called Risk Management for Open-Weight Models in Enterprise. Microsoft describes it as the first in a planned series of joint resources. Open-weight means the customer can get the model's weights, the learned numbers that define it.
Microsoft's blog post puts the central point this way: whether weights are open does not, by itself, set the risk. The model, the use case, the deployment and the safeguards all count.
The lesson for executives is simple. An open or closed label tells you who can inspect the model. It does not tell you how safe the model is to run in your business.
What the paper offers
The paper offers a shared vocabulary so that engineering, security, legal, safety and business teams can talk about the same risks. Its taxonomy sorts them into five broad groups. The groups are cybersecurity, data protection, content, human-AI interaction and bias. Microsoft says the approach rests on ISO standards and the NIST AI Risk Management Framework.
Microsoft says this is not a policy or a deployment checklist. Each company should adapt it to its own systems and risk criteria. Then it should tie each relevant risk to tests, fixes and a named owner.
The paper also links tests, called evaluations, to some of the risks in the five groups. A team can pick a risk that matters to it and find a test that produces evidence about it. Microsoft says the two companies plan to add more tests to a joint repository.
Same model, different exposure
Microsoft gives two examples. A model that helps an employee draft a document raises different questions than the same model facing customers. A standalone endpoint, where software sends text in and gets text back, differs from a system wired to outside data or tools.
So a risk may begin in the model while the best control sits somewhere else. It might sit in the environment that runs the model, in the application, or in the surrounding process.
Microsoft names several possible safeguards. They include changing the model, limiting access, filtering what goes in and out, monitoring, and human review. The right mix depends on the risk.
This first paper looks mainly at the model itself. Microsoft says a tested model does not prove that an agent or application is safe. Teams must also check what the system is allowed to do, what data it can reach, which tools it uses, and how it is run and controlled. Later work is meant to cover those layers.
Who carries the controls
The human issue is ownership. Microsoft points out that getting a model and deploying it are separate choices. Open-weight models can also run on managed platforms.
Who holds the safeguards depends on the service and how it is set up. Microsoft says a company that runs its own deployment may take on controls a managed service would otherwise supply.
Consider a platform engineer who self-hosts a model to save money or gain control. Using Microsoft's point, that person may now be responsible for safeguards, such as filtering or monitoring, that a managed service would have handled. This is our illustration, not a finding from the paper.
Read it with care
This is guidance from two vendors with products in the market. Microsoft's post points to its Foundry tests, automated red teaming and content-safety controls. It also tells teams to confirm that each control is available for their model and deployment, including whether it is still in preview.
This story draws on Microsoft's blog post, not the full paper. The post gives no data on how often these risks cause harm. Its value is as a structure for the conversation, not as proof of scale.
Questions to put to your team
First, for each AI system in use, who is the named owner of each of the five risk categories? Second, which layer holds the control for each risk: the model, the runtime or the application?
Third, if we host a model ourselves, which safeguards did a managed service provide that we now run? Fourth, what evidence do we hold from tests on our own use case, not a generic benchmark?
Fifth, when do we revisit these decisions? Microsoft says they must be revisited as models and deployments change.
A model's licence tells you what you may do with it. Only the deployment tells you what it can do to you.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Microsoft Security.
