An AI inventory should work for both engineering and compliance. If it is too legalistic, engineering teams will not keep it current. If it is too technical, compliance teams cannot use it for risk decisions. The right checklist captures the facts needed to understand the system and govern it over time.
The inventory is not just a list of model names. It is the system record that supports classification, approval, monitoring, and audit evidence.
Basic identity
Capture system name, description, owner, technical contact, business unit, repository or vendor, environment, launch status, and user group. Add whether the system is internal, customer-facing, partner-facing, or embedded in a regulated process.
The description should be plain enough for non-technical reviewers. What does the system do, and what decision or workflow does it support?
Model and architecture
Record model provider, model type, orchestration framework, retrieval sources, vector stores, prompt ownership, fine-tuning, evaluation approach, and integration points. For vendor tools, capture product name, enabled AI features, contract status, and data-processing terms.
The goal is not to document every implementation detail. The goal is to understand the architecture well enough to assess risk and changes.
Data access
Identify input data, output data, stored data, personal data, confidential information, regulated records, customer data, employee data, and training or retention behavior. Include retrieval sources and permission model.
Data access is often the factor that moves a system from low concern to formal review.
Autonomy and tools
Document whether the system suggests, drafts, recommends, decides, or acts. For agents, list each tool, permission, action type, approval requirement, and failure mode. Include whether the agent can send messages, update records, execute code, create tickets, or trigger transactions.
Autonomy should be described as actual capability, not marketing language.
Governance fields
Add risk tier, classification rationale, applicable obligations, required approvals, control requirements, monitoring owner, incident path, evidence location, review date, and change triggers.
A strong inventory lets a reviewer move from a system to the reason it was approved and the proof that controls exist. That is what makes it useful beyond bookkeeping.