Why do attribution explanations change when the baseline changes?

Attribution methods compare the observed input to a reference point, so the baseline is part of the explanation itself, not just an implementation detail. If the baseline shifts, the marginal contributions can shift as well. That is why teams should document baselines, test sensitivity, and avoid presenting attribution output as if it were an objective fact about causality.

Why This Matters for Security Teams

Attribution output is often treated as if it were a stable explanation of “what the model used,” but the baseline defines the comparison being made. In practice, a different reference point can shift which features appear influential, which makes governance, review, and communication harder if the team does not standardise the method. That matters in AI risk reviews, model debugging, and any workflow where explanations inform approvals or incident response.

For security and risk functions, the core issue is not whether attribution is mathematically valid. It is whether the explanation is reproducible, documented, and suitable for the decision being made. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, consistency, and repeatable control design, all of which are needed when explanations are used operationally.

Teams most often go wrong by assuming one attribution chart can be reused across models, datasets, or baselines without changing interpretation. In practice, many security teams encounter misleading explanation confidence only after a model has already been approved or deployed, rather than through intentional baseline testing.

How It Works in Practice

Attribution methods such as integrated gradients, SHAP-style comparisons, and other feature-based explanation techniques estimate how much each input contributes relative to a reference state. That reference state can be a zero vector, an average sample, a masked input, or a domain-specific neutral example. Because the baseline changes the comparison, it changes the resulting contribution scores. The explanation is therefore conditional on the baseline choice, not separate from it.

In practical AI security and model governance work, teams should treat the baseline as a controlled input with versioning, review, and justification. Current guidance suggests three habits that reduce confusion:

• Document the exact baseline used, including preprocessing and any masking rules.
• Test multiple plausible baselines to see whether the explanation is stable or highly sensitive.
• Use explanation output as decision support, not proof of causality or intent.

This becomes especially important in safety reviews, fraud triage, and adversarial testing, where an attacker may exploit brittle explanations or where a poor baseline can hide the real signal. For broader AI risk framing, the NIST AI Risk Management Framework and MITRE’s adversarial AI guidance both point toward evaluating robustness, provenance, and misuse conditions rather than trusting a single explanation artifact.

Operationally, a good review process compares the same model under several baselines and records whether the top attributions, ranking order, and sign of contributions remain consistent. If they do not, the explanation should be treated as fragile and contextual. These controls tend to break down when models are deployed across heterogeneous data pipelines because the “neutral” reference point is no longer consistent.

Common Variations and Edge Cases

Tighter explanation governance often increases review overhead, requiring organisations to balance interpretability against delivery speed and analyst workload. That tradeoff is real, and there is no universal standard for baseline selection yet. Best practice is evolving, especially for transformer models, multimodal systems, and agentic workflows where the notion of a single neutral baseline may not fit the task.

Some teams choose a zero baseline because it is simple and easy to reproduce, but that can be misleading when zero is not meaningful in the data domain. Others use an empirical baseline, such as a cohort average, which may improve realism but can hide minority behaviours or shift the explanation toward population norms. In regulated or high-assurance environments, the right answer is often to define more than one baseline class and explain why each is used.

Edge cases also appear when preprocessing changes, when feature scaling is inconsistent, or when the input domain contains sparse, categorical, or sequence-based data. In those environments, attribution stability can degrade quickly, and the explanation may vary even when the underlying prediction remains unchanged. For teams operating under AI governance or incident review requirements, the safest approach is to pair attribution with provenance tracking, model documentation, and repeatable test cases. Guidance from the OWASP Top 10 for Large Language Model Applications is relevant where explanations are exposed through prompts, interfaces, or agent tooling, because attackers can manipulate both the input and the interpretive context.

In practice, attribution becomes least reliable when the model, baseline, and preprocessing pipeline are all changing at the same time, because the team can no longer tell which change altered the explanation.

Related resources from NHI Mgmt Group

• Why do identity changes create change management risk?
• What breaks when Route53 changes are made without change control?
• Why do prompt changes create identity risk even when credentials do not change?
• When do attribution methods fail to provide trustworthy AI explanations?