Where does the register sit relative to the AI inventory?

The inventory lists systems. The register lists risks. Each register row belongs to exactly one inventory entry. Each inventory entry has one or more register rows. The two artefacts live together but answer different questions: the inventory answers "what AI does the organisation operate?" and the register answers "what risks does that AI create and how are they managed?"

How granular should the risk descriptions be?

A risk is granular enough when the description names a specific attack path or harm mechanism, identifies the data class involved, and points to the runtime layer where the control fires. A description that reads at the level of "the model could produce biased output" is too coarse. A description that reads at the level of "Adversarial prompt with indirect injection in a connected document, exfiltration via response routed to original requester, control at prompt classification layer" is at the right level.

What about risks that have no controls available?

Some risks have no current control. The register still records them, with the controls_applied column noting "no current control available" and the residual rating equal to the inherent rating. The risk owner is then responsible for raising the budget, vendor, or policy change needed. An untreated risk is worse hidden than visible.

How does the register interact with the incident response process?

Incidents materialise risks. When an incident closes, the postmortem identifies which register row corresponds to the materialised risk. The related_incidents column captures the linkage. The postmortem feeds back into the inherent and residual ratings. A risk rated low-likelihood that produced two incidents in a quarter is not low-likelihood. The register has to update.

Should the register be visible outside the risk function?

Yes, with appropriate access controls. The risk owners need to read and update their rows. The engineering teams operating the systems need to read the controls applied so they can keep the runtime configuration aligned. The board's risk committee needs read access to the residuals. The register is an operational artefact, not a confidential document.

AI Risk Register Template: What Each Row Has to Capture and Where the Evidence Comes From

An AI risk register is the operational artefact that records, for each AI system the deployer operates, the risks identified, the controls applied, the residual risk, and the evidence the controls are working. The register is the central document a regulator or internal auditor reads to assess whether the deployer's AI risk management actually functions. EU AI Act Article 9, NIST AI RMF, ISO/IEC 42001, and Fannie Mae LL-2026-04 each expect a register the deployer can produce on demand.

The format varies. The columns that hold up across regimes are stable. I want to walk through the row schema, the questions each column answers, and the runtime evidence each column has to depend on to stay current.

The row schema

A row in the register represents one identified risk for one AI system. Multi-risk systems generate multiple rows. The columns below are the minimum schema.

The row is short enough to scan. The evidence behind each column is where the work sits.

What each column captures

Risk identifier

A stable ID lets the register survive renaming, system retirement, and regulatory inquiry. Use a scheme such as RR-<system>-<sequence> so the ID encodes which system the risk belongs to.

System identifier

A foreign key to the AI inventory. Every system in the inventory needs at least one entry in the register, even if the entry says "no material risks identified, monitor at the system level." Systems missing from the register fail the Article 9 review.

Risk category

A small taxonomy keeps reporting consistent. Six categories cover most enterprise AI risk: privacy (data subject harm under GDPR), fairness (discriminatory outcomes), safety (physical or financial harm to users), security (confidentiality, integrity, availability of the AI system and its data), financial (loss to the deployer), reputational (loss of trust or market position).

Risk description

One paragraph that opens with the mechanism. Avoid generic phrasing. A description like "prompt injection could cause data exfiltration" is too thin. A description like "An attacker submits a prompt containing an indirect injection payload via a customer support ticket. The model executes the injected instruction, retrieving a colleague's PII from the connected CRM tool. The exfiltration channel is the model's response routed back to the original requester" is auditable.

Severity and likelihood

Two ratings, each on a consistent scale (1-5 is common). The inherent rating describes the world without controls. The residual rating describes the world with the documented controls applied. The gap between the two is the value the controls produce. A controls list that does not reduce the rating is either ineffective or mis-documented.

Controls applied

A list of control IDs from the deployer's control catalog. Each control has a definition elsewhere. Common controls for AI systems include identity context attachment, PII detection at the prompt layer, fail-closed policy on undefined cases, per-role policy on model endpoints, tamper-evident audit logging, and human-in-the-loop review for high-severity decisions.

Control evidence

A link to the runtime evidence that the controls fire. A per-decision audit record stream that shows the policy fired and the decision was logged is the evidence. A configuration snapshot in the control catalog is not.

Risk owner

A named executive accountable for the risk. The owner has the authority to allocate budget, change the runtime configuration, and escalate to the board. Generic owners ("the AI committee") fail under regulatory inquiry.

Review cadence

Quarterly is the default. Event-driven reviews fire on material changes: model change, training data change, scope change, deployment change, related incident. Both apply to most risks.

How the register interacts with the runtime architecture

A register that is six months stale at audit time will fail the review. The runtime architecture has to feed evidence back continuously.

Controls list points to actual policy

The controls list in the register names the controls. The runtime architecture's policy decision point holds the actual policy. The two have to map. A control named "block prompts containing PHI when caller role is not clinician" in the register has to correspond to a policy rule with the same semantics in the proxy.

Control evidence comes from production traffic

The control evidence link points to the audit record stream the proxy produces. Sampling from the stream shows the policy fired, the data classification was applied, and the decision was made with the documented identity context. If sampling shows the control did not fire on traffic that should have triggered it, the residual risk is higher than the register claims.

Incident linkage closes the loop

When an incident occurs, the related_incidents column links to the incident record. The incident postmortem feeds back into the inherent and residual ratings. A risk that materialised was not as low-likelihood as the register suggested.

Review cadence is non-negotiable

Quarterly review forces the deployer to look at each row and ask whether the controls still match the threat. Annual review is too slow for AI systems that change continuously. Event-driven review without a regular cadence misses slow drift.

What good looks like

A well-maintained register has the following properties.

Every inventory item has at least one row

Coverage matters more than completeness. A row for every system, even a thin one, is better than detailed rows for some systems and nothing for others. The Article 9 reviewer reads the gap, not the detail.

Controls map to policy

The control IDs are not free text. They reference a control catalog. The catalog entries reference the runtime configuration. The chain is traceable from the register to the runtime.

Evidence is production, not configuration

The control_evidence column links to the audit record stream, not to the control catalog entry. A reviewer can click through and see the controls firing on actual traffic.

Ratings are honest

A register where every residual risk is "low" fails the review. The reviewer looks for the gap between inherent and residual. If the gap is small, the controls are weak. If the gap is unbelievable, the documentation is wrong. The honest register reports residuals that justify the controls.

Review history is visible

The last_review_date and next_review_date columns are non-empty for every row. A row last reviewed twelve months ago fails the cadence check, regardless of the documented cadence.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users or agents and any LLM. Policies are configured per route and per role. Every request is evaluated against the configured policy using identity context the application supplies. Prompt content is classified before the request reaches the model. Every decision produces a signed, per-decision audit record.

For the register, the proxy is the evidence layer for both the controls applied and the control evidence columns. The control IDs in the register map to the proxy's policy configuration. The audit record stream is the runtime evidence the control_evidence column points to. The risk owner can pull a sample from the stream during the quarterly review and verify each control fires on the traffic that should trigger it.

The same evidence stream supports the related incidents column. When an incident occurs, the proxy's audit record shows what the policy allowed, what was actually requested, and what was returned. The postmortem references the same record stream the register's evidence column points to.

If you are running AI in a regulated environment and your risk register references a control evidence layer that does not exist, the regulator will find the gap before you do. Book a demo today.