TL;DR
An AI risk assessment template is a short record that scores the risks of one AI use case and decides whether it can go live. It splits into three blocks, a use-case profile, a risk register and a decision log. Each risk scenario gets an impact score and a likelihood score on anchored 1 to 5 scales, before and after controls. A tiering rule then sorts the use case into Low, Medium or High, after a gate that stops prohibited uses outright. The tier then decides who approves, what evidence is needed and how often the record is reviewed. The matrix and thresholds shown here are an illustrative policy, because neither NIST nor the EU AI Act prescribes one.
Key Takeaways An AI risk assessment template covers one use case rather than a whole platform, in three blocks of profile, risk register and decision log. Record the autonomy level as real permissions, because an agent that issues refunds carries more risk than one that drafts replies. Score impact and likelihood on anchored 1 to 5 scales, then tier on the highest material scenario, never an average. Run a prohibited-practice gate and forced-High triggers before any score counts, so a good number cannot approve a banned use. Keep the internal tier separate from the EU AI Act classification, since the two answer different questions. Tie approval to the assessed configuration, so a model swap, new data source or new tool reopens the assessment. Watch on YouTube
AI Agent Access Control: From Excessive Agency to Least Privilege
How to move AI agents from broad access to least privilege, the permissions question behind the autonomy field in every AI risk assessment.
362 Documented AI Incidents and the Intake Form That Should Catch the Next One
Stanford HAI’s 2026 AI Index counted 362 documented AI incidents, up from 233 in 2024. Those are reported cases rather than a failure rate. Even so, many of them trace back to a deployment that someone approved.
Picture the request that lands on a risk lead’s desk this week. The support team wants an agent that reads order history and issues refunds, and they want it live before the quarter ends. But nobody in the room knows which questions to ask, what score would be too high or who is allowed to say yes.
A good AI risk assessment template helps because it turns that meeting into a repeatable decision. Otherwise, the outcome depends on whoever argues hardest.
What Is an AI Risk Assessment Template (and What It Is Not)?
An AI risk assessment template is a structured record for one AI use case. It describes the system, lists what could go wrong, scores each scenario and captures the decision to approve, condition or reject it.
The unit of assessment is the use case rather than the platform. In practice, a use case is a business process, the AI component inside it, the people it affects and the actions it may take. So a chatbot platform with twelve deployments needs twelve assessments, because each one reads different data and reaches different people.
When to Run the Assessment
Run the assessment at three moments. The first is before a pilot gets access to sensitive data, and the second is before production. The third comes after any material change, such as a new model, a new data source or wider permissions.
One rule keeps the record honest: every score must point to something a reviewer can check. That might be an assumption, a test result, a control or the person who signed off.
How It Differs From Other AI Governance Records
In practice, the template sits beside other governance records without replacing them. The table shows where each one starts and stops.
Record Question it answers Unit Where it lives AI risk assessment (this template) Should this use case go live, and under what conditions? One use case This guide AI governance assessment How mature is the whole governance program? The organization AI governance assessment guide AI security assessment Do the technical controls hold up in testing? The system’s security controls AI security assessment checklist AI threat modeling How could this design be attacked? The architecture AI threat modeling method AI vendor risk assessment Can we trust the supplier and its model? The vendor A separate vendor due-diligence record AI system impact assessment or FRIA How does the system affect people’s rights? The people affected ISO/IEC 42001 clause 6.1.4, or EU AI Act Article 27
Data governance still owns the quality, lineage and access rules of the data the use case reads. The split between the two programs is set out in AI governance vs data governance , so the template simply records which data owner signed off. When the bigger question is whether your program can support per-use-case reviews at all, start with a maturity check.
AI Assessment
Check Whether Your AI Program Is Ready for Use-Case Reviews
Score your organization’s AI maturity across data, governance and security to see where per-use-case risk reviews will hold and where groundwork comes first.
Start Your AI Assessment → The AI Risk Assessment Template: Fields to Copy Into Excel or Sheets
The template is a spreadsheet. Copy the field names below into Excel or Google Sheets and the structure carries over, so no special download is needed.
Set Up Three Tabs Joined by One Assessment ID
To begin with, use one tab for the use-case profile, one for the risk register and one for the decision log. A single assessment ID, such as AIRA-2026-014, joins all three. That ID also links the record to later re-assessments, so the history stays intact instead of being overwritten.
Block A, the Use-Case Profile
First, the profile describes what is being approved. Keep it factual and short, because reviewers read it first and decide from it how deep the review must go.
Field What to write Example (refund agent, illustrative) Assessment ID Unique ID shared across all three tabs AIRA-2026-014 Use case and purpose The business task, plus uses that are out of scope Answer order questions and issue small refunds; no account closures Business owner The person accountable for the outcome Head of Customer Support Technical owner The person who can change or stop the system Support platform engineering lead Model type and version Predictive, generative, RAG or agent, with the exact version LLM agent on a hosted model, pinned to one version Source Built in-house, bought, or embedded in a SaaS tool Built in-house on a model API Data used and sensitivity Data sets, personal data, confidential data Order history, names, contact details, payment status Connected tools and permissions Every system it reads from or writes to CRM read, refund API write, ticket hand-off Autonomy level One of four levels, plus the real permissions Acts alone within limits Affected people and scale Who is affected, and roughly how many Retail customers, about 40,000 chats a month Jurisdictions Where users are and where outputs are used United States and EU
Also, a bought or embedded tool brings its supplier’s controls into the picture. Those controls belong in a separate vendor assessment, so the profile only records the source and that assessment’s reference. That keeps supplier questionnaires out of the use-case record.
The Autonomy Level Field
Autonomy is the field many published templates leave out, yet it changes risk more than the choice of model does. Use four levels. The system either suggests, drafts for a human to send, acts once a human approves, or acts alone within set limits.
Describe the actual permissions rather than the vendor’s label. A word like “agentic” says little, whereas “can call the refund API for amounts up to $50” tells a reviewer exactly what can go wrong. The same logic sits behind least-privilege security for AI agents .
Block B, the Risk Register Row
Each row in the register is one scenario, written so that a non-specialist can follow it. For example, “The agent issues a refund larger than the order value” is a scenario. In contrast, “hallucination” is a category, and it belongs in its own column.
Column What goes in it Risk ID R1, R2 and so on, under the assessment ID Scenario What happens, to whom, and through which path Category One of the eight categories in the next section Affected person or asset Customer, employee, company funds or a record Impact (1 to 5) Scored against the impact anchors Likelihood (1 to 5) Scored against the likelihood anchors Inherent score Impact times likelihood, before controls Controls What reduces impact or likelihood Control evidence Link to a test result, log or configuration Residual score Rescored only when evidence exists Treatment Mitigate, transfer, avoid or accept
The four treatment options come straight from the NIST AI RMF Core . There, Manage 1.3 lists mitigating, transferring, avoiding or accepting a risk as valid responses. Manage 1.4 then asks for remaining negative risks to be documented.
Block C, the Decision Log
Finally, the decision log records what was approved and under which conditions. It holds the internal tier, the EU AI Act status, the impact-assessment flag, the approver, the decision and its conditions. It also stores the approved configuration, the next review date and the event triggers that reopen the file.
The Row Most Templates Skip
After that, add one more row for the kill switch. In it, name the person who can turn the system off, the method they use and how long it takes. Then record what retires the use case, whether that is an end date, a replacement or a failed review.
Which Risks Should Every AI Use Case Be Checked For?
Eight risk categories cover the failures that enterprise use cases run into, such as wrong answers, leaks and attacks. Walk through each one in every assessment, even when the answer is “not applicable”, because a skipped category reads as an unchecked one.
Category What failure looks like Question to ask Typical control Accuracy and hallucination Confident, wrong answers Where does the answer come from, and can it be checked? Retrieval from approved sources with citations Bias and unfair outcomes Groups treated differently Does output differ by protected attribute? Fairness testing before launch, then on samples Privacy and data leakage Personal data shown to the wrong person Can one user’s prompt reach another user’s data? Per-user data scoping and masking Security Prompt injection, excessive agency What could an attacker make it do? Tool allow-lists, input and output filters Transparency People unaware they are dealing with AI Are users told, where the law requires it? Disclosure notice in the interface Over-reliance Staff approve output without reading it Will reviewers check, or just click approve? Sampling and deliberate friction on big actions Operational Outages and runaway cost What happens when it fails or usage spikes? Fallback queue and spend caps Legal and IP Output that breaks a contract or reuses protected work Who owns the output, and what does it draw on? Legal review and content filters
Where the Security Rows Come From
Security rows deserve the deepest work, and they should come from a threat model rather than guesswork. A threat model walks the data-flow diagram to find attack paths, and each serious threat then becomes a scenario row here. For the accuracy rows, the patterns behind AI hallucinations help teams write realistic scenarios, while AI privacy risks cover the leakage side.
Kanerika Service
AI Governance Consulting Services
Kanerika’s AI governance services cover bias and fairness auditing, LLMOps controls such as prompt injection protection and hallucination monitoring, and risk tiering with clear ownership.
Explore AI Governance Services How to Score AI Risk With Impact and Likelihood Anchors
Scoring multiplies two numbers, impact and likelihood, each on a 1 to 5 scale. The NIST AI RMF asks organizations to record the likelihood and magnitude of each identified impact (Map 5.1). It then asks them to prioritize treatment on that basis (Manage 1.2). It stops there, though, so the anchors and bands below are an illustrative policy for you to adapt.
Impact Anchors
Anchors matter because scores otherwise drift with the mood of the room. Each level below describes a concrete consequence across four dimensions, so assessors pick the highest one that applies.
Score Money People Legal and regulatory Operations 1 Minimal Loss absorbed in normal variance Minor inconvenience, easily fixed No obligation touched Brief slowdown, no customer effect 2 Minor Small, recoverable loss Annoyance for a few people Internal policy breach Workaround needed for hours 3 Moderate Loss that needs a manager’s sign-off Wrong information that shapes a decision Possible complaint or audit finding A team’s work stops for a day 4 Major Loss reported to leadership Harm to many people, or real harm to one Likely regulatory breach A customer-facing process stops 5 Severe Material financial loss Serious harm to rights, safety or livelihood Enforcement action or a prohibited use Critical service down or data breach
Likelihood Anchors
Likelihood should rest on exposure and evidence rather than optimism. State the period you are scoring against (a year is common), and then use the anchors below.
Score Evidence that supports it 1 Rare No failures in testing, low exposure, no similar incidents known 2 Unlikely Isolated failures in adversarial testing only 3 Possible Occasional failures in normal evaluation runs 4 Likely Regular failures in evaluation, or similar incidents seen elsewhere 5 Almost certain Seen repeatedly in testing or production at current volume
Inherent Versus Residual Risk
Score every scenario twice, before and after controls. First, the inherent score assumes no controls at all. The residual score counts only controls with evidence that they work, such as a test result, a log sample or a configuration export.
In general, controls lower likelihood. Impact falls only when a control caps the blast radius, as a hard refund limit does. So if the worst case is unchanged, the impact score stays where it was.
Score Bands and the Severity Override
With a 5×5 matrix, products run from 1 to 25. So an illustrative banding treats 1 to 4 as Low, 5 to 11 as Medium and 12 to 25 as High.
Two rules also sit on top of the bands. First, any scenario with an impact of 5 forces a High review, whatever its product. The use case also takes the score of its highest material scenario, never the average, because averaging lets one dangerous row hide among harmless ones.
Getting Two Assessors to the Same Number
To keep scores consistent, ask two people to score each scenario independently, then compare. Discuss any gap larger than one point and record why the final number won. Add a confidence field and list the missing evidence, so that a low-confidence score earns a follow-up instead of a pass.
The Tiering Rule: Low, Medium, High and a Prohibited Gate
Scores alone make a weak tiering rule, because some risks are serious whatever their product. The rule below runs four gates in order, and it sorts AI systems into low, medium and high risk.
Gate 1, Prohibited Practices
Screen first against Article 5 of the EU AI Act , which lists practices that are banned outright and has applied since 2 February 2025. Once a use matches, no score can approve it. Regulation (EU) 2026/1744 also adds two more prohibitions from 2 December 2026. Both target AI that generates non-consensual intimate images of identifiable people or child sexual abuse material.
Gate 2, Forced-High Triggers
Some features push a use case to High before anyone scores it. Decisions in an Annex III area count, such as employment, credit scoring, life and health insurance pricing, access to essential services and education. So do profiling of people, processing of minors’ data and any effect on physical safety.
Gate 3, the Score Band, and Gate 4, the Autonomy Floor
Only then does the highest scenario score set the tier. Then the autonomy floor applies. A system that acts alone is at least Medium, and one that acts alone on money, customer records or production systems is High.
Autonomy works as a floor rather than a multiplier on purpose. Multipliers add false precision, whereas a floor states a policy that anyone can check in seconds.
What Each Tier Means in Practice
Tier Typical trigger Approver Evidence before go-live Target turnaround Review cadence Prohibited Matches an Article 5 practice Nobody; the request stops None Same day Not applicable High Score 12 or more, any impact 5, a forced-High trigger, or autonomy on money or records AI risk committee plus an accountable executive Threat model, red-team results, legal review, tested kill switch 15 business days Quarterly Medium Score 5 to 11, or a system that acts alone AI governance lead with the data owner Evaluation results, privacy review, control evidence 10 business days Twice a year Low Score 1 to 4, read-only, internal users Business owner with the risk lead Completed profile and register 5 business days Yearly
Even so, every value in that table is illustrative. NIST gives that job to its Govern 1.3 subcategory, so set your own values under the risk tolerance your governance body approves. For High-tier systems, in particular, AI red teaming supplies the adversarial test evidence the approver will ask for.
Keep the Legal Classification in Its Own Column
In short, the internal tier answers how much scrutiny a use case gets. EU AI Act status, by contrast, answers which legal duties apply, so the two can differ. Record the status as out of scope, transparency duties under Article 50, Annex III high-risk, or prohibited.
Under the amended timeline, high-risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product-safety systems. An Annex III system can escape high-risk status under Article 6(3) when it does not materially influence decisions, but never when it profiles people. The provider must document that reasoning before launch, as Article 6(4) requires.
Also flag separately whether a fundamental rights impact assessment is needed. Article 27 requires one before an Annex III high-risk system goes live. It applies to public bodies, private entities providing public services and deployers of credit-scoring or life and health insurance-pricing systems.
Even so, US-based teams are not automatically outside the Act. Article 2 reaches providers and deployers in other countries whenever the system’s output is used in the EU, so route borderline cases to counsel. The EU AI Act compliance guide covers those obligations in more depth.
Mapping the Template to NIST AI RMF and ISO/IEC 42001
The template maps onto both frameworks, which helps when an auditor asks where risk assessment lives. The NIST AI RMF 1.0 is voluntary and under revision, while its four functions are not meant as a checklist. ISO/IEC 42001 gives risk assessment, risk treatment and impact assessment separate clauses, as the table shows.
Template part NIST AI RMF ISO/IEC 42001 Use-case profile Map (context and scope) 6.1.2 and 8.2, risk assessment inputs Impact and likelihood scores Map 5.1, Measure 6.1.2 and 8.2 Controls, residual risk and decision Manage 1.1 to 1.4 6.1.3 and 8.3 Tier thresholds Govern 1.3 Risk criteria set by your governance body Effect on people Map 5.1 6.1.4 and 8.4, a separate impact record
Teams that want the function-by-function detail can work from the NIST AI RMF playbook . Similarly, teams building toward the management-system standard will find the audit path in the ISO 42001 certification guide .
Checklist
Generative AI Checklist for Secure AI Adoption and Governance
18 actions across use case selection, data readiness, model architecture, security, evaluation and governance, to catch weak spots before they reach production AI systems.
Get the Checklist → Worked Example: Scoring a Customer-Support Agent That Can Issue Refunds
The example below is illustrative, with scores chosen to show the method rather than taken from a real deployment. In particular, it follows an LLM agent on a retailer’s help-desk chat. The agent reads order history through the CRM, issues refunds and then hands harder cases to a human.
Its profile is the example column in the Block A table. The one entry to add is the kill switch: the support platform lead disables the refund tool in the admin console.
Scenario Scores, Inherent to Residual
Scenario Inherent (impact x likelihood) Control that earned the change Residual (impact x likelihood) R1. Agent issues a wrong or excessive refund 4 x 3 = 12, High Hard refund cap; human approval above the cap 2 x 2 = 4, Low R2. Prompt injection exposes another customer’s data 5 x 2 = 10, High by the impact-5 override Per-customer data scoping, tool allow-list, output filter 5 x 1 = 5, stays on the High review list R3. Agent invents a refund policy 3 x 4 = 12, High Answers drawn from approved policy pages with citations; refusal outside scope 3 x 2 = 6, Medium R4. Agent or model provider outage 2 x 2 = 4, Low Automatic fallback to the human queue 2 x 1 = 2, Low
R1 shows the one case where impact falls. The cap limits the largest refund the agent can issue, so the consequence shrinks from major to minor. Human approval above the cap also lowers likelihood.
R2, however, behaves differently. Scoping and filtering make a leak much less likely, yet a leak would still be severe. So impact stays at 5, and the scenario remains on the High review list after go-live. The LLM security guide explains the injection controls behind that row.
On-Demand Webinar
The Real Cost of LLM Security Risks and How to Reduce Them
An on-demand Kanerika webinar on the LLM threats, including prompt injection, that cost enterprises the most and the controls that reduce them.
Watch the Webinar → R3 is a familiar failure for support bots, so grounding answers in approved pages is the usual fix. Even so, the residual 3 x 2 lands in Medium, so the register lists weekly sampling as a standing control.
The Decision
Overall, the agent is High at intake for two reasons. First, it acts alone on money, which trips the autonomy floor. Second, R2 carries an impact of 5. Good residual scores do not lower that tier, because they only shape the conditions attached to approval.
The approver then signs off with six conditions.
A $50 refund cap, so no single mistake costs much. Human approval whenever a refund exceeds the cap. Full logging of every agent action, so reviews have evidence. A weekly review of sampled conversations, especially refund disputes. A named kill-switch owner, on call whenever the agent runs. Re-assessment whenever the model changes. The Legal Column
Refund handling is not an Annex III use, so the agent is not high-risk under the EU AI Act. It talks directly to customers, however, so Article 50(1) applies where it serves people in the EU. Customers must be told they are dealing with an AI system unless that is obvious from the context.
Keeping a person on the larger refunds is a design choice as much as a control. The patterns in human-in-the-loop AI agents and AI agents for customer support show where that hand-off usually sits.
A Contrast Case: Why an Internal HR-Policy Assistant Lands in Medium
Now take a quieter system. An internal assistant answers employee questions from HR policy documents through retrieval, but it makes no decisions. It only reads, so no autonomy trigger fires.
In this case, two risks dominate the register. HR documents can hold personal data, so privacy scoping matters, and a wrong answer about leave or benefits rates an impact of 3. With likelihood at 3 before grounding, the top scenario scores 9, which puts the use case in Medium.
The assistant is not an Annex III system, because it does not filter candidates, decide promotions or monitor performance. That changes once someone connects it to internal job applications and asks it to rank candidates. Ranking applicants falls under Annex III point 4 on employment, so the use case jumps to High and gains high-risk status under the Act.
Nothing about the model changed in that story, only the use, so the tier moved anyway. That is why event triggers, rather than calendar dates, carry most of the weight after go-live.
From Intake to Approval: The Workflow and Who Signs
A template only works inside a process that people actually follow. Seven steps keep that process short for Low-tier requests and thorough for High ones.
First, the requester fills in a one-page intake form with the profile basics. Then the risk lead triages the request by running the four gates within two business days. After that, business, data, engineering and security owners score the scenarios, while the threat model feeds the security rows. Each control then gets an owner and a due date in a control plan. The approver then decides to approve, approve with conditions, run a pilot only, return it for rework or reject it. Once approved, the record joins the AI inventory under its assessment ID, often inside one of the AI governance tools teams already run. Finally, owners monitor the triggers and the review date. Approval binds to the configuration that was assessed, meaning the model version, data, tools and autonomy level. When any of them changes, the approval lapses. That also mirrors NIST’s Manage 1.1, which treats the go or no-go call as its own explicit decision.
Exceptions With an Expiry Date
Sometimes a business needs to launch with a risk still open. In that case, record it as an exception with four parts, namely the unresolved risk, the compensating control, the accountable executive and an expiry date. Unless it has an expiry date, a temporary exception becomes permanent by default.
Who Does What
Role What they do Data owner Scores the data rows and confirms the data may be used for this purpose Security Scores the security rows, then watches for attacks after go-live Legal and privacy Completes the legal column before the decision Risk lead Runs the gates and the scoring, then prepares the decision
The approving authority changes with the tier, as the tier table shows. So writing that down ahead of time removes a frequent delay, which is a finished assessment waiting for someone willing to sign. If those approvals sit next to your AI policies, the guide to AI policy management software shows how such tools route and version them.
For the policies and owners that sit around this workflow, a checklist helps teams confirm nothing has been left out before the first request arrives.
Checklist
AI Governance Checklist
A practical checklist of the policies, owners, reviews and evidence that an AI intake and approval workflow depends on.
Get the Checklist → Keeping the Assessment Alive After Go-Live
An assessment that never changes eventually describes a system that no longer exists. Systems drift away from their approved configuration one small change at a time, so the template needs triggers that reopen it.
Trigger Action Model or version swap, including a vendor’s Re-score every scenario before the new version goes live New data source Re-score privacy, accuracy and bias rows New tool, write permission or higher autonomy Full re-assessment and a fresh tier check New user group or country Re-check the legal column and affected people Incident or near miss Re-score the related row and review its controls Evaluation drift beyond threshold Re-score the accuracy and bias rows
Meanwhile, calendar reviews at the cadence in the tier table catch what the triggers miss. Keep each version under the same assessment ID and never overwrite the old one, because auditors need to see what was known at the time.
Model-level checks belong to model risk management, which tracks drift and validation across a model’s lifecycle. Meanwhile, LLMOps observability tools supply the signals that fire most of these triggers. An AI auditing framework then shows how the records hold up when someone checks them later.
Common Mistakes That Make the Template Useless
Overall, six mistakes, each covered above, turn a sound template into paperwork that nobody trusts.
Averaging scenario scores. Writing one assessment for a whole platform. Crediting controls that have no evidence. Treating the internal tier as the legal classification. Setting a review date with no owner. Stuffing vendor questionnaires into the use-case record. Take the first mistake. For example, averaging the refund agent’s four inherent scores (12, 10, 12 and 4) gives 9.5, a Medium. That average hides the impact-5 row, one of the two reasons the agent is High.
Each one is cheap to fix at intake, but expensive to unwind after an audit. Teams that write AI guardrails into the control column, rather than promising them, avoid the third by default.
Putting the AI Risk Assessment Template to Work
In the end, the minimum approval package is short: the profile, scored scenarios, verified controls, residual risk, a named approver and review triggers. Run it on the next AI request in your queue, even if the first version is rough.
So what goes into an AI risk assessment template, and how do you use it? It needs one use case per record and anchored impact and likelihood scores. It also needs a tiering rule that starts with a prohibited gate, plus a signed decision tied to the exact configuration that was assessed.
How Kanerika Helps Enterprises Run AI Risk Assessments
Kanerika’s AI governance consulting services focus on keeping deployed AI auditable and compliant. The service page describes an assessment that surfaces governance gaps before they become audit findings and tests controls on the highest-risk systems first.
Under responsible AI frameworks, Kanerika sets up risk tiering with clearly defined accountability and ownership, along with documentation for regulatory expectations. Its AI and model validation work also covers pre-deployment validation for regulated systems and post-change audits after model updates.
The service also covers bias and fairness auditing across protected attributes, plus LLMOps governance such as prompt injection protection, hallucination monitoring and model version control. In addition, AI policy work adds acceptable use policies, technical guardrails and escalation procedures with periodic review cadences. Kanerika’s Klara compliance agent applies the same idea to contracts: it checks them against enterprise playbooks, flags compliance risks and suggests redlines under human oversight.
Kanerika’s own security and privacy practices are certified to ISO 27001 and ISO 27701:2019, and the company also holds SOC 2 Type II. In one delivery, a payment technology provider used Kanerika’s conversational AI inside its brand compliance and approval workflow. As a result, approval turnaround fell by 60%, and manual effort per brand query dropped by 70%.
Case Study
60% Faster Approvals With Conversational AI
A payment technology provider used Kanerika’s conversational AI in its brand compliance and approval workflow, cutting approval turnaround by 60% and manual effort per query by 70%.
Read the Case Study → For the wider program view, the AI governance hub and the AI governance framework guide are good next reads. Likewise, for seven real cases and the artifacts behind them, see these AI governance examples . Teams weighing ethics questions alongside risk will also find the responsible AI guide useful.
Frequently Asked Questions
What should an AI risk assessment template include?
It should hold three blocks for one AI use case. The profile covers purpose, owners, model, data, tools, autonomy level, affected people and jurisdictions. The risk register scores each scenario for impact and likelihood before and after controls. The decision log records the tier, legal status, approver, conditions, approved configuration and review triggers.
Is there a free AI risk assessment template in Excel?
You can build one in Excel or Google Sheets in under an hour. Create three tabs for the use-case profile, the risk register and the decision log, and join them with one assessment ID. Copy the field names from this guide, add drop-down lists for the 1 to 5 scores, and multiply impact by likelihood.
Does NIST provide an official AI risk assessment template?
No. The NIST AI Risk Management Framework is voluntary guidance organized around four functions, Govern, Map, Measure and Manage. It asks organizations to record the likelihood and magnitude of impacts and to document residual risk, but it prescribes no form, scoring matrix or risk tiers. Teams build their own template and map it to the framework.
How do you calculate an AI risk score?
Score each risk scenario for impact and likelihood on anchored 1 to 5 scales, then multiply the two for a result between 1 and 25. Use the highest material scenario for the use case, never an average. A common illustrative banding treats 1 to 4 as Low, 5 to 11 as Medium and 12 to 25 as High.
Can a low internal risk score make a system low-risk under the EU AI Act?
No. The internal score and the EU AI Act classification answer different questions. A system used for an Annex III purpose, such as ranking job applicants or credit scoring, can be high-risk under the Act whatever its internal score. Record the legal status in a separate column and send uncertain cases to legal counsel.
How often should an AI risk assessment be updated?
Update it whenever something material changes, such as a model swap, a new data source, a new tool, wider autonomy, a new country or an incident. Add a calendar review as a backstop, for example quarterly for High, twice a year for Medium and yearly for Low. Keep every version rather than overwriting old ones.
Do internal AI copilots need a risk assessment?
Yes, although most will land in Low or Medium. An internal copilot can still expose confidential or personal data, give wrong answers that staff act on, or be connected later to tools that let it act. A short assessment records its data access and autonomy, so any later change triggers a fresh review.
What is the difference between an AI risk assessment and an AI impact assessment?
A risk assessment scores how likely and how serious each failure is for the organization and decides whether a use case can go live. An impact assessment looks at effects on people and their rights. ISO/IEC 42001 keeps them as separate clauses, and the EU AI Act requires a fundamental rights impact assessment for certain deployers.
