AI Risk Register: How to Build and Maintain One (With Template)

An AI risk register is the operational heart of AI governance — the living document that tracks what risks your AI systems create, how they are being managed, and who is accountable. How to build one that actually works.

Key Takeaways

An AI risk register has six fields that matter: the AI system, the risk (specific and concrete), the likelihood, the potential impact, the current controls, and the accountable owner. Everything else is decoration.
The most common risk register failure is recording risks at the wrong level of abstraction — 'AI may produce biased outputs' is not a registerable risk; 'our credit scoring model may produce loan denial rates that differ by 15% across demographic groups in ways that constitute indirect discrimination' is.
Risk registers must be reviewed at a set frequency — quarterly for high-risk AI, semi-annually for medium risk — and must be updated when AI systems change, when incidents occur, or when the regulatory environment materially changes.
The risk register is the primary evidence document for AI governance maturity in regulatory examinations, due diligence processes, and ISO 42001 audits. A risk register that is current, specific, and evidences active management is worth more than any amount of policy documentation.
For EU AI Act compliance, the risk register for high-risk AI must document: identified risks, their likelihood and severity, the measures taken to address them, and the residual risk after controls. This maps directly to the technical documentation requirement.

"Apenas para fins informativos. Este artigo não constitui aconselhamento jurídico, regulatório, financeiro ou profissional. Consulte um especialista qualificado para orientação específica."

The AI risk register — what it is and why every organisation needs one

An AI risk register is the central operational document of AI governance. It records every AI system in the organisation, the risks associated with each system, the controls in place, who is accountable, and how performance is monitored. Done well, the risk register answers the questions regulators, auditors, board members, and incident investigators will ask: what AI is in production, what are the risks, who owns them, what controls exist, and are they working.

Regulatory convergence on the AI inventory as a baseline expectation makes this non-optional. APRA's 30 April 2026 letter named AI inventory and lifecycle management as one of four gaps. The Federal Reserve's SR 26-2 (17 April 2026) requires materiality-tiered model risk management — impossible without an inventory. The EU AI Act requires registration and conformity assessment for high-risk AI. ISO/IEC 42001 expects documented AI lifecycle management. NIST AI RMF's MAP function begins with identifying AI systems in context. The Singapore Model AI Governance Framework, PCPD Hong Kong framework, and MAS TRM Guidelines all converge on this expectation. The UK's CDEI found that while 78% of public sector organisations use AI systems affecting service delivery, only 31% maintain AI-specific risk registers.

What goes in an AI risk register — the 20-30 fields

A useful AI risk register has approximately 20-30 fields per AI system. Too few and the register lacks operational utility; too many and it becomes a maintenance burden. The critical difference from a standard risk register is the AI-specific fields: model type, training data source, fairness metrics, explainability rating, drift monitoring, and regulatory mapping.

System identification: unique identifier, human-readable name, description, status (production/development/testing/decommissioned), deployment date, last review date.

Ownership: named business owner (individual, not team), technical owner, risk owner, approving authority. Named accountability matters — ISO 42001 Cl. 5.3 and NIST GOVERN 1.3 both require it.

Classification: internal risk tier (High/Elevated/Standard), EU AI Act classification (Prohibited/High-risk Annex III/Limited-risk Article 50/Minimal), applicable regulatory frameworks (CPS 230, DORA, GDPR Article 22, FCA Consumer Duty, HIPAA), and materiality assessment rationale.

System description: purpose, inputs, outputs, decisions affected, people affected, volume of decisions per period.

Vendor and procurement: primary vendor or "in-house", sub-processors (foundation model providers, cloud), contract status and AI Act/CPS 230/DORA alignment, vendor risk classification.

Risk identification: 3-8 specific risks per system (not generic — "bias in demographic group X via mechanism Y", not just "bias"), risk severity (likelihood × impact), residual risk after controls.

Controls: preventive (training, design, guardrails), detective (monitoring, KRIs, alerts), corrective (rollback, escalation, remediation). Each control has a named owner.

Performance: accuracy benchmarks, false positive/negative rates, demographic disparities, monitoring cadence, last validation date, next validation due.

Incidents: material incidents linked to this system, near-misses, material changes since deployment.

How to build the register

Most organisations do not start with a complete AI inventory. The practical path follows four phases:

Discovery. Identify AI systems through structured interviews with department heads, IT inventory review, procurement records, software license reviews, and employee survey. Expect to find more AI than anticipated — vendor AI features in existing tools, individual employee AI use, embedded AI in SaaS products. Shadow AI (employees using unvetted consumer tools with company data) typically surfaces during discovery. Nearly 90% of logins to generative AI tools are made with personal accounts, invisible to organisational identity systems.

Triage. Initial classification by likely risk tier. Focus detailed documentation on high-risk and elevated-risk systems first. Map each AI system against the EU AI Act's four-tier classification and the NIST AI RMF's context-dependent risk approach. Document the classification rationale — this documentation will be required if regulators investigate.

Documentation. For each system, populate the 20-30 fields. Engage business owners, technical owners, and vendors as needed. For high-risk systems, this takes real effort — typically 2-4 hours per system for the initial documentation.

Operationalise. Integrate register updates into AI deployment processes, vendor management, and incident response. Quarterly review at minimum, with triggered review for material changes (new AI deployment, vendor change, incident, regulatory development).

Common failure modes

Stale data. Register built once and not updated. Within 6-12 months, the register no longer reflects reality. Solution: integrate register updates into AI deployment approval processes — no new AI goes live without a register entry.

Incomplete inventory. Register captures formally approved AI but misses shadow AI, embedded vendor AI, and individual employee use. Solution: ongoing discovery activities, not one-time inventory.

Generic risk statements. "Model bias" listed without specifics. What bias, against whom, how would it manifest, what would it cost? Specific risks drive specific controls.

Wrong owner. Listed owner has left the organisation or doesn't actually own the system. Solution: annual ownership verification matched against organisational chart.

Disconnected from operations. Register exists but doesn't influence decisions. The register becomes operational when board reports, vendor renewals, incidents, and audit activities all reference it.

Tools and technology

For organisations with fewer than 20 AI systems, a structured spreadsheet suffices. Beyond this scale, dedicated GRC or AI governance tooling adds value: ServiceNow, Archer, OneTrust, Drata, AuditBoard, and AI-specific tools (Holistic AI, Modulos, Credo AI, Samta.ai) offer AI risk register functionality integrated with broader governance workflows. The tooling choice matters less than the discipline of operation — a well-maintained spreadsheet is better than a sophisticated tool used inconsistently.

Integration with other governance activities

The risk register is the central document that other governance activities reference. Board AI governance reports draw the inventory summary, risk tier breakdown, and incident summary from the register. Vendor management uses the register to identify which vendors are material and when contracts expire. Incident response uses the register to identify system owners and control frameworks when incidents occur. Audit uses the register to identify systems for review. Regulatory engagement uses the register to respond to enquiries about AI inventory and governance.

The register becomes operational when these integrations are real — when board reports actually quote the register, when vendor renewals trigger register updates, when incidents update incident counts in the register. A register nobody references is governance theatre.

Primary sources: NIST AI RMF · ISO/IEC 42001:2023 · EU AI Act