
A Model Registry a Regulator Can Read
You can't govern AI you can't list. A model registry catalogs every model you run — its purpose, data, limits, version, and owner — in a form a regulator can actually read, and keeps it current instead of letting it rot in a spreadsheet.
- Katya SavenkovaDirector of Operations
In this article
The first question any AI audit asks is deceptively basic: what AI are you actually running? Most organizations can't answer completely, because their models proliferated faster than any inventory. A model registry fixes that — a living catalog of every model in use, described in a way a regulator can read, that stays current instead of becoming another stale spreadsheet.
Why the inventory question is hard
Models arrive from everywhere — a vendor feature, a team's experiment, a capability inside a tool nobody thought of as 'AI.' Each is a small, reasonable decision, and collectively they produce a landscape no one can fully enumerate. When a regulator or a security review asks for the list, the honest answer is often 'we're not entirely sure,' which is precisely the answer you don't want to give about systems making decisions.
What belongs on a model card
A registry is only useful if each entry says something meaningful. A readable model card captures:
- Purpose — what the model is used for and where, in business terms.
- Data — what it was trained or grounded on, at a level that supports data-governance questions.
- Limitations — what it shouldn't be relied on for, stated honestly.
- Version and provenance — which model and version, so 'which one decided this' is answerable.
- Owner and risk tier — who's accountable and how it's classified.
Written this way, an entry answers a regulator's questions directly instead of pointing at a model name and a shrug.
Registry vs ledger: two different questions
A registry is often confused with an audit log; they answer different questions. The registry is a catalog of what you operate — the static inventory of models and their descriptions. The ledger is the dynamic record of what those models actually did, event by event. You need both: the registry answers 'what AI do you run,' the ledger answers 'what did it do.' A registry without a ledger can't show behavior; a ledger without a registry can't say what the behaving thing was.
The registry is the cast list; the ledger is the script. A regulator asks for both, and they have to agree.
Keeping it current
A registry maintained by hand is stale the day after it's compiled, because models change faster than anyone updates a document. The registry has to be tied to what's actually deployed, so adding, updating, or retiring a model updates its entry — rather than relying on someone to remember to edit a spreadsheet. A registry that drifts from reality is worse than none, because it gives false confidence about what you're running.
From inventory to governance
A complete, current registry isn't paperwork for its own sake — it's the foundation the rest of governance stands on. You can't classify risk, assess conformity, or scope an audit for systems you haven't enumerated. The registry turns 'we run some AI' into a defined set of systems, each accountable, which is the precondition for governing any of them.
Frequently asked questions
Answer 'what AI do you run' completely. See how a current, readable model registry catalogs every model's purpose, data, limits, and version — and ties to the ledger of what each actually did. Book a walkthrough.
Part of