A single AI system may require different kinds of explanations for different audiences. In enterprise settings, the goal is to give each group the right level of detail while preserving the shared understanding of how the system works.

The taxonomy below is adapted for enterprise settings from IBM Research’s AI Explainability 360 (AIX360) toolkit, which organized explainability techniques by what is being explained, how it is explained, and for whom.

This article is a sidebar to Crafting AI Explanations for Every Role in Your Enterprise.

In This Article:

Local vs. Global Explanations

Side-by-side comparison of Local versus Global explanations. The Local Explanation explains one decision: Email #4782 was flagged as spam at 89% confidence due to a suspicious sender domain (−40%), urgent-action language (−25%), and proper formatting (+10%). The Global Explanation describes overall behavior of the Spam Detection Model, listing key learned patterns: unknown sender domains, urgency keywords, and multiple links. The model has analyzed 847,293 emails at 96.2% accuracy.
Local explanations clarify a single output; global explanations describe how the system reasons overall. Different roles need different levels of detail.

Local explanations help users understand one specific AI output. They answer questions like “Why did the AI flag this case?”

Example: An HR manager wants to know why the AI flagged an employee as a retention risk. The system points to short tenure, a dip in performance metrics, and lack of recent promotions as the key factors i.

Global explanations show how the AI system makes decisions overall. They reveal the general patterns the model has learned.

Example: A service-desk manager asks, “What patterns does the AI use to escalate tickets?” The system reveals that urgency and VIP status are the strongest predictors across all escalation decisions.

Directly Interpretable vs. Post Hoc Explanations

Directly interpretable explanations come from AI systems built with transparent, rule-based logic where the decision path is clear by design.

Example: An AI-powered travel-approval system automatically approves a request because it follows a programmed rule: amounts under $500 for engineering team get automatic approval. The logic is transparent by design.

Post hoc explanations are generated after a decision, usually because the model’s internal decision-making process isn’t transparent (e.g., because a complex machine-learning model learned patterns independently). They help people interpret outputs from complex systems.Post hoc explanations are relevant for LLMs, which need to surface their reasoning in ways users can act on. Agentic AI is slightly different: when an agent produces a plan — a sequence of intended actions — that plan can often be shown to users before any action is taken. In that case, the explanation is closer to a preview than to a post hoc reconstruction. The key design question for agentic systems is when to surface  a clear, actionable explanation for the right user.

Example: An AI contract-analysis tool flags a contract as risky. To explain why,  the system shows three similar contracts from its training data that led to delivery issues, making its pattern-matching logic easier to understand.

Static vs. Interactive Explanations

Side-by-side comparison of Static versus Interactive explanations for a denied insurance claim (#2847-9201). Both panels list the same three reasons for denial: a pre-existing condition clause, missing documentation, and an exceeded coverage limit. The Static version is a fixed, one-way explanation. The Interactive version adds the ability to explore alternative scenarios (such as reducing the claim to $5,000) and ask follow-up questions about the decision.
Static AI explanations deliver a fixed rationale; interactive explanations let users ask questions,  test alternatives, and explore the reasoning.

Static explanations provide a fixed, noninteractive account of the AI’s reasoning, with no opportunity for followup or exploration.

Example: After an AI escalates a support ticket, it displays: Escalated due to predicted SLA breach (confidence: 87%). The user receives this assessment without further detail.

Interactive explanations let users to ask followup questions, and explore alternative scenarios.  These are especially valuable when business and technical users need to jointly review a decision but require different views of the same reasoning.

Example: When an AI rejects a change request, a product owner can ask, “What would make this request acceptable?” The AI then shows which inputs would need to shift to generate an approval recommendation.

Model-Based vs. Data-Based Explanations

Side-by-side comparison of Model-Based versus Data-Based explanations for a support ticket (#45821, app crashes on startup) rated High Priority at 92%. The Model-Based panel shows how the AI weighs factors: issue severity (35%), customer tier (30%), affected users (20%), and time since report (15%), combined via a decision tree ensemble. The Data-Based panel shows three similar past tickets the AI learned from, each with match percentages and resolution outcomes, drawn from over 84,000 past tickets.
Model-based explanations reveal how the AI weighs factors. Data-based explanations show what examples it learned from.  

Model-based explanations show how the AI weighs and combines factorsto reach its decision.

Example: An AI security system flags an employee as a potential threat. The explanation shows that unusual login hours and sensitive-system access were the two risk signals..

Data-based explanations show the training examples or patterns the AI learned from. They help users understand the foundation of the system’s behavior and are often especially useful for domain experts, who can evaluate the AI’s reasoning by recognizing or questioning the cases it learned from.

Example: When onboarding a new AI support agent, an IT lead reviews 10 representative support tickets from the training dataset to seethe types of issue patterns and resolution approaches the AI learned.