Build and maintain an AI use-case register

Purpose and fit

Use this when leaders cannot reliably answer where AI supports work or which uses need attention. Create one record per bounded use case, not just one per vendor: summarising internal meetings and drafting customer replies may need different owners and controls even when they use the same tool. A register improves visibility; an entry alone does not authorise the use.

Before you start

Start with the authorised workflow descriptions, pilot notes or inventory entries you already have; a complete company-wide dataset is not required. Remove confidential details not needed for the register and retain source dates or references where available.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

• The teams, systems and period covered by the initial discovery exercise.
• Existing application lists, procurement records, approved pilots and workflow descriptions that you are authorised to inspect.
• Business and system owner contacts, current approval categories and any existing incident or change records.
• An access-controlled register location, a coordinator and agreed update responsibilities.

Practical workflow

1. Define the unit of record and assign stable use-case IDs. Record a separate product/account reference so multiple uses of the same service can be linked without collapsing their different purposes.
2. Gather candidate uses from authorised records and team conversations. Include pilots, embedded features and connected agents where known. Document sources and discovery gaps rather than claiming the inventory is complete.
3. Ask the business owner to confirm each purpose, affected users, workflow stage and output destination. Describe data categories and systems without placing sensitive records, secrets or example customer content in the register.
4. Record the actual approval status and its evidence separately from activity status. For example, a use may be active with approval unverified. Treat missing evidence as unresolved and route it through the organisation's existing process.
5. Review entries for missing owners, changed scope, overdue reviews and unexplained external actions. Prioritise follow-up by the possible consequences and unresolved requirements, without turning missing paperwork into an unsupported conclusion about legality or safety.
6. Assign update triggers: introduction, material configuration or purpose change, ownership transfer and retirement. Schedule a proportionate owner check, record the last confirmation date and retain a clearly marked history for retired uses under existing retention rules.

Expected output

Expect a draft register of the supplied use cases, a missing-information follow-up list and an explicit coverage note, not automatic discovery of every AI tool or evidence of approval.

A use-case register, a discovery coverage note and an unresolved-items view. Copy these fields:

Use-case ID: [ ]. Name/purpose: [ ]. Business owner: [ ]. System owner: [ ]. Team/workflow: [ ]. Product/account reference: [ ]. AI role: [ ]. Input data categories: [ ]. Connected systems: [ ]. Output recipients: [ ]. Human review point: [ ]. Activity status: [proposed/pilot/active/paused/retired]. Approval status/evidence: [ ]. Known conditions: [ ]. Last owner confirmation: [ ]. Review trigger/date: [ ]. Related change/incident references: [ ].

Follow-up fields: Missing information: [ ]. Possible consequence: [ ]. Responsible owner: [ ]. Next action: [ ]. Due date: [ ]. Resolution evidence: [ ]. Coverage note: [teams/sources checked and known exclusions].

Keep status labels defined. “Registered” means recorded; “approved” requires the applicable approval evidence and scope.

Human checks

Each business owner confirms the accuracy of their entry. System owners validate product and connection details. The coordinator reconciles duplicates and checks whether ownership changes were accepted. Restrict detailed infrastructure and access information to appropriate readers; create a reduced leadership view if wider visibility is needed.

Limitations

Self-reporting and procurement records may miss embedded or informal uses. A register is not a real-time control, risk assessment or compliance certificate. Update frequency should reflect change and consequences; a recently checked entry can still become outdated.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.