AI risk / practical guide
What is AI risk?
AI risk is the possibility that an AI system, its use, or its dependencies create harmful or unwanted consequences.
A useful assessment connects a real use case to a credible failure, the consequence that could follow, the safeguards that matter, and the evidence needed for a decision.
Review the risk areas01 / Define the risk
AI risk depends on the use, not just the model.
The same model can present very different risks in different settings. NIST frames risk through the likelihood of an event and the magnitude of its consequences, while emphasizing that AI risks are contextual. NIST AI RMF 1.0 — Framing Risk
Identify, assess, respond to, monitor, and revisit risk in context.
Set authority, responsibilities, boundaries, escalation, and lifecycle decisions.
Examine evidence, limitations, and the strength of the conclusion.
Do not confuse uncertainty with severity. Missing or weak evidence can increase uncertainty about a risk, but it does not by itself prove the underlying risk is high. Complete documentation does not make a risky use safe.
02 / Review the failure surface
Eight areas organize the first pass.
The areas below are infoSecured.ai synthesis for practical review, not an official NIST or ISO taxonomy. They are informed by NIST trustworthiness characteristics and AI impact-assessment guidance from ISO/IEC 42005:2025. NIST trustworthiness characteristics · ISO/IEC 42005:2025
Performance & reliability
The system produces inaccurate, unstable, poorly generalized, or misleading results under conditions that matter to the use.
Ask: Does the evaluation represent the people, cases, environments, and failure costs that matter here?
Safety & harmful outcomes
Errors, unsafe recommendations, inappropriate automation, or interaction effects create physical, financial, operational, or other harm.
Ask: What is the credible worst case, and what prevents or contains it?
Human oversight & automation
People defer to the system, lack time or authority to challenge it, miss exceptions, or cannot intervene before a consequential action.
Ask: Can a reviewer understand, challenge, override, escalate, and verify the outcome when it matters?
Data, privacy & confidentiality
Data is poor quality, inappropriate, unexpectedly used, over-retained, exposed, or retrieved outside intended boundaries.
Ask: What data enters the system, where did it come from, who can access it, and what happens to it afterward?
Security & misuse
Attackers or users manipulate inputs, prompts, models, retrieval sources, tools, or permissions to produce unauthorized behavior or exposure.
Ask: Which attack paths or misuse cases can change outputs, reveal data, or trigger actions? For specialist security review, use NIST AI 100-2e2025 and OWASP GenAI LLM Top 10 2026.
Fairness & impact
Performance or consequences differ materially across people or groups, or the surrounding process amplifies harmful patterns.
Ask: Who may experience different errors, access, treatment, or downstream consequences?
Transparency & explainability
Users or affected people cannot tell when AI is involved, reviewers cannot interpret important outputs, or decision-makers cannot reconstruct the basis for action.
Ask: What does each audience need to know to use, question, review, or contest the system appropriately?
Vendors, dependencies & change
A supplier, upstream model, dataset, retrieval source, API, configuration, or workflow changes without enough visibility or reassessment.
Ask: Which dependencies can change the risk even when your own team changes nothing?
Generative AI needs an additional overlay. NIST AI 600-1 addresses risks that are novel to or intensified by generative AI and maps suggested actions to Govern, Map, Measure, and Manage. NIST Generative AI Profile
03 / Write the risk
Describe the failure before you score it.
A label such as “bias risk” or “hallucination risk” is too broad to tell a reviewer what to test or a decision-maker what to change. A useful statement connects the use, failure, and consequence.
What is the AI actually doing? Name the workflow, users, decision, output, and operating boundary.
What could fail? Describe an observable failure rather than a broad category.
What happens if it fails? State the consequence without assuming every error has the same impact.
Who or what is exposed? Identify affected people, processes, systems, assets, counterparties, or communities.
What currently limits the risk? Identify safeguards that actually operate in the workflow.
What evidence could change the decision? Ask for the test, operating record, incident history, or observation that would alter the assessment.
04 / Prioritize
Do not let the score replace the reasoning.
At minimum, examine consequence, likelihood or exposure, safeguard effectiveness, and uncertainty. A score can summarize judgment; it should not hide the assumptions behind that judgment.
How serious is the credible impact if the failure occurs?
How often can the failure arise, and how many decisions, users, or assets are exposed?
Do controls prevent, detect, contain, or recover from the failure in practice?
How much relevant evidence is missing, stale, indirect, or outside the assessed operating conditions?
05 / Reassess
AI risk changes after deployment.
Use event-driven reassessment instead of relying only on a calendar. NIST treats AI risk management as a lifecycle activity, and ISO/IEC 23894 provides organization-level guidance for integrating AI risk management into AI-related activities and functions. ISO/IEC 23894:2023
New users, populations, decisions, geographies, or downstream actions move beyond the original boundary.
A provider, model version, system prompt, tool, feature, API, or contract changes behavior or evidence.
Production data, knowledge sources, permissions, labels, or upstream feeds change materially.
Errors, latency, drift, override rates, complaints, or other monitored signals move outside expected conditions.
An incident, abuse case, control failure, or unexpected behavior reveals a scenario that was missed or underestimated.
A law, contract, policy, standard, or internal risk tolerance changes the decision criteria.
Record what changed, which prior evidence remains relevant, what must be re-tested, and who owns the new decision.
07 / FAQ
AI risk management questions
Short answers for common search and review questions. Applicability of laws, regulations, contracts, and sector requirements must still be assessed for the actual organization and use.
What is AI risk?
AI risk is the possibility that an AI system, its use, or its dependencies create harmful or unwanted consequences. A useful assessment considers the context of use, the credible failure, potential consequence, exposure or likelihood, safeguards, and uncertainty.
Is AI risk the same as model risk?
No. Model risk may be part of AI risk when model assumptions, errors, limitations, or performance are central. AI risk can also arise from data, people, workflow design, security, vendors, retrieval systems, interfaces, legal obligations, and downstream actions. For U.S. banking organizations, the April 2026 revised interagency model-risk guidance is reflected in Federal Reserve SR 26-2, which superseded SR 11-7 and SR 21-8.
How do AI governance and AI risk management differ?
Governance defines authority, decision rights, rules, responsibilities, and escalation. Risk management identifies and responds to uncertainty and potential consequences. They connect when a risk finding can actually change an approval, operating boundary, control, or stop decision.
What is the difference between inherent and residual AI risk?
Inherent risk describes risk before considering relevant safeguards. Residual risk describes what remains after those safeguards are considered. The distinction is useful only when the control assumptions are explicit and there is evidence that the safeguards operate as expected.
How often should AI risk be reassessed?
Use event-driven reassessment for material changes in use, models, vendors, data, permissions, performance, incidents, controls, or applicable requirements. Periodic review can supplement those triggers; it should not substitute for them.
What evidence should an AI risk review retain?
Retain enough context to reconstruct the decision: system and version, intended use and boundary, risk statement, assessment basis, relevant tests or operating records, control assumptions, unresolved issues, decision owner, response, and reassessment triggers.
Sources and evidence notes9 primary / authoritative sources · reviewed 5 October 2026
This guide combines primary risk-management, impact-assessment, security, legal, and sector guidance with infoSecured.ai’s practical synthesis. The eight review areas, worked example, prioritization prompts, and reassessment triggers are editorial structure rather than an official taxonomy or mandated checklist from the cited organizations.
- NIST AI RMF 1.0 — Framing Risk. Contextual risk framing, likelihood or probability, magnitude of consequences, and lifecycle risk considerations.
- NIST AI RMF — AI Risks and Trustworthiness. Validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and fairness.
- ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management. Organization-level guidance for integrating AI-specific risk management into AI-related activities and functions.
- ISO/IEC 42005:2025 — AI system impact assessment. Guidance for identifying, evaluating, and documenting potential impacts of AI systems and foreseeable applications.
- NIST AI 600-1 — Generative AI Profile. Cross-sector companion to the AI RMF for generative-AI risks and suggested actions.
- NIST AI 100-2e2025 — Adversarial Machine Learning. Adversarial ML attack taxonomy, attacker goals and capabilities, and mitigations, including generative-AI attack classes.
- OWASP GenAI LLM Top 10 2026. Specialist application-security guidance for critical risks in LLM-powered systems.
- Regulation (EU) 2024/1689 — consolidated text current to 27 July 2026. Operative EU AI Act text. See also the European Commission implementation timeline.
- Federal Reserve SR 26-2 — Revised Guidance on Model Risk Management. April 2026 interagency banking guidance; supersedes SR 11-7 and SR 21-8 and uses a risk-based, tailored approach to model risk management.
Source-status note: NIST states that AI RMF 1.0 is being revised, so this page cites the published 1.0 framework and records its review date. The EU AI Act link uses the consolidated legal text rather than the original 2024 publication alone. Banking references use SR 26-2 rather than superseded SR 11-7.