IAPP AIGP: Building an AI Risk Register
An AI risk register should help teams decide what to change, not become a catalog of everything that could theoretically go wrong with artificial intelligence. The most useful entries connect a concrete scenario to an affected objective, owner, evidence, control plan, and residual exposure. If a risk cannot influence a design, approval, monitoring threshold, contract, or operating decision, the register is probably too abstract.
The current AIGP materials emphasize governance across the AI lifecycle, which means risk identification cannot stop at model development. Deployment context, data, users, vendors, monitoring, human oversight, misuse, and downstream decisions all change the exposure. A risk register should follow those relationships rather than organize everything around a generic list of AI ethics principles.
Within AI governance, the register becomes a bridge between technical evidence and accountable business decisions. It gives governance teams a shared view of what matters, what is being done, who can accept what remains, and which signals should trigger reassessment.
Write risks as scenarios with consequences
A useful risk statement connects cause, event, and impact. “Hallucination risk” is too broad. “The customer-support assistant may generate an incorrect refund instruction when the retrieval index is stale, causing unauthorized credits and inconsistent treatment” gives the team something it can evaluate and control.
Scenario language also prevents duplicate categories from hiding the same issue. “Bias,” “fairness,” and “discrimination” can overlap, but the operational scenarios may be different: an eligibility model producing disparate denial rates, a language model generating offensive text, or a recruiting tool excluding qualified candidates because of proxy features.
Enterprise risk registers work better when entries are decision-relevant. The same discipline applies to AI: describe the actual loss path, not only the label.
Separate inherent and residual exposure
Inherent risk describes the exposure before controls; residual risk describes what remains after controls that are actually implemented and operating. This separation matters because teams can otherwise confuse planned safeguards with real safeguards and report an artificially low risk.
For each major control, record the evidence that supports effectiveness. A content filter may reduce one class of harmful output but not protect retrieval permissions. Human review may help only if reviewers have enough time and authority. A contract may allocate liability without reducing operational disruption. Control names alone do not justify a lower score.
Business impact should determine how residual exposure is interpreted. The same probability can be acceptable in a low-consequence use case and unacceptable where legal rights, safety, or major financial decisions are involved.
Use a small, explicit scoring model
Risk scoring should support prioritization without pretending to mathematical precision that the evidence cannot support. A simple model may consider likelihood and impact, while more mature programs may include scale, reversibility, affected population, sensitivity, autonomy, external visibility, and control strength.
Define the scales in observable terms. “High impact” might mean regulatory reporting, physical harm, material financial loss, or broad customer exposure. “High likelihood” should be tied to evidence such as evaluation failures, incident frequency, known model behavior, or operating conditions rather than intuition alone.
Keep room for qualitative judgment. Emerging AI risks often have limited historical data, and correlated failures can make neat numeric scores misleading. The scoring system should organize discussion, not replace professional judgment.
Connect risks to lifecycle evidence
A risk register should point to evidence rather than duplicate it. Data-quality risk can link to lineage and quality checks. Model performance risk can link to evaluation results. Security risk can link to architecture and testing. Vendor risk can link to assessments and contracts. Privacy risk can link to processing records and impact assessments.
Model registries can provide technical lineage for model versions, but the risk register should explain the business consequence of a model change. Technical inventory and enterprise risk serve different purposes and should reference each other.
Use stable identifiers so incidents, controls, tests, exceptions, and approvals can reference the same risk. This makes it possible to answer whether a known exposure was accepted, mitigated, or simply lost between tools.
Include misuse and human behavior
AI risk is not limited to model defects. Users can prompt systems in unintended ways, rely on outputs beyond the approved purpose, copy sensitive information into tools, bypass review, or create shadow workflows outside governance. Those scenarios belong in the register when they could materially affect the objective.
Human oversight can itself create risk if people become overly reliant on recommendations, lack the expertise to review them, or face incentives to approve quickly. The register should describe the conditions under which oversight is expected to work rather than treating “human in the loop” as an automatic control.
AI security also expands the scenario set to manipulation, data leakage, prompt attacks, model abuse, and other security concerns. Risk entries should reflect the system architecture and threat model instead of using one generic cyber-risk row.
Treat third parties as part of the risk model
A third-party model introduces dependencies on data handling, security practices, model updates, service continuity, subcontractors, geographic processing, monitoring information, and contractual remedies. The risk register should capture the consequence if those dependencies fail, not merely record that a vendor exists.
Third-party risk is particularly useful because a change at the supplier can alter the organization’s residual risk without any internal code change. A new model version or retention policy can justify reassessment.
Record what evidence can be obtained from the supplier and what remains opaque. Unknowns should be visible. If a high-impact use depends on a behavior that the supplier will not document or contractually support, that uncertainty is itself part of the decision.
Set triggers for reassessment
AI systems evolve quickly, so a risk register that is reviewed only annually will drift away from reality. Define triggers such as model replacement, new training or retrieval data, new automation capability, material prompt change, vendor update, incident, performance degradation, user expansion, or regulatory change.
Governance drift often appears when the system changes faster than the control record. Reassessment triggers should be tied to the deployment pipeline and service-management process so governance receives the change signal automatically where possible.
Close risks when the scenario no longer exists, but preserve the reason. If a feature was removed, a vendor changed, or evidence showed that an assumed failure mode is not relevant, the history can prevent the same debate from starting again without context.
Use the register in governance meetings
Teams pursuing IAPP certifications should treat the register as an operating artifact. Governance reviews can focus on the highest residual exposures, overdue controls, deteriorating indicators, open exceptions, and decisions that require senior acceptance rather than rereading every row.
Trend the portfolio as well as individual risks. Several medium risks may share the same dependency, such as one vendor, identity service, or data platform. Concentration can create enterprise exposure that is not obvious when each AI system is reviewed separately.
The register is strongest when it links to action: fund a mitigation, narrow a use case, add evaluation, change a contract, require human review, improve monitoring, or decide not to deploy. If it does not change decisions, simplify it until it does.
A strong AI risk register is a map of decision-relevant uncertainty. It describes concrete failure scenarios, connects them to business impact and evidence, names the owner, and shows how controls change the residual exposure.
That makes the register useful before approval and after launch, when changing models, data, users, and vendors require the organization to revisit what it thought it knew.
Link indicators to thresholds and owners
A risk register becomes more operational when major risks have indicators and thresholds. For a retrieval assistant, indicators might include stale-source rate, access-control failures, unsupported-answer frequency, or high-severity user reports. For an automated decision system, they may include performance by important population slices, override rates, or unusual input drift.
Each threshold should name the response owner and action. A metric that turns red without changing behavior is decoration. The response may trigger investigation, tighter limits, rollback, human review, vendor escalation, or temporary suspension depending on the consequence.
Indicators also reveal whether a mitigation is working. If a control was expected to reduce a risk but the relevant signal does not improve, the residual-risk assessment should be revisited instead of assuming the control is effective because it was implemented.
Distinguish risk from issues and control gaps
Keep the register focused on uncertainty. A control that is definitely missing is a gap to remediate; an incident that has already occurred is an issue to manage; a known defect is a defect. Those items can create future risk, but calling everything a risk makes ownership and status harder to interpret.
Link the records instead. An incident can increase the likelihood estimate of a related risk. A failed control test can weaken the residual-risk rating. A remediation task can reduce the exposure when completed and evidenced. The register then becomes part of a connected governance system rather than a universal ticket queue.
This distinction also improves reporting. Leaders can see what might happen, what has already happened, what control is deficient, and what action is underway without mixing different management problems into one score.