Announced on the Microsoft Security Blog and Microsoft Azure Blog by Michael Scovetta, Partner Security Assurance Manager at Microsoft, the paper was developed and edited by Andrew Berkley and April Chen of Microsoft alongside Michael Boone, Eileen Long, and Arun Rao of NVIDIA. Rather than treating open-weight models as either inherently dangerous wildcards or magic privacy bullets, the two companies are pushing enterprises to evaluate how a model's provenance, intended use, architecture, and surrounding safeguards interact in a real-world deployment.
Beyond the "Open vs. Closed" Label
Open-weight models—where developers release the trained parameters so organizations can inspect, test, fine-tune, or self-host the model inside their own environments—have become an essential part of enterprise AI strategies. They offer flexibility and architectural control that API-only models cannot match. However, that flexibility also shifts how organizations test models, where they place guardrails, and who carries the operational burden of maintaining those defenses over time.
Microsoft and NVIDIA argue that open-weight and closed-weight models share many of the same underlying vulnerabilities, and that risk materializes based on deployment context rather than weight licensing alone. Consider two common enterprise scenarios highlighted in the announcement:
- Internal vs. External Exposure: A model helping an internal employee draft a routine document carries a vastly different risk profile than that exact same model wired into a customer-facing workflow.
- Standalone vs. Connected Architecture: A standalone inference endpoint that only processes text in isolation is fundamentally different from an agentic system granted permissions to query enterprise databases or trigger external software tools.
Crucially, Microsoft separates the concept of model access from model deployment. Choosing an open-weight model does not automatically force an enterprise to rack its own GPUs and manage bare-metal inference; open-weight models are also widely consumed through managed cloud platforms. When an organization does opt to operate its own deployment rather than rely on a managed service, it must be prepared to take over the safety and security controls that a platform provider would otherwise maintain.
Section Summary: Weight openness alone does not dictate AI risk. Security leaders must look past whether a model is open-weight or closed-weight and examine how the model is hosted, who interacts with it, and what systems or data it can touch.
A Five-Part Risk Taxonomy for Cross-Team Alignment
One of the quiet headaches in enterprise AI governance is getting software engineers, CISO teams, legal counsel, safety researchers, and business unit owners to speak the same language. Grounded in established frameworks—including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework (AI RMF)—the Microsoft and NVIDIA paper introduces a shared risk taxonomy built around five primary categories:
| Risk Taxonomy Category | Operational Role in Enterprise Governance |
|---|---|
| Cybersecurity | Identifying and mitigating technical exploitation, prompt attacks, and system-level security threats across the deployment. |
| Data Protection | Governing how sensitive inputs, training data, and connected enterprise data sources are accessed, handled, and protected. |
| Content | Detecting and filtering harmful, inappropriate, or policy-violating inputs and generated outputs. |
| Human-AI Interaction | Assessing how end users—whether employees or customers—rely on, interpret, and interact with the model's outputs. |
| Bias | Evaluating and addressing unfairness or skewed behavior in model responses relative to the intended business use case. |
Microsoft emphasizes that this taxonomy is a shared vocabulary, not a turn-key policy or a static compliance checklist. Because this first paper focuses primarily on model-layer risks, passing a model-level evaluation never certifies that a broader application or AI agent is safe. Even when a risk originates inside the model's weights, the most practical mitigation might live in the inference runtime, the application wrapper, network access controls, or human review processes.
Outside legal and security commentary reinforces why enterprises need this layered view. For instance, an August 2026 enterprise advisory from the global law firm Cooley notes that organizations deploying open-weight models should also assess the jurisdiction, ownership, and supply chain of a model's developer and upstream contributors, check for export control or trade restrictions, and weigh whether self-hosted or managed inference better fits their data sensitivity and contractual obligations. Similarly, cybersecurity guidance published by BankInfoSecurity highlights the importance of maintaining a verifiable chain of custody for open-weight artifacts—through fine-tuning or quantization steps—while establishing clear acceptable-use policies to curb unsanctioned "shadow AI".
Section Summary: The joint paper organizes model-layer risks into Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It gives multidisciplinary teams a common starting point while reminding them that application permissions, tools, and runtime controls must still be assessed separately.
Turning Taxonomy into Evidence—and Watching the Fine Print
A risk taxonomy is only useful if it produces actionable evidence before a workload goes live. To bridge that gap, the Microsoft and NVIDIA paper maps a selection of risks across its five categories to specific evaluations, helping teams identify tests that generate concrete evidence for the threats that actually matter to their use case. Alongside the paper, the two companies are launching a joint repository to share evaluation resources, link to existing tools, and accept contributions from the wider security and developer community.
In its announcement, Microsoft points to Microsoft Foundry as one vehicle for executing this workflow, noting that the platform offers built-in and custom evaluations for quality, groundedness, and safety, alongside automated red teaming and configurable content-safety controls designed to catch harmful inputs, outputs, and prompt attacks.
However, enterprise architects should approach platform tooling with a healthy dose of verification:
- Treat vendor tooling claims as capabilities to test, not guarantees: While platform evaluations and content filters are helpful building blocks, they do not replace application-specific testing, continuous runtime monitoring, and human oversight.
- Verify feature and preview availability: Microsoft explicitly cautions teams to check whether specific safety controls and evaluations are actually supported for their chosen model and deployment architecture, including whether a feature is still in preview status.
- Match the control to the right architectural layer: Depending on the threat, the right fix might involve modifying the model, tightening identity and access controls, deploying input and output filtering, or requiring human sign-off.
- Reassess whenever the system changes: Fine-tuning weights, swapping quantization formats, or connecting an existing model to a new enterprise data source changes the risk profile and requires fresh evaluation.
What Comes Next for Enterprise AI Architects
Why are Microsoft and NVIDIA investing so heavily in open-weight governance right now? From an industry perspective, both companies sit at the center of the enterprise AI infrastructure boom—NVIDIA supplying the compute and software stack, and Microsoft operating the cloud, security, and developer platforms where both proprietary and open-weight models run. Helping enterprises deploy open-weight models without stumbling into preventable security failures directly supports broader adoption across their ecosystems.
Still, the guidance is candid about its own boundaries. Risk Management for Open-Weight Models in Enterprise is deliberately scoped to the model layer first. Microsoft and NVIDIA state that future installments in the series will expand upward into the runtime, harness, and application layers, where agent permissions, external tool execution, and orchestration logic live.
For Windows enterprise administrators, cloud architects, and security teams building AI workflows today, the takeaway is clear: stop treating "open-weight" as either a disqualifying security hazard or a free pass on governance. Start with the specific business workflow, map the failure modes across the five risk domains, back up your assumptions with documented evaluation evidence, and make sure every safeguard has a named human owner before the model ever sees production traffic.