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
- Responsible AI domain
- Lifecycle stage
- 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
| Framework | Clause | Title |
|---|---|---|
| EU AI Act | Article 13 | Transparency 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 2 | Systems are evaluated for trustworthy characteristics Evaluation of explainability. |
| SS1/23: Model Risk Management Principles for Banks | Principle 3 | Model 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
- NIST AI Risk Management Framework (AI RMF 1.0) NIST · framework
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.
Found an error or a better source? Report a correction.