What Should an AI Usage Register Include?

A practical guide to making AI use visible

An AI usage register is a central record of where, why, and how artificial intelligence is being used across an organisation.

It should record the AI tool, use case, business owner, data involved, risk level, approval status, review date, and business justification.

But for AI governance, the most important point is this:

An AI usage register should not be just a list of AI tools. It should be a register of AI use cases.

That distinction matters.

Knowing that an organisation uses ChatGPT, Microsoft Copilot, Claude, Gemini, or an AI feature inside another product is useful, but it is not enough. The same AI tool may be used for low-risk brainstorming, internal drafting, customer emails, confidential data analysis, legal drafting, code generation, hiring support, financial modelling, or board reporting.

Those uses do not carry the same risk.

A tool-based register tells the organisation what AI systems may be present.

A use-case register tells the organisation where AI is actually influencing work, data, decisions, customers, and accountability.

That is why an AI usage register is one of the most practical foundations of AI governance.

You cannot govern AI use you cannot see.

Why an AI usage register matters

AI governance often starts with policy. The policy sets the rules: what is allowed, what is prohibited, what requires approval, and how AI should be used responsibly.

But a policy is not enough.

An organisation also needs visibility into how AI is actually being used.

Without a usage register, AI governance depends on assumptions. Leaders may believe AI is only being used for harmless drafting, while employees are also using it for client work, customer communications, code, financial analysis, HR documents, or confidential business material.

That is the problem an AI usage register solves.

It helps the organisation answer:

What AI tools are being used?

What are they being used for?

Who owns each use case?

What data is involved?

Is the output internal, customer-facing, or decision-influencing?

What risks are created?

Has the use been approved?

What controls apply?

When should the use be reviewed?

What evidence supports the decision?

In practical terms, the register turns AI governance from an abstract policy into an operational record.

AI changes the old system-inventory model

Traditional technology governance often starts with a system inventory.

That made sense when important systems were visible, procured, permissioned, owned, and changed through formal processes. A business bought a system, IT configured it, access was managed, users were trained, and changes were reviewed.

AI weakens those assumptions.

AI can enter through a browser, private phone, personal account, plugin, productivity tool, code assistant, or embedded vendor feature. It can move across functions and change use cases without a new system being purchased.

This is a foundational shift for governance, risk, compliance, security, and IT.

AI is not just another system in the technology estate. It is a cross-business capability that can assist with writing, research, analysis, coding, customer communication, planning, reporting, and decision support.

That means governance must become more adaptive.

This is not a call for less discipline. It is a call for faster learning. In software, agile methods emerged because long planning cycles struggled with rapid change and uncertainty. AI governance faces a similar pressure. It needs tighter feedback loops, shorter review cycles, clearer ownership, and structured records that show what has changed and what is affected.

For AI, the register cannot be a static inventory. It must become part of a living governance loop:

Use case → Owner → Data → Risk → Approval → Evidence → Review → Outcome → Learning

Why the use case is the real unit of governance

For AI, the tool name is only the starting point.

The use case determines the real governance question.

For example, the same AI tool may be used to:

generate blog ideas;

draft internal meeting notes;

write customer emails;

summarise confidential client material;

generate software code;

draft contract clauses;

screen job applications;

analyse sales data;

prepare board reporting;

support customer advice.

Each of these uses has a different risk profile.

The risk changes depending on the data used, the output produced, the audience, the level of human review, and the decision being influenced.

A brainstorming use case may be low risk.

A customer-facing advice use case may be higher risk.

A use case involving personal information, confidential client data, legal terms, financial analysis, employment decisions, security-sensitive code, or regulated advice may require stronger review and approval.

This is why a register that only lists tools will miss the point.

For AI, the system tells you what is available.

The use case tells you what is at risk.

What should an AI usage register include?

A practical AI usage register should include enough information to support governance without becoming impossible to maintain.

The fields below are a strong starting point.

1. AI tool name

Record the name of the AI tool or AI-enabled product.

Examples might include ChatGPT, Microsoft Copilot, Claude, Gemini, Midjourney, GitHub Copilot, Notion AI, Canva AI, Zoom AI Companion, or an AI feature inside a CRM, HR, accounting, legal, customer support, or marketing platform.

The tool name matters because it helps identify the vendor, terms, data handling, access model, and technical controls.

But it should not be the only field.

2. Vendor or provider

Record the vendor or provider behind the tool.

This matters because the organisation may need to review terms, privacy arrangements, data retention, model training settings, security posture, contractual commitments, and support processes.

For embedded AI, the vendor may be the provider of a broader system rather than a standalone AI company.

3. Use case

This is the most important field.

Describe what the AI is actually being used to do.

Examples:

Draft internal marketing copy.

Summarise public research.

Generate first drafts of customer emails.

Assist with website code.

Review support tickets for themes.

Summarise sales call transcripts.

Analyse internal financial data.

Draft employment policy wording.

Generate product descriptions.

Support risk assessment preparation.

The use case should be specific enough that someone can understand the activity and assess the risk.

“Using AI for productivity” is too vague.

“Using AI to summarise customer support tickets and identify recurring product issues” is much better.

4. Business purpose or justification

Record why the AI use is needed.

This helps distinguish useful adoption from uncontrolled experimentation.

The business justification might include saving time, improving consistency, reducing manual effort, increasing quality, supporting research, improving response speed, or helping staff complete repetitive tasks.

The purpose does not need to be complicated, but it should be clear.

If no one can explain why the AI use matters, it may not be worth approving.

5. Business owner

Every AI use case should have an owner.

The owner is accountable for the use case, not necessarily for the technology itself.

The owner should understand:

why the AI is being used;

what data is involved;

what output is produced;

what risks exist;

what controls apply;

when review is required.

This is especially important for small and mid-sized businesses, where AI use may be informal and spread across roles.

If no one owns the use case, no one is accountable for checking whether it is still appropriate.

6. Team or function

Record where the AI use sits in the organisation.

Examples:

Marketing;

Sales;

Finance;

Operations;

HR;

Legal;

IT;

Customer support;

Product;

Compliance;

Leadership.

This helps the organisation see where AI adoption is concentrated and where additional guidance or training may be needed.

It also helps identify cross-functional dependencies.

7. Data types involved

Record what types of data are entered into or processed by the AI tool.

This may include:

public information;

internal business information;

customer information;

personal information;

employee information;

financial information;

legal information;

contracts;

health or sensitive information;

source code;

security information;

confidential commercial information;

vendor data;

board or strategy material.

This field is critical because a use case can change risk level when the data changes.

A tool used only with public information may be low risk. The same tool used with customer records, employee information, confidential contracts, or source code may require review, controls, or prohibition.

8. Output type and audience

Record what the AI produces and who will see or use the output.

Is the output:

internal only?

customer-facing?

used in a decision?

used in legal, financial, employment, health, safety, or security contexts?

published externally?

sent to clients?

used in software or operational processes?

This matters because AI output can look polished while still being wrong, incomplete, biased, or unsupported.

A private brainstorming output carries different risk from an AI-generated statement sent to a customer or used in a business-critical decision.

9. Decision impact

Record whether the AI output influences a decision.

This is different from asking whether the AI makes the final decision.

AI may influence human decisions by shaping the evidence, options, assumptions, analysis, or language presented to the decision-maker.

For example, AI may help rank options, summarise information, recommend actions, assess risk, write advice, or prepare a report.

If AI influences decisions, the use case may require stronger evidence, review, and accountability.

10. Risk level

Assign a risk level to the use case.

A simple model may be enough:

Low;

Medium;

High;

Prohibited unless approved.

The risk level should consider:

data sensitivity;

customer or employee impact;

legal or regulatory exposure;

security risk;

financial impact;

reputational impact;

degree of human review;

decision impact;

reliance on vendor claims;

ability to verify the output.

The point is not to overcomplicate the register. The point is to distinguish casual low-risk use from uses that need review.

11. Approval status

Record whether the use case is:

not reviewed;

approved;

approved with conditions;

rejected;

paused;

under review;

prohibited.

Approval status is important because AI use often starts informally. The register should make clear whether the organisation has actually considered the use or merely discovered it.

If approval is conditional, the conditions should be recorded clearly.

For example:

Approved for internal drafting only.

Approved only with public information.

Approved only with human review before customer use.

Approved only for non-production code assistance.

Approved only for named users.

12. Controls or conditions of use

Record any controls that apply.

Examples:

No personal information.

No confidential client data.

Human review required before use.

Output must be fact-checked.

Legal review required.

Security review required.

Vendor terms must be reviewed annually.

Only approved accounts may be used.

Do not use output for final decision-making.

Do not publish without review.

This field helps turn the register from a passive list into a governance tool.

13. Evidence and rationale

Record the evidence supporting approval or continued use.

This might include:

vendor documentation;

privacy review;

security review;

business justification;

risk assessment;

policy reference;

human review process;

testing results;

known limitations;

training guidance;

approval notes.

The register does not need to store every document in full, but it should point to the evidence that supports the decision.

This is important because governance decisions should be explainable later.

14. Known gaps

Record what is not yet known or resolved.

Examples:

Vendor data retention unclear.

No evidence of human review process.

Security review pending.

Owner not confirmed.

Policy condition unclear.

Use case has expanded beyond original approval.

Output accuracy not tested.

Known gaps are not failures. They are governance work items.

A good register should make gaps visible so they can be resolved.

15. Review date

Every AI use case should have a review date.

AI changes quickly. Tools change, vendor terms change, models change, use cases change, and regulations or standards may change.

A use case that was acceptable six months ago may need review today.

Review dates help prevent approvals from becoming stale.

16. Incidents, issues, or lessons learned

Record whether the use case has produced incidents, near misses, complaints, incorrect outputs, privacy concerns, security concerns, or lessons learned.

This is where the register becomes part of an empirical governance loop.

The purpose is not only to record what went wrong. It is to improve future decisions.

Which AI uses should be recorded?

Not every casual experiment needs a full governance record.

But the organisation should record AI use that is recurring, business-relevant, customer-facing, data-sensitive, decision-influencing, or operationally important.

A simple rule is:

Record the use if the organisation would care if the output was wrong, exposed, challenged, or relied on.

That includes use cases involving:

customers;

employees;

personal information;

confidential information;

legal or financial material;

software code;

security-sensitive work;

regulated activity;

external publication;

business-critical decisions;

vendor AI features connected to business data.

For small businesses, the register can start simple. The important thing is to make AI use visible before it becomes unmanageable.

Why AI usage registers must track use-case drift

AI use cases do not stay still.

A team may start using an AI tool for low-risk brainstorming. Over time, the same tool may be used for customer emails, contract drafting, financial analysis, technical support, HR communications, or confidential client work.

The tool has not changed.

The governance risk has.

This is use-case drift: the gradual movement of AI use from one purpose, data type, audience, or decision context into another.

Use-case drift matters because approval is usually conditional. A tool may be acceptable for internal drafting but not for personal information. It may be acceptable for brainstorming but not for customer-facing advice. It may be acceptable for code suggestions but not for unreviewed production code.

That means an AI usage register must track more than the tool name. It must track the use case, data involved, owner, output audience, decision impact, controls, approval conditions, and review date.

When the use case changes, the register should help show what else is affected.

Does the risk level change?

Is new approval required?

Do controls need updating?

Does human review become mandatory?

Is the policy still satisfied?

Does the owner need to be notified?

Should the review date be brought forward?

A change in AI use should create an impact map, not a hidden drift in a spreadsheet.

Spreadsheet or structured register?

A spreadsheet can be a reasonable starting point.

For a small organisation, a basic spreadsheet is much better than having no record at all.

But a spreadsheet has limits.

It may show rows and columns, but it does not naturally manage relationships.

It may not show that one AI tool supports ten use cases with different owners, risk levels, controls, evidence records, and review dates.

It may not show that a policy change affects five use cases.

It may not show that a vendor change creates new review tasks.

It may not show that a known gap weakens confidence in an approval.

It may not show that an incident should change the risk rating of similar use cases.

As AI use grows, the register needs to become more than a flat list.

It should become connected governance knowledge.

That does not mean every organisation needs a complex system on day one. But the direction matters.

The value of the register is not the rows it stores.

The value is the decisions it improves.

Common mistakes

Several mistakes are common when organisations create AI usage registers.

The first is treating the register as a list of tools only. The use case is what determines risk.

The second is failing to record shadow AI. If employees are using AI through personal accounts, browsers, phones, or embedded features, that use may still create business risk.

The third is not assigning owners. Without ownership, review and accountability become unclear.

The fourth is ignoring data types. The same tool may be low risk with public information and high risk with confidential or personal information.

The fifth is failing to record review dates. AI approvals should not last forever without reassessment.

The sixth is treating approval as a simple yes or no. Many AI use cases should be approved with conditions.

The seventh is not recording evidence. Later, the organisation may be unable to explain why the use was allowed.

The eighth is letting the register become stale. A stale AI usage register creates false confidence.

How AgorikAI helps

AgorikAI is designed to treat an AI usage register as connected governance knowledge, not a flat list of tools.

A single AI tool may support many use cases, each with different owners, data types, risks, controls, approvals, evidence records, review dates, and lessons learned.

AgorikAI helps connect those elements.

That means the register can support questions such as:

Which AI use cases involve customer data?

Which high-risk use cases are missing owners?

Which tools are approved only for internal drafting?

Which use cases rely on evidence that is now stale?

Which controls lack supporting evidence?

Which vendor AI features require review?

Which use cases changed since approval?

Which gaps should be resolved next?

This is where the register becomes part of a broader AI governance system.

AgorikAI supports an empirical and ontological approach to AI governance.

Empirical means decisions are grounded in evidence, reviewed against outcomes, and improved over time.

Ontological means the system understands the key things being governed and how they relate: tools, use cases, owners, vendors, data, risks, controls, evidence, gaps, approvals, reviews, incidents, outcomes, and learning.

For AI usage registers, that matters because the use case determines the risk, and use cases change.

AgorikAI helps organisations move from tool inventory to living governance knowledge.

Practical next steps

To create an AI usage register, start with the basics.

Identify where AI is already being used.

Record the tool name and vendor.

Describe the use case clearly.

Assign a business owner.

Record the team or function.

Identify the data types involved.

Record whether the output is internal, external, or decision-influencing.

Assign a risk level.

Record approval status and any conditions of use.

Link to evidence or rationale.

Record known gaps.

Set a review date.

Capture incidents and lessons learned.

Start simple, but design the register around use cases from the beginning.

That one decision will make the register far more useful.

Conclusion

An AI usage register is one of the most practical tools in AI governance.

It makes AI use visible.

It shows who owns each use case.

It records what data is involved.

It helps identify risk.

It supports approval, review, evidence, and accountability.

But the most important point is that an AI usage register should not be just a list of AI tools.

For AI, the use case is the real unit of governance.

The same tool can support low-risk drafting, customer communication, confidential analysis, code generation, hiring support, financial modelling, or decision support. The tool may stay the same while the risk changes completely.

That is why the register must track use cases, not just systems.

AI changes too quickly for governance to rely on static inventories. The register must become a living map of AI use, risk, evidence, ownership, review, and learning.

If the organisation cannot see where AI is being used, it cannot govern AI responsibly.

FAQ

What is an AI usage register?

An AI usage register is a central record of where, why, and how AI is being used across an organisation. It usually records the tool, use case, owner, data types, risk level, approval status, evidence, and review date.

Is an AI usage register the same as an AI tool inventory?

No. A tool inventory lists AI systems or products. An AI usage register should go further by recording use cases. For AI governance, the use case determines the risk.

What is the most important field in an AI usage register?

The use case. Knowing the tool name is useful, but the use case explains what AI is actually being used to do, what data is involved, and what risk may exist.

Does every AI experiment need to be recorded?

Not necessarily. Casual, low-risk experimentation may not need a full record. But recurring, customer-facing, data-sensitive, decision-influencing, or business-critical AI use should be recorded.

Who should own the AI usage register?

Ownership depends on the organisation. It may sit with operations, compliance, IT, risk, legal, or a founder in a smaller business. Each individual use case should also have a named business owner.

How often should an AI usage register be reviewed?

Regularly, and whenever something changes: the use case, data type, vendor terms, risk level, policy, approval conditions, controls, or evidence. AI use changes quickly, so review dates should not be ignored.

Can a spreadsheet be used as an AI usage register?

Yes, especially as a starting point. But as AI use grows, a spreadsheet may struggle to manage relationships between tools, use cases, owners, risks, controls, evidence, approvals, reviews, and incidents.