Purpose of the Template
This template helps your team structure a model inventory to capture AI-specific risks that traditional frameworks often miss. It's tailored for teams moving from SR 11-7-style model tracking to governance that includes foundation models, retrieval-augmented generation systems, and multi-component AI applications.
Use this template to:
- Document AI systems that don't fit the "single statistical model" pattern
- Track vendor dependencies, API integrations, and foundation model versions
- Identify automation bias risk and contextual risk factors your current inventory overlooks
- Prepare for ISO/IEC 42001 audits or EU AI Act compliance reviews
Prerequisites
Before customizing this template, ensure you have:
Access to current system metadata: Gather Model Cards, System Cards, deployment manifests, API documentation, and vendor contracts for any outsourced models or foundation model providers.
Clear ownership assignments: Each AI system needs a designated owner who can answer questions about training data provenance, model limitations, use restrictions, and post-market monitoring frequency.
A risk tiering methodology: Whether you're using NIST AI RMF Profiles, EU AI Act Risk Tiering, or internal risk scoring, consistent criteria are essential. Document your tiering logic before populating risk tier columns.
Baseline validation evidence: For any system already in production, have validation evidence showing performance on holdout data, bias mitigation steps taken, and documentation of known model limitations.
The Template
AI System Inventory
Organization: [Your org name]
Last updated: [Date]
Owner: [Governance lead]
System ID | System Name | System Type | [Foundation Model Provider](/glossary/foundation-model-provider) | Deployment Status | Risk Tier | Primary Use Case | Data Subjects | Validation Status | Post-Market Monitoring Frequency | Known Limitations | [Vendor Due Diligence](/glossary/vendor-due-diligence) Status
----------|-------------|-------------|---------------------------|-------------------|-----------|------------------|---------------|-------------------|----------------------------------|-------------------|---------------------------
[Auto-increment] | [Descriptive name] | [Classification, Generation, RAG, Agent, Multimodal] | [None / Provider name / Multiple] | [Development / Staging / Production / Decommissioned] | [Low / Medium / High / Prohibited] | [Brief description] | [None / Internal / External / Vulnerable populations] | [Not started / In progress / Complete / Expired] | [Continuous / Monthly / Quarterly / Event-triggered] | [Free text or link to limitations doc] | [Not required / Pending / Complete]
Example row:
SYS-047 | Contract Review Assistant | RAG | Anthropic (Claude 3.5) | Production | Medium | Flags non-standard clauses in vendor contracts for legal review | Internal (legal team only) | Complete (valid through 2025-Q2) | Monthly + event-triggered on model version change | Cannot interpret handwritten annotations; English-language only; requires human approval for all flagged items | Complete (2024-11-15)
Column Definitions:
System Type: Use this to distinguish architectures. "Classification" covers traditional supervised learning. "RAG" means retrieval-augmented generation with an external knowledge base. "Agent" indicates autonomous decision-making or tool use. This drives your validation approach.
Foundation Model Provider: If you're calling an API from a foundation model provider, name them. If you're fine-tuning or using multiple providers in a cascade, note "Multiple" and document the chain in your System Card.
Risk Tier: Map to your organization's methodology. If you're subject to the EU AI Act, mark any system meeting Annex III criteria as "High." If you're using NIST AI RMF, align with your AI RMF Profile.
Validation Status: Track expiration dates. Under SR 11-7, annual validation is standard for material models. For AI systems with continuous learning or frequent foundation model version updates, you may need event-triggered revalidation.
Post-Market Monitoring Frequency: Distinguish between scheduled reviews and event-triggered monitoring. If your foundation model provider releases a new version, that's an event trigger. If your system shows performance degradation on a dashboard, that's an event trigger.
Known Limitations: Reference your model limitations and use restrictions documentation. Don't leave this blank. If you don't know the limitations, your validation isn't complete.
Customizing the Template
For financial services teams under SR 11-7: Add columns for "Quantitative Impact" (dollar exposure or decision volume), "Model Developer," and "Independent Validation Lead." Map your existing model tier definitions to the Risk Tier column.
For EU AI Act compliance: Add "Prohibited AI Practices Check" (Yes/No), "High-Risk Annex III Category" (if applicable), and "Conformity Assessment Status." If you have General-Purpose AI Models with Systemic Risk, flag them explicitly and link to your General-Purpose AI Code of Practice compliance documentation.
For ISO/IEC 42001 certification: Add references to your Annex A Controls. Map each system to controls 6.2.2 (AI system inventory), 6.2.6 (data for AI systems), and 6.3.4 (monitoring). Your auditor will check that this inventory ties to your Plan-Do-Check-Act documentation.
For teams managing vendor model risk: Expand the Vendor Due Diligence column into multiple fields: "Vendor Risk Assessment Date," "SLA Terms," "Data Processing Agreement Status," "Vendor Security Certification," and "Exit/Transition Plan Status." Track foundation model provider API rate limiting and failover configurations.
For teams tracking automation bias: Add a "Human-in-the-Loop Requirement" column (None / Advisory / Approval / Full human decision). Document where you've designed controls to prevent Automation Bias outputs.
Validation Steps
Cross-check against deployment infrastructure: Your DevOps team should generate a list of every model endpoint, API integration, and inference service currently running. Compare that list to this inventory. Any system in production that's not in your inventory is an unmanaged risk.
Verify ownership assignments: Email each system owner and ask them to confirm the risk tier, validation status, and known limitations for their systems. If they can't answer, you've found a gap in your AI governance structure.
Audit foundation model provider dependencies: If a single foundation model provider appears in more than 30% of your inventory rows, you have concentration risk. Document your contingency plan for API outages, price changes, or model deprecation.
Test your event triggers: Pick one system with "event-triggered" monitoring. Simulate a foundation model version change or a performance threshold breach. Can your team execute the revalidation workflow you've documented? If not, your monitoring frequency is aspirational, not operational.
Map to your AI Management System documentation: If you're pursuing ISO/IEC 42001 certification, this inventory should reference your AI lifecycle processes (ISO/IEC 5338), your impact assessment records (ISO/IEC 42005), and your risk treatment plans (ISO/IEC 23894). An auditor will trace a sample of systems from this inventory through your full governance documentation.
Every quarter, export this inventory and compare it to the prior version. If your system count is growing but your validation completion rate is falling, you're accumulating technical debt. If your "Foundation Model Provider" column shows increasing concentration, you're accumulating vendor risk. The inventory doesn't manage risk by itself, it surfaces the risks your governance processes need to address.
