Inventory: The System of Record for AI Use

You cannot govern what you cannot enumerate, and in most large enterprises the enumeration is wrong in a specific, predictable direction. Ask for the AI inventory and you are usually handed a list of models the data science function built. Ask instead what AI the firm actually uses, and the answer is several times larger, because most AI now enters an enterprise through procurement rather than through engineering.

A typical audit finding runs like this. The HR platform gained a candidate ranking feature in a routine release. The customer relationship system gained lead scoring and automatic call summarisation. The email and document suite gained drafting and summarisation with access to the entire mailbox and file store. None of these were built in house, none appear in the inventory, and all of them process personal data and shape consequential judgements about people. The firm did not decide to deploy them; it accepted a set of release notes.

What the record has to carry

The test for including a field is simple: does an obligation, a monitoring decision or an accountability question depend on it? Fields that pass that test drive real work. Fields that merely look technical inflate the record and make it harder to keep current.

• Purpose and affected population. What the system is for, and who is on the receiving end of its outputs. This single pair drives tiering, transparency duties and most legal analysis.
• Model and version in use, with vendor dependency. Which model, which version or alias, self-hosted or hosted, and which supplier stands behind it. Without this you cannot tie an evaluation result to what is actually running.
• Assigned risk tier and named accountable owner. A tier with no owner is a label; an owner with no tier has no calibrated duty. Both are needed, and the owner should be a person, not a team mailbox.
• Data categories processed, including whether personal or special category data is involved, and the retention position.
• Lifecycle status and environment: piloted, in production, deprecated, and in which business units or jurisdictions.
• The human oversight arrangement, and whether the system is advisory, decisive or capable of acting autonomously.
• Dates of last evaluation and next scheduled review, plus links to the risk assessment, approval record and system documentation.

id: AI-0142
name: Candidate ranking in the recruiting platform
purpose: Ranks applicants for shortlisting by recruiters
affected_population: External job applicants, all regions
decision_role: advisory        # advisory | decisive | autonomous
model:
  source: vendor_embedded      # in_house | hosted_api | vendor_embedded
  vendor: recruiting platform supplier
  version_or_alias: ranking-service v4 (supplier release train)
  change_notice: 30 days contractual, alias pinning not offered
data:
  categories: [name, work history, education, self-declared skills]
  personal_data: yes
  special_category: no
  retention: 24 months in supplier tenant
risk_tier: 2                   # 1 highest
owner: Head of Talent Acquisition (named individual)
oversight: Recruiter reviews full application before any rejection
evidence:
  risk_assessment: RA-2210 (approved, 3 residual risks accepted)
  last_evaluation: bias and stability battery, run against v4
  next_review: due within tier 2 period
status: production

Discovery: how you actually find it

Self-declaration alone will not populate the inventory, because business owners frequently do not know that a feature they use is AI. Effective programmes triangulate. Procurement and contract review surfaces both new purchases and, more importantly, renewals where AI features appeared mid-term without a new contract. Vendor release notes and administrative console feature flags reveal what has been switched on by default. Network egress and DNS records show traffic to model endpoints, including self-serve use nobody approved. Expense and corporate card data finds individual subscriptions. Dependency and code scanning finds model client libraries in internal repositories. Structured attestation from business owners then confirms and assigns accountability rather than performing discovery on its own.

1. Start with the moneyPull procurement, contract and expense data, including renewals. Renewals are where AI features most often appeared mid-term without any new purchase decision being taken.
2. Read the release notesReview vendor release notes and administrative console feature flags for the major platforms already in use. Features switched on by default are the single largest source of shadow AI.
3. Look at the networkExamine egress and DNS records for traffic to model endpoints. This finds self-serve use that never touched procurement at all.
4. Scan the codeSearch internal repositories and dependency manifests for model client libraries and direct API calls.
5. Then askOnly now issue structured attestation requests to business owners. Attestation confirms findings and assigns accountability; used as the first step it mostly discovers what people already knew they ought to declare.
6. Wire it inMake registration a precondition in procurement and in the deployment pipeline, so that the next sweep is smaller than this one rather than the same size.

The final distinction is between an inventory and a system of record. A spreadsheet refreshed once a year is a snapshot that is wrong by the time it is circulated. A system of record is wired into the processes that create the risk: procurement cannot complete without registration, the deployment pipeline refuses to promote an unregistered system, and a change to model version, purpose or affected population updates the record as a side effect of the change itself. Governance downstream of the inventory only works if the inventory is a by-product of normal operations rather than a separate act of goodwill.