Create an AI Inventory and Risk-Tiering Method Teams Can Maintain

An AI inventory should be a routing layer for governance work, not a spreadsheet trying to contain every assessment ever produced. A customer-support assistant may begin as a drafting aid, then become a materially different use when it gains identity documents, refund permissions and authority to send messages. The supplier may be unchanged, but the use, exposure and review route have changed. A maintainable inventory makes that shift visible without forcing every owner to complete a full impact assessment at intake.

What exactly should go into an AI inventory?

Create one record for one AI-enabled use in a defined workflow, purpose, user group and output-to-action path. Split records when purpose, affected parties, input sensitivity, action authority, deployment exposure or accountable ownership differs materially. The same language model used to summarise internal notes and to recommend customer account actions therefore represents two governance records, even if procurement sees one supplier. Link shared model, supplier, application, data-source, assessment, control, incident and approval records instead of copying them. NIST describes inventories as resources for maintenance, incident response and questions at both system and portfolio level; its Core also calls for purpose, users, setting, impacts and lifecycle context to be documented. The OECD similarly characterises applied systems across people, context, data, models, tasks and outputs.

Which fields make the inventory useful without making intake unmanageable?

Use a compact discovery record that captures enough information to assign ownership and route review, then link deeper evidence only when exposure or an override calls for it. NIST documentation topics span contacts, justification, scope, impacts, data, dependencies, monitoring and change, while the UK recording standard includes responsibility, suppliers, decision influence, human review, scale and lifecycle. Compress those themes into purposeful fields rather than inviting essays. A listed control is not evidence that it works: summarise it in the row, then link its design, test results and operating evidence.

• Identity and ownership — Record the use ID, plain-language name, business owner and technical owner to support search, accountability, change and retirement.
• Purpose and boundaries — Record the workflow, intended purpose, allowed uses and excluded uses to define the use being reviewed.
• People — Record intended users and affected parties to show who operates the use and who may experience effects.
• Inputs and sensitivity — Record data categories, sources and the highest handling classification to route data, privacy and security review without listing every field.
• Outputs and authority — Record the output, downstream recipients and whether the use suggests, initiates or executes action to expose the path from output to consequence.
• Technology and dependencies — Record suppliers, models, permissions, integrations, upstream services and downstream systems to make third-party and cascading dependencies visible.
• Controls and evidence — Record human review, access, testing, monitoring, fallback, correction and evidence links to separate control descriptions from proof of effectiveness.
• Lifecycle and dates — Record whether the use is proposed, in pilot, in production, paused or retired, along with its last change, last review and next risk-based review, to create maintenance and stale-record queues.
• Ratings and decisions — Record the four ratings, provisional tier, overrides, rationale, conditions and approval links to make routing explainable and reviewable.
• Obligations status — Link relevant legal, contractual, privacy, security, employment, records and sector review to keep formal obligations separate from the internal tier.

How can teams rate inherent exposure in a way owners can explain?

Rate the use across consequence, autonomy, scale and sensitivity, with one use-specific evidence sentence for each rating and unknowns marked for resolution. This four-dimension rubric is an internal editorial proposal, not a method prescribed or endorsed by NIST, the OECD, Canada or the UK. Those sources cover broader characteristics: the OECD addresses affected stakeholders, deployment breadth, data rights, tasks, outputs and action autonomy, while Canada's federal assessment asks about impacts on people, reversibility, personal information, security classification and mitigations. The four dimensions turn those themes into practical triage anchors.

• Consequence asks what credible harm could occur if an output is wrong, misused, unavailable or acted on as designed. Level 1 means local, readily reversible inconvenience or low-value rework. Level 2 means a material operational, financial, customer, employee or reputational effect needing deliberate recovery. Level 3 means a credible effect on rights, important opportunities or services, health or safety, livelihood, critical operations, or another severe or difficult-to-reverse outcome.
• Autonomy asks how far the system can move towards action before informed intervention. Level 1 produces suggestions 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 asks how broad, frequent and connected the exposure is. 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 asks what information the use can receive, infer, retrieve, expose or change. Level 1 covers public, synthetic or approved non-confidential information without privileged access. Level 2 covers internal or 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 that can change important protected records.

How should the ratings determine the review path?

Set the provisional tier from the highest material dimension: all Level 1 ratings produce Tier 1; any Level 2 and no Level 3 produce Tier 2; any Level 3 produces Tier 3. This non-averaging rule is an editorial safeguard, not a scoring formula validated by NIST or the OECD, and each organisation should calibrate it against its risk tolerance. Escalate for out-of-tolerance activity, severe affected-party impact, sensitive data with broad access, ineffective human control, difficult reversibility, cascading dependencies, material incidents, applicable obligations or unresolved facts. NIST supports risk-prioritised inventory resources and defined ongoing review, but does not prescribe these three routes.

Rate inherent exposure from the actual use before crediting controls. Record controls separately, examine their design and evidence during review, then document the residual-risk decision and conditions; that sequence is also an editorial operating proposal because organisational terminology varies. Keep legal, regulatory, contractual, privacy, security, employment, records and sector classifications on a parallel track. Internal tiers allocate governance work and must not be mapped to legal categories; qualified organisational owners should determine which obligations apply.

What does the method reveal when an AI use changes?

A fictional support-assistant pilot becomes provisionally Tier 2 because context matters more than its model name. It retrieves approved help content and drafts a response for a trained employee, who edits and sends it. Account decisions, policy exceptions, unsupervised sending, payment data, identity documents, credits and account changes remain outside scope. NIST calls for outputs to be considered with their downstream use and oversight, while the OECD notes that classifications may change as systems gain data, capabilities, users or deployment breadth.

• Consequence is Level 2: a wrong response could materially misstate support policy and require deliberate customer remediation.
• Autonomy is Level 1: drafting is the action boundary, and an employee decides what to send.
• Scale is Level 1: one trained team handles a limited message class in a bounded pilot.
• Sensitivity is Level 2: the authenticated use receives ordinary customer and internal account context.

Keep required pre-send review, source links, blocked write actions, access controls, sampling, a complaint path and manual fallback in the control record rather than lowering the inherent ratings. If the proposal expands to reading identity and payment-dispute documents, issuing refunds, updating accounts, sending automatically and operating across regions, every dimension moves to Level 3. Reopen the record before expansion, route the changed use to Tier 3 and the separate obligations track, and test whether enhanced review should constrain or stop it. The earlier approval does not travel with new data, authority and scale.

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

How do you keep the inventory current after launch?

Keep the inventory current through event-driven reopening plus owner attestation at a risk-based interval. Draw discovery signals from product and workflow intake, procurement and renewals, application and architecture reviews, access administration, subscriptions, model and data processes, employee disclosures, incidents and complaints. These feeds improve coverage but do not prove completeness. Reopen a record after a material change to purpose, ownership, users, affected parties, geography, data, retention, access, outputs, permissions, human review, supplier, model, integration, volume, controls, evidence, incidents, obligations, pause, replacement or retirement.

• Operate queues for missing owners, unknown ratings, unresolved overrides, overdue reviews, changed uses awaiting decisions, missing control evidence, supplier changes and incomplete retirement evidence.
• Track 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, not proof that every use has been found.
• Keep retirement as a controlled state with ownership, access removal, migration, dependency closure and required shutdown evidence; do not impose one universal retention period.

1. Days 1–10: define the record unit, minimum fields, ownership rule, lifecycle states and discovery feeds.
2. Days 11–20: test the method on a varied sample, compare rating rationales and calibrate anchors and overrides.
3. Days 21–30: launch owner attestations, material-change triggers, stale-record queues and a small portfolio dashboard.

The result is an operating method, not a compliance determination. Review higher-exposure, fast-changing or weakly evidenced uses more closely without imposing a universal cadence. Ask qualified legal, compliance, privacy, security, procurement, records, employment and sector owners to assess applicable obligations. Consequential or high-stakes uses should not proceed without appropriate domain expertise, accountable human review and the approval authority established in organisational policy.