According to the McKinsey State of AI 2025 report, 78% of organizations now use AI in at least one business function yet only 13% have hired dedicated AI compliance specialists to manage it. The gap between adoption and governance infrastructure has become a compliance liability, and it shows up most sharply in records management: organizations that cannot produce an accurate account of what AI systems they operate, what each one does, and how it was validated will fail their first serious audit.
Two terms sit at the center of that accountability challenge: the AI system registry and the model inventory. Both are foundational to ISO/IEC 42001 certification, EU AI Act compliance, and NIST AI RMF implementation. Both are widely misunderstood, frequently conflated, and routinely built in ways that satisfy neither auditors nor regulators.
This guide draws a precise distinction between them, defines what each record must contain, and maps the specific fields required by each major framework so compliance teams can build both correctly from the start.
Why These Two Records Are Not the Same Thing
The terminology confusion is understandable. Both records deal with AI assets. Both appear on governance checklists. Many platforms use the terms interchangeably, and even some regulatory guidance is imprecise. But the distinction is architecturally important, because the two records serve fundamentally different purposes.
A model inventory is an internal catalog. Its job is to capture every AI model the organization has built, acquired, or deployed along with the technical and operational metadata needed to understand what each model is and how it behaves. Think of it as the engineering record of your AI portfolio. It answers questions like: What training data was used? What version is currently in production? When was it last validated? Who owns it?
An AI system registry operates at a higher level of abstraction and carries a different accountability function. Where an inventory answers “what do we have,” a registry answers “what do we have, who is responsible, what governance applies, and how does it interact with affected stakeholders.” As documented by Agility at Scale, the registry is the governance layer that sits on top of the inventory and in many regulatory contexts, it is the registry that carries legal weight.
The distinction matters in practice because an organization can have a thorough model inventory and still fail a conformity assessment if the registry is missing the accountability fields auditors need. Conversely, a well-structured registry built without a supporting inventory will lack the technical evidence to substantiate its claims.
AI SYSTEM REGISTRY VS MODEL INVENTORY: CORE DISTINCTION
| Dimension | AI System Registry | Model Inventory |
|---|---|---|
| Primary purpose | Governance accountability and regulatory disclosure | Technical lifecycle management |
| Audience | Auditors, regulators, board, oversight body | ML engineers, compliance teams, risk owners |
| Level of abstraction | System-level (business function + risk tier) | Model-level (architecture + data + metrics) |
| Required by | ISO 42001, EU AI Act Art. 49, NIST Govern function | ISO 42001 Annex A, NIST Map function, model risk management |
| Trigger for update | New deployment, ownership change, regulatory re-classification | Model version change, retraining, drift threshold breach |
| Legal weight | Can be externally disclosed or submitted to authorities | Internal use; supports the registry but is not itself the submission |
What an AI System Registry Must Contain
The specific fields required in a compliant AI system registry are determined by the frameworks your organization operates under. For US-based organizations, NIST AI RMF’s Govern function establishes the governance documentation baseline. For those with EU-facing AI deployments, EU AI Act Article 49 and Annex VIII impose mandatory registration requirements for high-risk systems. ISO/IEC 42001:2023 layers on top with its AIMS documentation requirements under Clause 7.5 and Annex A.
These frameworks share significant overlap on core fields, but each adds requirements the others don’t. A registry built only for NIST will miss the EU AI Act’s transparency and conformity fields. A registry built only for ISO 42001 may lack the risk tier classification EU regulators expect.
The following fields are required or strongly expected by at least two of the three major frameworks:
- System identifier and name
- A unique ID for each AI system, consistent across all governance documentation and incident records.
- System purpose and use case
- Plain-language description of what the system does, in which business function, and for what population of users or decisions.
- Risk tier classification
- Under EU AI Act Annex III: prohibited, high-risk, limited-risk, or minimal-risk. Under NIST AI RMF: risk impact category (low/medium/high/critical).
- Owner and accountability
- Named individual responsible for governance not a team, a person. ISO 42001 Clause 5.3 requires explicit responsibility assignments.
- Deployment status and environment
- Current state: development, staging, production, or retired. Deployment environment: internal, customer-facing, or third-party API.
- Affected populations and stakeholders
- Who is subject to the system’s outputs employees, customers, regulated individuals and any third parties with oversight rights.
- Human oversight mechanism
- What human-in-the-loop controls exist, at what decision thresholds, and how overrides are documented.
- Applicable regulatory frameworks
- Every regulation, standard, and internal policy the system is governed by, with compliance status against each.
- Conformity assessment status
- For EU AI Act high-risk systems: whether a conformity assessment has been completed, by whom, and when it expires.
- Incident and nonconformity history
- Link to the incident log and any open corrective actions affecting this system.
EU enforcement note: The EU AI Act Article 49 requirement for high-risk systems to be registered in the EU database applicable to Annex III systems with full enforcement from August 2026 means this is no longer a matter of internal housekeeping. For US organizations deploying AI systems into EU markets, the registry must be structured to support external submission, which is a materially higher standard than a spreadsheet built for internal oversight.
What a Model Inventory Must Contain
If the registry is the governance record, the inventory is the technical evidence that supports it. Auditors reviewing an AI system registry will pull on the inventory to verify claims if a registry entry says the model was validated against bias metrics, the inventory should contain the validation results, the evaluation methodology, and the date they were conducted.
The model inventory exists at a finer level of granularity. A single AI system in the registry may be powered by multiple models, each with their own training history, versioning, and performance metrics. The inventory captures all of them.
OneTrust’s AI governance documentation draws the key distinction: “An AI model inventory focuses on internal documentation and lifecycle management, while an AI Registry is typically a public or regulatory-facing disclosure of high-risk AI systems.” That internal/external framing holds across frameworks.
Core fields for a compliant model inventory include:
- Model identifier and version
- Unique ID tied to the registry’s system identifier, plus version history with semantic versioning and rationale for each change.
- Architecture and model type
- Model family, algorithm type, framework used (TensorFlow, PyTorch, etc.), and any fine-tuning applied to a foundation model.
- Training data provenance
- Dataset name, version, source, date range, preprocessing steps applied, and data controller especially critical under GDPR.
- Training and evaluation dates
- When the model was trained, evaluated, and last validated. ISO 42001 Annex A.6 controls on AI system lifecycle require this to be current.
- Performance metrics
- Accuracy, precision, recall, F1, AUC, or task-relevant metrics plus fairness and bias evaluation results across relevant demographic slices.
- Known limitations and failure modes
- Documented out-of-scope use cases, known distributional limitations, and conditions under which the model degrades. The field most commonly missing from enterprise inventories.
- Deployment pipeline
- CI/CD pipeline reference, staging and production environments, rollback procedure, and monitoring hook configurations.
- Drift monitoring status
- Current performance against baseline metrics, drift detection methodology, and threshold at which retraining is triggered.
- Retirement and archival plan
- Planned end-of-life date, data retention policy for model artifacts and inference logs, and documented decommissioning procedure.
How ISO 42001, EU AI Act, and NIST AI RMF Divide the Record-Keeping Work
Understanding which framework requires which record and at what level of detail is the core challenge for US organizations managing multi-framework compliance. The good news is that the overlap is substantial. Building both records to the highest common standard satisfies most requirements across all three frameworks simultaneously.
FRAMEWORK RECORD-KEEPING REQUIREMENTS
| Framework | Registry Requirement | Inventory Requirement | Key Reference |
|---|---|---|---|
| ISO/IEC 42001:2023 | AI system inventory required under AIMS scope (Clause 4.3); system records under Clause 7.5 documented information | Annex A.6 (AI lifecycle); Annex A.4 (resources including data, models, tools) | Clause 7.5; Annex A.4, A.6 |
| EU AI Act | Mandatory registration for Annex III high-risk systems (Article 49); technical documentation before deployment (Article 11) | Annex IV technical documentation: 8 sections covering design, data, testing, monitoring | Art. 11; Art. 49; Annex IV; Annex VIII |
| NIST AI RMF | AI system catalog as part of Map 1.1 (Govern function governance documentation) | MAP 2.1 (scientific/technical basis); MAP 5.1 (residual risk); MEASURE 2.5 (bias evaluation) | Map 1.1; Map 2.1; Measure 2.5; Manage 2.2 |
The most significant documentation requirement sitting outside the registry/inventory split is the EU AI Act’s Annex IV technical documentation package. For high-risk systems, this is a structured eight-section document that blends registry-level governance information with inventory-level technical detail into a single compliance artifact. Organizations with both a well-maintained registry and a comprehensive inventory will find that most of the Annex IV content already exists the challenge is assembling it into the prescribed structure.
One important nuance for US-headquartered organizations: ISO 42001 does not use the term “AI system registry” as a named artifact. The standard requires an “inventory of AI systems” as part of defining the AIMS scope under Clause 7.5. In practice, auditors treating this as a governance accountability record not just a technical list is the de facto standard. Organizations that frame their inventory at the registry level (with ownership, oversight mechanisms, and risk classifications) consistently perform better in conformity assessments.
The Shadow AI Problem: Why Your Registry Is Probably Incomplete
Here is the uncomfortable reality most AI governance guides skip past: most enterprise AI system registries are incomplete on the day they are first reviewed by an auditor. Not because governance teams are careless, but because AI proliferation has moved faster than discovery processes can track.
Research compiled by Unseen Security, drawing on data from Awareways and Netskope across 2025 and 2026, shows that 75% of employees use AI at work but only 16% use employer-authorized tools. Separately, 46% of employees have installed AI tools without consulting their IT department. The result is an unregistered AI footprint that is, conservatively, larger than the registered one.
This is not a behavioral problem. It is a structural problem. When employees use personal AI tools for work tasks, copy AI-generated outputs into production systems, or run AI models in unsanctioned cloud environments, those systems are making consequential decisions within the organization’s operational boundary without appearing in any registry.
For ISO 42001 purposes, the AIMS scope must cover all AI systems within the organization’s control (Clause 4.3). An audit that surfaces three unregistered AI applications that have been processing customer data for eight months is a material nonconformity, regardless of how well-maintained the registered systems are.
Practical discovery approaches that governance teams are using to close this gap:
- Network traffic analysis
- Identifying API calls to known AI provider endpoints (OpenAI, Anthropic, Google, Azure AI) that are not associated with registered systems.
- SaaS usage audits
- Reviewing software procurement and expense data for AI tool subscriptions that bypassed IT approval.
- Business unit self-disclosure
- Structured quarterly questionnaires to department heads identifying AI tools used by their teams, with amnesty for undisclosed legacy systems.
- Procurement control
- Requiring AI system registration as a prerequisite for vendor contracts involving AI components catching third-party AI before deployment, not after.
The goal is not zero shadow AI, it is full visibility. An AI system that is discovered, assessed, and added to the registry is no longer shadow AI. The governance risk is invisible use, not historic unauthorized use that has been brought into the light.
Records That Must Persist Through the Model Lifecycle
One of the structural weaknesses in how most organizations approach AI record-keeping is treating registry and inventory entries as static documents. They fill them out at deployment and revisit them at audit time. Both frameworks and practical risk management require something different: living records that update when the system changes.
The EU AI Act Article 11 requirement is explicit: technical documentation “shall be kept up-to-date” and must reflect any substantial modification to the system. Under Article 12 of the EU AI Act, logging requirements for high-risk systems must capture events that could indicate risks throughout the operational lifetime which means the monitoring record is part of the compliance record.
ISO 42001’s Plan-Do-Check-Act model requires that AI systems are monitored continuously (Clause 9.1) and that nonconformities are corrected and documented (Clause 10.2). Neither of those requirements can be met with a registry that isn’t connected to the system’s operational state.
LIFECYCLE RECORDS REQUIRED BY MAJOR FRAMEWORKS
| Record Type | Trigger for Update | Retention Period | Framework Requirement |
|---|---|---|---|
| Risk assessment | Retraining, new use case, regulatory change | Duration of operation + 10 years (EU AI Act) | ISO 42001 Cl. 6.1; EU AI Act Art. 9 |
| Bias and fairness evaluation | Model version change, demographic scope change | Each version’s results retained separately | NIST AI RMF Measure 2.5; EU AI Act Annex IV |
| Monitoring logs | Continuous event-driven | At least 6 months immediately accessible (EU AI Act Art. 12) | EU AI Act Art. 12; NIST Manage 2.2 |
| Human oversight records | Each manual review or override event | Linked to incident history | ISO 42001 Annex A.9; EU AI Act Art. 14 |
| Incident and corrective action | Any identified failure, nonconformity, or near-miss | 10 years for EU AI Act high-risk systems | ISO 42001 Cl. 10.2; EU AI Act Art. 9(7) |
| Supplier and third-party records | Contract renewal, model update from provider | Duration of supplier relationship | ISO 42001 Annex A.10; EU AI Act Art. 28 |
The retention requirement deserves specific attention. EU AI Act Article 18 requires providers to retain technical documentation and keep it available for at least 10 years after the system is placed on the market or put into service. For organizations managing AI systems with short operational lifetimes models retrained quarterly, for example this means maintaining historical documentation for deprecated versions long after those versions have been superseded.
How to Build Both Records Without Building Two Separate Systems
The practical problem most compliance teams face is not conceptual it’s operational. Maintaining a registry and an inventory as two separate documents, in two separate systems, owned by two separate teams, is an unsustainable model at any meaningful scale.
The architecture that works is a single system of record that supports both views. The registry view surfaces governance fields for auditors, oversight bodies, and board reporting. The inventory view surfaces technical fields for ML engineers, risk owners, and certification bodies. The same underlying data powers both. A model version change in the inventory automatically prompts a review of the registry entry to confirm whether the governance classification still holds.
Research from Scrut.io published in 2026 identifies the core structural problem: “Engineering teams think in terms of pipelines, deployments, and access controls, while compliance teams focus on policies and documentation. The result is a disconnect. Policies are often defined separately from how systems actually operate.”
That disconnect is what makes AI governance programs fail audits despite considerable effort. The registry accurately describes the policy intent. The inventory accurately describes the technical reality. Neither is wrong they just don’t connect.
Building integrated records requires three deliberate design choices:
- Shared identifiers
- Every system in the registry and every model in the inventory must share a common ID schema, so that registry entries link directly to inventory entries without manual cross-referencing.
- Change propagation rules
- Define which inventory changes automatically trigger a registry review flag. Model retraining, version promotion, and new use cases should trigger a review. Minor bug fixes should not.
- Evidence linking
- Audit evidence – validation reports, bias evaluations, human oversight logs should be linked at the inventory level, with the registry entry pointing to the inventory for underlying evidence. This prevents the registry from becoming a claims document that auditors can’t verify.
Govern365.ai‘s AI model registry is designed around this integrated architecture registry-level governance fields and inventory-level technical evidence in a single platform, with automated change propagation and evidence linking built into the workflow. For teams preparing for ISO 42001 certification or EU AI Act compliance, the audit evidence package assembles continuously rather than being constructed manually in the weeks before an assessment.
Quick Reference: Minimum Required Fields for Each Record
The tables below represent the minimum fields a compliance-grade AI system registry and model inventory must contain to satisfy ISO/IEC 42001, EU AI Act (Annex III/IV), and NIST AI RMF requirements. Organizations under additional frameworks HIPAA, FFIEC SR 11-7, FDA AI/ML guidance will need to extend these field sets with sector-specific requirements.
AI SYSTEM REGISTRY: MINIMUM REQUIRED FIELDS
| Field | Required By | Notes |
|---|---|---|
| System ID (unique) | All frameworks | Must be stable across the system’s lifetime |
| System name and description | ISO 42001 Cl. 4.3; EU AI Act Annex VIII | Plain-language purpose statement |
| Owner (named individual) | ISO 42001 Cl. 5.3 | Cannot be a team or role without a named person |
| Risk tier | EU AI Act Annex III; NIST Map 1.1 | Prohibited / High-risk / Limited / Minimal for EU Act |
| Deployment status | ISO 42001 Cl. 8.1; NIST Govern | Development / Staging / Production / Retired |
| Applicable frameworks | Best practice | ISO 42001, EU AI Act, sector-specific regulations |
| Affected populations | EU AI Act Art. 9; NIST Map 3.5 | Users, subjects, third parties |
| Human oversight mechanism | EU AI Act Art. 14; ISO 42001 Annex A.9 | Override authority, escalation path |
| Last review date | ISO 42001 Cl. 9.1 | Date of last governance review |
| Conformity status | EU AI Act Art. 11; ISO 42001 | Certified / In progress / Gap identified |
MODEL INVENTORY: MINIMUM REQUIRED FIELDS
| Field | Required By | Notes |
|---|---|---|
| Model ID and version | ISO 42001 Annex A.6; NIST Map 2.1 | Semantic versioning; linked to registry system ID |
| Model architecture | EU AI Act Annex IV §1 | Algorithm type, framework, foundation model base |
| Training data reference | EU AI Act Annex IV §2; ISO 42001 Annex A.4 | Dataset ID, version, date range, source |
| Training date | EU AI Act Annex IV §2 | Date model was trained, not just deployed |
| Performance metrics | EU AI Act Annex IV §5; NIST Measure 2.5 | Task metrics + fairness/bias metrics |
| Known limitations | EU AI Act Annex IV §3; NIST Map 2.3 | Out-of-scope uses, distributional limitations |
| Deployment environment | NIST Govern; ISO 42001 Cl. 8.1 | Cloud provider, API endpoint, access controls |
| Monitoring configuration | EU AI Act Art. 12; ISO 42001 Cl. 9.1 | Drift thresholds, alert routes |
| Last validation date | ISO 42001 Cl. 8.1; NIST Measure 2.5 | Date of most recent bias/performance evaluation |
| Retirement plan | ISO 42001 Annex A.6.2.7 | End-of-life date and data disposal procedure |
Frequently Asked Questions
Is an AI system registry the same as the EU AI Act’s mandatory registration database?
Not exactly. The EU AI Act’s Article 49 establishes an EU-wide public database for high-risk AI systems, managed by the European Commission. Your internal AI system registry is the organizational governance record that feeds into that external registration. You maintain your registry; the EU database receives a structured submission based on Annex VIII fields. Both are required the internal registry enables the external submission.
Does ISO 42001 explicitly require a model inventory?
ISO 42001 does not use the term “model inventory” as a named artifact. However, Clause 4.3 requires defining the AIMS scope including all AI systems, Clause 7.5 requires maintaining documented information on AI systems, and Annex A.4 and A.6 require documentation of AI resources and lifecycle management. In practice, a model inventory is the standard vehicle for meeting these requirements. Auditors expect to see one.
How often should the AI system registry be reviewed and updated?
ISO 42001 Clause 9.1 requires monitoring and measurement at planned intervals, and Clause 9.3 management reviews should include registry status. The EU AI Act requires documentation to be kept “up-to-date,” triggering updates on substantial modifications. In practice: review registrations quarterly, update immediately on any material system change, and conduct a comprehensive audit annually or before any certification assessment.
What happens if an auditor finds AI systems that aren’t in the registry?
Under ISO 42001, unregistered systems operating within the AIMS scope represent a nonconformity against Clause 4.3 and Clause 8.1. The severity depends on the risk level of the unregistered system and the scale of the gap. Under the EU AI Act, deploying a high-risk Annex III system without registration in the EU database can result in penalties of up to €15 million or 3% of global annual turnover.
Can a spreadsheet serve as a compliant AI system registry?
Technically, yes frameworks specify what must be documented, not the tool. In practice, spreadsheets fail at scale because they lack version control, change history, evidence linking, automated update workflows, and access controls. Most organizations outgrow spreadsheet-based registries around 10 to 15 registered systems. Beyond that threshold, the manual maintenance burden creates documentation gaps that become audit findings.
Do model inventory requirements apply to third-party AI models we use but didn’t build?
Yes. If you deploy a third-party AI model in your operations, you are a deployer under the EU AI Act and have documentation obligations under ISO 42001 Annex A.10 (AI supply chain). You may not be able to document internal training data or architecture details for a proprietary third-party model, but you must document the system’s use case, risk classification, your oversight mechanisms, and your process for monitoring performance.
Building Records That Actually Hold Up to Audit
The distinction between an AI system registry and a model inventory is not semantic it is structural. The registry carries governance accountability; the inventory carries technical evidence. ISO 42001 certification, EU AI Act compliance, and NIST AI RMF implementation all require both, and they require them to be connected rather than parallel.
The practical starting point is straightforward: audit what you have, identify what is missing, and build toward a single integrated system that supports both views without duplicating effort. For most organizations, the registry gaps are in accountability fields named owners, risk tier classifications, and oversight mechanisms. The inventory gaps are in technical evidence validation results, known limitations, and lifecycle records.
Start by mapping your current AI systems against the minimum required fields in this guide. What you find will tell you exactly where to focus first.
| Start your 14-day free trial Build your AI system registry and model inventory on a platform designed to satisfy ISO 42001, EU AI Act, and NIST AI RMF from day one. |
