AI System Inventory: What Should Companies Document?

An employee may introduce an AI writing assistant without telling IT. A facilities team may adopt a predictive maintenance add-on through an existing monitoring contract. A developer may integrate a third-party model into an internal dashboard. These are different forms of what organizations often call shadow AI: uses that are not visible to the people responsible for security, procurement, compliance or operational risk.

The first step is discovery, not purchasing governance software. The register can begin in a controlled spreadsheet or an existing asset-management system, provided owners maintain it and changes are traceable. NIST's voluntary AI Risk Management Framework explicitly identifies mechanisms to inventory AI systems as a governance outcome.

Start with business processes, not vendor names

Ask department leads which tools draft, classify, predict, rank, recommend, generate or automate work. Check procurement records, enterprise app catalogs and integrations with existing systems. Include pilots, embedded AI features and tools used through approved corporate accounts. Do not assume every rule-based automation is an AI system.

Six documentation areas worth capturing

1. Ownership and intended purpose

Give each system a stable internal identifier. Describe the business problem it addresses and distinguish approved purposes from prohibited or untested uses. Record the responsible business owner, technical contact and the team authorized to change its configuration. Avoid using only a generic department name when a specific accountable role is available.

2. Architecture, supplier and version

Note whether the AI is a vendor-managed service, an embedded feature, a locally hosted open-weight model or an internally developed system. Record the supplier, relevant model or service version, integration points, hosting location when material and contractual links. Some suppliers change models or behavior without a visible version string, so document how updates are communicated and verified.

3. Risk and potential impact

Record who or what can be affected if an output is wrong. Distinguish internal risk scoring (the company's own prioritization) from a legal classification under the EU AI Act. A company may consider an AI tool operationally critical even when it is not legally classified as high-risk under the Act. Conversely, a tool affecting hiring decisions deserves closer legal analysis even if its cost is small.

4. Data and permissions

Document the categories of inputs and outputs, access permissions, transfers to third parties, retention and any personal or sensitive data. For fine-tuned systems, identify relevant training or evaluation datasets where known. Verify contract terms and service settings rather than assuming that all enterprise plans prohibit provider training or that all free plans permit it.

5. Human oversight and operating controls

State whether outputs are read-only, recommendatory or directly executable. Identify the decision-maker, the review procedure, performance measures, user guidance and limits of permitted use. If the model controls a facility system, link to engineering safety interlocks and rollback procedures rather than duplicating them loosely in a register.

6. Incidents, changes and retirement

Record how suspected errors are escalated, who can disable the system and what happens when the supplier becomes unavailable. Log major version changes, expansions in purpose, revised datasets and material incidents. Include an owner and process for decommissioning an obsolete AI feature and managing retained records.

An illustrative AI inventory record

This simplified example concerns an internal recruitment-screening tool, deliberately chosen because decisions about employment may affect individuals significantly. It is fictional: no claim is being made about a named product, supplier or its contractual guarantees.

Treat the inventory as a living operating record

Model behavior, suppliers and organizational uses change. Set review triggers instead of relying only on an annual spreadsheet exercise. Suitable triggers include the release of a new model version, an expanded business purpose, new personal-data inputs, a consequential incident, a major workflow change or the end of a supplier agreement.

1. 01
   Discover and prioritize

   Begin with high-impact decisions, sensitive inputs and systems that can initiate real-world actions.

2. 02
   Validate records with owners

   Confirm how the system is actually used rather than relying on a product brochure.

3. 03
   Connect to existing evidence

   Link contracts, assessments, operating procedures, incident records and approvals.

4. 04
   Review when something changes

   Keep ownership and version history visible, with a date for the next risk-based review.

Does the law require every company to keep the same inventory?

No. Maintaining an inventory is a broadly useful governance practice, and NIST recommends inventory mechanisms, but the EU AI Act does not impose one identical company-wide list requirement on every organization using every AI tool. Particular duties depend on legal roles, system classifications and applicable provisions. Privacy, employment and cybersecurity laws may add separate documentation requirements.

A useful inventory therefore records both what the business knows and what remains to be checked. “Legal classification pending review” is preferable to silently assuming that a system is exempt. The outcome is a practical register that supports decisions, rather than a spreadsheet maintained solely for an audit.