Assessment method · Published September 14, 2026
AI Risk Assessment: Method, Tiers, and Scoring
An AI risk assessment is a structured review of one AI use case. It names what could go wrong, rates how likely and how severe each harm is, chooses controls, and records whether the remaining risk is acceptable. This page sets out the method LA Global Institute uses in its own governance work: eight steps, four tiers, a likelihood by severity score, and the evidence to keep at each point.
Where it fits
One use case at a time
Assess the use case, not the organization.
A team can be ready to run a summarization assistant and unready to automate a benefits decision. Nearly nine in ten organizations now use AI in at least one function, and 44% are scaling it across the enterprise, according to McKinsey’s State of AI 2026. The number of use cases is the reason to assess each one on its own facts.
What it is
A structured review of one AI use case. It names what could go wrong, how likely and how severe each harm is, which controls reduce it, and whether the remaining risk is acceptable.
When to run it
Before a pilot reaches real people, before procurement closes, and again whenever the model, data, population, or law changes. One assessment per use case, not one per organization.
What it produces
A tier, a scored scenario register, a control plan with owners and dates, a written decision, and a monitoring plan with reassessment triggers. Together these form the evidence record.
What it does not prove
It does not certify a system, prove legal compliance, or replace a required legal, privacy, security, clinical, or employment review. It shows the organization looked, decided, and recorded why.
Why now
The evidence for assessing before deploying
Incidents, breaches, and penalties are now measured.
IBM’s 2025 breach study found that 63% of breached organizations had no AI governance policy, and that shadow AI added about $670,000 to the average breach cost. The numbers below are the ones a sponsor should have in hand before signing off.
AI incidents recorded in 2025
Up from 233 in 2024, according to the AI Incident Database as reported in the Stanford AI Index 2026.
Stanford HAI, AI Index 2026, Responsible AI chapterOrganizations reporting breaches of AI models or applications
Of those, 97% reported lacking proper AI access controls. One in five breaches involved shadow AI.
IBM, Cost of a Data Breach Report 2025Distinct AI risks catalogued from 65 frameworks
The MIT AI Risk Repository organizes them into 7 domains and 24 subdomains. Use it to check a scenario register for blind spots.
MIT FutureTech, AI Risk Repository (April 2025 update)Maximum fine for prohibited AI practices
Whichever is higher, of worldwide annual turnover. Prohibitions already apply; high-risk obligations follow the Commission’s published timeline.
European Commission, Enforcement of the AI ActThe method
Eight steps, each with an owner and evidence
How to conduct an AI risk assessment.
The sequence follows the four functions of the NIST AI Risk Management Framework: Govern, Map, Measure, and Manage. Steps one to four map the system. Steps five and seven measure it. Steps six and eight manage it. Governance runs through the owners and evidence named at every step.
Describe the system and the use case
One bounded description: what the AI does, for whom, which decision or output it touches, which vendor or model runs it, and where people review it.
Owner: Use-case sponsor
Evidence: Entry in the AI inventory with a system owner and a business owner.
Assign a provisional risk tier
Place the use case in one of four tiers. The tier sets how deep the rest of the assessment goes and who must review it.
Owner: Governance committee or delegated reviewer
Evidence: Tier decision with the indicators that drove it.
Map data, people, and decisions
List every input and its source, any personal or regulated data, the people affected, the decisions influenced, and who can reach the system.
Owner: System owner with privacy and security input
Evidence: Data map and affected-population note.
Identify harm scenarios
Write plain statements of what could go wrong: wrong output, unfair outcomes, exposed data, prompt injection, over-reliance, outage, legal or reputational harm.
Owner: Cross-functional reviewers
Evidence: Scenario register checked against a public risk taxonomy.
Score inherent risk
Rate each scenario for likelihood and severity on a 1 to 5 scale before any controls. Multiply to get an inherent score and a band.
Owner: Reviewer, confirmed by the system owner
Evidence: Scored register with the reasoning for each rating.
Choose controls and name owners
For every scenario above the accept line, pick controls that prevent, detect, or respond. Add a human review point wherever output is consequential.
Owner: Control owners named per scenario
Evidence: Control plan with an owner, a date, and a test for each control.
Score residual risk and decide
Rescore with controls in place. Decide: proceed, proceed with conditions, redesign, or stop. High-tier decisions get an independent second reviewer.
Owner: Decision authority named in the committee charter
Evidence: Signed decision with residual scores and conditions.
Set monitoring and reassessment triggers
Define the metrics to watch, the incident route, the events that reopen the assessment, and the next scheduled review date.
Owner: System owner and monitoring owner
Evidence: Monitoring plan, trigger list, and the next review date.
Risk tiers
Four tiers set the depth of review
Place the use case before you score it.
Unacceptable
Uses the organization will not run regardless of controls. The practices the EU AI Act prohibits illustrate this tier, but an organization may set its own lines above the law.
High
The output influences a consequential decision about a person, or a safety outcome. This tier gets the full method, independent review, documented human oversight, and monitoring.
Limited
People interact with the AI or see AI-generated content, and harm is bounded but real. Transparency and human review of consequential outputs are the core controls.
Minimal
Internal productivity use with no personal-data path and no consequential decision. Record it, confirm acceptable-use rules, and review it once a year.
Scoring
Likelihood by severity, before and after controls
Score every scenario twice.
The inherent score describes the scenario with no controls. The residual score describes it with the chosen controls in place. The gap between the two is the value of the control plan, and the residual band drives the decision.
Likelihood
- 1RareNot expected within the review period. Would need unusual conditions.
- 2UnlikelyCould occur. No precedent in comparable systems or in testing.
- 3PossibleHas occurred in comparable systems or appeared during testing.
- 4LikelyExpected to occur at least once during the review period.
- 5Almost certainOccurs routinely or has already been observed in production.
Severity
- 1NegligibleMinor inconvenience, corrected within normal work.
- 2MinorLimited harm to a few people. Recoverable within days. No notification duty.
- 3ModerateMaterial harm to some people, a notifiable incident, or measurable financial loss.
- 4MajorSerious harm to people, rights, or safety. Significant legal or financial exposure.
- 5SevereIrreversible harm, or harm to life, liberty, livelihood, or a large population.
Low 1 to 4
Accept. Record the score and review on the scheduled date.
Moderate 5 to 9
Proceed with named controls, a control owner, and a date for each.
High 10 to 14
Proceed only after controls bring the residual score to Moderate or lower, confirmed by an independent reviewer.
Critical 15 to 25
Do not deploy. Redesign the use case or stop. Record the decision.
Worked example
An assistant drafts replies to customer complaints.
Scenario: the assistant states a refund policy that does not exist. The team scored it before and after controls, then decided.
- Inherent score
- Likelihood 4, because testing showed invented policy details. Severity 3, because refunds and trust are at stake for some customers. Score 12, High band.
- Controls chosen
- Retrieval limited to approved policy text. Every draft reviewed by an agent before sending. A refusal when no policy text applies. A weekly sample audit owned by the customer operations lead.
- Residual score
- Likelihood 2, severity 3. Score 6, Moderate band. Decision: proceed with conditions. Reassess in ninety days or when the refund policy changes.
Decision gate
Eight questions before the decision is signed
A score is not a decision until someone owns it.
A “no” does not end the use case. It names a gap that needs an owner, a documented choice, and a control proportionate to the consequence before the system reaches people.
- 01
Is the use case, the affected population, and the decision path written in one place?
YesNoNot applicable - 02
Has the tier been assigned and, for the high tier, confirmed by an independent reviewer?
YesNoNot applicable - 03
Does every harm scenario carry an inherent score, a residual score, and the reasoning for both?
YesNoNot applicable - 04
Is every residual score in the High or Critical band resolved, or is deployment stopped?
YesNoNot applicable - 05
Does a named person own each control, with a date and a way to test it?
YesNoNot applicable - 06
Can affected people learn that AI was involved and reach a human who can correct the outcome?
YesNoNot applicable - 07
Has the system been tested on the organization’s own data and failure cases, not only vendor benchmarks?
YesNoNot applicable - 08
Are monitoring metrics, an incident route, reassessment triggers, and the next review date recorded?
YesNoNot applicable
Reassessment
Triggers reopen the assessment
The score expires when the system or its context changes.
Rescore the scenarios that depend on model behavior. Re-run acceptance tests on the organization’s own cases.
Change record and updated scores
Redo the data map and the affected-people review. Confirm the tier still holds.
Updated data map and tier confirmation
Treat it as a new use case when the decision path changes. Otherwise amend the existing record.
New or amended assessment
Rescore the scenario that occurred. Check whether the likelihood assumption was wrong.
Incident record linked to the register
Check the tier and the required controls against the new obligation, for example an EU AI Act application date or a sector rule.
Obligations review note
Minimal tier yearly. Limited tier every six months. High tier quarterly, with monitoring reviewed between cycles.
Signed review with the next date
Public toolkits
Use the public frameworks as source material
The method draws on public work. It does not replace it.
NIST AI Risk Management Framework
NIST released AI RMF 1.0 on January 26, 2023 and the Generative AI Profile, NIST AI 600-1, on July 26, 2024. The four functions, Govern, Map, Measure, and Manage, structure the eight steps above. The framework is voluntary, and NIST has announced revisions under the 2025 federal AI Action Plan, so check the current edition.
Review NIST AI RMF Review the NIST playbookRisk taxonomies and vendor toolkits
The MIT AI Risk Repository is the broadest public checklist for step four. Microsoft publishes a Responsible AI Impact Assessment template, and Google publishes the Secure AI Framework for security scenarios. Governance platforms such as TrustArc, Drata, and BigID automate registers and evidence. Each is useful. None replaces the judgment, owners, and decision recorded here.
Explore the MIT AI Risk Repository Review the OECD AI PrinciplesLA Global operating resources
File each assessment where the governance system can act on it. The checklist holds the use-case evidence and launch gate. The committee charter names the decision authority. The acceptable use policy sets the rules for the people using the tools.
Use the governance checklist Draft the committee charter Adopt the AI acceptable use policy Read the AI frameworkReferences indicate source alignment only. They do not imply affiliation, endorsement, certification, or approval by NIST, MIT, OECD, the European Commission, any vendor, or any other organization.
Common questions
AI risk assessment FAQ
Straight answers to the questions people search for.
How do you perform an AI risk assessment?
Describe one use case, assign a tier, map the data and people, write harm scenarios, score likelihood and severity before controls, choose controls with owners, rescore, and decide. Then set monitoring and the events that reopen the review. The eight steps above are that sequence, with the evidence to keep at each step.
What is the difference between an AI risk assessment and an AI impact assessment?
A risk assessment scores what could go wrong and decides controls. An impact assessment centers on the effects a system has on people and their rights, and some laws require one for specific high-risk uses. This method maps affected people in step three, so one record can support both. Whether a formal impact assessment is legally required depends on the applicable rule, not on this page.
What are the four types of AI risk?
The most cited four-part classification is the EU AI Act’s tiering: unacceptable, high, limited, and minimal. Other sources group risk by harm type, such as privacy, security, fairness, and safety, and the MIT AI Risk Repository uses seven domains and twenty-four subdomains. Pick one taxonomy, state which one, and use it consistently across the register.
What is the 30% rule in AI?
It is an informal heuristic, not a law or a standard. The idea is that AI can handle roughly 70% of a task while people keep about 30% for judgment, context, and accountability. It is a useful reminder that human oversight must be designed in. It is not a substitute for scoring the specific scenarios in a specific use case.
Can AI write a risk assessment?
An AI assistant can draft scenario lists, summarize documentation, and check a register for gaps against a public taxonomy. It cannot verify facts about your system, own a control, or be accountable for the decision. Treat drafted content as unverified input, have a named person confirm every score and control, and do not paste confidential system details into a tool your acceptable use policy has not approved.
Is there an AI risk assessment certification?
There is no single recognized certification for a completed AI risk assessment. ISO/IEC 42001 is a certifiable standard, but it certifies an organization’s AI management system, not the risk of one use case. The NIST AI Risk Management Framework is voluntary and carries no certification. LA Global Institute does not certify systems, assessments, or organizations.
How often should an AI risk assessment be repeated?
On a schedule set by tier, and immediately on a trigger. Minimal-tier uses are reviewed yearly, limited-tier uses every six months, and high-tier uses quarterly with monitoring in between. A model change, a new data source, a new population, an incident, or a change in law reopens the assessment regardless of the calendar.
Is this a free AI risk assessment template or PDF?
This page is a published method with a working record. It can be printed or saved from the browser without a signup. It is written for use-case-level assessment inside an organization’s own governance system, and it is not a fill-in form. Use it with the AI inventory, the governance checklist, and the committee charter so each assessment lands in the right place.
Build the connected governance system