What Is a Model Risk Register? Structure and Examples

Definition and Purpose

A model risk register is a governance artifact that catalogs models and, increasingly, AI agents, and links each entry to the information needed to manage the risk it presents. Under supervisory guidance such as SR 11-7 and OCC Bulletin 2011-12, model risk is defined as the potential for adverse consequences from decisions based on incorrect or misused model outputs. A register operationalizes that definition by creating a single, auditable record that risk teams and examiners can use to answer a basic question: what models exist, who owns them, how risky are they, and are they currently validated. Without a register, organizations typically rely on scattered spreadsheets or informal tracking, which makes it difficult to demonstrate consistent oversight when regulators or auditors ask for evidence of a functioning model risk management program.

Register vs. Model Inventory vs. Enterprise Risk Register

These three artifacts are often conflated but serve different purposes. A model inventory is primarily a list: it confirms a model exists and captures basic descriptive metadata. A model risk register builds on the inventory by adding risk-specific structure, including tiering logic, validation history, dependencies between models, and open mitigation items. It is best understood as a relational record set rather than a flat list, since a single model may link to multiple validation cycles, data sources, and downstream consumers. An enterprise risk register, by contrast, tracks operational, financial, and strategic risks broadly and generally lacks model-specific fields such as data lineage, retraining triggers, or validation cadence. Attempting to manage model risk inside a generic enterprise risk template usually results in fields that do not map cleanly to how models are actually developed, validated, and monitored.

Regulatory and Framework Context

SR 11-7, issued by the Federal Reserve in 2011, remains the primary reference point shaping model risk register structure for regulated financial institutions, and OCC Bulletin 2011-12 adopts substantively identical guidance for national banks and federal savings associations. Both call for a comprehensive model inventory and recommend tiering models by materiality, complexity, and the extent of institutional reliance on their outputs, but neither prescribes a specific field list or template, since both predate the AI systems many organizations now operate. More recent frameworks extend this thinking to AI broadly. NIST's AI Risk Management Framework, published in January 2023, organizes AI risk management into four functions: Govern, Map, Measure, and Manage, and NIST's Generative AI Profile, released in July 2024, adds risks specific to generative systems. ISO/IEC 23894:2023 provides parallel international guidance on AI risk identification and treatment across the system lifecycle. The EU AI Act introduces its own risk-based tiering, from unacceptable to minimal risk, with different compliance obligations at each level. Organizations operating in the EU may need to map internal tiering logic to these regulatory categories rather than relying solely on internal materiality criteria.

Extending Registers for AI Agents

Traditional registers assume a static, versioned artifact, such as a scored regression model, with fixed inputs and outputs and a validation status that reflects a point-in-time sign-off. AI agents behave differently: their outputs vary across sessions, their action space can include tool calls and API access, and their decision paths are not fixed at deployment time. SR 11-7 and OCC 2011-12 do not reference autonomous agents, tool-use permissions, or dynamic runtime decision paths, since both were written before such systems existed, and NIST's Generative AI Profile notes that generative and agentic systems introduce unpredictable outputs and an expanded action space compared to traditional statistical models. This creates a documented gap: existing supervisory guidance provides the tiering and inventory logic, but organizations must extend it themselves. In practice, this means adding fields for tool-call permissions, autonomous action scope, and delegation boundaries, and treating validation as an ongoing or event-triggered process tied to behavior drift rather than a single review date. Agent risk tiering also needs to account for action reversibility and permission scope, not just output reliance, since an agent with broad tool access carries different risk than one restricted to read-only queries even if their statistical performance is similar.

Design Principles for a Model Risk Register

• Define tiering criteria before populating the register so statistical, ML, generative, and agentic entries are classified consistently
• Separate validation status for static models from continuous or event-triggered validation for agentic systems
• Include tool-call permissions, action scope, and escalation or human-in-the-loop triggers as first-class fields for agents
• Map internal risk tiers to external regulatory categories, such as EU AI Act tiers, where applicable
• Assess integration with existing GRC or model inventory systems early, since agent-specific fields often require schema changes rather than simple additions
• Maintain an audit trail of tiering decisions, validation history, and remediation actions to support examiner or regulator review