Traditional MRM frameworks already consider materiality, purpose, use and potential impact. This experiment asks an additional question: should the concentration and connectivity of an AI component influence the intensity of governance around it?
Exploratory — not a regulatory scoreThis is an exploratory framework, not a regulatory methodology. The characteristics are intended to support judgement rather than produce a mechanically calibrated risk score.
A traditional model inventory tells a bank which governed models exist. A dependency map adds a view of how components combine to produce a business outcome and where important shared dependencies sit.
Consumes model, RAG, policy and bureau data; produces a recommendation used by an underwriter. Click any node to explore its ownership and governance implications.
The important point is not that dependencies are new. AI can make them more significant: shared foundation models, changing RAG content, third-party components and increasingly autonomous systems can allow changes in one component to affect several otherwise separately governed use cases.
A dependency map can make those relationships visible, but it is only a starting point.
Dependency materiality becomes useful only when it changes what the firm does: inventory, tiering, validation, monitoring, escalation or risk appetite.
A highly connected component could affect the perimeter and intensity of assurance even when the component itself has not become more technically complex. The questions below are research propositions, not current PRA requirements.
| MRM activity | Possible dependency-aware adaptation |
|---|---|
| Inventory | Record upstream/downstream dependencies and shared components, not only standalone model records. |
| Tiering | Supplement inherent model materiality with concentration and dependency information. |
| Validation | Use event-triggered reassessment when a material shared component, provider, RAG source or control changes. |
| Monitoring | Monitor system behaviour and critical dependencies alongside model performance. |
| Governance | Route issues to MRM, Data, Technology/Cyber, TPRM, Compliance or Operational Risk according to the affected dependency. |
| Risk appetite | Consider aggregate/concentration measures: e.g. exposure to a common provider, common data source or shared AI component. |
Potentially. The 2026 US guidance explicitly says sound practice includes assessing model risk both individually and in aggregate, including interactions, dependencies and common assumptions, data or methodologies. A dependency view suggests that appetite could therefore consider correlated exposure, not only individual-model exceptions.
There are three plausible ways to draw the boundary around AI. Each solves a different problem and creates a different failure mode.
| System type | Likely perimeter |
|---|---|
| Conventional ML model | Primarily existing MRM |
| GenAI assistant with external model + internal data | MRM plus defined Data / Technology / TPRM review |
| Highly connected agentic system | Cross-functional AI-system governance |
The governance perimeter should follow the risk architecture of the system, rather than being fixed once for all of “AI”.
Primary and industry sources that frame the current MRM perimeter and the emerging system-governance question.
These sources frame the debate: established MRM structure, current bank AI operating models, and the emerging argument for horizontal governance.
| Current anchor | Emerging anchor |
|---|---|
| Model owner | Decision-system owner + component owners |
| Model inventory | Dependency graph / system inventory |
| Fixed validation cycle | Risk-based + event-triggered assurance |
| Validation team as tester | Validation team as tester + assurance orchestrator |
| Model tier | Model tier + dependency / blast-radius materiality |
| MRM committee | Cross-risk AI / system governance with clear MRM decision rights |
Prototype hypothesis: preserve independent challenge, but shift governance from isolated model records toward connected decision systems.