Model risk classification is the process of assigning an AI system a risk level based on factors such as toxicity, bias, hallucination potential, malicious use, and regulatory exposure. It helps organisations decide whether to sanction, restrict, or block a model. This step turns abstract AI risk into actionable policy decisions.
Expanded Definition
Model risk classification is a governance step that places an AI system into a defined risk tier so security, legal, and product teams can apply proportionate controls. It is broader than simple model testing because it considers likely harm, intended use, data sensitivity, user impact, and exposure to misuse. In practice, the classification determines whether a model can be approved for general use, limited use, or must be blocked pending further review.
For NHI Management Group, the key distinction is that model risk classification is not a property of the model alone. It also reflects the operating context, including whether the model can access sensitive data, produce regulated decisions, or be exposed to adversarial prompts. That makes the classification process dynamic rather than one-time. The idea aligns with governance approaches in the NIST Cybersecurity Framework 2.0, where risk treatment is tied to business context and control selection. Definitions vary across vendors on which factors should dominate, but the common thread is that classification should drive policy, not merely documentation.
The most common misapplication is treating model risk classification as a procurement checkbox, which occurs when teams label a model after deployment instead of before access, data, or release decisions are made.
Examples and Use Cases
Implementing model risk classification rigorously often introduces review overhead, requiring organisations to weigh faster model adoption against stronger governance and release control.
- A customer support chatbot is classified as low to moderate risk because it has limited data access and no authority to make binding decisions, but its responses still require monitoring for hallucination and harmful advice.
- An internal coding assistant may be classified higher if it can access proprietary repositories, because prompt leakage, insecure code suggestions, and secrets exposure create operational risk.
- A hiring model is usually placed in a restricted or high-risk category when it influences employment outcomes, since bias, explainability, and regulatory exposure become central concerns.
- A finance-facing agent that drafts account actions may be blocked until controls are verified, especially if it can trigger downstream workflows or amplify malicious use.
- A foundation model integrated into multiple business units may receive different classifications depending on the data, permissions, and decision authority assigned in each deployment.
Risk tiers should be backed by control requirements, not just labels. That is why teams often pair classification with security baselines from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially when the model participates in systems handling sensitive data or regulated workflows.
Why It Matters for Security Teams
Model risk classification helps security teams decide how much oversight a model needs before it is allowed to interact with users, data, or autonomous workflows. Without it, organisations tend to apply the same controls to every model, which creates two problems: low-risk tools are slowed unnecessarily, and high-risk tools are released without sufficient scrutiny. The result is weak governance, inconsistent approvals, and unclear accountability when incidents occur.
This matters especially where AI systems intersect with identity, privileged access, or agentic execution. A model that can query internal systems, recommend access changes, or trigger actions on behalf of a user may create NHI and PAM implications even if it is not itself an identity system. Security teams need the classification to determine whether the model should be isolated, monitored, or prevented from reaching sensitive toolchains. The governance question is not only what the model can say, but what it can cause.
Organisations typically encounter the consequences only after a model produces unsafe output, exposes sensitive information, or is implicated in a policy breach, at which point model risk classification becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF frames governing, mapping, measuring, and managing AI risk. | |
| NIST AI 600-1 | The GenAI profile addresses risk management for generative AI systems. | |
| NIST CSF 2.0 | GV.RM-01 | CSF 2.0 ties risk management decisions to business context and governance. |
| NIST SP 800-53 Rev 5 | RA-3 | Risk assessment controls support evaluating model threats and impacts before authorisation. |
| OWASP Agentic AI Top 10 | Agentic AI guidance highlights risks from tool use, autonomy, and unsafe output. |
Use AI RMF to define risk criteria, assign ownership, and track model risk treatment through review.
