You don't want to send confidential documents to an external API. You want monthly usage costs to be more predictable. For reasons like these, plans come up to run models whose weights are public, such as Gemma or Qwen (open-weight models), on your own servers or in your own cloud environment.
What is easy to overlook at that point is the controls that API providers had been supplying behind the scenes. When you run a model yourself, detecting inappropriate output, monitoring usage, limiting abuse, and similar controls often have to be provided by your own company.
In October 2026, Microsoft and NVIDIA published a joint document that organizes this point, "Risk Management for Open-Weight Models in Enterprise" (version 1.0; updated to version 1.0.1 on October 27). The document and the risk taxonomy are published in NVIDIA's GitHub repository. In this article, based on the document's contents, we lay out what to decide before running models in-house.
The document's position: publishing weights alone does not determine risk
At the core of the document is the idea that "whether weights are public does not by itself determine the level of risk of an AI system. It is determined by the model, the use case, the deployment method, and the safeguards."
It then explains that the difference lies in "who provides the controls." Models with closed weights are often offered in combination with safety mechanisms, security monitoring, caching, and so on. Open-weight models, on the other hand, are often distributed as weight files alone, and reaching the same level requires additional integration. The controls themselves are largely the same, but who provides them changes.
It also states that how you obtain a model and how you deploy it are separate choices. Open-weight models can also run on a managed cloud platform, in which case the division of responsibility changes depending on the service and configuration.
The document describes where to place controls in four layers: the model, the runtime, the harness, and the application. However, this first document covers the model layer in detail, and the remaining layers are planned for future documents. It also states explicitly that "model evaluation alone cannot demonstrate the safety of agents or applications."
A risk taxonomy of 5 categories and 30 types
The risk taxonomy consists of 5 top-level categories (L1) and 30 types (L2).
- Cybersecurity (5 types): generation of vulnerable code or code with malicious dependencies, unintended tool calls, excessive token generation, and more
- Data protection (6 types): disclosure of training data, disclosure of personal information, reconstruction of sensitive information through inference, model theft, failure of isolation between multiple users, and more
- Content (7 types): harmful content, reproduction of copyrighted works, unfounded content (information accuracy), and more
- Human-AI interaction (7 types): manipulation, deception, overreliance, sycophancy, and more
- Bias (5 types): AI profiling, representational bias, ideological bias, censorship, and more
The document says this taxonomy is "neither a policy nor a checklist." It is positioned as a common vocabulary for selecting the risks that fit your own use cases, assigning an owner to each risk, and linking them to evaluation and mitigation. Techniques such as jailbreaks and prompt injection are left out of the taxonomy itself, as things that can lead to cybersecurity risks.
Example: an inference endpoint exposed to internal users and dealers
As a concrete example, the document describes "a model-only inference endpoint that does not call tools." An industrial equipment manufacturer runs an open-weight model as a shared internal text service and uses it to summarize field reports, translate into 14 languages, and classify inquiries. The same endpoint is also exposed to contracted dealers.
The document explains that controls should be placed where they can be enforced most reliably, and that in this configuration those are the following two layers.
- Model layer: evaluate harmful content generation, jailbreak resistance, refusal behavior, and factual accuracy using the weights actually being distributed. For example, verify summary accuracy in 14 languages using your own reports
- Serving layer: put in place authentication and authorization to identify users, rate limits, abuse monitoring, and input and output inspection. Separate internal and dealer traffic, apply stricter inspection and rate limits to the external-facing endpoint, and narrow its use cases
In addition, because input and output inspection is often done by a separate model, the document points out that "there are two things to evaluate: the model being distributed and the model doing the inspection." It also lists as a key risk that, on an endpoint that does not cite source documents, fabricated numbers (in the document's example, a tightening torque value) read just like correct values.
What to decide before adoption
Based on the document's process (setting scope and criteria, evaluation, mitigation, and monitoring), the editorial team has organized what to decide first for small and medium-sized in-house deployments.
- Verify the files you obtained: the document says to "verify provenance before behavior," and treats using signatures (such as OMS Model Signing) to confirm that the weights you received are the same as those published by the provider as a basic control that evaluation cannot replace. If there is no signature, record it as an unverified risk
- Write the pass criteria first: decide before evaluation what kinds of errors, and how many, would mean you will not use the model. The document cautions that what evaluation measures is "the tendency for that behavior to appear under test conditions," which is different from the likelihood of it occurring in production
- Re-evaluate when the weights change: the document notes that fine-tuning, quantization, and model merging can weaken safety behavior alone while preserving performance. If you distribute a quantized version, evaluate the quantized version
- Decide where in your organization to place serving-layer controls: authentication, rate limits, input and output inspection, and logging. The document also notes that logging prompts and outputs can itself become a data protection risk
- Decide what to monitor: releases of derivative versions, changes in distributor or license, new jailbreak techniques, and vulnerabilities in tokenizers or runtimes. Keep inspections and limits in a form you can change quickly so you can respond without waiting for weight updates
We covered the risk of relying on a single source for obtaining models in Re-evaluating AI model acquisition routes following the Hugging Face acquisition agreement. For distributing local AI to company devices, Introduction to Microsoft Foundry Local is a useful reference. If you are deciding whether to send data to an external API or run models yourself based on where the data is stored, please also read Which country's servers receive the data provided to generative AI used in business?
Scope of verification
On October 29, 2026, we retrieved
NVIDIA/OpenEnterpriseRiskManagementGuidancefrom GitHub (commit16a16f4of October 28, 2026) and read the document PDF (version 1.0.1, 22 pages), the risk taxonomy PDF, the README, and the changelog. We also checked the introductory article on the Microsoft Security Blog (October 16, 2026) (document research). We did not run the document's evaluation procedures or benchmarks. The section "What to decide before adoption" above is the editorial team's summary based on the document's contents.
For the architecture of AI you run in-house and the design of evaluation and controls, please contact us through Development, AI, and automation consultations.
