Practical intelligence for accountable AI programmes.
Build a maintainable AI inventory, rate inherent exposure across four clear dimensions, and route each use to proportionate review as its context changes.
ModelFold Editorial Team10 min read
An AI inventory should be a routing layer for governance work, not a spreadsheet trying to contain every assessment. A customer-support assistant might begin by drafting replies for an employee, then become a materially different use when it can read identity documents, issue refunds and send messages itself. The supplier and model may be unchanged, but the exposure, evidence and approval route are not. A compact, owned record makes those changes visible while deeper assessments remain linked and available when the use warrants them.
The operating rules
The maintainable unit is one AI-enabled use in a defined workflow, purpose, user group and output-to-action path. Create separate records when purpose, affected parties, input sensitivity, action authority, deployment exposure or accountable ownership differs materially. The same language model used to summarise internal meeting notes and to recommend customer-account action therefore belongs in two records. Shared technology is a relationship between records, not a reason to collapse distinct operating contexts.
NIST describes an AI system inventory as an organised resource supporting maintenance, incident response, individual-system queries and portfolio questions. The OECD framework characterises applied systems across people, economic context, data, models, tasks and outputs. Together, those perspectives support a register that can answer both “Who owns this use?” and “Where do we have broad write access?” Link shared vendor, model, application, data, assessment, control, incident and approval records instead of copying them into every use record.
Use a short discovery record that establishes identity, ownership, context and routing, then attach conditional evidence only when exposure or an override calls for it. The NIST Playbook identifies documentation topics including contacts, justification, scope, risks, assumptions, data, dependencies, deployment, monitoring and change management. The UK recording standard covers responsibility, suppliers, decision-process integration, human review, scale, lifecycle, architecture, source data, access, risks, mitigations and assessment information.
Do not turn a control label into assurance. NIST calls for risks and controls to be mapped across system components, including third-party software and data, but a row saying “human review” does not show who reviews, when intervention remains possible or whether review catches meaningful errors. Link validation reports, vendor reviews, test results, incident records, approvals and monitoring plans. Use controlled lifecycle states such as proposed, pilot, production, paused and retired, without imposing one review interval on every use.
Rate inherent exposure across consequence, autonomy, scale and sensitivity, using three concrete levels for each dimension. This is an editorial triage proposal synthesised from broader official characteristics; no cited authority prescribes or endorses this exact rubric. The OECD framework addresses affected stakeholders, deployment breadth, data identifiability and rights, tasks, outputs and action autonomy, while recognising that classification criteria can be interdependent. Each organisation should test the anchors against its work and risk tolerance.
Require one use-specific evidence sentence for each dimension and record an unknown for resolution instead of guessing. Consequence should describe the most credible harm if an output is wrong, unavailable, misused or acted on as intended. Autonomy follows the path from output to action. Scale covers breadth, frequency and connectedness, while sensitivity considers what the use can receive, infer, retrieve, expose or change. These anchors support disciplined discussion; they do not create mathematical certainty.
Set the provisional tier from the highest material dimension: all Level 1 ratings produce provisional Tier 1; any Level 2 with no Level 3 produces Tier 2; and any Level 3 produces Tier 3. Using the highest material dimension instead of an average is an editorial safeguard against obscuring one severe exposure, not a scoring formula validated by NIST or the OECD. Organisations must calibrate the rule to their own risk tolerance and obligations.
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. Rate the actual use before crediting controls. Separating inherent exposure, documented controls and the residual-risk decision is an editorial operating design; the cited sources address risks, controls and evidence but do not prescribe this sequence. Test control design and evidence during review, then record the decision and conditions.
| Internal tier and route | Minimum review | Decision and evidence | Monitoring and reopening |
|---|---|---|---|
| Tier 1 — Registered | Owner confirms the record, approved boundaries, standard controls and operating instructions. | Follow the organisation's standard policy path, retaining 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, vendors, dependencies, tests, fallback and correction routes. | A named accountable owner decides against targeted evidence, residual risk, conditions and a monitoring plan. | Refresh evidence at a defined risk-based interval and reassess when events change exposure. |
| Tier 3 — Enhanced Review | Independent challenge and relevant domain expertise test necessity, alternatives, authority, reversibility, control effectiveness, incidents and exit. | The authority named in organisational policy gives explicit approval, constrains the use or stops it where exposure remains unresolved or intolerable. | Apply closer monitoring and reopen immediately after incidents, control failure or material scope change. |
NIST calls for inventory mechanisms to be resourced according to organisational risk priorities and for ongoing monitoring and periodic review with defined roles and frequencies. Its Playbook discusses standardised risk scales and portfolio risk levels while recognising that risk and tolerance can change through the lifecycle; it does not prescribe these three tiers. An internal tier routes organisational governance work. Qualified owners must determine applicable legal, regulatory, contractual, privacy, security, labour, records and sector requirements separately.
A change in authority, data or reach can move the same underlying service from Tier 2 to Tier 3. 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 alongside downstream use and oversight, with human oversight defined for the use.
The highest rating makes the pilot provisionally Tier 2. Its source links, required pre-send review, blocked write actions, access controls, sampling, complaint route and manual fallback stay in the control record; their presence does not lower inherent exposure. Now allow the assistant to read identity and payment-dispute documents, issue refunds, update account status, send automatically and operate across regions. Consequence, autonomy, scale and sensitivity each become Level 3 under the proposed anchors, sending the changed use to Tier 3 before expansion.
The OECD framework says classifications can change as systems gain data, capabilities, users, maturity or deployment breadth and should be reviewed as relevant conditions evolve. Approval for one defined use does not travel automatically when permissions, data, autonomy or scale change materially. Enhanced review may constrain or stop the expanded proposal; it is not an endorsement of autonomous consequential action. The example and its ratings are fictional applications of the proposed method, not measured outcomes, external validation or an endorsement of the expanded use.
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, risk-based owner attestation and visible work queues. NIST recommends defining who maintains the inventory, which systems it covers and which attributes it contains, while favouring broad organisational coverage. Feed discovery from product and workflow intake, procurement and renewals, application and architecture reviews, access and integration administration, subscriptions, model and data processes, employee disclosure, support cases, incidents and complaints. These feeds widen coverage but do not prove that the inventory is complete.
Use event-driven reopening together with owner attestation at a risk-based interval rather than one universal review cadence. Higher exposure, rapid change, recent incidents or weak evidence may justify closer review. The UK standard records lifecycle phase, maintenance and review frequency, update timestamps and a retired state. Treat dashboard coverage as a discovery indicator, not certainty: a growing register may reflect better detection, wider adoption or both, so investigate movement rather than rewarding a superficially low count.
Retirement is a controlled state, not deletion of an inconvenient row. NIST decommissioning guidance addresses accountability, dependencies, business continuity, migration, regulatory needs and preservation of required artefacts. Retain the ownership, migration, dependency closure, access-removal and other evidence required to show that the use has stopped without inventing a universal retention period. Confirm downstream integrations and permissions have been dealt with, then record who accepted closure and which obligations still govern retained material.
This method is an internal routing proposal, not a compliance determination. South African organisations operating across products, sectors or markets should send applicable legal, compliance, privacy, security, procurement, records, labour and contractual questions to qualified organisational owners. Consequential or high-stakes uses require appropriate domain expertise, effective accountable human review and authority defined in policy before they proceed. The inventory's job is to surface the context and send the use to that work early enough to matter.
Include a stable use ID, business and technical owners, purpose, boundaries, users, affected parties, inputs, outputs, action authority, vendors, dependencies, controls, lifecycle state, ratings, tier rationale, dates and obligations status. Link assessments, tests, approvals and monitoring evidence instead of copying them into the discovery row.
Define three anchored levels for consequence, autonomy, scale and sensitivity, then require evidence for every rating. Set the provisional tier from the highest material dimension, apply explicit escalation overrides and calibrate both anchors and review routes to organisational risk tolerance.
Make the primary governance record one AI-enabled use in its workflow context. Link that record to shared model, vendor, application, data and assurance records so materially different uses remain visible without duplicating common information.
Reopen a record whenever its purpose, data, permissions, users, ownership, dependencies, controls, scale, incidents or obligations change materially. Add owner attestation at a risk-based interval rather than imposing one quarterly or annual cadence on every use.
No. Internal tiers route organisational review; they do not determine legal, regulatory or contractual classification. Qualified legal, compliance, privacy, security, labour, records and sector owners should assess which obligations apply to the specific use and operating context.
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 guide to assigning AI decision rights, balancing central and business-unit authority, and turning pilot evidence into strategy changes.
Bind prompts, models, tools and workflow logic into one testable AI release, then promote and restore the same complete, known-good configuration.
A practical method for defining an AI assistant’s information boundaries, tool permissions, approvals, refusals and accountable escalation paths.
