How to Build an AI Inventory and Risk-Tiering Method Teams Can Maintain

An AI inventory should be a routing layer for governance work, not a spreadsheet attempting to contain every assessment. A customer-support assistant may start as a drafting aid, then gain access to identity documents, refunds and automatic sending. Although its vendor remains unchanged, its exposure and review route have changed sharply. A maintainable inventory captures that use in context, assigns an owner and links to deeper evidence only when the route requires it.

What exactly should an AI inventory record?

Record one AI-enabled use in a defined workflow, with a clear purpose, user group and path from output to action. NIST describes an inventory as an organised resource that can support maintenance, incident response, individual-system queries and portfolio questions. The OECD framework likewise characterises applied systems across people, context, data, models, tasks and outputs. Those perspectives make the use, rather than a product name, the practical governance unit.

Split the record when purpose, affected parties, input sensitivity, action authority, deployment exposure or accountable ownership differs materially. Two teams using the same model may therefore need different records. Link shared vendor, contract, model, data-source, application, assessment, incident and approval records instead of copying them. NIST also calls for intended purpose, users, deployment settings, impacts, assumptions, limitations and lifecycle context to be documented.

• Answer record-level questions: who owns this use, what may it do and what decision is pending?
• Answer portfolio questions: where are the highest exposures, missing owners, stale reviews and unresolved changes?
• Route deeper assessment, monitoring, incident response and retirement work without turning discovery into a full assurance exercise.

Which fields keep the inventory useful without overwhelming owners?

Use a compact discovery record, followed by conditional links to fuller evidence. The NIST Playbook covers contacts, business justification, scope, uses, impacts, data, dependencies, deployment, monitoring and change. The UK Algorithmic Transparency Recording Standard covers similarly practical information, including responsibility, suppliers, decision influence, human review, scale, lifecycle, architecture and mitigations. The table compresses those broader materials into routing fields for an enterprise inventory.

• Use ID, name, business owner and technical owner: Provides stable identity and names who can approve, change or stop the use.
• Purpose, workflow, boundaries, users and affected parties: Shows where the use operates, what is excluded and who may experience its effects.
• Inputs and sensitivity: Records data categories, sources and highest handling classification rather than every column.
• Outputs, downstream use and action authority: Shows whether the system drafts, recommends, initiates or executes action.
• Vendors, models, permissions, integrations and dependencies: Exposes linked services, access and downstream reliance without duplicating shared records.
• Controls and evidence links: Summarises review, access, testing, monitoring, fallback, correction and appeal arrangements.
• Lifecycle, changes and review dates: Supports controlled states, history and the next risk-based review.
• Ratings, tier, overrides, rationale and obligations status: Makes routing explainable while keeping applicable-obligations work separate.

A control listed in the record is not necessarily effective. Summarise the current arrangement, then link its test results, validation, vendor review, impact assessment, monitoring plan, incident history and approval evidence where required. NIST calls for risks and controls to be mapped across components, including third-party software and data. This linked structure lets reviewers inspect the evidence without forcing every owner to maintain an unwieldy questionnaire.

How can owners explain inherent exposure consistently?

Rate consequence, autonomy, scale and sensitivity, giving each dimension one of three anchored levels and one use-specific evidence sentence. This is a practical internal proposal synthesised from broader official characteristics; no cited framework prescribes or endorses this exact rubric. The OECD framework considers affected stakeholders, deployment breadth, data characteristics, tasks, outputs and action autonomy, but organisations must calibrate the anchors to their own risk tolerance and operating context.

• Consequence: Level 1 means local, readily reversible inconvenience or low-value rework. Level 2 means a material operational, financial, customer, employee or reputational effect requiring deliberate recovery. Level 3 means a credible effect on rights, important services or opportunities, health or safety, livelihood, critical operations, or another severe or difficult-to-reverse outcome.
• Autonomy: Level 1 produces suggestions that a person chooses whether to use. Level 2 ranks, routes, recommends, personalises or initiates bounded action with limited or later review. Level 3 executes external actions, changes records or permissions, commits resources, or materially influences consequential decisions without effective case-by-case approval.
• Scale: Level 1 is a bounded pilot or small internal group with little downstream reuse. Level 2 is repeated use across a function, segment or material workflow with meaningful volume or several consumers. Level 3 is enterprise-wide, public, cross-market, high-volume, real-time or deeply integrated use capable of propagating correlated effects.
• Sensitivity: Level 1 covers public, synthetic or approved non-confidential information without privileged access. Level 2 covers confidential business data, ordinary personal information, customer content or bounded authenticated access. Level 3 covers highly sensitive or regulated data, credentials, secrets, privileged material, protected characteristics or proxies, precise monitoring data, or access able to change important protected records.

Rate the actual proposed or operating use, not the supplier's generic product. For each level, write a short sentence naming the relevant workflow fact: who may be affected, what the system can do, how broadly it runs or what it can access. Mark an unknown for resolution instead of guessing. This preserves disagreement and gives the next reviewer something concrete to test.

How should the ratings determine the review route?

Set the provisional tier from the highest material dimension: all Level 1 ratings produce Tier 1; any Level 2 with no Level 3 produces Tier 2; and any Level 3 produces Tier 3. This non-averaging rule is an editorial safeguard, not a formula validated by NIST or the OECD. It prevents one severe exposure from disappearing inside an attractive total and should be calibrated against the organisation's risk tolerance.

Move a use upwards when an explicit override identifies out-of-tolerance activity, severe affected-party impact, sensitive data with broad access, ineffective human control, difficult reversibility, cascading dependencies, a material incident, an applicable obligation or unresolved facts. Rate inherent exposure before giving controls credit. Reviewers can then examine control design and evidence, record residual risk, impose conditions or decline the use.

Keep legal, regulatory, contractual, privacy, security, employment, records and sector questions on a parallel track owned by appropriately qualified people. Internal tiers organise governance effort; they are not compliance determinations and should not be mapped to legal categories. The applicable-obligations field should show whether that separate work is pending, complete or needs reopening, without pretending the inventory itself settles the answer.

What changes when a support assistant gains more authority?

The route changes because approval belongs to a defined use, not permanently to its vendor or model. Consider a fictional pilot that retrieves approved help content and drafts a reply for a trained support employee, who edits and sends it. Account decisions, policy exceptions, automatic sending, identity documents, payment data, credits and account changes are outside the approved boundary.

Rate consequence Level 2 because an incorrect reply could materially misstate support policy and require deliberate customer remediation. Autonomy is Level 1 because drafting is the action boundary; scale is Level 1 because one team handles a limited message class; and sensitivity is Level 2 because ordinary customer and internal account context enters an authenticated system. The highest rating makes the pilot provisionally Tier 2.

Now propose access to identity documents and payment-dispute details, permission to issue refunds and update account status, automatic sending and operation across regions. Each dimension becomes Level 3: customer funds and access raise potential consequences; actions execute without case-by-case approval; deployment becomes broad and high-volume; and the data plus write access are highly sensitive. Reopen the record before expansion and route the changed use to Tier 3 and the separate obligations track.

The original record may list source links, required pre-send review, blocked write actions, access controls, sampling, a complaint route and manual fallback. Their presence does not lower inherent exposure; reviewers need evidence that the controls work as intended. Enhanced review may constrain or stop the expansion rather than endorse autonomous consequential action. The example illustrates the proposed method and claims no measured result or external validation.

The inventory earns trust when a change in data, authority or scale changes the route—not merely the row.

How do teams keep the inventory current after launch?

Keep the inventory current through event-driven reopening plus owner attestation at a risk-based interval. NIST recommends defining who maintains the inventory, which systems it covers and which attributes it contains, while preferring broad organisational coverage. Discovery feeds can include procurement, renewals, architecture, access administration, subscriptions, employee disclosures, support cases, incidents and complaints. These signals improve coverage; they never prove that every use has been found.

• Reopen for material changes to purpose, ownership, users, affected parties, geography, data, retention, access, outputs, permissions, human review, vendor, model, integration, volume, controls, incidents or obligations.
• Operate queues for missing owners, unknown ratings, unresolved overrides, overdue reviews, pending changes, missing control evidence, vendor changes and incomplete retirement evidence.
• Use closer review where exposure is higher, change is faster, incidents are recent or evidence is weaker; do not impose one universal quarterly or annual cycle.

Keep the portfolio dashboard small enough to provoke action. Useful views include records and affected parties by tier and lifecycle, missing fields, overdue decisions, open exceptions, control gaps, routing time and retirement closure. Treat coverage measures as discovery indicators rather than declarations of completeness. The OECD framework supports reassessment as data, capabilities, users, maturity, deployment breadth or surrounding conditions change.

Retirement is a controlled lifecycle state, not deletion of an inconvenient row. The UK standard includes lifecycle and update information, including a retired state, while NIST decommissioning guidance covers accountability, dependencies, continuity, migration and preservation of needed artefacts. Retain the ownership, access-removal, migration, dependency and other required evidence needed to confirm shutdown, using retention rules set by qualified organisational owners.

1. Days 1–10: define the use-level record, compact schema, ownership rule, lifecycle states and discovery feeds.
2. Days 11–20: pilot the rubric on a varied sample, compare evidence sentences and calibrate anchors, overrides and routes.
3. Days 21–30: launch owner attestations, change triggers, stale-record queues and a small portfolio dashboard.

The first month should establish a workable routing loop, not manufacture a compliance claim. Ask qualified legal, compliance, privacy, security, procurement, records, employment and sector owners to assess applicable obligations. Before consequential or high-stakes uses proceed, require suitable domain expertise, accountable human review and the approval authority defined in organisational policy. The inventory's job is to reveal what needs that attention and when the facts have changed.