How to Build an AI Risk Register: Template, Fields, and Governance Workflow

Why Generic Risk Registers Fail AI

Most organisations try to manage AI risk inside the same spreadsheet or GRC tool they use for cybersecurity, data privacy, and vendor due diligence. The logic is understandable: risk is risk, and consolidation reduces tool sprawl. But AI systems fail in ways that existing risk taxonomies were never designed to capture. A misconfigured firewall does not produce discriminatory hiring decisions. A lapsed SSL certificate does not cause cascading harm to thousands of users before anyone notices. A software vendor going offline does not rewrite its own behaviour based on new training data.

The gap shows up immediately when you try to populate a standard risk register with AI entries. Fields like 'asset owner', 'threat vector', and 'residual risk score' were built for static systems with predictable failure modes. AI models are non-deterministic, they drift over time, their outputs can be proxies for protected characteristics, and their risk profile changes every time the underlying model is updated or the use case expands. A field that said 'Low' six months ago may be 'High' today because the vendor silently shipped a new model version.

The EU AI Act makes this gap legally consequential. Article 9 requires providers of high-risk AI systems to establish a risk management system that is ongoing and iterative, not a one-time assessment filed in a drawer. Article 26 extends meaningful obligations to deployers, including the duty to implement technical and organisational measures that operationalise the provider's instructions. Neither obligation can be discharged with a generic risk log that treats AI as just another IT asset.

Building a purpose-built AI risk register is therefore not a compliance box-tick. It is the foundational data structure from which every downstream governance process flows: incident escalation, post-market monitoring, board reporting, and regulatory evidence packs. Get the structure wrong and everything built on top of it is unreliable.

The Anatomy of an AI Risk Register Entry

Before you can define the fields, you need to settle on the unit of registration. The most defensible choice for enterprise purposes is the AI use case or deployment, not the model. A single foundation model may power fifteen different internal tools, each with a distinct risk profile, a different set of affected users, and separate accountability chains. Registering at the model level collapses distinctions that matter enormously for governance. Registering at the deployment level keeps risk accountability tied to the decision context where harm actually occurs.

With that framing in place, a complete AI risk register entry needs to capture information across five logical clusters. The first is identification: a unique system ID, the business unit sponsoring the deployment, the use case description in plain language, the AI capability type (generative, predictive, classification, recommendation, agentic), and the vendor or model underpinning it. The second cluster is risk classification: the EU AI Act risk tier (unacceptable, high, limited, minimal) mapped to the specific article that triggered the classification, plus any sector-specific regulatory overlay such as DORA, MDR, or the Credit Institutions Regulation.

The third cluster is impact and likelihood scoring. Unlike cybersecurity risk, AI impact must be assessed across multiple harm dimensions simultaneously: individual harm (discrimination, financial loss, physical safety), societal harm (market distortion, democratic process), and operational harm (business continuity, reputational damage). A two-axis likelihood-by-severity matrix is the minimum; more mature organisations add a third axis for reversibility, because an AI decision that causes irreversible harm to a person is categorically different from one that causes recoverable financial loss.

The fourth cluster is control state: which mitigations are in place, who owns them, and whether they have been tested. The fifth is accountability metadata: the human oversight contact, the escalation path, the date of last review, and the next scheduled review trigger. Every field should have a defined owner, not just a value. A register full of accurate data with no named steward is a compliance artefact, not an operating governance tool.

Scoring AI Risk: A Framework That Holds Up Under Scrutiny

Risk scoring for AI is where most register templates collapse into subjectivity. Teams assign a number, nobody can explain the methodology, and the score becomes meaningless the moment a regulator or auditor asks how it was derived. A defensible scoring framework requires four decisions made explicitly before any system is assessed.

First, define your harm taxonomy. The EU AI Act Annex III and the accompanying NANDO guidance provide a starting point for high-risk categories, but your internal taxonomy needs to go further. Map each use case to the specific population affected, the nature of the decision or output, and whether the AI output is the sole basis for action or one input among many. A model scoring credit applications where the output is the direct lending decision carries fundamentally different risk than a model flagging anomalies for human analysts to review.

Second, set your likelihood scale explicitly. A five-point scale anchored to empirical frequencies works better than vague qualitative labels. Likelihood 1 means fewer than one incident per hundred thousand inferences based on red-team or historical data. Likelihood 5 means the harm mode has already been observed in production or in a materially similar deployment. Anchoring to observed data forces teams to go find evidence rather than guess.

Third, define your severity scale against real-world consequences. Severity 1 is inconvenience with no lasting effect. Severity 5 is irreversible harm to a fundamental right, loss of life, or systemic market disruption. The EU AI Act's prohibited practices under Article 5 are all effectively severity 5 by definition: no likelihood score makes them acceptable.

Fourth, decide your risk appetite threshold before scoring begins, not after. If the organisation's threshold is that no deployment with a combined score above 15 on a 25-point matrix proceeds without board-level sign-off, document that policy in the register governance rules and apply it consistently. Retroactively adjusting thresholds to avoid triggering escalation is the single most common governance failure mode.

Mandatory Fields for EU AI Act Compliance

If your organisation deploys AI systems that fall within the EU AI Act's scope, the risk register must do more than satisfy internal governance. It must generate or point to the evidence a deployer needs to demonstrate compliance with specific articles. This changes which fields are mandatory versus optional.

Article 26 requires deployers of high-risk AI systems to ensure that human oversight is technically feasible and actually implemented. Your register entry must therefore include a human oversight field that specifies not just that oversight exists, but the mechanism: is it pre-deployment approval, real-time monitoring, post-hoc audit, or some combination? Who holds the override authority? What is the documented response time for flagged outputs? Vague statements that 'a human reviews decisions' will not satisfy a supervisory authority conducting a post-market review.

Article 27 introduced the deployer obligation to conduct a Fundamental Rights Impact Assessment for certain high-risk systems where the deployer is a public authority or operates critical infrastructure. The risk register entry should include a FRIA status field with four possible states: not required, required and pending, in progress, and completed with document reference. Connecting the register entry to the FRIA output document closes the evidence chain. Fronterio's FRIA wizard generates structured outputs that can be linked directly to the corresponding register record, which eliminates the manual cross-referencing that typically creates audit gaps.

Article 72 and Article 73 address post-market monitoring and serious incident reporting respectively. For high-risk systems, your register must include a post-market monitoring plan reference and an incident log link. Article 73 specifies that serious incidents and malfunctions that constitute a breach of fundamental rights obligations must be reported to the relevant national authority without undue delay. The register entry needs a field that captures whether Article 73 reporting obligations apply, the relevant national authority, and the current incident status. Having this field populated in advance means that when an incident occurs, the escalation path is already defined rather than improvised under pressure.

The Governance Workflow That Keeps the Register Alive

A risk register is not a document. It is a living process, and without a defined governance workflow, even a perfectly structured register degrades into stale data within months. The workflow must answer four operational questions: who can create an entry, who reviews and approves risk assessments, what triggers a mandatory review, and who is accountable for keeping the record current.

Entry creation should be demand-driven and gated. Any team proposing a new AI deployment should be required to submit a register entry before the deployment receives technical resource or budget approval. This intake step is the moment where AI risk is most efficiently addressed: before the system is built or procured, when changing course costs nothing. The intake form should auto-populate the risk tier based on use case type and the answers to a structured questionnaire aligned to Annex III criteria, so that teams are not expected to interpret the regulation themselves.

Approval workflow should be tiered to risk level. Minimal-risk systems might require only the AI lead's sign-off. Limited-risk systems require the data protection or legal team. High-risk systems require a formal review panel that includes the AI lead, the CISO, legal, and a business sponsor. This tiering prevents the governance process from becoming a bottleneck for low-stakes tools while ensuring that consequential deployments receive proportionate scrutiny.

Mandatory review triggers must be defined in advance and enforced systematically. The five standard triggers are: scheduled periodic review (at minimum annually for high-risk systems), a model version update by the provider, a material change in the use case or affected population, a new regulatory development that changes the risk tier, and any incident or near-miss logged against the system. Fronterio's deployer obligations tracker monitors provider update feeds and flags when a model version change should trigger a register review, which addresses one of the most common gaps in manually maintained registers.

Finally, assign a named register steward to every entry. Not a team, a named individual. This person is accountable for the accuracy of the record, the completion of review actions, and the escalation of any change that affects the risk tier. Distributing stewardship across a team without naming an individual creates diffuse accountability that evaporates when an audit question arrives.

Connecting the Risk Register to Post-Market Monitoring

One of the most significant differences between an AI risk register and a conventional IT risk log is the need to connect static risk assessments to live operational data. A firewall's risk profile does not change between assessments unless a new vulnerability is disclosed. An AI model's effective risk profile can shift continuously as the distribution of real-world inputs drifts from the training distribution, as user behaviour adapts to the system's outputs, or as the social context in which the model operates changes. A risk register that is only updated at scheduled intervals will systematically lag behind the actual risk state of deployed systems.

Post-market monitoring under Article 72 is the EU AI Act's mechanism for addressing this gap. Providers of high-risk AI systems must have a post-market monitoring plan, and deployers must feed relevant operational data back to the provider. But the practical implication for deployers is that they need their own monitoring capability, because the provider's plan covers the model in the aggregate, not the specific deployment context that the deployer controls.

The connection between the risk register and post-market monitoring should be structural, not manual. Each high-risk register entry should link to a set of monitored metrics that serve as leading indicators for the risk dimensions identified in the assessment. For a predictive model used in HR, those metrics might include output distribution by demographic group, decision reversal rates by oversight reviewers, and volume of user complaints. For a customer-facing generative AI, they might include harmful output detection rates, refusal rates, and escalation-to-human frequency.

When a monitored metric crosses a defined threshold, the governance workflow should automatically trigger a register review rather than waiting for the next scheduled cycle. Fronterio's post-market monitoring synthesiser aggregates signals from model outputs, user feedback channels, and provider release notes into a unified dashboard, and can surface register review recommendations when metric thresholds are breached. This closes the loop between the static governance record and the dynamic operational reality in a way that purely manual processes cannot sustain at enterprise scale.

From Register to Audit-Ready Evidence Pack

Regulators and auditors do not read risk registers. They review evidence that the register was used as a genuine governance instrument, not assembled retrospectively. The difference between a register that satisfies internal comfort and one that satisfies external scrutiny comes down to three things: completeness of the audit trail, linkage between register entries and downstream decisions, and evidence that the workflow operated as documented.

Completeness of the audit trail means that every change to a register entry is timestamped, attributed to a named individual, and accompanied by a reason for the change. A risk tier that moves from High to Medium must be justified by documented evidence, not just overwritten. Version history must be preserved and retrievable. This is a technical requirement that rules out basic spreadsheet-based registers at any meaningful scale: the version history of a shared spreadsheet is not an audit trail.

Linkage between register entries and downstream decisions means that the register entry is referenced in deployment approval records, FRIA outputs, incident reports, and board governance packs. The register is the source of truth that those documents draw from, and the evidence pack demonstrates that chain. Fronterio's auto-evidence ladder assembles these linkages automatically as governance actions are completed, generating a structured evidence pack that maps each register field to the relevant regulatory article and the document that satisfies it.

Evidence that the workflow operated as documented means that review logs show reviews actually occurred on schedule, that escalations were triggered when thresholds were crossed, and that named stewards responded within the defined windows. A governance policy that says reviews happen quarterly but a register that shows the last review was eighteen months ago is worse than no policy at all, because it demonstrates that the organisation has identified its obligations and ignored them.

The standard to aim for is that any competent external auditor could pick up the evidence pack for any register entry and reconstruct the full governance history of that deployment without asking a single clarifying question. That standard is achievable, but it requires treating the register as an operational system from day one rather than a compliance deliverable produced at year-end.

Getting Started: A Practical Implementation Sequence

The biggest implementation failure mode for AI risk registers is scope paralysis: teams try to register every AI tool simultaneously and produce an overwhelming, inconsistently populated record that nobody trusts. A staged implementation sequence produces a working register faster and builds internal capability that sustains the programme.

Start with your highest-risk deployments. If any of your systems fall within Annex III categories, these are your mandatory starting point under the EU AI Act regardless of organisational preference. Run a structured intake exercise with the business units responsible for these systems, using a fixed questionnaire that maps directly to the register fields defined above. Aim for complete, reviewed entries for these systems before expanding scope. A register with five complete, accurate, reviewed entries is more governance value than one with fifty incomplete stubs.

In parallel, establish the governance workflow as a formal process with documented owners before it is tested under pressure. Define the intake gate, the tiered approval process, the review triggers, and the stewardship assignment rules. Get these agreed at the level of the AI governance committee or equivalent body so they carry authority rather than being informal team conventions.

In the second phase, expand to all active AI deployments, prioritised by risk tier output from the intake questionnaire. This is typically where organisations encounter the shadow AI problem: systems that are in production but have never been formally registered. A discovery exercise using network monitoring, software asset management data, and a self-declaration process from business units is often necessary to surface these. Each discovery feeds a new register entry and triggers the intake workflow.

By the third phase, the register should be integrated into procurement and project approval processes so that no new AI deployment can be approved without a corresponding register entry. This is the point at which the register shifts from a remediation exercise to an operating governance control. The measure of success is not the number of entries but the percentage of active AI deployments with a complete, current, reviewed record. Fronterio's agent register and governance workflow features are designed to support exactly this maturation arc, from initial intake through to continuous monitoring at enterprise scale.