Enterprise AI Risk Taxonomy: Models, Agents, Vendors and Decision Paths

Introduction

Model risk is carrying too much weight in many enterprise AI risk registers.

A failed claims decision might trace back to an obsolete policy retrieved from a knowledge base, a third-party fraud service that changed after an update, an agent operating with excessive authority, or a reviewer who accepted the recommendation without examining its supporting evidence. More than one of those failures can contribute to the same outcome.

Recording the incident simply as model risk obscures where the problem originated and who is responsible for fixing it. Enterprise AI systems now combine models, data sources, retrieval components, agents, tools, external services, business rules and human decisions. Risk may sit inside one component, emerge at an integration point, or accumulate across several steps in the decision path.

An enterprise AI risk taxonomy has to preserve those differences. It should identify the source of exposure, the affected process or decision, the route through which risk can propagate, and the control owner responsible for managing it.

The difficulty is visible even in large-scale attempts to organise AI risk. The MIT AI Risk Repository now contains more than 1,700 risks and maintains separate causal and domain taxonomies because one classification system could not adequately represent both how a risk arises and the type of harm involved. MIT also notes that important dimensions such as impact and likelihood sit outside those taxonomies.

For an enterprise, that makes taxonomy design an operational problem rather than an exercise in terminology. The categories need to remain useful during incident investigation, control assignment, supplier assessment, system comparison and portfolio-level risk reporting.

At a glance

• Model risk remains important, but many enterprise AI failures originate elsewhere in the decision path.
• Agents add exposure around tool use, delegated authority, persistent context, identity and multi-step execution.
• Third-party models, APIs, datasets and embedded AI services can change the organisation’s risk profile without changes to its own application code.
• Risk categories are more useful when they connect directly to evidence, controls and accountable owners.
• A common taxonomy should support both system-level investigation and portfolio-level aggregation without reducing very different exposures to one generic score.

Model-centric AI risk categories miss system-level exposure

Early AI risk programmes naturally concentrated on models. Accuracy, harmful bias, explainability, robustness, privacy, drift and security were familiar assessment areas because the model appeared to contain much of the uncertainty. Enterprise AI architectures now contain far more moving parts.

A generative application may depend on a hosted model, embeddings, retrieval infrastructure, enterprise data, prompt logic, orchestration software, moderation services and several APIs. An agent can add memory, machine identity, planning, tool selection and the ability to act across other systems.

The model can perform within its evaluated limits while the overall application still produces an unacceptable result.

NIST’s Generative AI Profile reinforces the need to treat AI risk across the design, development, use and evaluation of systems rather than reducing assessment to the behaviour of a model in isolation.

Agentic systems extend the risk surface further. OWASP’s Agentic Threats Navigator identifies reasoning, memory, tools, identity, human oversight and multi-agent interactions as distinct attack surfaces. Several of those risks exist because of the architecture surrounding the model, not because of the model alone.

A taxonomy dominated by model attributes can therefore misclassify application-level failures, collapse technically different problems into one category, or fail to record them at all.

Decision paths reveal where enterprise AI risk originates

A consequential business result usually has a lineage.

For the claims example, it might be:

claim documents → document extraction → retrieval → model interpretation → fraud API → agent recommendation → policy rule → adjuster review → claim decision

Each stage introduces its own exposure, but the connections matter just as much.

A hallucinated sentence inside an internal drafting assistant has one consequence profile. Put the same reliability problem inside a workflow that influences a coverage decision, combines it with stale retrieval and passes the result into a largely automated claims process, and the enterprise exposure changes considerably.

A useful taxonomy therefore needs to retain several pieces of context.

Origin of exposure

Model, data source, retrieval process, agent, tool, vendor, human process, integration or infrastructure.

Type of failure or hazard

Incorrect output, unauthorised action, data disclosure, manipulation, loss of traceability, dependency failure, regulatory breach or another defined event.

Affected business decision or process

Customer eligibility, fraud escalation, pricing, access, payment, employment, clinical work, infrastructure change, regulatory filing or another material activity.

That does not require an organisation to discard its existing enterprise-risk structures.

ISO/IEC 23894 is designed to help organisations integrate AI-related risk management into their broader activities and functions, while ISO/IEC 42001 provides requirements for establishing, implementing, maintaining and continually improving an organisation-wide AI management system. An internal AI taxonomy can work underneath those structures as the vocabulary teams use to classify the systems and decisions they actually operate.

Model risk still needs clear diagnostic boundaries

Broadening the taxonomy should not make model risk vague.

There are still failures that originate meaningfully at the model layer. Depending on the use case, they may include:

• factual unreliability;
• harmful bias or differential performance;
• adversarial susceptibility;
• poor calibration;
• instability between versions;
• inappropriate refusal or compliance behaviour;
• weak performance outside evaluated conditions;
• insufficient transparency for the intended decision.

A customer assistant might give incorrect product information because the underlying model cannot reliably reason over a particular numerical constraint. Another instance of the same assistant might provide obsolete information because retrieval indexed an outdated policy document.

The customer receives a wrong answer in both cases. The evidence required to investigate the failures is different. So are the teams, controls and remediation paths.

Classifying both only as accuracy risk loses useful technical information.

Classifying one as model risk and the other as data risk is better, but still incomplete if both contribute to the same customer-outcome exposure.

A mature taxonomy needs to retain both the source of the problem and the consequence it can create.

Agentic AI risk accumulates across authority, state and execution

A model inference has a relatively clear beginning and end. Agent behaviour can extend through a sequence of decisions.

An agent may construct a plan, retrieve data, invoke a tool, inspect the result, revise its next step, write information to memory, delegate part of the task and later resume work using previously retained context. The exposure is cumulative: an individual step can appear acceptable while the sequence produces a result that was never intended.

OWASP’s agentic security work treats reasoning, memory, tool use, identity, human oversight and multi-agent interaction as separate areas of exposure for precisely this reason.

Four properties deserve explicit treatment in an enterprise taxonomy.

Authority: Which systems and operations can the agent reach, and whose authority is it exercising?

State: What information persists between steps, sessions or delegated tasks?

Sequence: Can several individually acceptable operations produce an unacceptable combined outcome?

Delegation: Can work or authority move into another agent, service or process without the original control assumptions following it?

An ordinary model evaluation may not expose any of these problems.

An agent can use a reliable model, retrieve accurate information and still perform an inappropriate operation because its delegated task is poorly bounded. Another can behave correctly in isolated tests while accumulating sensitive context in persistent memory across repeated use.

Those findings need somewhere to go in the risk register without stretching model risk until it loses diagnostic value.

Third-party AI risk can change without an application release

Most enterprise AI stacks contain external dependencies.

A production system may rely on a foundation-model provider, vector database, document-processing service, evaluation platform, external dataset, content filter and several business APIs. Other dependencies arrive less visibly as AI capabilities embedded inside enterprise software already under contract.

Exposure can shift without an application-code change: a provider introduces a new model version, an API revises its data-retention terms, a SaaS supplier activates an AI feature, a subcontractor enters the processing chain, a region experiences a prolonged service failure, or a commercial service is withdrawn.

The implications depend on what that dependency does inside the business process.

The EU AI Act provides a useful example of why information must move along the AI value chain. Obligations for providers of general-purpose AI models entered into application on August 2, 2025, including documentation and information-sharing requirements intended to help downstream AI-system providers understand model capabilities and limitations. From August 2, 2026, the European Commission’s enforcement powers for GPAI-provider obligations entered into application, including the ability to impose fines. Providers of GPAI models placed on the market before August 2, 2025 have until August 2, 2027 to comply.

An enterprise taxonomy therefore needs more than a generic third-party risk label.

Useful attributes can include:

• whether the dependency is practically replaceable;
• what information crosses the supplier boundary;
• which business decisions depend on the service;
• whether the provider can change behaviour unilaterally;
• what assurance evidence is available;
• exposure to subcontractors;
• geographic or regulatory constraints;
• continuity arrangements if the service changes or fails.

A temporary outage in an optional summarisation service and the loss of an external fraud-control API should not receive equivalent treatment simply because both originate with third parties.

The dependency matters because of its position in the decision path.

Business decision context changes AI risk severity

Technical categories tend to dominate AI risk registers because they are comparatively easy to name, while the business decision often appears later as an impact field. For consequential systems, that ordering can hide much of what determines the severity of an exposure.

An internal meeting-summary application and a credit-decision system may use the same foundation model, retrieval technology and monitoring infrastructure. The required controls can still differ sharply because one output is low-consequence internal information while the other may materially affect an individual.

Decision-level attributes might include:

• informational, advisory or executable output;
• material effect on an individual or organisation;
• financial significance;
• reversibility;
• regulatory sensitivity;
• required human authority;
• available time for detecting and correcting errors;
• concentration of exposure where one system influences many decisions.

Giving the decision more weight connects technical findings directly to enterprise risk and avoids equating technical sophistication with severity.

A complex multi-agent research system used for internal analysis may create less consequential exposure than a relatively simple classifier embedded in a regulated eligibility process.

The architecture tells teams how a failure can occur. The decision tells them why the failure matters.

Some AI risks span multiple control domains

Data provenance can affect reliability, privacy, copyright, security and auditability at the same time. Identity touches agents, tools, APIs and human approval. An external component can create operational, security, compliance and concentration exposure simultaneously.

Requiring every finding to occupy one exclusive category can remove information rather than organise it.

The MIT AI Risk Repository encountered a comparable classification problem. Its researchers maintain causal and domain taxonomies separately because high-level explanations of how risks occur could not be cleanly unified with categories describing hazards and harms.

Enterprise programmes can preserve the same multidimensionality through tags or secondary attributes.

One record might contain:

Object: external fraud-scoring API

Failure: unavailable or materially changed service

Decision path: insurance-claim escalation

Risk domains: operational resilience, vendor dependency, decision quality

Control owner: claims technology / third-party risk

Evidence: service monitoring, contractual change notice, fallback test

The taxonomy remains structured, but the exposure is not forced into an artificially narrow box.

AI risk categories need a direct link to controls and evidence

A risk category earns its place in an enterprise taxonomy when somebody can use it.

The classification should help determine what evidence would establish the exposure, which control can reduce it and who is responsible for acting.

MIT’s AI Risk Mitigation Map contains more than 800 mitigations and groups them into governance and oversight, technical and security, operational process, and transparency and accountability controls.

An enterprise taxonomy can create similar connections.

Agent privilege risk can point to machine identities, delegated permissions, tool-access records and privileged-access controls.

Retrieval provenance risk can point to source inventories, document versions, ingestion records and validation mechanisms.

Model performance risk can point to evaluation datasets, production-quality measures, model versions and acceptance thresholds.

Vendor dependency risk can point to contracts, service evidence, architecture dependencies, change notifications and fallback arrangements.

Decision accountability risk can require reviewer identity, escalation criteria, override evidence and decision records.

Linking categories to evidence keeps the taxonomy from turning into an encyclopaedia of possible AI problems. It also allows different control functions to work from the same record: a security architect, auditor, model-risk specialist and business owner may each care about different fields, but they can still trace the exposure back to the same system and decision.

An enterprise AI risk taxonomy can expose portfolio concentration

Individual assessments can tell an organisation whether one system carries an acceptable level of risk.

Consistent classification across the portfolio reveals a different class of problem.

Management can begin asking:

How many production systems depend on the same foundation-model provider?

Which customer-facing decisions involve agents with write access?

Where does sensitive information pass through external AI services?

Which important processes lack a fallback if a model or API becomes unavailable?

The same portfolio view can expose less obvious concentrations. Human approval may have been added to so many workflows that review capacity itself has become a control weakness. A recurring risk category may appear across multiple systems without a clearly assigned owner.

At portfolio scale, the significance of a dependency can look very different from its treatment inside an individual system assessment.

One critical application relying on a single provider may represent an accepted architectural choice. Fifty critical workflows relying on the same provider create a concentration exposure that no isolated application assessment will reveal.

Taxonomy design therefore has to satisfy two competing practical requirements.

The categories need enough consistency to support aggregation across systems, but enough technical and business context to remain useful when somebody has to investigate or remediate an individual exposure.

An elegant hierarchy is secondary to that job.

FAQs: enterprise AI risk taxonomy

What is an enterprise AI risk taxonomy?

An enterprise AI risk taxonomy is a structured vocabulary for identifying and classifying AI-related risks across an organisation.

A useful taxonomy can cover models, data, agents, tools, third-party services, infrastructure, human processes and business decisions while connecting those exposures to evidence, controls and accountable owners.

What categories should an AI risk taxonomy include?

There is no universal category set suitable for every enterprise.

Common areas include model performance, data, privacy, security, agent behaviour, tool use, identity and access, third-party dependencies, operational resilience, legal and regulatory exposure, human oversight and business-decision risk.

The final structure should reflect the organisation’s architecture and existing enterprise-risk disciplines.

How is agentic AI risk different from model risk?

Model risk concerns properties or failures associated with the model itself, including unreliable output, harmful bias, robustness problems or behaviour outside evaluated conditions.

Agentic AI risk also covers behaviour across time and action: tool calls, delegated permissions, memory, multi-step planning, identity, coordination and interactions with other agents or enterprise systems.

How should third-party AI risk appear in the taxonomy?

Third-party AI risk should record both the dependency and its role in the business process.

Relevant attributes can include data exposure, provider change rights, model or API dependency, subcontractors, available assurance evidence, jurisdiction, resilience, substitutability and which business decisions are affected if the service changes or fails.

Should enterprises create a separate AI risk framework?

Not necessarily.

ISO/IEC 23894 is intended to help organisations integrate AI-related risk management into existing activities and functions. ISO/IEC 42001 provides the management-system structure for establishing, implementing, maintaining and continually improving AI governance. An internal risk taxonomy can extend those disciplines with the technical and operational categories required by the organisation’s AI architecture.

A durable enterprise AI risk taxonomy must survive architecture change

The names of models, orchestration frameworks and AI vendors will change faster than most enterprise risk frameworks.

A taxonomy built too closely around today’s products will age with them.

Models will continue to introduce particular forms of uncertainty. Agents will add state, delegation and action. External suppliers will create dependencies the enterprise cannot fully control. Data will move through those components, and people will remain part of many consequential decision paths.

The durable structure sits in the relationships between those elements and the business outcomes they help produce.

An enterprise AI risk taxonomy therefore has a more demanding job than cataloguing failure modes. It needs to help teams locate exposure inside a real system, identify what else depends on it, retrieve the right evidence, assign control ownership and recognise the same risk elsewhere in the portfolio.

The architecture will change.

The taxonomy should still be able to explain where the risk sits.