AI governance / risk navigation
AI risk domains.
Know where to look.
AI risk domains group recurring ways an AI system can fail or cause harm. Use this directory to identify the relevant risks, find the evidence needed to assess them, and route the review to the right owner or specialist guidance. One system can involve several domains at once.
What this page does
Classify the issue before selecting the control.
An AI risk assessment should begin with a specific system, intended use, affected people and plausible failure. From there, several risk domains may apply. A domain is a navigation category—not a risk rating, a control, an assurance finding, or proof of compliance.
This directory is a practical synthesis informed by the NIST AI Risk Management Framework and other guidance. Its groups are deliberately not mutually exclusive. NIST AI RMF uses the cross-cutting functions Govern, Map, Measure and Manage; the directory below does not replace them. [1]
- Domain
- Area of concern: vendor dependency, data quality, human oversight, model performance, or another risk family.
- Failure
- A concrete event or behavior: unauthorized retrieval, unreliable output, stale assumptions, or missed escalation.
- Evidence
- Records and tests that establish what was reviewed, when, for which configuration, and with what limitations.
- Decision
- What use is allowed, limited, deferred, remediated, or stopped—and who has authority to decide.
Classification rule: describe the failure mode before choosing a label. Assign multiple domains when necessary; do not convert a missing document into a severity score without assessing actual likelihood, impact, exposure, and compensating controls.
The risk directory
Nine domains. Different evidence questions.
Read each entry as a starting point for an assurance review. Examples are illustrative, not an exhaustive inventory of AI harms or mandatory artifacts. Use links to move into the relevant detailed guide.
- 01
Data, provenance & privacy
Inputs · lineage · access
Incorrect, unrepresentative, unauthorized or stale inputs can undermine outputs. Trace origin, quality, permissions, sensitive-data handling, and changes to the data used by the system.
Examine: lineage, dataset scope, sampling/quality checks, access testing, retention, and data-change records.
Broader AI risk assessment → - 02
Model fitness & performance
Validation · drift · limitations
Assumptions, evaluation conditions or deployed populations may not match the actual use. Review performance by material error, subgroup where relevant, limitations, monitoring, and change triggers.
Examine: design rationale, evaluation methods, validation, monitoring metrics, exceptions and recalibration decisions.
Model risk evidence crosswalk → - 03
Generative AI & RAG integrity
Retrieval · grounding · output
Generated responses may be unsupported, sensitive, inconsistent, or based on misleading retrieved material. Evaluate source relevance, citation support, abstention, versioning and user reliance.
Examine: evaluation sets, retrieval traces, source versions, error analysis, prompts and documented release criteria.
LLM & RAG risk guide → - 04
Security, misuse & tool actions
Injection · access · execution
AI applications can expose protected material, follow hostile instructions from lower-trust inputs, or perform unauthorized actions through integrations. Review boundaries at the application and tool layers.
Examine: access-control tests, injection exercises, tool permission maps, logging and incident records.
Review application controls → - 05
Vendor & supply-chain dependency
Supplier claims · opacity · concentration
External services can obscure provenance, shared responsibilities, underlying providers, material changes and recovery options. The evidence should fit the purchased product and intended configuration.
Examine: supplier evaluations, terms, data flows, independent tests, change notices, subprocessor and exit arrangements.
Vendor AI risk guide → - 06
Human oversight & decision rights
Challenge · override · escalation
Formal human review can fail if staff lack time, context, authority or a meaningful route to intervene. Review the actual decision workflow rather than whether a human appears in the diagram.
Examine: reviewer instructions, permissions, case samples, overrides, escalation outcomes and challenge records.
Human oversight guide → - 07
Fairness, harm & affected people
Distributional impact · contestability
Errors or unequal impacts may fall differently across populations and contexts. Document whose interests are affected, what harms are plausible, and how people can challenge consequential decisions.
Examine: population coverage, relevant subgroup testing, impact assessments, complaints, appeals and mitigation results.
Assess the use and affected parties → - 08
Governance, compliance & accountability
Roles · requirements · approvals
Ownership, applicable requirements, assessment criteria and exception authority can be unclear. Distinguish voluntary guidance from binding legal duties, contractual commitments and internal policy.
Examine: approved use, policy-to-control map, responsible roles, decision minutes, exception and remediation records.
Frameworks & standards directory → - 09
Operational resilience & change
Incidents · updates · recovery
A change to a model, dataset, upstream supplier, prompt, retrieval index or permitted use can invalidate earlier tests. Plan for disruption, correction, rollback, contingency and retesting.
Examine: change impact records, monitoring, incident response, fallback tests, release restrictions and reassessment triggers.
Third-party change evidence →
Domains can overlap. Financial crime, hiring, lending, healthcare and public services are use contexts in which several domains may apply, rather than mutually exclusive technical risk categories.
Applied example
One AI workflow. Several risk domains.
An illustrative financial-crime workflow shows why a single-domain label is not enough to evaluate actual reliance.
A financial institution uses a vendor-supplied predictive model to rank monitoring alerts. Analysts investigate and decide which cases require escalation. The tool influences attention and review timing, but does not make the final disposition.
Which alerts are missed or delayed?
Check validation against relevant alert populations, data completeness, changes in performance and thresholds, and the limits of evaluation samples.
What changed since approval?
Identify model/version updates, scoring logic changes, supplier evidence, impact review, and whether prior evaluation still supports current reliance.
Can analysts challenge priority?
Check review queues, explanations, override authority, escalations, case notes, and exceptions when the model priority is not persuasive.
The conclusion should be about the defined use and evidence—not whether the model is “safe” in the abstract. Additional security, fairness, governance and operational assessments may also be required. For a specialist example of AML evidence records, use the AML AI Assurance Evidence Kit.
From risk to review record
Eight fields make a risk review traceable.
This is a record design, not a downloadable risk-register product. Add fields for legal requirements, scoring, testing, retention and sign-off as your organization’s actual process requires.
System & use
System identity, version, deployment, purpose, users and excluded uses.
Failure & consequence
What could happen, to whom, and how serious the outcome could be.
Domains & dependencies
All relevant risk domains, upstream parties and connected workflows.
Applicable criteria
Legal duties, policies, controls and assessment criteria, with scope noted.
Evidence & tests
Source, version, method, observed results, coverage and limitations.
Owner & review
Control owner, reviewer, review date and authority to challenge.
Gap & treatment
Uncertainty, needed remediation, restriction, exception and due date.
Decision & trigger
Proceed, restrict, defer or stop; decision-maker and reassessment trigger.
Evidence sufficiency is contextual.
A missing report is not automatically a high-risk failure, and an extensive documentation package does not prove a control operated. Evaluate directness, coverage, independence, freshness and risk consequence.
Use an existing evidence workflow.
The AI Assurance Evidence Review Kit provides a general structured workbook; the Evidence Library collects the available resources. This page itself does not offer a separate AI Risk Register Starter Kit.
Framework relationship
Use each source for what it actually says.
Framework functions, technical risk domains and legal obligations are different structures. Mapping between them requires interpretation and a check of applicability—not one-to-one equivalence.
NIST AI RMF 1.0
Voluntary cross-sector risk management organized around Govern, Map, Measure and Manage. Use it to connect system context, measurement, governance and risk response; these nine domains are not official NIST categories. NIST states that AI RMF 1.0 is being revised. [1]
View NIST AI RMF →NIST Generative AI Profile
Supplemental, voluntary considerations for generative AI risks, including provenance, information integrity, testing, incident processes and third-party risks. Adapt to the use case rather than treating the profile as a certification. [2]
View NIST AI 600-1 →ISO/IEC 42001:2023
AI management-system requirements for organizational policies, objectives, processes, risk assessment, treatment and continual improvement. It is not a prescribed list of nine AI failure domains. [3]
View ISO standard record →Sector & jurisdiction rules
Applicability depends on the system, role, organization and location. For example, EU AI Act Article 9 addresses risk-management systems for covered high-risk AI; U.S. banking model-risk guidance has its own model definition and explicitly excludes generative and agentic AI. [4] [5]
Review the banking model-risk scope →Quick answers
Questions about AI risk classification.
Practical distinctions used in governance, assurance, technology risk and internal audit.
What is an AI risk domain?
A grouping of related potential failures or harms that helps reviewers find appropriate controls, tests, owners and evidence. Domains are analytical aids, not automatically legal classifications or severity levels.
Can an AI system belong to several domains?
Yes. For example, a vendor-operated RAG assistant can present third-party, data privacy, security, output integrity, human oversight and operational risks simultaneously.
Is model risk the same as all AI risk?
No. Model risk management is a specialized discipline with defined contexts and obligations. The April 2026 U.S. interagency guidance excludes generative and agentic AI from its scope, although those systems still require other applicable governance and controls. [5]
Does an evidence gap automatically mean high risk?
No. An evidence gap identifies uncertainty. The risk decision must also consider the system’s impact, exposure, compensating controls, nature of the missing evidence and whether use can be restricted while the gap is resolved.
Sources & scope notes
These sources inform the directory, but the domain labels, evidence-field design and AML example are infoSecured.ai’s practitioner synthesis. The page is not a reproduction of an official taxonomy, compliance crosswalk, audit methodology or regulator-endorsed assessment.
- NIST (2023). AI Risk Management Framework 1.0 and AI RMF Core. Voluntary Govern, Map, Measure and Manage functions; current revision status on NIST’s official page.
- NIST (2024). NIST AI 600-1: Generative AI Profile. Risks, documentation, evaluations, incident handling and third-party considerations for generative AI.
- ISO/IEC (2023). ISO/IEC 42001:2023 — Artificial intelligence management system. Official description of scope and management-system purpose.
- European Union. AI Act Article 9: Risk management system. Requirements for covered high-risk AI systems; consult current applicability and implementation timelines.
- Federal Reserve / FDIC / OCC (2026). SR 26-2: Revised Guidance on Model Risk Management. Risk-based model-risk guidance with defined scope and express exclusions for generative and agentic AI.