Introduction: How an AI Inventory Maintains Responsible Governance
AI now runs through models, copilots, agents, embedded SaaS features, and third-party services in nearly every department. Often nobody has a reliable record of what each one does, what data it touches, or who answers for it.
The pilot stage makes this harder. In KPMG's 2025 survey of 130 US leaders, 65% were piloting AI agents and 11% had deployed them. Pilots are systems too.
An AI inventory is a living, authoritative record. It ties each AI system to its business purpose, owners, dependencies, risk classification, controls, evidence, and lifecycle status. A spreadsheet of tool names doesn't do that.
This guide covers why visibility supports governance, what to capture, how to build the process, and how to report to executives.
Key Takeaways
- You can't govern AI you can't identify, classify, or assign to an owner.
- Scope must include built models, generative AI, agents, embedded features, vendor services, and shadow AI.
- Risk tiers send deeper review to sensitive, autonomous, or high-impact systems.
- Value comes from wiring the inventory into procurement, change management, and incident response.
- Executive reports should show ownership, trends, exceptions, and decisions needed in plain English.
What Is an AI Inventory and Why Does Responsible Governance Depend on It?
What an AI inventory is, and what it is not
The NIST AI RMF Playbook describes an inventory as an organized database of artifacts about an AI system or model. Examples include documentation, incident plans, data dictionaries, code links, and maintenance contacts.
An operational inventory differs from a static asset list because each record supports a decision: approve, restrict, monitor, remediate, suspend, or retire.
Scope should cover:
- Traditional machine learning and generative AI
- Automated decision tools and agents
- AI features inside existing SaaS products
- APIs and third-party providers
- Employee-adopted tools that process company information
One caution: a model card, which documents a single model's intended use and evaluation, is supporting evidence. It is not the inventory.
Why visibility is the foundation
NIST AI RMF 1.0 (GOVERN 1.6) calls for mechanisms to inventory AI systems and resource them by risk priority. You can't map or measure risk on systems you haven't identified.
With an accurate inventory, teams can:
- Name owners and affected stakeholders
- Assess data and decision risk
- Assign controls
- Pull evidence during an audit, incident, or board review
The failure case is real. A 2025 New York State audit found no formal AI inventory at any of four sampled agencies. The sample was small and nonstatistical, so treat it as an example, not a national rate.
How an inventory enables risk-based oversight
Applying one review process to every use case doesn't work. Prioritize by:
- Sensitive or regulated data
- Affected populations and consequential decisions
- External exposure
- Model autonomy
- Third-party dependency
- Business criticality
Set minimum controls for every system, then add depth as risk rises. A marketing-copy assistant and a loan-screening model shouldn't get the same review.
How you label that risk depends on the framework you follow. Classification mechanisms differ:
- NIST prioritizes by assessed risk and impact
- ISO/IEC 42001 requires risk and impact assessment inside a management system
- Colorado's statute targets automated decisions in areas such as employment, housing, lending, insurance, and health care
These aren't interchangeable labels.
Responsible governance principles the inventory makes visible
NIST names seven trustworthy-AI characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair with harmful bias managed.
Some of these can be documented in a field, such as owner, data categories, or human-oversight role. Others need testing, monitoring, or human review. A "fairness tested" checkbox proves nothing without the test results linked behind it.
What leaders should gain
Boards, audit committees, and CEOs use the inventory to ask what changed, where exposure is growing, which exceptions are open, and which decisions need executive action.
This is where Tyson Martin's approach applies: a plain-English risk posture, stable trend metrics, clear delegation, and escalation thresholds. The aim is fewer surprises without slowing the business.
What Should a Governance-Ready AI Inventory Contain?
Identification, purpose, and ownership
Each record needs the following minimum:
- Unique identifier and name
- Plain-language description and business purpose
- Business owner and technical owner
- Department, deployment type, and lifecycle status
- Date of last review
Name an accountable owner and a separate technical contact where responsibilities differ. "The IT team" is not an owner.
Federal 2025 reporting fields offer a model: use-case ID, contact, development stage, high-impact determination, and intended problem.
Data, model, dependency, and deployment context
Capture:
- Data categories, including personal or sensitive data
- Data source and lineage
- Training or retrieval data summary
- Model type, provider, and version
- Infrastructure, integrations, and external services
For third-party foundation models, NIST's generative AI profile suggests recording the underlying model, version, and access mode. OpenAI's documentation notes that behavior can change between snapshots and recommends pinned versions with evaluations. Record your pinning approach and define what triggers revalidation after a provider change.
Risk, impact, and control information
Record the classification and the reasoning behind it, so a reviewer can see how the call was made. Related fields include:
- Decision impact and affected populations
- Regulatory or policy scope
- Privacy, security, and fairness or performance assessments
- Human oversight requirements
- Approved use boundaries
- Open exceptions
Agentic, third-party, embedded, and shadow AI
Agents need extra fields:
- Autonomy level
- Permitted tools and actions
- Escalation triggers
- Human handoff rules
- Access context
- Audit-log location
Also require records for:
- Vendor-operated AI
- AI inside existing SaaS products
- Outsourced decision processes
- Tools found through surveys, procurement reviews, network telemetry, or cloud activity
Evidence, lifecycle, and change history
Link evidence for approvals, contracts, data assessments, test results, monitoring reports, incidents, and exception decisions.
Track lifecycle details:
- Deployment date and status
- Next review date
- Version history
- Substantial-change triggers
- Decommission plan
- Who made each material update and why
Split fields into two tiers. Mandatory intake fields let teams register a system fast. Enrichment fields get completed before higher-risk use or production deployment.
How to Build an AI Inventory Governance Process
Define scope, decision rights, and sponsorship
Decide what counts as AI for inventory purposes, including agents, embedded features, and vendor-operated capabilities.
- Appoint one accountable executive sponsor, often the CEO or COO, and a process owner with authority to require disclosure across business units
- Define the board or committee's oversight role separately from management's operational accountability
- Assign responsibilities across technology, security, privacy, legal, compliance, procurement, data teams, business owners, internal audit, and risk
A three-lane model works well: who owns a decision, who shares it, and who advises. Go-live approval for high-risk systems is typically shared.
Discover AI across the organization
No single source reveals everything. Combine:
- Procurement and contract reviews
- Software, cloud, and SaaS inventories
- API and network activity
- Code and deployment pipelines
- Vendor questionnaires
- Employee self-declarations and business-unit interviews
Prioritize shadow AI, embedded vendor features, outsourced services, internal models, and autonomous agents running outside formal IT processes.
Frame discovery as enablement, not punishment. Teams disclose experiments when disclosure leads to approval, not discipline.
No reliable US prevalence figure for shadow AI exists, so don't invent one. Gallup's 2025 finding that 45% of US employees use AI at least a few times a year measures general use, not unauthorized use.
Establish intake, triage, and approval workflows
Build one repeatable path for systems that are built, bought, discovered, or materially changed:
- Register the system
- Assign an owner
- Run an initial risk screen
- Complete required assessments
- Approve or restrict
- Decide on deployment
- Schedule review
Define escalation thresholds for sensitive data, consequential decisions, external-facing outputs, high autonomy, material financial impact, or unresolved control gaps. Connect the workflow to procurement, architecture review, release, vendor onboarding, privacy, security, and incident management.
Map the inventory to US requirements
Map fields and evidence to the NIST AI RMF, NIST's generative AI profile, federal or agency requirements, state AI and privacy laws, and sector rules. Then verify each one against official sources, because this area moves quickly.
A few examples, as of late October 2026:
- Colorado's replacement law (SB26-189) begins new duties January 1, 2027, and supersedes the earlier SB24-205 framework
- California's CCPA regulations on risk assessments took effect January 1, 2026, with automated decision-making requirements starting January 1, 2027
- Fed/OCC/FDIC SR 26-2 supersedes SR 11-7 for banks and excludes generative and agentic AI
- OMB M-25-21 requires federal agencies, not private businesses, to inventory AI use cases
The inventory should show which requirements apply, which controls exist, who owns the evidence, and what remains open. This is governance support, not legal advice.
Launch a 90-day plan
- Days 1-30: Secure sponsorship, set scope and decision rights, and publish a minimum viable schema.
- Days 31-60: Run discovery and collect known and shadow AI records.
- Days 61-90: Classify risk, assign owners, and start priority remediation.
Set measurable outcomes per phase: records with named owners, high-risk systems reviewed, missing evidence assigned, and escalations handled on time. Publish a usable first version and enrich it on a review cycle. Waiting for perfect records means never launching.
How to Keep the Inventory Current and Prove Governance Readiness
Connect updates to operational triggers
Updates should fire on operational events, including:
- New procurement or deployment
- Model or data changes
- Foundation-model and vendor feature updates
- Ownership, policy, or incident changes
- Suspension and decommissioning
Wire the inventory into change management, release controls, vendor management, cloud and SaaS discovery, incident response, and identity processes so updates do not depend on reminders. NIST's generative AI profile also recommends records of third-party content changes, including sources and timestamps.
Keep a versioned audit trail showing what changed, when, by whom, why, and whether it triggered a new review. Retired systems should stay in the record, and identifiers shouldn't be reused.
Apply a governance-readiness stress test
Sample a few systems and ask whether a reviewer can determine:
- What is running and where
- What it depends on
- Who owns it
- What evidence supports it
- Whether the record matches runtime reality
A passing record has a current owner, version reference, dependencies, approval status, review date, exception history, and retrievable evidence, with no reliance on informal knowledge.
This lines up with NIST's lifecycle guidance on post-deployment monitoring, change management, and decommissioning, and with ISO/IEC 42001's documented-information and performance-evaluation clauses. But an inventory is not a certification. ISO describes certification as voluntary and performed by independent bodies against the full management-system requirements.
Report to executives without creating noise
Board reporting works best as a one-page dashboard with trend lines, thresholds, and three parts: top risks, what changed, and decisions needed. Include:
- Inventory coverage, owner assignment, and evidence completeness
- Risk distribution and trend
- Overdue reviews and unresolved exceptions
- Material changes and incidents
- Decisions requiring escalation
Boards need this. A 2025 Deloitte and Society for Corporate Governance survey found boards regularly receive the current AI inventory at just 22% of large-caps and 10% of mid-caps. That measures board receipt, not whether inventories exist.
Common failure modes:
- Narrow definitions hide embedded and vendor AI
- IT-only ownership leaves business risk unowned
- Stale records make reports misleading
- Disconnected spreadsheets break the audit trail
- Chasing perfect data delays a usable first version
Write every report to say what changed, why it matters, who owns the response, and what decision is required.
Conclusion: Turn the AI Inventory Into an Inspectable Governance Control
An AI inventory maintains responsible governance by turning a growing, partly invisible AI environment into an accountable, reviewable operating record. The payoff is better decisions, faster escalation, defensible evidence, and proportionate oversight.
If you need help clarifying decision rights, building a board-ready reporting model, or running a 90-day governance plan, Tyson Martin works with boards and executive teams as a board advisor and as an interim or fractional CISO. The work centers on a stable dashboard, escalation thresholds that hold in real incidents, and a 90-day plan with owners and measurable outcomes.
Frequently Asked Questions
What is the AI governance process?
It's a structured set of policies, processes, and controls across the AI lifecycle: inventory and intake, risk classification, ownership, approval, monitoring, escalation, review, and continuous improvement.
Who should be responsible for AI governance?
Executive sponsorship and cross-functional participation are both required. Still, every AI system needs a named business owner and an accountable technical or operational owner.
Why does AI need governance?
AI creates privacy, security, fairness, reliability, and regulatory exposure. Governance adds accountability and human oversight, so innovation continues without unmanaged risk.
What should be included in an AI inventory?
Purpose, owners, data, model and vendor details, dependencies, risk classification, controls, approvals, evidence, lifecycle status, review dates, and change history.
How do you keep an AI inventory up to date?
Combine automated discovery with procurement and release integrations, defined update triggers, periodic validation, incident-driven reviews, ownership checks, and a versioned audit trail.
