The AI use-case register: the boring artefact that holds the whole controls system together.

If we had to recommend a single artefact for a bank starting to use AI seriously, it would be the use-case register. Not the steering committee, not the policy, not the model risk framework. Those all matter, but they hang off the register. The register is the index. Without it, the rest of the controls system has nothing to attach to.

This post describes what the use-case register is, what goes in each entry, who keeps it, and how it gets used in practice at Veetso.

Key facts

01: One entry per use case, not per model. A use case is the unit a regulator asks about. One model can power many use cases; one use case can use several models. The register is organised the way regulators query it.
02: Twelve fields per entry. Identifier, name, owner, description, inputs, outputs, decision authority, vendor and model, gates passed, risk rating, effective date and review date, status, audit-log linkage.
03: One editor, single source of truth. The AI controls lead edits day to day; owners propose changes; the steering committee reviews. A register with several free editors drifts into inconsistency.
04: Every audit log entry references it. The use-case identifier is what ties a log entry to the register. Together they answer most questions a regulator could ask about a specific AI action.

What it is

A list of every place AI does work inside the bank. One entry per use case. Each entry describes the use case, the data it touches, the people who use the output, the decisions that flow from it, and the controls applied. The register is searchable, versioned, and visible to everyone who needs it (which is more people than you would think).

A use case is not a model. One model can power many use cases; one use case can use several models. The register is organised around the use case because that is the unit a regulator asks about. "Where do you use AI in compliance?" is a register query. "Which model do you use?" is a detail of a register entry.

What goes in each entry

Twelve fields. None optional.

01. Identifier and name

A stable identifier (e.g. UC-COMP-2026-018) and a human-readable name (e.g. "AI-assisted KYC narrative summarisation").

02. Owner

A named individual. Not a team. The owner is responsible for keeping the entry current and answering questions about the use case.

03. Description

One paragraph. What the model does, who consumes the output, and what changes when the output arrives. Plain English. No marketing.

04. Inputs

The data classes the model sees. Cross-references the data classification scheme. If the data class is not classified, the register cannot accept the entry.

05. Outputs

What the model produces. Text, score, structured field, summary, ranking. Specific enough that the audit log can validate that the model produced what the register says it does.

06. Decision authority

Who acts on the output. For Veetso this is always a named human role. The decision authority field is what stops the register from quietly drifting into "the model decides."

07. Vendor and model

Which provider, which model identifier, which version pin. Links into the vendor due diligence file. See the vendor post for what that file contains.

08. Gates passed

Confirmation that each of the six gates has been cleared, with the date and the person who signed off on each.

09. Risk rating

The use case's risk rating under the bank's existing risk framework. The framework is not AI-specific; AI use cases sit alongside everything else.

10. Effective date and review date

When the use case went live, and when it is next reviewed. Reviews are at least annual, more often for higher-risk use cases.

11. Status

In design, in review, live, paused, retired. Retired entries stay in the register forever; the audit history depends on them.

12. Audit log linkage

The use-case identifier is what ties an audit log entry to a register entry. Every log entry references the use case it falls under, and the register entry is the answer to "what was the model supposed to be doing here?"

Who keeps it

The AI steering committee owns the register. A single person, the AI controls lead, edits it day to day. Owners propose changes; the lead applies them after the steering committee reviews. Every change is itself logged.

We keep this responsibility narrow because a register that several people can edit independently drifts into inconsistency, and an inconsistent register is worse than no register at all. The register either reflects reality with high fidelity or it stops being useful.

How it gets used

Four common uses, each of which would be painful without the register.

Regulatory request

"List every use of AI in your customer-facing operations." We sort the register by the decision-authority field and the consumer field and produce the list in under an hour. Without the register, this is a six-week project.

Vendor change

A vendor announces a model deprecation. We query the register by vendor and model identifier, get the list of affected use cases, contact each owner, and plan migrations. The query takes a minute.

New use case proposal

A team wants to add AI to a workflow. The proposal template is the register entry template with the gate fields blank. The team fills it in; the steering committee reviews; if approved, the entry goes from "in design" to "in review" to "live" with the dates recorded. The register both documents the use case and gates it.

Internal training

New compliance and engineering staff read the register on their first week. It is the most efficient way to learn where AI is used in the bank, and the most accurate map of the controls system in practice.

What the register does for the audit log

Every audit log entry has a use-case identifier. Without the register, the identifier is just a string; with the register, it is a link to the description, the owner, the data classes, the decision authority, and the gates. The audit log entry plus the register entry together answer most questions a regulator could ask about a specific AI-assisted action.

This is why we built the register before we built the Brain. It is the schema for the controls system. Everything else fits around it.

FAQ

Questions readers ask

What is an AI use-case register?

An AI use-case register is a list of every place AI does work inside a bank, with one entry per use case. Each entry describes what the model does, the data it sees, the people who consume the output, the decisions that flow from it, and the controls applied. It is the index for the rest of the AI controls system.

What fields should a use-case register entry contain?

At Veetso, twelve fields: a stable identifier, a human-readable name, a named owner, a plain-English description, input data classes, expected outputs, the decision authority (always a named human role), vendor and model version, gates passed with sign-off dates, risk rating under the bank's existing framework, effective date and review date, status, and a link into the audit log.

Who maintains the use-case register?

The AI steering committee owns it, with a single named editor (the AI controls lead) applying day-to-day changes after committee review. Single-editor responsibility prevents the drift that comes from multiple independent edits; an inconsistent register is worse than no register at all.

How does the use-case register connect to the audit log?

Every audit log entry references a use-case identifier. The register entry tells the auditor what the model was supposed to be doing; the log entry tells them what it actually did. Together they answer most regulator questions about a specific AI-assisted action.

Do retired use cases get deleted from the register?

No. Retired entries stay in the register forever, with status changed to retired and a retirement date recorded. The audit history depends on them: a regulator querying historical actions needs to resolve the use-case identifier even after the workflow is gone.