An AI risk assessment template documents why a use case exists, who may be affected, what can go wrong, how likely and severe the harm may be, which controls reduce it and who accepts the residual risk. Assess the complete sociotechnical workflow, not only the model or vendor.
Use the scorer above for structured discussion, then preserve evidence behind every rating. Score inherent risk before controls and residual risk after specific controls have been implemented and tested. A mathematical average must never override an unresolved critical condition.
1. Purpose of an AI risk assessment template
The assessment helps an authorized decision-maker compare expected benefit with possible harm and uncertainty. Its output should be a decision: approve, approve with conditions, redesign, gather specific evidence or stop.
Risk tolerance is contextual. NIST’s AI Risk Management Framework is voluntary and use-case-led; it organizes outcomes around Govern, Map, Measure and Manage. Use it as a structure, not as certification of a particular system.
2. Describe the use case and boundaries
Record the purpose, intended benefit, users, affected people, input data, output, decision or action, model or service, product plan, integrations, deployment environment, geographic scope and lifecycle stage. State what the system will not do.
Map upstream data and downstream reliance. A low-risk drafting feature can become high impact if its output automatically changes a customer record or decision. Identify reasonable misuse, automation bias, unauthorized access, failure under unusual inputs and provider changes.
3. Involve the right reviewers
Name a business owner accountable for the use case and a technical owner for configuration and monitoring. Include people with security, privacy, legal, compliance, accessibility, domain, procurement and incident-response expertise where relevant. Consider the perspectives of people affected by errors or unequal performance.
Separate evidence gathering from risk acceptance. The person seeking faster deployment should not silently set the organization’s tolerance or accept residual risk outside their authority.
4. Score likelihood and impact consistently
Define scales before scoring. Likelihood should consider exposure, frequency, detectability, incentives, system behavior and control maturity. Impact should consider people, rights, safety, finances, operations, security, reputation, legal duties and reversibility.
| Score | Likelihood example | Impact example |
|---|---|---|
| 1 | Rare under expected conditions | Minor and quickly reversible |
| 2 | Possible but uncommon | Limited effect with simple correction |
| 3 | Likely during normal variation | Material harm, rework or disruption |
| 4 | Very likely without strong controls | Major effect on people or operations |
| 5 | Expected or already observed | Severe, broad or difficult to reverse |
Multiply likelihood and impact only as an aid to prioritization. Preserve the two inputs because identical products can hide different risk patterns.
5. Assess eight risk domains
- Privacy: lawful use, minimization, retention, rights and transfers.
- Security: accounts, permissions, integrations, leakage and adversarial use.
- Accuracy: factual quality, uncertainty, drift and failure detection.
- Fairness: unequal outcomes, representation, accessibility and affected groups.
- Oversight: meaningful review, authority, workload and override.
- Legal and contractual: terms, intellectual property, records and sector duties.
- Operations: availability, dependency, switching and recovery.
- Transparency: disclosure, explanation, contestability and reputation.
The ICO’s AI and data protection risk toolkit provides practical support for risks to individuals’ rights and freedoms. Where personal data is involved, determine whether a DPIA or other assessment is required.
6. Specify and test controls
A control must have an owner, implementation, evidence and expected risk effect. “Human in the loop” is incomplete: name the reviewer, information available, competence, time, authority to disagree and escalation path. “Encryption” is incomplete without scope, keys, access and plan-specific evidence.
Use the 30-day pilot framework for representative cases, edge cases, baseline and stop rules. Record failed outputs as evidence rather than removing them as exceptions.
Compare the use case with safer alternatives
Do not assess only the proposed configuration. Compare a manual process, a lower-autonomy design, less data, a smaller user group, a different product and the option not to deploy. A control that reduces benefit may still produce the best overall decision when it substantially limits exposure.
Record expected benefit with the same discipline as risk: baseline, affected volume, evidence, owner and uncertainty. Avoid accepting serious risk for a benefit described only as innovation, productivity or competitive pressure.
Maintain a risk register and decision record
For each material risk, preserve cause, event, consequence, affected people, inherent rating, controls, evidence, residual rating, owner, status and review date. Link incidents and monitoring results back to the record. Close risks only with documented reason; do not delete their history when the project changes.
Distinguish assumptions from observed facts and vendor claims. Give every unresolved evidence gap an owner and deadline so uncertainty cannot quietly become permanent acceptance.
7. Decide and monitor residual risk
Re-score after controls are implemented and tested. Identify uncertainty separately. Approval should include conditions, monitoring metrics, incident thresholds, owner, expiry and reassessment triggers. Reject the use when critical harm cannot be reduced to approved tolerance.
Reassess after material changes to purpose, users, data, model, provider, plan, integrations, autonomy, law or observed performance. Connect approved risks to the AI incident response plan.
8. Assessment examples
Internal meeting summaries
Risks include participant notice, sensitive discussion, access, retention, incorrect actions and unauthorized integrations. Controls must match the exact capture method and plan.
Customer support draft
Measure incorrect advice, disclosure, unequal service, review time and downstream records. A human reviewer helps only when they can detect errors and stop publication.
Employment screening
The use may affect rights and opportunities, requiring heightened assessment of lawfulness, fairness, explanation, human authority, evidence quality and contestability. A generic vendor score is insufficient.
Common risk-assessment mistakes
- Assessing a vendor rather than the intended use case.
- Scoring after controls without recording inherent exposure.
- Averaging away a severe risk to one group.
- Using a control label without testing effectiveness.
- Ignoring affected people, misuse and downstream reliance.
- Treating uncertainty as low likelihood.
- Approving without owner, monitoring or reassessment trigger.
AI risk assessment template FAQ
Is a high score an automatic rejection?
It is a signal to redesign, reduce exposure or add and test controls. A critical unresolved condition should stop approval regardless of the average.
What is the difference between inherent and residual risk?
Inherent risk is exposure before controls. Residual risk remains after specific controls are operating and their effectiveness has been considered.
Does this replace a DPIA?
No. Determine applicable legal and organizational assessment duties. The template may contribute evidence but is not a substitute for a required process.
Who should accept residual risk?
An authorized owner at the level required by the impact and organizational governance—not simply the tool user or project advocate.
Methodology and limitations
This AI risk assessment template uses eight domains, five-point likelihood and impact scales, critical gates and separate inherent/residual decisions. The scorer processes inputs locally and does not save or transmit them.
It is general information, not a compliance determination, safety certification or professional advice. Adapt domains, thresholds, evidence and authority to the organization, people affected, jurisdiction and consequences of failure.