What Actually Goes in an AI System Register

Most AI governance programs begin the same way. Someone pulls the proxy logs, greps for the well-known provider domains, and pastes the result into a spreadsheet called AI Inventory. Forty rows, one column, sorted alphabetically.

It is a reasonable first day of work. It also fails the first question anybody asks of it, which is never “what AI do you use?” It is “who decided that was allowed, and how do you know this list is complete?”

The frameworks all ask for a register. None of them ships a template. So teams build the artifact from the name — a list — when what is being asked for is a record of decisions with evidence attached.

A list of tool names is not a register

The gap is easiest to see by trying to use the spreadsheet. Pick any row. Now answer, without opening another system:

• Who in this organization is accountable for it?
• Was it approved, or has nobody looked at it yet? By whom, and when?
• Is it approved for everyone, or for one team?
• What does it reach — which systems, whose accounts?
• Does the vendor train on what gets submitted to it?
• How did we find out it was here, and when did we last see it?

A tool name answers none of these. And the honest answer to several of them, on day one, is we don’t know yet — which is fine, and which the register has to be able to say out loud rather than leave as an empty cell that reads like a zero.

What the frameworks ask a deployer to produce

Four documents drive most of this work, and it is worth separating what they ask of the people who build AI from what they ask of the far larger population who merely use it. Almost every organization is in the second group.

ISO/IEC 42001 asks for a register of AI systems, supplier controls covering the AI your vendors bring with them, assigned accountability for each system, and the inputs to an impact assessment. The accountability column is the one most inventories skip and most assessors open first.

NIST AI 600-1 asks you to enumerate the organization’s generative-AI systems and to document third-party and value-chain components. Value chain is the operative phrase: not just your vendor, but the vendors your vendor hands data to.

The EU AI Act speaks to deployers mainly through Article 26 — use the system per the provider’s instructions, assign human oversight to a named person, monitor operation, and keep records of use. Its transparency duties add a separate question: which of the products already in use put AI in front of a person, and does the vendor switch that on by default?

NYDFS Part 500 never says “AI,” which is exactly why it applies. Its asset inventory, third-party policy and access-privilege requirements land on AI systems the same way they land on anything else that touches your data.

Read together, they are not four different asks. They are four framings of one artifact: every AI system in use, how you know it is there, who owns it, what was decided, and what it touches.

The columns that do the work

A register that answers all four has roughly these:

Identity and kind. What the system is, and which of the four shapes it takes — a hosted AI service, an AI feature inside an app you approved before it had one, a model runtime installed on a laptop or server, or a remote endpoint something in your estate connects out to. A register holding only the first kind was incomplete the day it was written.

Provenance, per value. Not a source column for the row — a provenance class for each cell. Was this observed in your own telemetry, curated from research with a review date, typed in by someone on your team, or not assessed yet? These are not the same kind of claim and an assessor will not treat them as one.

Accountability. A named owner, plus who set that owner and when. “The security team” is not an owner.

The decision, and its history. Not a checkbox. A real review passes through states — unreviewed, evaluating, approved, approved for a specific group, prohibited — and it reverses. The history of how a system reached its current state is the part that demonstrates a process existed, rather than that somebody tidied the sheet before the meeting.

Reach. Which assets and identities touch the system, how many of those hold admin, and whether any of it lands on something the business actually runs on. This is what turns forty undifferentiated rows into a short list.

Vendor posture. The vendor’s own published position on training with submitted data, its certifications, and its sub-processors — dated, and sourced to the vendor’s own page so a reader can check it.

Unknown is a value, not a blank

The single most important design rule: a register must distinguish no from not yet assessed.

A vendor whose training policy you have not established is not a vendor that does not train on your data. An AI system whose reach you cannot compute because the identity feed is not connected is not an AI system that reaches nothing. If those two cases render identically to “clear,” the register is quietly manufacturing assurance, and the first person to check a row will stop trusting the other thirty-nine.

Showing unassessed cells feels worse in a demo and is worth far more in an audit.

The export has to state its own limits

The register leaves as a file, and the file gets read by someone with no access to the system that produced it. So it has to carry its own context: what it is, the date it was generated, how many systems it covers, and which discovery sources were live when it ran.

That last part matters more than it sounds. If a data source was down, rows are missing — and without a note saying so, missing-because-unread is indistinguishable from missing-because-absent. One is a gap in coverage; the other is a clean bill of health. A register that cannot tell them apart is worse than no register, because it is confidently wrong.

Keep each export as a point-in-time record, too. “What did we know on the day we made this decision?” is a question that gets asked later, and it cannot be answered by a live view that has since moved on.

How KeyCaliber approaches it

KeyCaliber builds the register from read-only connections to tools already in your environment — network, DNS, gateway, identity, endpoint software inventory — rather than adding a sensor. Every AI system found lands as one row across the four kinds, including local model runtimes read from the software inventory your EDR and MDM already collect, and remote endpoints linked to the vendor app behind them.

Each cell carries its provenance. Each app carries a named owner, a five-state decision scoped to the people it applies to, and the full history of every approval, reversal and owner change behind it. Vendor training policies and sub-processor lists are read from the vendors’ own published pages and dated. Columns map to what ISO 42001, NIST AI 600-1, the EU AI Act and NYDFS Part 500 ask a deployer to produce, and the whole thing exports as one dated file that opens by stating what it covers and what it could not read.

We do not certify anyone, and nothing here assigns your systems a risk class on your behalf — the catalog offers a suggestion, labelled as one, and your classification stands.

The register is not the goal. Being able to answer “how do you know?” about every cell in it is.