The AI-use register: the first artifact every framework asks for

Every AI governance framework, from the EU AI Act to Colorado's deployer duties to the NIST AI RMF, presumes you can produce a list of your AI systems. Almost no company under a thousand people can. The register is the unglamorous artifact that fixes this, and it is worth doing before any policy, because policies written without an inventory describe a company that does not exist.

The columns that earn their place

A register row should answer, in one screen:

• System and vendor: what it is and whose model runs it
• Purpose: the job it does, in one sentence a new hire would understand
• People affected: customers, candidates, employees, nobody
• Decision impact: informational, assistive, or substantially factors into a decision
• Data in: the categories it sees, especially personal data
• Human oversight: who reviews, what they check, how an override is recorded
• Risk level and the obligations mapped to it
• Owner and review date

Three rules that keep it honest

First, write purposes in plain language. If the purpose needs jargon, you do not understand the use case yet, and neither will a regulator.

Second, record decision impact truthfully. The difference between assists a recruiter and decides who gets reviewed is the difference between minimal and high risk in every framework that matters.

Third, give every row exactly one owner. Shared ownership is how registers die. The owner is not the person who runs the model; it is the person who can turn it off.

Keeping it alive

A register decays the day someone enables a new copilot. Two habits prevent that: make adding a row part of procurement, and re-check the mapping when the rules change, which they now do several times a year. This second habit is exactly why Regolyn versions its obligation library and re-scores your readiness against updates, so the register you show an auditor describes the company you actually are.