Every AI governance task starts with the same question: which AI systems do we have? Risk assessments need it. Impact assessments need it. Questionnaire answers need it. When the answer lives in several people's heads, each of those tasks starts with a week of asking around.
An inventory fixes that, if it stays current. Most do not. They are built once for an audit or a board paper, then drift until nobody trusts them, and the next project builds a new one.
This article covers what to include, which fields earn their place, where entries come from, and how to tie updates to processes that already run. It does not cover finding tools nobody told you about. That is a discovery exercise with its own methods.
Why you need one, even if no standard names it
ISO/IEC 42001 does not contain a requirement titled "AI system inventory." It does not need to. Clause 4 asks you to set the scope of your AI management system and determine your role toward the AI systems in it. Annex A.4 asks you to document the resources each AI system relies on. Impact assessments run per system. None of that works without a list.
Outside ISO/IEC 42001, the inventory supports the asset inventory ISO/IEC 27001 already expects under Annex A 5.9, your subprocessor list, and every AI answer in a customer questionnaire. If you have read the AI questions in security questionnaires, most of the fact base described there is this inventory.
What counts as an AI system
Decide the boundary in writing, because people will disagree. A useful practical definition covers three categories:
Systems you build. Models you train, fine-tune, or assemble into a product, including retrieval systems built on a third-party model.
AI features you provide. Anything in your product that uses a model to generate, classify, rank, or decide, whoever built the model.
AI tools you use. Assistants, coding tools, transcription, and AI features inside software you buy, where they process your data or your customers'.
The gray area is conventional automation and fixed rules. A scoring rule a person wrote is not usually an AI system. A model trained on historical data to produce that score is. If you are unsure, include it and mark the category. A slightly long inventory costs little. A missing system costs an impact assessment that never happened.
ISO/IEC 22989 provides the definitions ISO/IEC 42001 relies on, if you need a formal reference for the boundary.
The fields worth keeping
Keep the field list short enough that owners will fill it in. These earn their place because each one answers a question someone will ask.
| Field | The question it answers |
|---|---|
| Name and description | What is it, in a sentence a customer would understand? |
| Category | Do we build it, provide it, or use it? |
| Business owner | Who decides whether it keeps running? |
| Technical owner | Who knows how it works and can change it? |
| Provider and model | Whose model is it, and which one? |
| Data received | What classification of data goes in, including personal data? |
| Users and affected people | Who uses the output, and who is it about? |
| Decision influence | Does the output inform or make a decision about a person? |
| Hosting and region | Where does processing happen? |
| Status | Proposed, in development, live, or retired |
| Last risk and impact assessment | When was it last assessed, and where is the record? |
| Next review date | When does the owner next confirm the entry? |
Resist adding more until a real need appears. Fields like "model architecture" or "training data size" matter for systems you build. For tools you use, they are usually unknowable and get left blank, which makes the whole inventory look incomplete.
Where entries come from
You probably have most of the raw material already. The work is consolidating it, not inventing it.
Vendor inventory. Filter for vendors whose product includes AI features you use. One vendor can produce several entries, one per use.
Product documentation and roadmaps. Every AI feature in the product, and every one in development.
Architecture and data flow diagrams. Calls to model providers show up here even when nobody thought of them as an AI system.
Procurement and expense records. Subscriptions to AI tools, including team-level ones.
Code repositories. Dependency manifests that include a model provider's SDK, and configuration that holds a provider's API endpoint, point to AI use in internal services as well as the product. Engineering can usually produce this list in an afternoon, and it often finds internal tools that no procurement record shows.
Your approved tools list. If your AI acceptable use policy points to one, every entry belongs in the inventory.
Then ask each owner to confirm their entries. An entry the owner has never seen is a guess.
Keeping it current
An inventory goes stale because updating it is a separate task that nobody remembers. The fix is to make the update a step in processes that already run.
Procurement. A new AI tool cannot be approved until its inventory entry exists. Approval and entry happen together.
Product release. A release that adds or changes an AI feature updates the inventory as part of the release checklist.
Change management. A new model version, a new provider, or a new data source counts as a change to the entry and may trigger a new risk or impact assessment.
Owner attestation. On a fixed cycle, quarterly is common, each owner confirms their entries are accurate or corrects them. Keep the record.
Retirement. When a system is switched off, mark it retired rather than deleting it. Auditors and customers may ask about systems that ran during a period you are reporting on.
The attestation step is what makes the inventory evidence. It shows the list was checked by someone accountable, at a known date.
How the inventory feeds everything else
Once it is reliable, the inventory becomes the source for:
Scope. The AI management system scope statement, described in building an AI management system.
Annex A evidence. Resource documentation under A.4, and the starting point for the life cycle and data controls, which also work per system.
Risk and impact assessments. One assessment per entry, linked from the entry.
Vendor reviews. Entries in the "use" and "provide" categories that rely on third parties point to the vendor review, as in AI vendor risk questions.
Incident response. When a provider reports an incident, the inventory tells you which systems and data are affected.
What people get wrong
One entry per vendor. A vendor whose tool is used by sales on public data and by support on customer tickets is two uses with two risk profiles.
No owner. An entry without a named owner does not get updated.
A separate spreadsheet. If the AI inventory is disconnected from the asset and vendor inventories, the three will disagree within months. Link them.
Treating it as complete. The inventory reflects what you know. Say so, and run discovery periodically to find what you do not.
The ISO 42001 framework page summarizes the clauses that depend on it.
How TrustLynce helps
TrustLynce's third-party risk tools keep the vendor inventory with risk tiers and scheduled reassessment, so AI tools you use are reviewed on a cycle. Each AI system's risks and treatments sit in the risk register with owners and review dates.