The easiest AI-use register to create is a spreadsheet. The harder part is keeping it connected to what people actually do.
A central team can list the tools it purchased and the projects it knows about. Employees may still use approved AI for new tasks every week, test browser tools through personal accounts, or change the information entering an existing workflow. The register becomes stale because updating it is a separate administrative job.
While building Can I Use AI?, I ended up treating the register as an output of the request process. Someone proposes a use, the current policy answers or routes it, and the completed case becomes a register entry. The person gets help with the immediate question, and the company gets structured visibility from the same action.
Decide what the register is tracking
An AI tool inventory and an AI-use register answer different questions.
The tool inventory describes products and systems: vendor, owner, contract, hosting, integrations, approved account types, and assessment status.
The use register describes how the organisation uses those tools: task, team, information, affected people, intended impact, safeguards, approval, owner, status, and governing policy version.
One approved tool can support many uses. A writing assistant might help marketing draft public copy, help support summarise customer cases, and help HR prepare interview questions. Those entries should remain separate because the data, impact, and review differ.
Create entries from work people already need to do
Do not ask employees to maintain a register for the benefit of a future audit. Ask them to submit a short request because they need a company answer before using AI.
The request should capture the decision-relevant facts. Once it reaches a usable outcome, the system can create the register entry automatically. If a reviewer adds conditions, those conditions remain attached to the same use.
This reduces duplicate work and improves the data. The person closest to the proposed use provides the facts, while the policy and reviewer add the governance context.
Store enough to understand the use
A useful entry normally includes:
- a stable reference;
- the proposed task and business owner;
- the AI tool and account type;
- the highest information sensitivity involved;
- the purpose and intended impact;
- the human review expected;
- the applicable region or coverage question;
- the policy result and safeguards;
- any reviewer decision and rationale;
- the current status;
- the policy version and dates.
The register does not need full prompts, generated outputs, customer files, or copies of every supporting document. Store concise classifications and references. The AI-use approval record guide explains that boundary in more detail.
Use statuses that describe the real lifecycle
A binary approved/rejected column cannot explain what is happening.
Useful statuses include:
- approved by policy;
- approved with conditions;
- waiting for review;
- information requested;
- rejected by a reviewer;
- stopped by policy;
- policy review required;
- withdrawn;
- expired.
Keep the original decision in the history when the current status changes. A use approved in June and flagged for review in August has two relevant events. Replacing the first with the second makes the timeline harder to explain.
Give every active use an owner
The owner is responsible for the business use after the first approval. They should know the conditions, make sure human review occurs, and submit a new request when the use changes.
Ownership should be attached to a role or person who can act. A department name may help with filtering, but “Marketing” cannot answer a review question or stop a workflow by itself.
Connect policy changes to the register
This is where a living register becomes more useful than a static inventory.
When the company publishes a new policy version, compare the changed rules with the rules that affected earlier decisions. Uses touched by the change can move to policy review. Unrelated uses can keep their current status.
The earlier record remains fixed. The register shows that it was valid under one version and needs reassessment under another.
Our guide to AI policy changes and existing approvals covers that process.
Keep access proportionate
Employees should normally see their own requests and decisions. Reviewers need the cases routed to their role. Policy owners may need the full register and aggregate patterns.
Some requests can reveal confidential projects, health information, employee matters, or legal issues even when full prompts are excluded. Role-based access, retention, export, and deletion rules belong in the design from the beginning.
Use the register to improve the policy
The useful questions are operational:
- Which tools are repeatedly unknown?
- Which information categories cause confusion?
- Where do requests wait longest?
- Which safeguards appear most often?
- Which policy changes trigger the most reviews?
- Which recurring safe uses could the policy resolve directly?
Those answers improve the policy. Counting how many requests one employee submitted usually does not.
The smallest workable version
Start with one request form, a small set of outcomes, named approval routes, a versioned policy, and a register built from completed cases. Add vendor assessments, integrations, and deeper reporting when the volume justifies them.
Can I Use AI? combines the employee request, published policy, approval workflow, decision history, and living AI-use register. Each entry remains connected to the exact policy version that produced its original result.
This article provides general operational guidance. Register scope, access, retention, and review duties should reflect the organisation’s actual risks and obligations.