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 that attempts to contain every assessment. A customer-support assistant may start as a bounded drafting aid, then gain access to identity documents, refund permissions, and automatic sending. The vendor may not change, yet the use clearly has. A compact, owned record makes that shift visible and sends the proposal to a review path proportionate to its exposure.

What belongs in a practical AI inventory?

The practical record unit is one AI-enabled use in a defined workflow, with a stated purpose, user group, affected parties, and output-to-action path. NIST describes an AI inventory as an organized resource that can support maintenance, incident response, individual-system queries, and portfolio questions. The OECD framework likewise examines applied AI across people, economic context, data and inputs, models, tasks, and outputs. Both perspectives point toward context, not a product label alone.

Create separate use records when purpose, affected parties, input sensitivity, action authority, deployment exposure, or accountable ownership differs materially. Link shared vendor, contract, model, data-source, application, assessment, control, incident, and approval records rather than copying them. NIST also calls for documentation of intended purpose, users, deployment settings, possible impacts, assumptions, limitations, and lifecycle context, giving each use record enough context to route deeper work.

• Split the record when the same service supports materially different purposes or affected groups.
• Split it when data sensitivity, permissions, geography, scale, or ownership changes the exposure.
• Link common technical and assurance records so corrections happen once and history remains traceable.

Which fields keep intake useful without making it unmanageable?

Use a compact discovery record that answers ownership and routing questions, then link conditional evidence outside it. The NIST Playbook covers contacts, justification, uses, impacts, data, dependencies, deployment, monitoring, and change management. The UK recording standard covers responsibility, suppliers, decision influence, human review, scale, lifecycle, architecture, source data, access, risks, mitigations, and assessments. A maintainable enterprise row compresses these themes instead of demanding a full assessment at intake.

• Use identity: Stable ID and plain-language name for search, links, and history.
• Ownership: Business and technical owners able to approve, change, pause, or retire the use.
• Purpose and boundaries: Workflow purpose, intended scope, and prohibited or out-of-scope uses.
• People: Intended users and affected parties, recorded as distinct groups.
• Inputs and sensitivity: Data categories, sources, and highest handling classification—not every column.
• Outputs and authority: Recipients, downstream use, and whether the system suggests, initiates, or executes action.
• Technology and dependencies: Linked vendors, models, permissions, integrations, upstream services, and downstream systems.
• Controls and evidence: Current review, access, testing, monitoring, fallback, correction, and appeal controls, with evidence links.
• Lifecycle and dates: Controlled state, last material change, last review, and next risk-based review.
• Ratings and route: Four ratings, provisional tier, overrides, unknowns, and owner rationale.
• Obligations status: Link to separate legal, privacy, security, contractual, labour, records, and sector review.

Keep comprehensive assessments, validation reports, vendor reviews, test results, incidents, approvals, control evidence, and monitoring plans as linked artifacts requested by the route. NIST calls for risks and controls to be mapped across components, including third-party software and data, but a listed control is not proof that it works. Use controlled lifecycle states such as proposed, pilot, production, paused, and retired; avoid imposing one review interval on every use.

How can owners explain inherent exposure consistently?

Rate inherent exposure across consequence, autonomy, scale, and sensitivity, using three anchored levels for each dimension. This is a practical internal proposal synthesized from broader official characteristics, not a method prescribed or endorsed by NIST, the OECD, Canada, or the UK. The OECD framework addresses affected stakeholders, deployment breadth, data, tasks, outputs, and action autonomy. Within its federal scope, Canada's assessment asks about rights, dignity, privacy, health, economic interests, reversibility, personal information, security classification, and mitigations.

• Consequence: Level 1 is localized, readily reversible inconvenience or low-value rework. Level 2 is a material operational, financial, customer, employee, or reputational effect requiring deliberate recovery. Level 3 is a credible effect on rights, important services, 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, personalizes, 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. Level 3 is enterprise-wide, public, cross-market, high-volume, real-time, or deeply integrated use capable of propagating correlated effects.
• Sensitivity: Level 1 uses public, synthetic, or approved non-confidential information without privileged access. Level 2 uses confidential business data, ordinary personal information, customer content, or bounded authenticated access. Level 3 uses highly sensitive or regulated data, credentials, secrets, privileged material, protected characteristics or proxies, precise monitoring data, or consequential write access.

For each rating, require one evidence sentence grounded in the actual use: who could be affected, what the system can do, how broadly it operates, and what information it can reach. Keep unknown facts visible for resolution rather than converting uncertainty into a convenient low rating. Rate the proposed or operating use itself, not a vendor's generic product description or a model's advertised capability.

How should the ratings determine a review path?

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. Each organization must calibrate its anchors, routes, and decision authority against its risk tolerance and applicable obligations.

Apply explicit overrides when the provisional route is inadequate: severe affected-party impact, sensitive data with broad access, ineffective human control, difficult reversibility, cascading dependencies, material incidents, applicable obligations, or unresolved facts should move the use upward. Rate inherent exposure before crediting controls. Review control design and evidence separately, then document the residual-risk decision, conditions, and accountable approval; organizational terminology may differ.

Keep legal, regulatory, contractual, privacy, security, labour, records, and sector classifications in a parallel track. Internal tiers allocate organizational attention; qualified owners must determine which obligations apply. A low internal tier cannot waive a separate requirement, and a higher tier is not a legal conclusion. Consequential or high-stakes uses require appropriate domain expertise, accountable human review, and the approval path established by organizational policy.

What changes when a customer-support assistant expands?

A bounded drafting pilot is provisionally Tier 2 under this method. The fictional assistant retrieves approved help content and drafts a response for a trained employee, who edits and sends it. It cannot make account decisions, grant policy exceptions, send without review, issue credits, change accounts, or access payment and identity documents. The record names ordinary customer and internal account context as its highest-sensitivity input.

Consequence is 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 trained team handles a limited message class; sensitivity is Level 2 because the authenticated workflow uses customer and account context. Source links, required pre-send review, blocked write actions, access controls, sampling, complaints, and manual fallback remain controls, not discounts to inherent exposure.

Now add identity documents, payment-dispute details, refunds, account-status changes, automatic sending, and cross-region operation. Under the proposed anchors, every dimension becomes Level 3: funds and access create severe potential consequences; the system acts without case-by-case approval; deployment is broad and high-volume; and the information and write permissions are highly sensitive. Reopen the record before expansion, route it to Tier 3 and the obligations track, and permit enhanced review to constrain or stop the proposal.

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, backed by owner attestation at a risk-based interval. NIST recommends defining who maintains the inventory, what it covers, and which attributes it contains, while preferring broad organizational coverage. Procurement, architecture, access, subscriptions, employee disclosures, incidents, and complaints can all reveal uses, but checking those feeds never proves the inventory is complete. Assign a named owner to reconcile discoveries and unresolved records.

• Reopen for material changes to purpose, owners, users, affected parties, geography, data, retention, access, outputs, permissions, review, vendors, models, integrations, volume, controls, evidence, incidents, obligations, pause, replacement, or retirement.
• Operate queues for missing owners, unknown ratings, unresolved overrides, overdue reviews, material changes awaiting decisions, missing control evidence, vendor 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 AI-enabled use has been found.

Use closer review where exposure is higher, change is faster, incidents are recent, or evidence is weaker, without declaring one universal quarterly or annual cadence. Retirement remains a controlled state: preserve ownership, migration, dependency, access-removal, and required evidence sufficient to confirm that the use has stopped. NIST decommissioning guidance addresses accountability, dependencies, continuity, migration, regulatory needs, and artifact preservation; specific retention periods still depend on policy and applicable obligations.

During the first 30 days, define the record unit, minimum schema, ownership rule, lifecycle states, and discovery feeds. Pilot the four dimensions on a varied sample, compare reviewer rationales, and calibrate anchors and overrides. Then launch owner attestations, change triggers, stale-record queues, and a small portfolio dashboard. Treat the method as an internal routing proposal, and involve qualified legal, compliance, privacy, security, procurement, records, labour, and sector owners wherever their judgment is required.