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 attempting to contain every assessment. A customer-support assistant that only drafts replies is not the same use once it can inspect identity documents, issue refunds, change accounts, and send messages automatically. The product may be unchanged, but the exposure, evidence needs, and approval route have changed. A maintainable inventory makes that difference visible without forcing every owner to complete a full impact assessment at intake.

What belongs in an AI inventory?

Create one record for one AI-enabled use in a defined workflow, purpose, user group, and output-to-action path. NIST describes an inventory as a resource that can support maintenance, incident response, individual-system queries, and portfolio questions. Its Core also calls for documenting purpose, users, deployment settings, possible impacts, assumptions, limitations, and lifecycle context. The OECD framework similarly characterizes applied systems across people, economic context, data, models, tasks, and outputs. Together, those characteristics favor a use-in-context record over a model or vendor label.

• Split records when purpose, affected parties, input sensitivity, action authority, deployment exposure, or accountable ownership differs materially.
• Link shared vendor, model, application, data-source, assessment, control, incident, and approval records instead of copying them.
• Use the inventory to route assessment, monitoring, incident response, change review, and retirement while supporting portfolio questions.

Which fields make the inventory useful without overwhelming owners?

Use a compact discovery record whose fields answer ownership and routing questions, then link conditional evidence when exposure warrants it. The NIST Playbook and UK recording standard identify a much broader documentation universe, while the NIST Core calls for mapping risks and controls across components, including third-party software and data. Compress those topics at intake: name data categories and the highest handling classification, describe downstream authority, summarize current controls without claiming effectiveness, and keep assessments, tests, reviews, incidents, approvals, and monitoring plans as linked artifacts.

• Use ID and plain-language name — Provide stable identity for search, links, and history.
• Business and technical owners — Name accountability and who can change or stop the use.
• Purpose, workflow, and boundaries — Show why the use exists and what remains prohibited or out of scope.
• Users and affected parties — Separate system operators from people or groups influenced by outputs.
• Inputs and sensitivity — Record categories, sources, and the highest handling classification.
• Outputs, downstream use, and authority — Show whether the use suggests, recommends, initiates, or executes action.
• Vendors, models, permissions, and dependencies — Expose providers, access, integrations, upstream services, and downstream systems.
• Current controls and evidence links — Summarize review, access, testing, monitoring, fallback, correction, and appeal.
• Lifecycle state and dates — Record status, last material change, last review, and next risk-based review.
• Ratings, tier, overrides, and rationale — Make routing explainable and expose unknowns or disagreements.
• Applicable-obligations status — Link separate legal, privacy, security, contractual, labor, records, and sector review.

How can owners explain inherent exposure consistently?

Rate inherent exposure with four dimensions: consequence, autonomy, scale, and sensitivity. This is a practical internal proposal synthesized from broader characteristics in official materials; no cited authority prescribes or endorses this exact rubric. The OECD framework considers affected stakeholders, deployment breadth, data characteristics, tasks, outputs, and action autonomy. Canada's federal assessment also illustrates that consequence can encompass rights, dignity, privacy, well-being, economic interests, reversibility, and duration. For every rating, require one use-specific evidence sentence and mark unknown facts for resolution instead of guessing.

• Consequence — Level 1: localized, readily reversible inconvenience or low-value rework. Level 2: a material operational, financial, customer, employee, or reputational effect requiring deliberate recovery. Level 3: a credible effect on rights, important opportunities or services, health or safety, livelihood, critical operations, or another severe or difficult-to-reverse outcome.
• Autonomy — Level 1: suggestions a person chooses whether to use. Level 2: ranking, routing, recommending, personalizing, or bounded action with limited or later review. Level 3: external actions, record or permission changes, resource commitments, or material influence over consequential decisions without effective case-by-case approval.
• Scale — Level 1: a bounded pilot or small internal group with little reuse. Level 2: repeated use across a function, segment, or material workflow with meaningful volume or several consumers. Level 3: enterprise-wide, public, cross-market, high-volume, real-time, or deeply integrated use capable of propagating correlated effects.
• Sensitivity — Level 1: public, synthetic, or approved non-confidential information without privileged access. Level 2: internal or confidential business data, ordinary personal information, customer content, or bounded authenticated access. Level 3: highly sensitive or regulated data, credentials, secrets, privileged material, protected characteristics or proxies, precise monitoring data, or important record-changing access.

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 with no Level 3 produces Tier 2; any Level 3 produces Tier 3. This non-averaging rule and the three routes below are editorial design choices, not formulas validated by NIST or the OECD. Each organization must calibrate them to its risk tolerance and obligations. Rate the actual use before crediting controls, test control design and evidence during review, and document the residual-risk decision and conditions separately.

• Escalate for out-of-tolerance activity or a severe affected-party effect.
• Escalate when sensitive data combines with broad access or ineffective human control.
• Escalate for difficult reversibility, cascading dependencies, or a material incident.
• Escalate when applicable obligations or unresolved material facts require deeper review.

Keep legal, regulatory, contractual, privacy, security, labor, records, and sector obligations on a parallel track. Internal Tier 1–3 labels allocate organizational review; they do not determine whether a use is prohibited, legally high-risk, regulated, or subject to transparency or other duties. Qualified organizational owners must assess applicability independently, and an applicable requirement may impose additional review or prevent a use regardless of its internal tier.

What changes when the AI use expands?

The tier can change even when the vendor and model remain the same because data, users, deployment, capabilities, and downstream authority can change. Consider a fictional pilot that retrieves approved help content and drafts a response for a trained support 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 downstream use and oversight, while the OECD framework supports reassessment as relevant conditions evolve.

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

The highest rating makes the pilot provisionally Tier 2. Its required pre-send review, source links, blocked write actions, access controls, sampling, complaint path, and manual fallback belong in the control record; merely listing them does not lower inherent exposure or prove effectiveness. The assessed review path must examine their evidence, record residual risk and conditions, and run the separate obligations check before an accountable owner decides whether the bounded pilot may proceed.

• Consequence becomes Level 3 when refund and account errors could affect customer funds or account access.
• Autonomy becomes Level 3 when the assistant can issue refunds, change accounts, and send without case-by-case approval.
• Scale becomes Level 3 when the use expands across regions at high volume with multiple downstream effects.
• Sensitivity becomes Level 3 when it gains identity documents, payment-dispute details, and account-write access.

Reopen the record before that expansion and route the changed proposal to Tier 3 plus the parallel obligations track. The original approval does not travel with broader data, permissions, autonomy, and scale. Enhanced review must be able to constrain or stop the proposal, not merely endorse it. These ratings illustrate the article's method; they are not measured outcomes, external validation, or a conclusion that autonomous consequential action should be approved.

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. NIST recommends defining who maintains the inventory, what it covers, and which attributes it contains, while favoring broad organizational coverage. Discovery feeds improve visibility but never prove completeness. The OECD supports reassessment as relevant system conditions change, and the UK standard records lifecycle phase, review frequency, update timestamps, and retirement. Higher exposure, rapid change, recent incidents, or weak evidence may justify closer review; there is no universal schedule.

• Discover uses through product and workflow intake, procurement and renewals, architecture and application review, and access or integration administration.
• Add subscription review, model and data processes, employee disclosure, owner attestations, support cases, incidents, and complaints.

• Reopen for material changes to purpose, ownership, users, affected parties, geography, data, retention, or access.
• Reopen for changes to outputs, permissions, human review, vendors, models, integrations, volume, or dependencies.
• Reopen after control or evidence changes, incidents, new obligations, pauses, replacements, or retirement decisions.

• Operate queues for missing owners, unknown ratings, unresolved overrides, overdue reviews, and pending change decisions.
• Also queue missing control evidence, vendor changes, and incomplete pause or retirement evidence.
• Track records and affected parties by tier and lifecycle, missing fields, overdue decisions, open gaps, routing time, and retirement closure.

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

Treat retirement as a controlled state until ownership, migration, dependencies, access removal, and required shutdown evidence are addressed. NIST decommissioning guidance covers accountability, continuity, migration, dependencies, regulatory needs, and preservation of needed artifacts, but it does not set one retention period. This method remains an internal routing proposal, not a compliance determination. Qualified legal, compliance, privacy, security, procurement, records, labor, and sector owners should assess obligations, while appropriate domain expertise and accountable human review remain necessary before consequential uses proceed.