Your AI System Inventory Is Wrong (And That's Normal)

The first thing we ask for on an ISO 42001 engagement is a list of your AI systems. The list we get back is never complete. That is not a criticism of the teams who produce it — it is a structural property of how AI gets adopted inside a company, and it is the single most common reason certification timelines slip.

Why the inventory decides everything

ISO/IEC 42001 scope drives every other requirement. Which impact assessments you owe, which Annex A controls apply, what your Statement of Applicability justifies, what your auditor samples — all of it derives from what is in scope.

Get the inventory wrong and you either do a great deal of unnecessary work, or you discover mid-audit that a system nobody assessed is squarely in scope. The second failure mode is considerably worse, because a Stage 2 auditor who finds an unregistered AI system does not just raise a finding on that system. They start doubting the register itself, and the sampling gets a lot more aggressive.

Where the missing systems are

From the gap assessments I have run, the same categories go missing every time.

AI features inside SaaS tools other teams adopted. Your support platform added AI reply drafting. Your recruiting tool ranks candidates. Your sales tool scores leads. Nobody filed a procurement request because nobody bought a new tool — a vendor shipped a feature. Several of these process personal data and make or influence consequential decisions, which puts them in scope and occasionally puts them in the EU AI Act's high-risk categories.

LLM API calls inside internal automation. A script that summarises tickets. A bot that triages alerts. A pipeline step that classifies inbound documents. Each was fifteen lines of code and a weekend, none went through review, and collectively they process a surprising amount of customer data.

Data team models that became load-bearing. The churn model built as an experiment that now drives retention spend. The pricing model in a notebook that finance relies on. These have real business consequence and usually no documentation, no versioning, and no owner who would describe themselves as the owner.

Embedded ML in the product that predates the AI conversation. Recommendation ranking, fraud scoring, search relevance, spam filtering. Teams frequently exclude these because they think of them as "just algorithms" rather than AI. Auditors do not accept that distinction, and neither does the AI Act.

Copilots on customer data. The coding assistant with repository access. The meeting transcription tool. The browser extension someone installed. These are usage, not development, and ISO 42001 covers organisations that use AI systems.

Fine-tunes and prompt-chained variants. One base model, seven distinct deployed configurations with different guardrails, different data access, and different risk profiles. Registered as one system, they will be sampled as seven.

What a defensible register contains

Per system, the fields that an auditor will actually use:

• Identifier and name — stable, so you can reference it in assessments and evidence
• Purpose — what decision or output it produces, in a sentence
• Owner — a named person, not a team
• Lifecycle stage — development, production, deprecated
• Build vs buy vs use — determines which Annex A third-party controls apply
• Model and provider — including version, and whether you fine-tuned it
• Data categories processed — with personal and special-category data flagged
• Affected parties — who is subject to its outputs, including non-customers
• Autonomy level — advisory, human-in-the-loop, or fully automated
• Risk tier — under your own methodology
• EU AI Act classification — prohibited, high-risk, limited-risk, minimal, or GPAI, with reasoning
• Impact assessment reference — link to the completed assessment
• Evaluation evidence — where the latest test results live
• Last reviewed — date and reviewer

The last field matters more than it looks. A register with no review dates tells an auditor it is a snapshot, not a control.

Finding what the survey misses

Asking teams to self-report gets you maybe 60% of the picture. The rest requires looking:

Search the codebase for model API calls. Grep for the obvious provider endpoints and SDK imports across all repositories, not just the product monolith. Internal tooling repos are where the surprises live.

Pull the SaaS spend list. Every tool in your expense and SSO records, checked against its current feature set. Vendors ship AI features continuously and rarely tell your procurement team.

Review egress to model provider domains. Network or proxy logs pointed at known inference endpoints find the scripts nobody mentioned.

Check your cloud ML services. Managed ML endpoints, notebook instances, batch inference jobs, vector databases. Vector stores in particular indicate a retrieval pipeline that somebody built.

Audit browser extension and SSO grants. OAuth grants to AI tools show individual adoption that never appeared in any budget.

Between these, you get close to complete. It takes a few days.

Keeping it accurate

A register that is accurate once is a document. A register that stays accurate is a control, and only the second one passes a surveillance audit.

What works, in rough order of effectiveness:

1. Make registration a deployment gate. A pipeline check that fails when a service calls an inference endpoint without a registry entry. Unpopular for a week, then simply how things work.
2. Automate discovery on a schedule. The searches above, run monthly as a job, output diffed against the register, differences raised as tickets.
3. Hook procurement and SSO. New SaaS tool or new OAuth grant triggers an AI-feature review question.
4. Put it in the definition of done. New AI feature is not shipped until the register entry, impact assessment, and evaluation evidence exist.
5. Review it quarterly, with a signature. Owner confirms their entries are current. This is the record your auditor samples.

The reason I build this as automation rather than process is that manual registers decay on a predictable curve. They are accurate on the day of the audit and drifting by the following month, and the drift is invisible until the next audit finds it.

Start here

If you are at the very beginning of an ISO 42001 project, build the inventory before you write a single policy. It costs a few days, it determines your scope, your timeline, and your budget, and every policy you write before it exists will be rewritten after it does.

---

We build the AI system inventory — with discovery, not just a survey — as the first deliverable of every AI Governance Gap Assessment.