Enterprise AI Inventory

Governance cannot operate consistently when the organization does not know which AI systems and use cases exist. Policies can describe approved behavior, committees can define principles, and risk teams can publish assessment forms, but none of those measures reaches an unknown deployment. The enterprise AI inventory establishes the population that ownership, classification, control, monitoring, and evidence processes are expected to govern.

The visibility problem is structural. AI enters through product development, cloud services, employee subscriptions, software updates, vendor features, acquisitions, client projects, and local automation. Different functions see different parts of that picture. Technology may know the architecture, procurement the supplier, security the application, and business teams the actual use. A shared AI system inventory turns these partial views into one accountable record.

An inventory also improves prioritization. Leadership does not need every low-impact experiment to receive the same treatment as a system affecting employment, customer eligibility, sensitive data, safety, or essential operations. By recording purpose, consequence, scale, dependency, and review status, the inventory helps teams find material exposure and direct specialist attention where uncertainty matters most.

The inventory unit should be meaningful to governance. A single foundation model may support several applications with different owners, data, users, and consequences. Conversely, one business service may combine multiple models, rules, and vendor components into a single decision process. The record should represent the system or use case at the level where an owner can explain its purpose, operation, risk, and controls.

Scope should include more than custom machine-learning systems. Relevant entries may include generative AI assistants, recommendation and scoring tools, intelligent document processing, forecasting, computer vision, speech analysis, AI agents, model APIs, and AI functionality embedded in approved enterprise software. Third-party and employee-adopted tools matter because organizational exposure can exist even when the organization did not develop or host the model.

Experiments require a proportionate approach. Recording every temporary test in the same detail as a production system can make the inventory unusable, but ignoring experimentation allows pilots to become operational without review. A practical model uses lifecycle states and minimum intake fields, then increases record depth when a use gains real users, accesses organizational data, influences a process, or moves toward production.

No single discovery method is complete. Surveys and interviews reveal business context but depend on what people remember and recognize as AI. Procurement and expense data identify suppliers but may miss embedded capabilities or free tools. Application portfolios show managed software but not how features are configured. Technical telemetry can reveal domains, APIs, extensions, and data flows while still lacking purpose and ownership.

A strong discovery process combines evidence sources. Teams can review vendor catalogues, software inventories, security findings, browser and network signals, cloud accounts, model endpoints, data-platform workloads, procurement records, privacy assessments, automation platforms, and product roadmaps. Workshops with business units then validate what the tools are used for, whether outputs affect decisions, and which local workarounds or experiments are absent from central records.

Discovery should be framed as fact-finding rather than a hunt for rule-breakers. Employees often adopt AI to solve genuine workflow problems, and punitive messaging can push use further underground. The objective is to understand the operating environment, distinguish approved, tolerated, experimental, embedded, and unapproved uses, and decide what should be governed, restricted, replaced, monitored, or retired.

Every entry needs a stable identifier and a clear name, but useful records go much further. Core descriptive fields include business purpose, intended users, operational owner, technical owner, provider, model or service dependency, deployment method, lifecycle state, geographic use, affected process, input data categories, outputs, and the degree to which people or downstream systems rely on those outputs.

Governance fields connect description to decisions. These may include approval status, role analysis, risk tier, impact assessment status, human oversight, data and security review, supplier due diligence, applicable policies, required controls, exceptions, monitoring owner, incident route, review date, and next review trigger. The record should identify supporting evidence rather than asking users to infer that a completed field proves a control operates.

Field design should balance consistency and usability. Long forms encourage incomplete or stale records, while short lists cannot support risk or readiness work. A layered model works well: collect minimum discovery fields first, then require deeper information based on lifecycle, materiality, role, and exposure. Controlled vocabularies improve reporting, but narrative context remains necessary where a label cannot explain how the system influences a real process.

An enterprise AI inventory and a model registry answer different questions. A model registry typically manages technical model artifacts, versions, metrics, lineage, and deployment information for data science or machine-learning operations. The enterprise inventory operates at the governance level. It connects systems and use cases to business purpose, accountable owners, people affected, vendors, data exposure, risk decisions, controls, and evidence, including systems built entirely by third parties.

A configuration management database, or CMDB, records technology assets and their operational relationships. It may show servers, applications, services, and dependencies without explaining whether an application uses AI, how an AI output affects a decision, or which governance review applies. Rather than replacing the CMDB, the AI system inventory should reference relevant technical records and add the business and governance context those records were not designed to hold.

A record of processing activities, or ROPA, documents personal-data processing for privacy governance. It can provide valuable information about purposes, data subjects, recipients, transfers, retention, and safeguards, but not every AI system processes personal data and not every AI governance question is a privacy question. The records should be linked where relevant, while each remains authoritative for its own purpose. Duplication should be reduced through references and shared identifiers.

A central governance team can steward the inventory, but it cannot own every record's truth. Business owners should be accountable for intended use and process consequences. Technical owners should maintain architecture and operation. Procurement or vendor owners should manage supplier information. Risk, security, privacy, legal, and compliance functions contribute reviews within their mandates. The inventory should make these responsibilities explicit rather than reducing ownership to one name.

Lifecycle states help the organization apply proportionate requirements. Common states include proposed, experimental, under review, approved, operational, suspended, and retired. Movement between states should trigger defined information and decisions. A pilot accessing production data may require review; an approved tool used for a new purpose may need reassessment; a retired system may still require evidence retention, access removal, contract action, or dependency cleanup.

Review triggers are more reliable than a calendar alone. Material vendor changes, model replacements, new data categories, expanded user groups, changed intended purpose, incidents, control failures, geographic expansion, or integration into a consequential process can all invalidate an earlier assessment. Periodic review still matters, but event-driven updates keep the enterprise AI inventory aligned with operating change between scheduled cycles.

The inventory should route systems into governance rather than becoming a reporting endpoint. Recorded characteristics can determine whether a use needs supplier review, security analysis, privacy assessment, AI risk assessment, legal interpretation, human-oversight design, monitoring, or executive approval. This routing makes the inventory useful to delivery teams because it clarifies what happens next instead of merely collecting information for a central function.

Control coverage should be visible at the system level. An entry can show which controls are expected, who operates them, where evidence is stored, and whether exceptions exist. Relevant measures may include access restrictions, approved-use boundaries, testing, data controls, output verification, human review, logging, performance monitoring, incident response, change control, and periodic reassessment. The inventory links these controls to the use they are intended to govern.

Evidence links make governance defensible. Approvals, assessments, supplier records, testing results, oversight procedures, monitoring reports, literacy records, incidents, exceptions, and remediation decisions should be retrievable from the system record. The inventory does not need to store every artifact directly, but it should provide a coherent index so leadership, clients, auditors, and regulators can understand what was decided, by whom, on what basis, and whether it remains current.

EU AI Act readiness begins with a system population. Organizations need to identify relevant systems before they can analyze whether they act as providers, deployers, importers, distributors, or other actors in a value chain. Intended purpose, branding, modification, deployment context, users, and geographic reach are system-specific facts. An enterprise AI inventory organizes those facts and records where legal analysis remains unresolved.

The inventory also supports risk screening and evidence planning. It can connect each system to classification questions, affected people, human oversight, technical and supplier documentation, monitoring, incident processes, and AI literacy measures. These records do not determine compliance on their own, and qualified legal advice may be required. They ensure that readiness work is performed against known systems rather than a policy-level estimate.

Regulatory value depends on maintenance. A role or risk analysis can change when a system is repurposed, substantially modified, rebranded, expanded to another population, or updated by a supplier. Review triggers and version history help the organization identify those changes and preserve the evidence behind earlier decisions. The inventory becomes the operational bridge between discovery, legal interpretation, governance controls, and ongoing readiness.

A one-time spreadsheet decays quickly. Sustainable inventories are integrated into procurement, application onboarding, product development, security review, privacy review, architecture governance, vendor change management, and retirement workflows. Teams should be able to propose a record through a simple intake route, while governance owners enrich and validate the information according to materiality and lifecycle.

Quality measures should focus on decision usefulness. Relevant indicators include records without owners, overdue reviews, unresolved role or risk questions, systems missing evidence, unapproved uses, stale vendor information, and material changes awaiting assessment. A total system count can be informative, but it should not be mistaken for completeness. Unknowns, confidence levels, and discovery coverage should remain visible in leadership reporting.

The inventory should support action at several levels. System owners need clear next steps. Governance functions need a dependable queue for review and monitoring. Executives need an aggregated view of exposure, ownership, exceptions, and remediation. When the same operating record serves these needs, maintenance becomes part of ordinary governance rather than an administrative exercise performed only before an audit or regulatory deadline.