AI Risk Assessment Template: Naming What Could Go Wrong

A risk assessment is useful when it names concrete failures and who they harm. This template covers writing one, drawn from FISTA Solutions' AI enablement governance work. This is general guidance, not legal advice.

What does each entry contain?

Six fields per scenario.

Field	What it establishes
Scenario	What concretely happens
Affected party	Who is harmed
Likelihood	How often, with a basis
Impact	How bad, in what terms
Mitigation	What reduces it, and its status
Residual and accepter	What remains, and who accepts

Scenario identification

Concrete and specific.

• Scenarios described as events, not as categories
• Failure modes from similar systems reviewed
• Harm from correct behaviour included
• Adversarial scenarios included
• Scenarios from actual incidents included
• Input from people who do the work manually
• Scenarios reviewed by someone outside the build team

Affected parties

Who is harmed determines the mitigation.

• Customers and end users considered
• Employees affected by the system's output considered
• Third parties considered
• Groups who may be disproportionately affected identified
• Business harm stated separately from harm to people
• Regulatory exposure noted
• Reputational harm noted where material

Likelihood and impact

With a stated basis, however rough.

• Likelihood estimated with the basis stated
• Evaluation results used where they inform likelihood
• Impact expressed in concrete terms, not a score alone
• Worst case stated as well as typical case
• Volume considered: a rare error at scale is frequent
• Detectability assessed; undetected harm is worse
• Reversibility assessed

Mitigations

Implemented, not planned.

• Each mitigation named and its status recorded
• Preventive and detective controls distinguished
• Human review points identified where used as mitigation
• Limits and permission constraints listed
• Monitoring that would detect the scenario identified
• Owner named per mitigation
• Planned mitigations dated and tracked

Residual risk and acceptance

The step that closes the assessment.

• Residual risk stated per scenario after mitigation
• Accepter named with their role
• Acceptance dated
• Conditions on the acceptance recorded
• Scenarios not accepted escalated
• Review date set
• Assessment stored where governance can find it

Maintenance

Assessments age with the system.

• Revisited when scope or capability changes
• Revisited after any incident
• Revisited on material model or provider change
• Reviewed at least annually
• New scenarios added from production experience
• Mitigations verified as still in place
• Accepter confirmed still in post

What are the most common failures?

Abstract categories instead of scenarios. Harm to the business only. Mitigations that are plans. No named accepter. And an assessment written once for approval and never revisited.

Who should own this?

The business owner of the system owns the assessment and accepts the residual risk; risk or governance functions review the method; engineering supplies technical input.

How often should it run?

Before launch, on material change, after incidents, and annually. A capability or scope expansion should trigger a full revisit rather than an amendment.

What evidence should it produce?

The dated assessment with named accepters, mitigation status records, and revisions triggered by changes and incidents.

How does this connect to bias and explainability work?

They feed it. Disparate outcomes and inability to explain a decision are both risk scenarios, and the assessments that find them should produce entries here.

Keeping them separate produces three documents nobody reconciles. The risk assessment should be where the findings land with an owner and an acceptance. See AI bias testing checklist.

What should you do first?

Write one concrete failure scenario for your main AI system, naming who is harmed. That single entry usually reveals whether the mitigations are real.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: risk written as concrete scenarios naming who is harmed, with mitigations verified as implemented and residual risk accepted by a named person, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI governance framework.