A Practical AI Risk Taxonomy for Auditors

An organization can put “AI risk” on a corporate risk register and still have no idea what to audit. The label may refer to poor-quality data, a model whose performance has deteriorated, confidential information entered into a generative AI tool, a vendor changing its service without notice, or an agent operating with excessive permissions.

Each can lead to financial loss, regulatory exposure, reputational damage, or customer harm. But those consequences do not tell the auditor where the failure originated or which control should exist.

That is the value of a practical taxonomy. Its purpose is not to create more labels. It is to turn a diffuse topic into control surfaces that auditors can understand, prioritize, and test.

A useful taxonomy classifies risk sources, not just consequences

The leading frameworks do not provide one universal list of AI risks. The NIST AI Risk Management Framework organizes risk management through Govern, Map, Measure, and Manage and considers impacts on individuals, organizations, and society. ISO/IEC 23894:2023 provides guidance for integrating AI-related risk management into organizational activities and functions. The IIA’s Artificial Intelligence Auditing Framework gives internal auditors principles-based guidance on AI governance, risk, and controls, including data, algorithms, and cybersecurity.

For audit work, a different synthesis is useful: classify first by the source of risk or the control surface, then record the business impact.

“Discrimination in hiring decisions,” for example, is an outcome that could originate in unrepresentative data, model design, business rules, or weak human oversight. “Financial loss,” “noncompliance,” and “reputational damage” remain important, but they work better as impact dimensions than as technical risk families.

The taxonomy below is therefore an audit operating tool. It is not a substitute for legal classification, the enterprise risk register, or the requirements of any individual framework.

Eight risk families cover most of the auditable surface

Risk family	What can go wrong	Evidence an auditor can look for	Audit question
1. Governance and accountability	Unclear ownership, incomplete inventory, fragmented decision rights, weak policies, poor escalation, or insufficient competence.	AI inventory, approved roles, policies, committees, approval criteria, meeting records, and escalations.	Is it clear who can approve, change, stop, and accept the risk of each AI use?
2. Data	Poor quality, incomplete or unrepresentative data, unknown provenance, misuse of personal or confidential information, IP issues, or weak lineage.	Data records, sources, access controls, quality assessments, retention rules, lineage, preparation records, and usage rights.	Are the data fit for purpose, and can the organization demonstrate where they came from and who may use them?
3. Model and performance	Inadequate accuracy, bias, weak robustness, drift, insufficient explainability, or use outside the validated context.	Performance criteria, validation results, testing, thresholds, monitoring, drift analysis, documented limitations, and change approvals.	Is performance assessed against the system’s purpose, users, and real-world consequences?
4. Generative AI and application	Confabulation, inconsistent output, unsafe content, prompt injection, data leakage, IP concerns, misleading citations, or over-reliance.	Behavioral testing, filters, system instructions, approved RAG sources, usage logs, human review, and incident management.	Does the workflow control both what the model generates and the information and context it receives?
5. Agents and autonomy	Excessive permissions, unintended actions, tool misuse, persistent memory, hidden dependencies, cascading failures, or approval bypass.	Agent identities, permissions, enabled tools, action boundaries, approvals, logs, stopping conditions, and revocation mechanisms.	Is the agent’s authority proportionate to the task, and can significant actions be traced back to authorization?
6. Third parties and concentration	Opaque models, vendor changes, unknown subcontractors, dependency on cloud or foundation-model providers, weak audit rights, continuity gaps, or no exit strategy.	Due diligence, contracts, SLAs, change notices, subprocessors, audit rights, metrics, incidents, continuity plans, and exit plans.	Can the organization manage the risk even when it does not control the underlying model or infrastructure?
7. Security and AI-enabled threats	Data exfiltration, insecure integrations, adversarial attacks, malicious prompt inputs, credential or model theft, deepfakes, and AI-assisted fraud.	Architecture, identity and access controls, security testing, monitoring, segregation, logs, incident response, and antifraud controls.	Do controls protect the AI system and the surrounding business process against new attack capabilities?
8. People and societal impact	Automation bias, discrimination, manipulation, accessibility failures, erosion of professional judgment, workforce impact, or nominal human oversight.	Impact assessments, defined roles, training, review and appeal mechanisms, group-level metrics, exceptions, and documented human decisions.	Does human oversight have the authority, information, time, and competence to change a decision when needed?

These categories are deliberately not mutually exclusive. One risk can span several families. A generative AI error used by an agent to approve a payment may involve generative AI, autonomy, data, security, and governance at the same time. Forcing one exclusive label can hide the causal chain.

A better practice is to assign a primary family, where the main control should sit, and one or two secondary relationships when they improve understanding.

Four modifiers turn classification into prioritization

The taxonomy answers “Where does the risk come from?” Prioritization requires a second layer.

Business impact. Translate the failure into objectives and consequences: financial reporting, compliance, privacy, security, operations, customers, reputation, rights, or strategy. NIST emphasizes that AI risks can affect individuals, organizations, and society, so the analysis should not stop at financial impact.

Lifecycle stage. The same issue changes depending on whether it appears during selection, design, training, configuration, acquisition, deployment, operation, monitoring, or retirement. ISO/IEC 42001:2023 specifies requirements for an AI management system using a risk-based approach; its informative Annex C also identifies potential AI-related objectives and risk sources, including data, machine learning, and lifecycle issues.

Scale and exposure. An occasional error in a productivity tool is not equivalent to an automated decision affecting hundreds of thousands of customers. Volume, frequency, reversibility, data sensitivity, and the population affected change severity.

Degree of autonomy. This modifier is increasingly important. A copilot that proposes text presents a different risk profile from an agent that can send email, execute code, or modify records. NIST’s 2026 work on agentic AI and agent security highlights issues such as identity, authorization, tool access, and autonomous action. The audit question is no longer only “Is the output correct?” It also becomes “What can the system do if it is wrong?”

Turn each category into an auditable risk statement

A label such as “model risk” is still too broad. The next step is to connect cause, failure, and impact:

Because of [risk source or control condition], the AI system or workflow may [failure mode], causing [business impact] to [objective or stakeholder].

Example: “Because monitoring and update criteria have not been defined, the claims-prioritization model may deteriorate without detection, causing inconsistent decisions, longer resolution times, and unequal treatment of some customers.”

That statement immediately generates control questions: What threshold triggers review? Who monitors performance? What evidence shows that a deterioration was investigated? Who can withdraw the model?

It also prevents a common mistake: turning the taxonomy itself into a control checklist. Risk describes exposure; controls are management’s response. The same risk may be treated through different combinations of prevention, detection, human review, technical constraints, monitoring, or explicit acceptance.

Where the taxonomy fits into internal audit

The Global Internal Audit Standards do not prescribe an AI taxonomy. They do, however, require risk-based planning and engagement risk assessment. Standard 9.4 requires the internal audit plan to be based on a documented assessment of strategies, objectives, and risks, while Standard 13.2 requires internal auditors to understand the activity under review and identify potentially significant risks to its objectives.

A reusable taxonomy supports at least four audit decisions:

Audit universe and planning. Find AI exposure even when AI is embedded in procurement, HR, finance, customer service, or cybersecurity rather than managed as a standalone technology.
Engagement scoping. Prevent an “AI governance audit” from covering policies and committees while ignoring data, suppliers, or systems with action-taking capability.
Testing design. Translate each family into control expectations, evidence requests, and procedures.
Issue aggregation. Identify cross-cutting themes such as incomplete inventories, weak change controls, or common dependence on one provider.

The important design choice is to keep the taxonomy relatively stable while allowing individual risks to evolve. NIST currently notes that AI RMF 1.0 is being revised. The technology is also moving quickly. A taxonomy built around control surfaces —governance, data, models, applications, agents, third parties, security, and people— is more durable than one built around whichever incident happens to dominate the headlines.

The goal is not better classification. It is better assurance.

A taxonomy becomes useless when it tries to be perfect. If it contains dozens of categories, people stop applying it consistently. If it speaks only about “ethics,” “privacy,” and “cybersecurity,” it does not tell the auditor where to look for evidence. And if it copies a framework without adapting it to the organization, it can create a false impression of coverage.

A more practical standard is simple: every significant AI risk should be locatable, expressible as a causal chain, connected to a business objective, and translatable into evidence an auditor can request.

When that happens, the AI conversation no longer depends on whether everyone understands terms such as “model,” “algorithm,” or “agent.” It returns to familiar audit territory: who is accountable, what can fail, what control should respond, and what evidence shows that it actually works.