Risk · R-155 · Transparency & Explainability

Opaque model logic

Developers, validators and owners cannot explain why a model produces its outputs well enough to challenge, correct or defend it.

Severity
High
Audience
Heads-of · Practitioner
Frameworks
Article 13 · MEASURE 2 · Principle 3
Reviewed
2026-11-11

What it is

Some models are understandable by inspection: a scorecard, a short decision tree. Most modern ones are not. A deep network or a large language model contains millions or billions of parameters, and no person can trace why a given input produced a given output. Techniques exist that approximate an explanation, and they have limits of their own. The risk is internal: the organisation relies on a system it cannot interrogate. It does not know what the model has learned, whether it is right for the right reasons, or how it will behave on a case unlike those tested. What the affected person is told is a separate matter, covered in inadequate explainability for affected individuals.

How it happens

  • A complex model is chosen for a small gain in accuracy over an interpretable one.
  • A supplier's model is used as a black box.
  • Explanation tooling was not built, or was built and never checked.
  • A general-purpose language model is used for a decision task.

Why it matters

Validation is reduced to testing inputs and outputs, which cannot show that the model's reasoning is sound. Faults such as reliance on a spurious feature go unseen until they cause harm. When a decision is challenged, the organisation cannot say why it was made. Supervisors of financial firms expect the degree of explainability to be weighed in model risk.

Warning signs

  • Nobody can state the main drivers of the model's outputs.
  • Model choice was made on accuracy alone.
  • Validation contains no examination of what the model relies on.
  • Unexpected outputs are explained after the event by guesswork.

Who owns it

The model owner is accountable for understanding the model to the degree its use requires. Data science provides explanation methods. Independent validation tests them. The business owner decides whether the remaining opacity is acceptable for the decision.

In practice

A hospital trust adopts an image model that performs very well at detecting a condition in testing. Later analysis finds it had learned to recognise the scanner type used in the specialist unit, where most positive cases were imaged. The same pattern generalises to any model trusted on its results by people who could not see what it had learned.

Mitigating controls

Primary controls

Explanation method validation Detective
Tests whether explanation techniques reflect the model's behaviour. The techniques used to explain a model are tested to confirm that they reflect the model's actual behaviour before explanations are relied on internally or given to anyone.
Independent model validation Detective
Requires conceptual soundness to be demonstrated or the opacity compensated for. A function independent of the developers tests each model's conceptual soundness, data, performance and limitations before approval and periodically afterwards, to a depth set by the model's tier.

Supporting controls

Model and system documentation Directive
Records design choices and known limitations. Each AI system's purpose, design, data, test results and limitations are documented to a set standard that allows a validator, auditor or regulator to understand it without its authors.

Compensating controls

AI risk tiering and classification Directive
Where the logic cannot be explained, restricts the model to uses where opacity is tolerable. Each system is assigned an internal risk tier and a regulatory class by documented criteria, the result is reviewed independently, and it is revisited whenever the system or its use changes.

Framework and clause references

FrameworkClauseTitle
EU AI ActArticle 13Transparency and provision of information to deployers Systems must be transparent enough for deployers to interpret output.
NIST AI Risk Management Framework (AI RMF 1.0)MEASURE 2Systems are evaluated for trustworthy characteristics Evaluation of explainability.
SS1/23: Model Risk Management Principles for BanksPrinciple 3Model development, implementation and use Understanding of model limitations.

Sources

EU AI Act: Regulation (EU) 2024/1689 European Union (EUR-Lex) · official text
SS1/23: Model Risk Management Principles for Banks Bank of England PRA · official text

Related terms

How to cite

Axiom Verity (2026). Opaque model logic. Reference Library, R-155. https://axiom-verity.com/risks/opaque-model-logic. Reviewed 2026-11-11.