Practical intelligence for accountable AI programmes.
Build a maintainable AI inventory, rate each use across four clear dimensions and route it to proportionate review without implying legal classification.
ModelFold Editorial Team9 min read
A maintainable AI inventory is a routing layer for governance work, not a spreadsheet expected to hold every assessment. Consider a customer-support assistant that first drafts replies, then gains access to identity documents, refund authority and automatic sending. The supplier may be unchanged, but the use is not. A compact, owned record should expose that change, reassess the exposure and send the proposal to the appropriate review path before the wider capability goes live.
The operating rules
The basic unit should be one AI-enabled use in a defined workflow, with a clear purpose, user group and path from output to action. NIST treats an inventory as a resource for maintenance, incident response and questions about individual systems or the wider portfolio. The OECD framework likewise examines applied AI across people, context, data, models, tasks and outputs. Together, those perspectives favour a contextual use record over a bare product name.
Split the record when the purpose, affected parties, input sensitivity, action authority, deployment exposure or accountable owner differs materially. A shared language model might therefore support separate records for internal drafting, customer correspondence and account changes. Link the common supplier, model, data source, application, test, control, incident and approval records instead of copying them. NIST also identifies purpose, users, deployment setting, possible impacts, assumptions, limitations and lifecycle context as relevant documentation.
The useful minimum is a short discovery record that establishes identity, ownership, context, exposure and routing. The NIST Playbook and the UK recording standard cover broader documentation spanning contacts, purpose, suppliers, decision influence, data, dependencies, human review, scale, lifecycle, risks and mitigations. Compress those topics into routing fields, then link assessments, validation reports, supplier reviews, tests, incidents, approvals and control evidence only when needed.
Record what is known without mistaking a populated field for assurance. For example, note the highest data classification rather than reproducing a data dictionary, and describe downstream authority rather than simply naming an output. NIST calls for risks and controls to be mapped across components, including third-party software and data. A listed control is still only a claim until reviewers examine its design, operation and supporting evidence.
Rate the actual use across consequence, autonomy, scale and sensitivity, using three anchored levels for each dimension. This four-part rubric is an internal editorial proposal, not a method prescribed or endorsed by NIST, the OECD, Canada or the UK. It synthesises broader characteristics found in those materials, including affected stakeholders, deployment breadth, data rights and identifiability, reversibility, tasks, outputs, action autonomy and mitigation context.
Require one evidence sentence for every rating: name the affected party, action boundary, deployment reach or information class that justifies the level. Record an unknown for resolution rather than choosing a reassuring answer. The Canadian federal assessment illustrates why traceability matters by asking separately about rights, dignity, privacy, well-being, economic interests, reversibility, personal information, security classification and mitigations, although its scope and impact levels are not this enterprise rubric.
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 formula validated by NIST or the OECD. Each organisation must calibrate the anchors, routes and decision rights against its own risk tolerance and obligations.
| Internal tier and route | Minimum review | Decision and evidence | Monitoring and reopening |
|---|---|---|---|
| Tier 1 — Registered | Owner confirms the record, approved boundaries, standard access and use controls, output checking and operating instructions. | Approval follows the organisation's standard policy path, supported by the rationale and control attestation. | Use risk-based owner attestation and reopen on material change. |
| Tier 2 — Assessed | Cross-functional reviewers examine affected parties, data, oversight, suppliers, dependencies, testing, fallback, correction routes and control evidence. | A named owner records residual risk, conditions and required evidence after the relevant specialist reviews. | Define measures and issue routes, refresh evidence proportionately and reassess on relevant events. |
| Tier 3 — Enhanced review | Independent challenge and appropriate domain expertise test necessity, alternatives, authority, reversibility, controls, incident readiness and exit. | The authority named in organisational policy explicitly approves, constrains or stops the use; unresolved exposure is not waved through. | Apply closer monitoring matched to exposure and reopen immediately after incidents, control failure or material scope change. |
Keep applicable legal, regulatory, contractual, privacy, security, employment, records and sector obligations in a parallel track. Internal Tier 1–3 labels organise work; they do not determine whether a use falls within any legal category. Qualified organisational owners should assess applicability separately. This boundary matters in Ireland, where an internal portfolio label cannot replace a use-specific examination of relevant EU, national, contractual or sector requirements.
A changed use requires a fresh route even when its supplier and model remain the same. Take 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, unsupervised sending, payment data, identity documents, credits and account changes remain outside scope. NIST's framework supports examining outputs alongside downstream use and defined human oversight.
The highest rating makes the pilot provisionally Tier 2. Required pre-send review, source links, blocked write actions, access controls, sampling, a complaint route and manual fallback stay in the control record; their presence does not lower inherent exposure. If the proposal expands to identity documents, payment-dispute details, refunds, account updates, automatic sending and cross-region operation, all four dimensions become Level 3. Reopen the record before expansion and route it to Tier 3 and the separate obligations track.
The inventory earns trust when a change in data, authority or scale changes the route, not merely the row.
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 the OECD supports reassessment as data, capabilities, users, maturity or deployment breadth change. Higher exposure, faster change, recent incidents or weak evidence may justify closer review, but there is no sound universal quarterly or annual cadence.
Operate queues for missing owners, unknown ratings, unresolved overrides, overdue reviews, changes awaiting decisions, absent control evidence, supplier changes and incomplete retirement evidence. A small portfolio dashboard can show records and affected parties by tier and lifecycle, missing fields, overdue decisions, open exceptions, control gaps, routing time and retirement closure. Coverage measures indicate where discovery is weak; they cannot certify that every use has been found.
Treat retirement as a controlled state rather than deleting the row. Preserve enough ownership, migration, dependency, access-removal and required evidence to confirm that the use has stopped, without inventing a universal retention period. The method remains an internal routing proposal, not a compliance determination. Consequential or high-stakes uses require appropriate domain expertise, accountable human review and assessment by qualified legal, compliance, privacy, security, procurement, records, employment and sector owners before proceeding.
Include a stable use ID, business and technical owners, purpose and boundaries, users, affected parties, inputs, outputs, action authority, suppliers, dependencies, controls, lifecycle dates, ratings, overrides and applicable-obligations status. Keep the discovery row concise and link assessments, tests, approvals, incidents and control evidence instead of copying them into it.
Define clear Level 1–3 anchors for consequence, autonomy, scale and sensitivity, then require a use-specific evidence sentence for each rating. This article proposes taking the highest material level as the provisional tier, applying explicit upward overrides and calibrating the routes to the organisation's risk tolerance.
Use one primary record for each AI-enabled use in its workflow and action context. Link shared model, supplier, application, data and assurance records so common information is maintained once without hiding material differences between uses.
Reopen a record whenever a material change affects its purpose, ownership, data, permissions, oversight, dependencies, scale, controls, incidents or obligations. Add owner attestation at a risk-based interval; do not apply one universal schedule to every tier.
No. An internal tier routes organisational review and cannot determine a legal or regulatory classification. Qualified legal, compliance, privacy, security, employment, records and sector owners should assess applicable requirements through a separate track.
This article was researched using the following sources:
We report on how AI actually lands inside a business. Our work starts from named sources, separates what we found from what we think, and uses AI assistance for research and drafting under documented editorial controls. We are not a substitute for individual expert review.
A practical method for assigning AI decision rights, choosing mixed operating structures and turning pilot evidence into strategy changes.
A practical method for binding prompts, models, tools and workflow logic into one testable AI release, with staged promotion and complete rollback.
A practical method for setting capability-level context, tool permissions, action limits, approvals, refusals and release evidence for business AI assistants.
