Most AI risk registers we see in the field are not registers, they're spreadsheets. A list of AI tools, a column for "risk level" filled in by intuition, a column for "owner" that often points back to the person who built the spreadsheet, and not much else. They satisfy a checklist obligation. They will not satisfy an auditor, a regulator, or a board member who actually reads them. The gap between an AI inventory and an AI risk register is the gap between knowing what you have and knowing what to do about it, and closing it is one of the highest-leverage governance moves a regulated organization can make this year.
What an AI Risk Register Has to Do
A risk register is a control. It exists to answer specific questions, reliably, the same way every time, for every AI system in your environment. The questions are not novel. Auditors and regulators ask versions of them across SOC 2, ISO 27001, HIPAA, and emerging AI-specific frameworks like ISO 42001 and the NIST AI RMF.
For each AI system: what is it? What does it do? What data does it touch? What's the impact if it fails or is compromised? Who owns it? Who approved it? What controls are in place? When was it last assessed? When will it be reassessed? An AI risk register that can't answer all of those questions for every system in scope is incomplete, and the audit finding writes itself.
The Fields That Actually Matter
System identity and purpose. A short, plain-language description of what the system does and why it exists. Auditors are not AI engineers, and a register entry that requires technical translation is a register entry that won't survive review. "Customer support chatbot for tier-one inquiries, replaces email triage" is useful. "GPT-4 wrapper" is not.
Data classification and flow. What data the system processes, where it comes from, where it goes. This is the field that surfaces the risks that matter most: a system processing PHI is a different control posture than one processing public marketing copy. The register needs to capture both data-at-rest classification and data-in-transit destinations, including any third-party model providers in the path.
Risk classification and rationale. Not just a number or a color. The methodology that produced the classification, traced to a recognizable framework. ISO 42001's risk tiering, NIST AI RMF's characterization, or the OWASP LLM Top 10's vulnerability classes are all reasonable starting points. What's not reasonable is "high/medium/low" without a defensible reason for each placement.
Controls in place and gaps. What existing controls reduce the risk, mapped to the actual risk being controlled. Generic statements like "we use SSO" don't establish that a specific risk is mitigated. A control field that says "API access logging captures all model invocations and is retained 365 days, addresses traceability requirement under ISO 42001 Annex A.6.2" does.
Owner and approver. Two distinct fields. The owner is operationally responsible. The approver is accountable for the risk acceptance. These are often different people, and conflating them is a governance failure that auditors find quickly.
Assessment cadence and history. When the system was last assessed, when it will be reassessed, and a pointer to the actual assessment artifact. A register that says "last reviewed Q1 2026" without a link to the review document is hearsay. The auditor will ask for the document.
Vendor and contract context. For third-party AI services, the vendor, the contract terms relevant to AI use (training opt-out, data residency, model version control), and the date of the last vendor security review. AI vendor contracts often have terms that materially affect risk, and those terms change. The register needs to track that.
The Process Around the Register
The register isn't the control. The process around the register is. A perfect register that's updated annually is worse than a less-detailed register updated continuously, because the perfect register will be lying within months. The process needs three working pieces:
Discovery feeding the register. Some path by which new AI systems get added without depending on someone proactively filing paperwork. This usually means a combination of automated discovery (network scans, expense report analysis, SSO logs revealing AI tools) and process integration (procurement requests for any AI tool route through the register before approval).
Periodic reassessment. Each entry has a defined reassessment cadence based on its risk tier. High-risk systems quarterly. Medium-risk systems semi-annually. Low-risk systems annually. The cadence is enforced by the register itself, with overdue items flagged automatically.
Change-driven reassessment. Reassessment isn't only calendar-driven. Vendor model upgrades, contract changes, scope expansions, and incidents all trigger out-of-cycle review. The register needs hooks into change management to catch these triggers.
"The risk register an auditor accepts and the risk register that actually reduces risk are usually the same document. Build for the second goal and the first follows."
What Auditors Are Actually Looking For
Auditors evaluating an AI risk register are looking for evidence of three things. First, completeness, that the register reflects the AI footprint they can independently observe through other discovery paths. If they find AI tools in expense reports or vendor contracts that aren't in the register, you have a finding. Second, currency, that the register is being maintained, not built once and abandoned. Stale dates, identical assessment notes across multiple entries, and missing recent changes are red flags. Third, usefulness, that the register supports actual decision-making, that controls are mapped to specific risks, that risk acceptance has named approvers, that the document is operational rather than ceremonial.
What to Build First
If you're starting from a spreadsheet today, the first three moves are: get discovery in place so the register reflects reality, define the risk classification methodology so the entries are comparable, and assign a single owner for the register itself, separate from the owners of the systems within it. Without those three pieces, a more elaborate register will not be more credible. With them, even a basic register will hold up under scrutiny, and the elaboration can come over time without compromising the foundation.
The window for getting AI governance right on your own terms is narrowing. Customer questionnaires are asking for register evidence already. Auditors are starting to ask. Regulators are not far behind. Building the register now, when you can shape its scope and content, is materially easier than building it under inquiry pressure later.