Enterprise Governance & Risk

Maintaining an Enterprise AI Registry

You cannot govern what you cannot list. The AI registry is the unglamorous document that every other governance practice — risk tiering, reviews, audits, incident response — quietly depends on.

Claude 3P 101 · Updated July 2026 · Unofficial guide

An AI registry is a living inventory of every AI use case in the organization: what it does, who owns it, how risky it is, what it runs on, and where it stands in its lifecycle. It is almost always the first artifact an auditor or examiner requests, and it is the index into everything else — each entry points at the risk assessment, the evaluation results, the change log. This article covers what a good entry contains, how to keep the registry honest, and how the Claude platforms make parts of it verifiable rather than aspirational. All of it is recommended practice; no registry format is mandated by any particular regulation, and yours should fit your industry's expectations.

What each entry records

FieldWhat it captures
Use case & descriptionWhat the system does, for whom, in plain language a non-engineer can assess
OwnerA named individual accountable for the use case (a role, backed by a person — see defining AI roles)
Risk tierThe classification from your risk tiering scheme, with a pointer to the assessment behind it
Technical footprintPlatform (first-party API, Claude Platform on AWS, Bedrock, Vertex AI, Foundry), exact model ID, workspace or project identifier, prompt version
Data touchedData classes in and out, and any special arrangements (retention, residency) that apply
StatusLifecycle stage: proposed → piloting → production → under review → retired
Last review & next reviewDate, reviewer, outcome — with the next date set by risk tier

Two fields deserve emphasis. Exact model ID: every Claude model ID is a pinned snapshot, so recording claude-opus-4-8 or a dated ID like claude-haiku-4-5-20251001 names precisely what runs — and lets you act when Anthropic publishes deprecation dates (Claude Opus 4.1, for instance, is deprecated with a published retirement date of August 5, 2026; a registry query for affected use cases turns that announcement into a task list). Workspace identifier: if each use case runs in its own workspace on the Claude API — workspaces exist to separate projects and teams under centralized administration, with API keys scoped to a single workspace — the registry maps one-to-one onto real, enforceable boundaries rather than onto tribal knowledge. Organizations can create up to 100 workspaces, which is ample for mapping use cases.

Keeping it honest: reconcile against reality

Registries rot in a predictable direction: reality grows, the document doesn't. The countermeasure is periodic reconciliation against sources that cannot forget:

Rule of thumb: the registry is trustworthy only if a new use case cannot get credentials without an entry. Make registry registration a gate in your intake process, not a follow-up chore.

Reviews and lifecycle

The "last review" field is what separates a registry from a graveyard of good intentions. Set review cadence by risk tier — high-stakes use cases reviewed frequently, low-stakes ones annually — and define what a review checks: is the use case still needed, still within its approved scope, still on a supported model version, still performing per its last evaluation? Status transitions should be events with owners: moving to production requires validation evidence; moving to retired triggers the decommissioning checklist. A use case that fails review doesn't get a note in a column; it gets a remediation task with a date.

Start small, but start

A spreadsheet with ten honest rows beats a governance platform with three stale ones. Start with the fields above, populate it by walking the org (and the billing data), and only add tooling when the row count demands it. The registry's value is not sophistication — it is that when anyone asks "what AI do we run, and who owns it?", there is exactly one place the answer lives.

Where to go next

The registry anchors the records regulators ask for and feeds the model inventory; entries are born in use-case intake and die via the decommissioning checklist.

Sources