AI inventory: what auditors expect
Every AI governance framework begins by asking what AI you have. An inventory that satisfies an auditor is less about the list than about what you can show for each line.
- By
- GhostAudit
- Published
- Last reviewed
- Reading time
- 5 min read
Key points
- An auditor tests three things: completeness, accountability and currency.
- Each record needs an owner, a purpose, a data classification, a risk tier with its rationale, and a last-reviewed date.
- Be ready to explain how you know the list is complete. "We asked" is the weakest answer.
- Keep the history. Evidence that the inventory is maintained matters more than how it looks on audit day.
Why the inventory comes first
Read any AI governance framework and the first substantive step is the same.
The NIST AI Risk Management Framework asks organizations, under its Map function, to inventory AI systems and document their context, intended use and impacts. ISO/IEC 42001 requires you to define the scope of your AI management system and to perform risk assessments and impact assessments on the AI systems within it, which presupposes a list of them. Under the EU AI Act, obligations depend on what each system is used for, so a deployer cannot know its duties without knowing its uses.
Customers ask too. Security questionnaires increasingly include a section on AI: which AI systems process our data, and how are they governed? The inventory is the source for those answers.
An inventory is therefore both a control in its own right and the index to every other control. Assessments, policies, notices and reports all refer back to it.
What counts as an AI system
Scope disputes waste time, so settle the definition early and err on the side of inclusion. A practical inventory covers:
- Third-party AI products used by staff: assistants, coding tools, transcription and translation services, image and video generators.
- AI features inside other software: the assistant in your CRM, the scoring model in your applicant-tracking system.
- AI you build: models you train or fine-tune, and applications built on third-party model APIs.
- AI components in code: SDKs and frameworks in your repositories.
Record systems that turn out to be low-risk as well. A short entry marked minimal risk shows that someone looked and decided; an absent entry shows nothing.
The fields that matter
Auditors do not prescribe a schema, but the questions they ask map onto a consistent set of fields.
| Field | The question it answers |
|---|---|
| Name, vendor, version or plan | What is it, exactly? |
| Owner | Who is accountable for it? |
| Purpose and usage context | What is it used for, and by whom? |
| People affected | Whose interests does its output touch: staff, customers, applicants? |
| Data sensitivity | What is the most sensitive data it receives? |
| AI capability | Does it generate, predict, classify, decide? |
| Human oversight | Does a person review output before it has an effect? |
| Risk tier and rationale | How risky is it, and why do you think so? |
| Controls and gaps | Which safeguards exist: logging, bias monitoring, data governance? Which are missing? |
| Applicable rules | Which laws and frameworks reach it? |
| Status | Approved, under review, not approved, prohibited? |
| Last reviewed, next review | Is the record current? |
Two of these deserve emphasis.
Owner. A record without a named owner is the most common finding, and the most telling. If nobody is accountable for a system, nothing else in the record can be relied on. "IT" is not an owner; a person or a specific role is.
Risk tier with rationale. A tier alone invites the question "why?". The record should show the attributes behind the rating, so that a reviewer can follow the reasoning and see that the same logic was applied to every system.
What an auditor will test
Completeness
How do you know this is everything?
The strong answer describes a discovery process with more than one source: single sign-on applications, code repositories, endpoint data, procurement records. The weak answer is a survey. Expect the auditor to pick a tool they know is widely used and ask whether it appears. If your inventory lists three AI tools and your staff number two thousand, expect scepticism.
Being able to show findings that were reviewed and deliberately excluded, with a reason, is itself good evidence. It demonstrates a process.
Accountability
Who decided this, and when?
For a sample of records, the auditor will ask who approved the system, who assigned the risk tier, and when it was last reviewed. They are looking for names and dates, ideally in a log that cannot be quietly rewritten.
Currency
Is this still true?
They will compare the inventory with reality: a system marked "under review" for eleven months, a listed owner who left the company, a tool everyone knows was replaced. Review dates that have passed are an easy finding.
Consistency
Does the rest of your documentation agree?
The acceptable use policy's approved list, the risk assessments and the vendor register should all match the inventory. Discrepancies suggest documents that were written separately for the audit.
Common gaps
The spreadsheet that was true once. Built for last year's audit and not touched since. Without a feed of new findings, an inventory decays within months.
Vendors, not uses. Listing a general-purpose assistant as one line hides the fact that it is used for marketing copy by one team and for screening job applicants by another. Risk attaches to the use. Where one tool has materially different uses, record them separately.
Embedded AI. Features switched on inside existing products rarely pass through any intake process.
Declared but not observed. The inventory says forty people use a tool; nobody has checked. Actual usage data, where you have it, is a useful control on declared information, and the reverse.
No trail. The current state is recorded, but not how it came to be. When a risk tier changed, who changed it and why?
Keeping it alive
An inventory stays current when updating it is a side effect of normal work, not a separate chore.
- Feed it automatically. Connect discovery sources so that new tools appear as findings for review, not as surprises.
- Make it the system of record. If approvals, assessments and status changes happen in the inventory, it is current by construction.
- Set review cadences by risk. Review high-risk systems more often than minimal-risk ones.
- Report on it. A regular summary to management of new systems, open gaps and overdue reviews keeps attention on it, and is the management-review evidence a standard such as ISO/IEC 42001 looks for.
What to hand over
When the request comes, a good package contains: the inventory report with risk distribution, owners and control coverage; the description of your discovery process and its sources; a sample of records with their change history; and the list of findings that were dismissed, with reasons.
How GhostAudit supports this
The GhostAudit inventory holds these fields for each system, and is fed by discovery from Google Workspace, Microsoft 365, Okta, GitHub, browser and desktop sensors and log import. Findings are accepted or dismissed with a reason, and every change is written to an audit log with the person and the time. Observed usage from the sensors appears alongside declared information.
The AI system inventory report is generated from the register: risk distribution, data sensitivity, owners, control coverage, review schedule and vendor concentration. The regulation tracker adds which rules reach each system, with the reason for each match.
Sources
This guide is for orientation and is not legal advice. It was last reviewed on 10 November 2026; laws and guidance change, so check the official texts linked above. Spotted something out of date? Tell us.