A global asset manager is building an enterprise AI model inventory to comply with SR 11-7 and emerging EU AI Act obligations. Their Chief Risk Officer asks what the MINIMUM set of metadata fields should be captured for each model entry. Which combination best satisfies both regulatory frameworks?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A model inventory is like the manifest on a cargo ship — if the manifest only says 'box from Bob,' nobody knows what's inside or whether it's dangerous. SR 11-7 wants you to know what a model does, who validated it, and when. The EU AI Act layers on top with risk tiers and regulatory classification. Option B hits all the bases both regulators actually care about.
Full explanation below image
Full Explanation
SR 11-7 requires banking institutions to maintain a comprehensive inventory of models used in material business decisions. The guidance does not prescribe an exact schema, but supervisory expectations and examination manuals make clear that inventories must capture: the model's purpose and business context, the model owner and developer, key inputs and outputs, the validation status and date of last independent review, and any limitations identified during validation.
The EU AI Act (Regulation 2024/1689) adds a second dimension: AI systems used in financial services must be classified by risk tier (Unacceptable, High, Limited, Minimal). High-risk AI systems—which include credit scoring, insurance underwriting, and employment screening—require extensive documentation including data governance records, accuracy metrics, and human oversight mechanisms.
Option B is correct because it captures the fields needed to satisfy both frameworks: business use case and data inputs/outputs (SR 11-7 functional requirements), last validation date (SR 11-7 ongoing monitoring), vendor identification (SR 11-7 third-party risk), and risk tier plus regulatory classification (EU AI Act).
Option A is inadequate—developer name and deployment date alone leave regulators unable to assess whether a model has been reviewed, what it does, or how it is governed.
Option C captures infrastructure and cost information, which may be useful for IT asset management but is not what model risk regulators require in a model inventory.
Option D describes metrics useful for ML practitioners but ignores governance fields entirely. Training-set accuracy is not a validation substitute, and a GitHub link does not satisfy documentation requirements under either framework.
Best practice is to integrate the model inventory with the institution's risk management system so that high-risk models automatically trigger validation workflows and re-review schedules.