According to a February 2026 Gartner press release, organisations deploying AI governance platforms are 3.4 times more likely to achieve high effectiveness in AI governance than those that do not yet fewer than 1% of organisations have fully operationalised responsible AI, according to the World Economic Forum and Accenture. At the centre of that gap is a single, solvable problem: most organisations cannot tell an auditor, with confidence, exactly which AI systems they are running, who owns them, or what risks they carry.
An AI model inventory is the document that closes that gap. When structured correctly, it serves as the evidence backbone for ISO/IEC 42001 conformity assessments, NIST AI RMF Map function deliverables, and EU AI Act Article 9 risk management obligations. This guide provides a practitioner-grade template and the context to fill it out correctly so that your next audit conversation starts with answers, not scrambling.
Why Most AI Inventories Fail Audits
The audit failure rate for AI model inventories is not a documentation problem. It is a structural one. Organisations build spreadsheets that capture what a system is called, who built it, and maybe a brief description then present that at audit and discover the auditor wants something entirely different.
Auditors reviewing AI governance evidence under ISO/IEC 42001 Clause 6.1.2 and Clause 8.1 are looking for four things: completeness (does this list include all AI systems, including third-party and embedded ones?), traceability (can you follow a risk finding back to a control decision, and that decision back to a specific system entry?), currency (does the inventory reflect the current deployment state, not what was deployed at the last review cycle?), and scope clarity (does each entry define the system’s purpose, intended use, and organisational boundaries?).
Spreadsheets fail on completeness and currency almost universally. According to a 2025 PwC Global Compliance Survey, 85% of respondents reported that compliance requirements had become more complex in the last three years, yet most AI governance still relies on manual documentation that auditors treat as unreliable. The core issue: a spreadsheet has no mechanism to alert a governance team when a data scientist deploys a new model in production, or when a SaaS vendor quietly updates the AI embedded in a procurement tool. By the time the next quarterly review runs, the inventory is already out of date.
Shadow AI compounds this. A 2025 Gartner forecast projects that by 2030, more than 40% of enterprises will experience a security or compliance incident linked to ungoverned shadow AI. That means the systems most likely to cause audit findings are the ones least likely to appear in a spreadsheet-based inventory.
The template structure in the following sections is designed to resolve these failure modes — not by adding more columns, but by building the right columns in the right hierarchy.
The Core Template: What Every AI Model Entry Must Include
An AI model inventory entry is not a system description. It is a risk-traceable governance record. Every field exists because an auditor, a regulator, or a risk committee will eventually ask for exactly that piece of information, and the answer needs to be specific, dated, and owned.
The template below reflects the field requirements across three frameworks simultaneously: ISO/IEC 42001 Clause 8.1 operational planning, NIST AI RMF Map function documentation, and EU AI Act Annex IV technical documentation requirements for high-risk systems.
Section 1 – System Identification
| Field | Description | Example |
| System ID | Unique, versioned identifier | AI-2025-017-v2 |
| System Name | Descriptive name (not internal codename) | Customer Credit Scoring Model |
| System Version | Current production version | v2.3.1 |
| Deployment Date | Date current version went live | 2025-03-14 |
| Last Updated | Date of last inventory record update | 2026-01-08 |
| System Owner | Named individual with accountability | Head of Credit Risk, J. Martinez |
| Technical Owner | Named developer or engineering lead | ML Engineering Lead, R. Patel |
| Business Domain | Functional area this system operates in | Retail Lending, Credit Decisioning |
Section 2 – System Classification
This is where most templates are underdeveloped. Classification drives every downstream control decision the risk assessment process, the monitoring cadence, the human oversight requirements, and the regulatory obligations that apply.
| Field | Description | Notes |
| AI System Type | Model category | Predictive, Generative, Recommendation, NLP, Computer Vision |
| Deployment Context | Where the model operates | Internal tool / Customer-facing / Automated decision-making |
| ISO 42001 Scope | Role classification | Developer / Deployer / User |
| EU AI Act Risk Tier | Annex III classification if applicable | Prohibited / High-Risk / Limited-Risk / Minimal-Risk |
| NIST AI RMF Category | Impact classification | High-impact / Moderate / Low |
| Data Sensitivity | Highest sensitivity class in training data | Personal Data / Sensitive Personal Data / Proprietary / Public |
| Autonomous Decision Flag | Does this system make consequential decisions without human review? | Yes / No / Partial |
The EU AI Act risk tier field is particularly important for US organisations with EU market exposure. Annex III of the Act lists the high-risk categories including AI used in employment decisions, credit scoring, and law enforcement and each carries specific documentation and human oversight obligations.
Section 3 – Risk Profile
| Field | Description | Notes |
| Risk Assessment Reference | Pointer to the formal risk assessment document | RA-2025-017 |
| Risk Assessment Date | When the current assessment was completed | 2025-09-30 |
| Residual Risk Rating | Post-control risk level | High / Medium / Low |
| Open Risk Items | Count of unmitigated risk findings | 2 open (as of 2026-01-08) |
| Next Review Trigger | Condition or date that requires reassessment | Major model update, data drift alert, or 12-month interval |
| Incident History | Count of logged incidents for this system | 1 (2025-07-12, resolved) |
Section 4 – Technical Documentation Pointers
The inventory is an index, not an archive. Each entry should point to the substantive technical documentation, not attempt to replicate it.
| Field | Description |
| Model Card Reference | Link or document ID for the model card |
| Training Data Provenance | Document or data lineage record reference |
| Algorithm Description Reference | Technical specification document ID |
| Validation Report Reference | Most recent validation report ID |
| Monitoring Dashboard Link | URL or path to active monitoring logs |
| Audit Evidence Package | Location of the compiled evidence set for this system |
This pointer structure is how the inventory becomes the navigation layer for your audit evidence management — rather than a standalone document that auditors must take on trust.
Mapping Inventory Fields to ISO 42001 Controls
ISO/IEC 42001:2023 does not mandate a specific inventory format. What it requires, across several clauses, amounts to a de facto inventory specification and understanding those requirements prevents the most common certification failure: building an inventory that satisfies common sense but not the standard.
Clause 4.3 requires organisations to document the scope of the AI Management System, including the AI systems in use, relevant organisational boundaries, and the context in which those systems operate. This is the foundational justification for the system identification and classification fields in the template above. An inventory that does not establish scope is not an ISO 42001-compliant inventory.
Clause 6.1.2 requires a documented AI risk assessment process one that identifies the risks associated with each AI system, evaluates their likelihood and impact, and links findings to treatment decisions. The risk profile section of the template creates the traceability between each system record and its risk assessment. Without that explicit pointer, auditors cannot verify that a risk assessment was conducted for a specific system rather than for AI generally.
Clause 8.1 requires operational planning and control over AI system processes which includes maintaining documentation sufficient to demonstrate that controls are implemented and operating effectively. This is where the technical documentation pointers become mandatory, not optional. An auditor will not accept “we have a model card” as evidence; they will ask to see it.
A 2025 implementation guide from ISMS.online describes the AI asset inventory as including a detailed list of AI models, training datasets, real-time AI data feeds, inference engines, and deployment environments a scope that extends well beyond what most organisations first document. That scope is not pedantic; it is the reason why organisations that attempt to certify with an incomplete inventory typically receive a major non-conformity in their stage-one assessment.
Annex A of ISO 42001 provides 42 control objectives across eight domains. The inventory structure above aligns most directly with controls in the data management (A.6), system development (A.7), and operational controls (A.8) domains. Building the inventory to address these domains from the start means your first evidence review produces a document that can be cross-walked against the Annex A controls without additional work.
The practical implication: treat the inventory not as a standalone register but as the first document in a chain. Each entry points to a risk assessment, which points to a treatment plan, which points to control evidence. That chain is what ISO 42001 conformity looks like on paper.
NIST AI RMF Map Function: Inventory as the Foundation
The NIST AI RMF organises AI risk management across four functions: Govern, Map, Measure, and Manage. The AI model inventory is the primary deliverable of the Map function without it, neither Measure nor Manage can operate on a complete picture of the AI ecosystem.
Map Function documentation requirements for inventory are explicit in the NIST AI RMF Playbook. MAP 1.1 requires organisations to establish and maintain a current inventory of AI systems, including their purpose, ownership, and risk context. MAP 1.6 extends this to third-party AI components models embedded in vendor software, APIs consumed by internal systems, and foundation models used as base layers for fine-tuned applications.
This third-party requirement catches most organisations unprepared. The AI systems with the largest footprint in a typical enterprise are not the ones built in-house; they are the AI embedded in the ERP, the CRM, the HR platform, and the procurement tool. A NIST AI RMF-aligned inventory must account for these, even where the organisation’s direct control over the model is limited to configuration rather than architecture.
The NIST AI 600-1 Generative AI Profile, released by NIST in July 2024, extends these requirements to LLMs and foundation models. For organisations deploying or consuming generative AI including coding assistants, customer service bots, and document processing tools the inventory must capture the additional risk categories defined in AI 600-1: confabulation risk, prompt injection exposure, data privacy handling, and model provenance.
Practically, this means every generative AI system in the inventory needs two additional fields: a foundation model identifier (which model or API is it built on?) and a GenAI risk flag (has a GenAI-specific risk assessment been completed against the AI 600-1 categories?).
The Map function also aligns closely with the “Autonomous Decision Flag” in the template’s classification section. NIST MAP 5.1 requires characterising the impacts on individuals and groups from AI system decisions. Any system flagged as making autonomous consequential decisions needs an expanded impact assessment entry not just a risk rating, but a documented analysis of who is affected and how.
NIST’s AI RMF Playbook is available as a free download and provides the detailed sub-practice guidance that maps these requirements to specific documentation actions. Cross-referencing the inventory template against the MAP function sub-practices before finalising your field set is the most reliable way to ensure NIST alignment without over-engineering the document.
Shadow AI Discovery: Populating the Inventory Before the Auditor Does
An inventory with 12 entries for an organisation running 200 AI systems is not a governance document. It is a liability. The most important challenge in building an AI model inventory is not structuring the template it is finding everything that belongs in it.
Shadow AI is the primary gap. Research from Gartner’s 2025 forecast identifies ungoverned AI deployments as the leading cause of future AI compliance incidents. The mechanisms for this are straightforward: a product manager adds a Copilot feature to a business tool, a developer integrates an LLM API into an internal workflow, a vendor updates their SaaS product to include AI-driven recommendations. None of these require a formal procurement process that would trigger governance review.
Discovery needs to run on multiple channels simultaneously:
1. Infrastructure scanning API call logs, cloud usage dashboards, and network traffic analysis can identify calls to known AI endpoints OpenAI, Anthropic, Cohere, AWS Bedrock, Azure OpenAI Service. This catches direct API consumption and embedded model calls from developer-built tools.
2. Procurement and vendor review Audit every active SaaS contract for AI disclosure. Most vendors updated their product documentation in 2024-2025 to describe AI features; these descriptions are the starting point for identifying embedded AI systems. The contracts themselves often contain data processing terms relevant to AI that require governance treatment.
3. Departmental self-disclosure A structured disclosure process sometimes with an amnesty mechanism for previously undisclosed systems surfaces the AI usage that department teams are aware of but have not reported. The NIST AI RMF Playbook recommends establishing amnesty periods specifically to encourage honest disclosure without triggering disciplinary consequences.
4. Change management integration The most durable shadow AI prevention mechanism is making AI disclosure mandatory in the change management and procurement workflows. When the question “does this involve AI?” appears in every software procurement request and every change request, the inventory becomes self-maintaining rather than requiring periodic rediscovery campaigns.
The practical cadence for a mid-market organisation: conduct a full discovery sweep when standing up the inventory for the first time, then rely on procurement integration and quarterly verification sweeps to maintain currency. The quarterly sweep is the minimum ISO 42001 Clause 8.1 expects periodic review of AI usage across the organisation to catch ungoverned deployments.
One thing that consistently separates organisations that pass their first AI governance audit from those that receive major non-conformities: the former treat discovery as an ongoing operational process, not a one-time project.
Audit Evidence: Turning Inventory Records into Demonstrable Controls
An auditor reviewing an AI governance programme does not read the inventory in isolation. They use it as a map to the evidence. Every entry should serve as a trailhead leading directly to the documents, logs, and records that demonstrate the control is real and operating.
The evidence package for a single AI system in a well-governed organisation typically includes:
- The inventory record itself (dated, versioned, owned)
- The risk assessment document (methodology, findings, treatment decisions)
- Model card or equivalent technical documentation (capabilities, limitations, training data summary, evaluation results)
- Validation and testing records (pre-deployment testing, bias evaluation, performance benchmarks)
- Approval record (who authorised deployment, under what conditions, on what date)
- Monitoring logs (performance metrics, drift detection alerts, incident reports)
- Review and revalidation records (any reassessments triggered by updates or incidents)
For organisations pursuing ISO 42001 certification, this chain is exactly what a stage-two auditor will sample. They will take a selection of inventory entries and request the evidence package for each. Gaps in any link a missing approval record, a risk assessment that predates a major model update, monitoring logs that stop 60 days before the audit generate findings.
The PwC 2025 Compliance Survey finding that most AI governance documentation is treated as unreliable by auditors stems from this specific problem: organisations produce documentation at point-in-time for audit preparation, rather than maintaining it continuously as operational evidence. An auditor can usually distinguish between a monitoring log that has been running for 18 months and one that was configured two weeks before the audit.
For EU AI Act high-risk systems specifically, Article 9 requires that risk management documentation be maintained throughout the system’s lifecycle, with updates triggered by significant changes or operational findings. This lifecycle requirement is not satisfied by an annual review cycle. It requires the inventory record to function as a living document with an attached event log recording when the system changed, what was reassessed, and what the outcome was.
Govern365.ai’s audit evidence management module links each model registry entry to its evidence chain, with version history and change event logging built into the record structure. For organisations managing more than a handful of AI systems, the operational overhead of maintaining that linkage manually is the point at which a purpose-built platform becomes a practical necessity rather than a luxury.
Third-Party and Vendor AI: The Inventory Blind Spot
Most AI model inventories are built around first-party systems the models an organisation’s data science or ML engineering team built and deployed. Third-party AI sits in a different accountability position, but it belongs in the same inventory with the same governance rigour.
ISO/IEC 42001 Clause 4.2 requires organisations to identify interested parties and their requirements which includes AI vendors and the obligations that flow from their products and APIs. Annex A control A.9.4 specifically addresses supplier relationships: organisations must assess and manage the risks from AI systems and components obtained from third parties. An inventory that excludes vendor AI is not ISO 42001 compliant.
NIST AI RMF MAP 1.6 is equally direct: the Map function includes third-party software and data components. The practical implication is that every AI API your organisation calls, every embedded AI feature in your SaaS stack, and every pre-trained model or foundation model your teams build on top of must appear in the inventory.
The entry structure for third-party AI differs slightly from first-party entries. Key additional fields:
| Field | Third-Party Specific Content |
| Vendor Name | Legal entity providing the AI component |
| Contractual AI Terms Reference | SLA/DPA clause governing AI use |
| Data Processing Agreement Status | In place / Required / Not applicable |
| Vendor Compliance Evidence | Vendor certifications (SOC 2, ISO 27001, ISO 42001) |
| Exit / Substitution Plan | Documented approach if vendor access is terminated |
| Foundation Model Identifier | For GenAI tools: which underlying model is in use (e.g., GPT-4o, Claude, Llama 3) |
The exit plan field sounds excessive until a vendor discontinues a service mid-production deployment. For high-risk or business-critical AI systems using third-party models, the ability to explain to a regulator or auditor how the organisation would transition to an alternative without operational disruption is part of the risk management case.
Elevate Consult’s guidance on EU AI Act implementation notes that organisations must inventory foundation models and flag which qualify as General Purpose AI (GPAI) under the Act. For US organisations with EU customers, this determination affects the supply chain obligations that apply not just what documentation the vendor must provide, but what governance obligations transfer to the deploying organisation.
The practical discovery approach for third-party inventory: start with the vendor list from procurement, filter for any vendor whose product description mentions AI, automation, machine learning, or predictive analytics, then map each to the relevant inventory entry fields. For SaaS tools with embedded AI, vendor documentation pages and data processing agreements are the primary sources.
Maintaining the Inventory: Governance Without the Overhead
Building the inventory is a project. Maintaining it is a process. The difference matters because the single most common cause of audit failure for AI inventories is not incomplete initial build it is inventory decay: entries that were accurate at creation but have not been updated as systems evolved.
Inventory maintenance requires three operational mechanisms:
1. Change-triggered updates Every material change to a production AI system should trigger an inventory update — at minimum, a version flag and a date stamp. “Material change” needs a defined threshold in your governance policy: typically, changes to training data, model architecture, deployment scope, or intended use. Minor performance updates to a stable model may not require a full record update; replacing the underlying model or extending it to a new use case certainly does.
2. Periodic verification sweeps Even with change-triggered updates, a quarterly or semi-annual verification sweep confirms that the inventory reflects actual deployment state. The sweep process involves reviewing each entry against the production environment checking that the system is still active, that the owner assignment is current, and that no undisclosed changes occurred outside the change management process.
3. Decommissioning protocol AI systems are retired, but their records should not be deleted they should be archived with a decommission date and a record of any residual obligations (data retention requirements, regulatory notification obligations, ongoing monitoring for downstream effects). An auditor reviewing a governance programme across a three-year period may ask about systems that are no longer in production; the records need to exist.
The governance overhead of this process scales with the number of systems in the inventory. For organisations managing fewer than 20 AI systems, manual maintenance with structured templates and calendar-based review cadences is workable. Above 50 systems, the operational burden of manual maintenance typically exceeds the capacity of the governance team, and the error rate makes the inventory unreliable.
This is the point where organisations consistently report that a dedicated AI model registry one that integrates with deployment pipelines and generates alerts on change events delivers a return that justifies the investment. The Gartner figure on AI governance platform effectiveness is partly explained by this: platforms that automate inventory maintenance produce inventories that are actually current, which means the governance programme they underpin is built on a reliable foundation rather than a periodically updated approximation.
Frequently Asked Questions
What is an AI model inventory?
An AI model inventory is a structured register of every AI system an organisation operates, develops, or procures. Each entry documents the system’s identity, ownership, risk classification, technical documentation references, and current operational status. It serves as the governance foundation for risk assessments, compliance audits, and regulatory evidence under frameworks including ISO/IEC 42001, NIST AI RMF, and the EU AI Act.
Is an AI model inventory required for ISO 42001 certification?
ISO/IEC 42001 does not use the phrase ‘AI model inventory’ explicitly, but its requirements across Clauses 4.3, 6.1.2, and 8.1 collectively require organisations to document the scope of their AI systems, maintain records of risk assessments linked to specific systems, and demonstrate operational control all of which require an inventory as the foundational document. Attempting to certify without one consistently results in major non-conformities at stage-one assessment.
How do I handle AI embedded in third-party SaaS tools?
Third-party AI systems belong in the inventory with the same rigour as first-party models, per ISO 42001 Annex A control A.9.4 and NIST AI RMF MAP 1.6. Start with your vendor list and filter for any product that describes AI, machine learning, or predictive analytics features. Key additional fields for vendor entries include the data processing agreement status, vendor compliance certifications, the specific AI functionality in scope, and for generative AI tools the underlying foundation model identifier.
How often should the AI model inventory be updated?
At minimum, inventories should be updated whenever a material change occurs to a production system changes to training data, model architecture, deployment scope, or intended use all qualify. A periodic verification sweep, quarterly for higher-risk environments, confirms the inventory reflects actual deployment state. ISO 42001 Clause 8.1 expects periodic surveys of AI usage across the organisation to catch ungoverned deployments. Static annual reviews are not sufficient.
What does ‘shadow AI’ mean in the context of an AI inventory?
Shadow AI refers to AI systems deployed or used within an organisation without going through a formal governance or procurement process typically models embedded in departmental tools, informal LLM API usage by developers, or AI features enabled within SaaS products without IT review. Gartner projects that by 2030, more than 40% of enterprises will experience a compliance incident linked to ungoverned shadow AI. Discovery mechanisms including infrastructure scanning, vendor contract review, and change management integration are required to surface these systems.
What is the difference between an AI model inventory and a model card?
An AI model inventory is an organisational governance register it tracks what systems exist, who owns them, their risk classification, and their compliance status. A model card is a technical documentation artefact for a specific model it describes the model’s architecture, training data, intended use cases, performance characteristics, and known limitations. The inventory entry for a system should point to its associated model card as a key piece of evidence, but the two documents serve different purposes.
Do US companies without EU operations need to worry about EU AI Act documentation requirements?
US companies that develop AI systems used by EU-based customers, or that process EU personal data, fall within the EU AI Act’s extraterritorial scope. Article 2 applies the Act to providers placing AI systems on the EU market regardless of where they are established. For high-risk AI systems under Annex III, this triggers Annex IV technical documentation requirements which overlap substantially with what a well-structured AI model inventory already captures.
Conclusion
An AI model inventory is not a compliance checkbox. It is the operating infrastructure for every downstream governance activity risk assessment, audit evidence management, regulatory disclosure, and board-level AI oversight reporting all depend on it being accurate and current.
Build the inventory to the standards described here, link every entry to its evidence chain, and maintain it through change management integration rather than periodic manual updates. That combination produces a governance programme that holds up under scrutiny and a first audit conversation that starts with confidence.
Start your 14-day free trial of Govern365.ai and explore how the AI model registry maps each system entry directly to its ISO 42001 controls and compliance evidence.
