Last updated: September 10, 2026
An AI risk assessment is a structured process for identifying what could go wrong with a specific AI system, estimating how likely and how severe each outcome is, and deciding what to do about it. It differs from a traditional IT risk assessment because AI systems introduce risks that conventional controls do not address: biased or drifting outputs, opaque decision logic, data provenance problems, prompt injection, and harms to people who never interact with the system directly. A good AI risk assessment produces a ranked risk register, a treatment plan with owners, and evidence you can show to auditors, regulators, and customers.
This guide is part of our AI governance guide. It walks through a method that satisfies ISO 42001, the EU AI Act, and the NIST AI RMF at the same time, so you only have to build one process.
Key takeaways
- Assess systems, not technologies. The unit of analysis is a specific AI system in a specific use case, not “our use of LLMs” in general.
- ISO 42001 requires both an AI risk assessment (Clause 6.1.2) and an AI system impact assessment (Clause 6.1.4 and control A.5). They are related but not the same.
- The EU AI Act requires a documented risk management system for high-risk AI (Article 9) and, for certain deployers, a fundamental rights impact assessment (Article 27).
- NIST AI RMF’s Map and Measure functions give you the most detailed vocabulary for what to look for.
- The process has seven steps: scope, inventory and classify, identify risks, analyze and evaluate, treat, document, and monitor. Most teams can run the first pass on a system in one to three working sessions.
Why is AI risk different from ordinary technology risk?
Traditional IT risk focuses on confidentiality, integrity, and availability of systems and data. AI systems carry those risks and add several more. Their behavior is probabilistic, so the same input can yield different outputs. Their performance depends on training and inference data that may be incomplete, unrepresentative, or stale, which creates bias and drift. Their reasoning is often not inspectable, which complicates accountability and appeals. They can be manipulated through inputs (adversarial examples, prompt injection, data poisoning) in ways that have no equivalent in deterministic software. And their harms frequently fall on third parties: applicants who are screened out, patients whose scans are misread, users exposed to fabricated content.
This is why every serious AI governance framework asks for a dedicated assessment. ISO/IEC 42001 makes it a core requirement of the management system, the EU AI Act makes it a legal obligation for high-risk systems, and the NIST AI RMF devotes two of its four functions to it. Our comparison of ISO 42001 vs the EU AI Act vs NIST AI RMF explains how the three fit together.
What do the frameworks actually require?
ISO 42001
Clause 6.1.2 requires a documented AI risk assessment process with defined criteria, applied at planned intervals and when significant changes occur. Clause 6.1.3 requires a risk treatment process and a Statement of Applicability against the Annex A controls. Clause 6.1.4, together with control A.5, requires an AI system impact assessment that considers effects on individuals, groups, and society, not just on the organization. Clause 8.4 requires the impact assessment to be carried out and its results retained as documented information. See our guide to ISO 42001 requirements for the full clause breakdown.
EU AI Act
Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system that runs continuously across the lifecycle: identify known and reasonably foreseeable risks, estimate and evaluate them (including under reasonably foreseeable misuse), evaluate risks emerging from post-market monitoring, and adopt targeted risk management measures. Article 27 requires certain deployers (public bodies and providers of essential services, among others) to conduct a fundamental rights impact assessment before deploying a high-risk system. Following the Digital Omnibus on AI, these high-risk obligations apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I product-embedded systems. Our EU AI Act compliance guide and high-risk categories explainer cover the details.
NIST AI RMF
The Map function establishes context: intended purpose, deployment setting, affected stakeholders, and the risks and benefits of each component. The Measure function covers identifying appropriate metrics, evaluating trustworthiness characteristics (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed), and tracking risks over time. The Manage function then prioritizes and treats them. NIST’s Generative AI Profile (AI 600-1) adds 12 risk categories specific to generative models, including confabulation, information integrity, and harmful bias.
How do you run an AI risk assessment step by step?
Step 1: Define scope and criteria
Decide which system you are assessing, where its boundaries are (model, data pipelines, integrations, human review steps), and what risk criteria you will use. Criteria means the likelihood and impact scales, the risk appetite thresholds, and the categories of harm you care about. Most organizations use a 4×4 or 5×5 matrix with impact defined separately for the organization (financial, legal, reputational, operational) and for affected people (safety, rights, discrimination, financial, psychological). Write the criteria down once and reuse them; ISO 42001 auditors will ask for them.
Step 2: Inventory and classify the system
You cannot assess what you have not catalogued. Record the system’s purpose, owner, model type and source (built, fine-tuned, bought, embedded in a vendor product), training and inference data, users, affected parties, and deployment context. Then classify it: EU AI Act risk tier, whether it makes or materially influences consequential decisions, whether it processes personal or sensitive data, and whether it is customer-facing. The classification determines how deep the rest of the assessment needs to go. A marketing copy assistant and a resume screener should not get the same treatment.
Step 3: Identify risks
Work through a structured list of risk sources rather than brainstorming from scratch. A practical taxonomy covers eight areas:
- Performance and reliability: accuracy below requirements, hallucination or confabulation, drift as data or usage changes, failure under edge cases.
- Bias and fairness: disparate outcomes across protected groups, unrepresentative training data, proxy discrimination.
- Transparency and explainability: inability to explain decisions to affected people, undisclosed AI interaction, lack of audit trail.
- Privacy and data governance: personal data in training sets without a lawful basis, memorization and leakage, inadequate data lineage.
- Security: prompt injection, jailbreaks, data poisoning, model theft, insecure integrations and tool access.
- Safety and misuse: harmful outputs, use outside intended purpose, automation of decisions that require human judgment.
- Third-party and supply chain: dependence on a vendor model with unknown training data, changes pushed without notice, contractual gaps.
- Legal and regulatory: EU AI Act tier obligations, sector rules, intellectual property in training data, consumer protection.
For each area, ask what could go wrong, how it would happen, and who would be affected. Involve the people who built the system, the people who use it, and someone who represents the people it affects. Risk identification done by the compliance team alone misses most of the technical failure modes.
Step 4: Analyze and evaluate
Score each risk for likelihood and impact using the criteria from Step 1, then compare against your appetite thresholds. Two refinements matter for AI. First, score inherent risk (before controls) and residual risk (after existing controls) separately, so you can show what your controls are actually buying you. Second, for any system that affects people’s rights or access to services, run the impact assessment in parallel: describe the affected populations, the nature and severity of potential harm, and mitigations. This is what ISO 42001 A.5 and EU AI Act Article 27 are asking for, and it is where reviewers will focus.
Step 5: Treat the risks
For each risk above appetite, choose a treatment: mitigate with a control, transfer through contract or insurance, avoid by changing scope or not deploying, or accept with documented sign-off from an accountable owner. Typical AI mitigations include human-in-the-loop review for consequential decisions, output filtering and guardrails, bias testing before release and on a schedule, red-teaming for security, data minimization and provenance tracking, vendor due diligence, user disclosure, and kill switches. Map each control to the ISO 42001 Annex A control, EU AI Act article, or NIST subcategory it satisfies so your evidence serves every framework.
Step 6: Document and approve
Produce a risk register (one row per risk with source, description, affected parties, inherent score, controls, residual score, treatment, owner, and due date), the impact assessment where applicable, and a decision record showing who approved deployment and on what basis. Store them where your GRC evidence lives. For high-risk systems under the EU AI Act, this documentation feeds directly into the technical documentation required by Article 11 and Annex IV.
Step 7: Monitor and reassess
AI risk is not static. Set monitoring metrics tied to your top risks (accuracy, drift indicators, fairness metrics, incident counts, user complaints) and define triggers for reassessment: model updates, new data sources, new use cases, regulatory changes, or incidents. ISO 42001 expects reassessment at planned intervals; the EU AI Act expects it as part of post-market monitoring under Article 72. Annual is a reasonable floor for low-risk systems, with quarterly or event-driven reviews for anything consequential.
What are the most common mistakes?
The first is assessing “AI” as a category rather than individual systems, which produces generic findings and no actionable treatments. The second is skipping the impact assessment because the organization-level risk looks small; a chatbot that cannot damage your revenue can still harm a vulnerable user. The third is treating vendor AI as out of scope. If a feature inside your CRM or HR platform makes recommendations, you are the deployer and you carry obligations. The fourth is running the assessment once at launch and never again. The fifth is keeping the results in a slide deck rather than in a system where controls, evidence, and owners can be tracked and audited.
How does the assessment connect to certification and compliance?
For ISO 42001 certification, the auditor will trace from your risk criteria to your register, from the register to your Statement of Applicability, and from there to evidence that controls operate. For EU AI Act high-risk systems, the risk management system is a core part of the technical documentation reviewed in conformity assessment. For customer security reviews, a completed assessment for the system in question is increasingly the difference between a fast yes and a lengthy follow-up. One well-run process serves all three audiences.
Frequently asked questions
What is the difference between an AI risk assessment and an AI impact assessment?
A risk assessment looks at what could go wrong and how it affects the organization and its objectives. An impact assessment looks specifically at the consequences for individuals, groups, and society. ISO 42001 requires both, and the EU AI Act’s Article 27 fundamental rights impact assessment is a form of the second. In practice they share inputs and are often run together.
How often should you reassess an AI system?
At least annually for low-risk systems, and whenever there is a material change: a model update, new training data, a new use case, a regulatory change, or an incident. Consequential systems warrant quarterly review of monitoring metrics with a full reassessment at least yearly.
Who should own the AI risk assessment?
The system owner is accountable for completing it, with input from data science or engineering, legal, security, privacy, and a representative of affected users where possible. The AI governance or GRC function owns the method, criteria, and register.
Do you need to assess third-party AI features inside SaaS products?
Yes, if the feature influences decisions or interacts with your users or their data. The depth can be proportionate to the risk, but the system should be in your inventory and the vendor’s own controls should be reviewed.
Is a risk assessment required for the EU AI Act if the system is not high-risk?
Not by Article 9, which applies to high-risk systems. But limited-risk systems carry transparency obligations, the AI literacy duty under Article 4 applies to everyone, and you need an assessment to demonstrate that a system is not high-risk in the first place. Documenting the classification decision is itself a form of assessment.
What tools do you need?
A spreadsheet works for a first pass on a handful of systems. Once you have more than a few, or you need to link risks to controls, evidence, and multiple frameworks, a GRC platform with an AI system inventory and crosswalked control library saves significant effort.
Putting it into practice
An AI risk assessment is the single most reusable artifact in AI governance: it feeds your ISO 42001 management system, your EU AI Act documentation, your NIST AI RMF alignment, and your customer security reviews. Compyl gives you an AI system inventory, configurable risk and impact assessment workflows, and a control library mapped to ISO 42001, the EU AI Act, and NIST AI RMF, so you assess once and reuse the evidence everywhere. If you are building your first assessment process or scaling one across dozens of systems, our team can show you how it works.
