A risk register that says “bias”, “privacy” and “security” is not an AI governance artefact. It is a prompt for further work. To build an AI risk register that can support legal review, board oversight and an external audit, each entry must connect a specific AI system and use case to a defined harm, applicable obligation, accountable owner, treatment decision and retained evidence.
That distinction matters because AI risk is not held in one place. A model may be developed by a vendor, configured by IT, used by a business team and overseen by compliance. Spreadsheets usually capture the issue but lose the chain of accountability. A usable register makes that chain visible.
What an AI risk register must do
An AI risk register is the operational record of risks created by, or materially affected by, an AI system across its lifecycle. It should not be confused with an AI inventory. The inventory answers what systems exist, who uses them, what they do and where they are deployed. The risk register records what may go wrong, who is responsible for responding, and whether the response is working.
For organisations operating in Europe, the register should support more than internal risk management. It needs to evidence proportionate governance against the EU AI Act, particularly where a system may be prohibited, high-risk or subject to transparency obligations. It should also support the AI risk assessment and treatment process required by ISO/IEC 42001 clauses 8.2 and 8.3.
This does not mean every low-impact productivity tool requires the same volume of assessment as an AI system supporting recruitment, creditworthiness or access to essential services. It means the depth of the entry should follow the use case, role in the AI value chain, affected people, data sensitivity and potential consequence of failure.
Start with the AI system, not a generic risk library
A common failure is to copy a generic technology risk library into a new tab and label it “AI”. Risks such as cyber attack, data loss and supplier failure remain relevant, but AI introduces system-specific concerns: performance drift, inappropriate reliance on outputs, opaque decision logic, unfair outcomes, training data provenance, model changes and misuse beyond the approved purpose.
Create the register from an authoritative AI inventory. Give each risk a unique identifier and link it to the relevant system record, version, supplier and business use case. If one foundation model supports several internal applications, assess the applications separately where their users, decisions, data or impacts differ.
A customer service assistant that drafts responses may present manageable information-quality and data-handling risks. The same model used to rank job applicants creates a different risk profile because its output influences individuals’ access to employment. Treating both as “generative AI risk” conceals the decision that matters.
Establish legal classification before scoring risk
Risk scoring should not replace legal classification. Under the EU AI Act, an organisation must first consider whether a practice falls within a prohibition under Article 5, whether the system is high-risk under Article 6 and Annex III, or whether transparency duties under Article 50 apply. The organisation must also establish whether it acts as a provider, deployer, importer, distributor or authorised representative.
These findings should be recorded against the system and referenced from each linked risk. A high residual score may justify stronger controls, but it does not determine whether an AI system is legally high-risk. Keep these decisions separate and traceable.
Define the fields that make a register actionable
The register should be structured enough to produce a defensible answer when a regulator, auditor or executive asks: what was known, who accepted the exposure, and what evidence supports that position?
At minimum, every risk entry should capture:
- the linked AI system, use case, business process, lifecycle stage and affected stakeholder group;
- a precise risk statement describing cause, event and consequence;
- inherent likelihood and impact, with a documented scoring methodology;
- relevant legal, contractual and policy obligations, including EU AI Act articles and ISO/IEC 42001 control references where applicable;
- existing controls, control owner, evidence location and an assessment of control effectiveness;
- residual risk, treatment action, action owner, target date, review cadence and formal acceptance where risk remains.
The risk statement is where discipline begins. “Model bias” is too vague to treat. A more useful statement is: “Where historical recruitment data contains demographic imbalance, the candidate-ranking model may produce systematically less favourable recommendations for protected groups, resulting in discriminatory outcomes, legal challenge and reputational harm.” It identifies the source, the failure mode and the consequence.
Use a consistent scoring model, but do not pretend that a numerical score removes judgement. A five-by-five matrix can be practical if scoring criteria are defined. For AI systems, impact criteria should include harm to individuals, fundamental rights, safety, financial detriment, operational disruption, regulatory exposure and reversibility. A wrong recommendation that is reviewed before action is not equivalent to an automated adverse decision with no meaningful human intervention.
Map controls to risks, then retain proof
A control is not “we have a policy”. A policy may establish intent, but a control needs an operating mechanism that can be tested. For an AI system, that may include pre-deployment validation, access restrictions, approval gates, human review procedures, logging, incident handling, user training, supplier assurance and scheduled performance monitoring.
Map each control to one or more risks and specify how it operates. If a human oversight control is relied upon, define who reviews outputs, what competence they need, when they can override the system and how overrides are recorded. “Human in the loop” is not evidence by itself.
Evidence should be attached or referenced at the control and risk level: impact assessments, test results, fairness analyses, model cards, technical documentation, supplier due diligence, approval records, monitoring reports, training completion records and incident logs. Version dates matter. An assessment conducted before a material model update may no longer support the current residual-risk decision.
This is the point at which spreadsheet-led programmes usually become fragile. Files become detached from decisions, ownership is overwritten, and no one can show which evidence was available when the system was approved. A dedicated governance system of record, such as Endaxi AIG, keeps inventory records, classifications, risks, controls and audit evidence connected rather than distributed across folders and email chains.
Assign ownership at three levels
One named “AI owner” is rarely enough. Effective registers distinguish between the business owner, who is accountable for the use case and its benefits; the risk owner, who owns the treatment decision and residual-risk acceptance; and the control owner, who operates a specific safeguard.
The same individual may hold more than one role in a smaller organisation, but the distinctions should remain explicit. They prevent an IT team from becoming accountable for business decisions, or a compliance team from being assumed to operate technical controls it cannot test.
Escalation thresholds should also be defined. For example, high residual risks, unresolved supplier evidence gaps, suspected fundamental-rights impacts, significant performance degradation and material changes to intended purpose should trigger review by the appropriate governance forum. The register then becomes a management mechanism, not an archive.
Build review into the AI lifecycle
A register prepared for a launch approval and never revisited will fail when the system changes. Review events should include model replacement, significant prompt or configuration changes, new data sources, expansion to a new geography or user group, a new decision purpose, supplier notices, incidents and monitoring thresholds being breached.
Set a routine review interval as well, proportionate to the system’s classification and residual risk. High-impact systems may require monthly performance and control monitoring, while a low-risk internal tool may justify a quarterly or annual review. What matters is that the cadence is documented and overdue actions are visible.
Monitoring should test the assumptions behind the original assessment. If human reviewers increasingly accept outputs without challenge, the oversight control may be weakening. If a supplier changes the underlying model, accuracy, explainability, data-processing and security assumptions may all need reassessment. A register that records only original risks cannot identify this drift.
Make board reporting a by-product, not a manual exercise
Senior stakeholders do not need every risk row. They need a clear view of exposure, movement and decisions requiring attention. A well-maintained register can produce concise reporting on the number of AI systems by legal classification, high and critical residual risks, overdue treatments, control effectiveness, incidents, material supplier dependencies and risks accepted outside appetite.
The underlying detail must remain available. Board reporting without drill-down evidence creates false confidence, while a register with no executive view fails to secure decisions and resources. The answer is a single record with different levels of reporting, not separate spreadsheets for every audience.
The practical test is simple: choose one deployed AI use case and ask whether your organisation can trace it from inventory entry to legal classification, risk assessment, control evidence, approval and latest review. If that trail cannot be produced quickly, the immediate priority is not another policy. It is building the register into the way AI is actually governed.