The trustworthiness atlas — ISO/IEC TR 24028

Transparency & explainability — can stakeholders see and understand?

Transparency is disclosure about the system: its existence, capabilities, limitations, data provenance, design choices. Explainability is the harder promise — making individual outputs interpretable to the people they affect. TR 24028 treats explainability methods (feature attribution, surrogate models, counterfactuals) as approximations to be validated, not oracles: an explanation that sounds plausible but misdescribes the model’s actual behaviour is itself a trustworthiness failure.

Robustness, reliability, resilience & availability — does it keep working?

Four siblings, often confused. Robustness: maintaining performance under perturbation — noisy inputs, distribution shift, adversarial manipulation. Reliability: performing as intended, consistently, over time. Availability: being there when needed. Resilience: recovering when something does go wrong. The ISO/IEC 24029 series supplies the measurement machinery for the first one — including formal methods that can prove a neural network’s behaviour within bounded input regions, one of the few places in AI assurance where mathematical certainty is on offer.

Accuracy, safety, security & privacy — does it avoid causing harm?

Accuracy is statistical correctness — and TR 24028 insists it be reported honestly: disaggregated, with uncertainty, against realistic data. Safety is freedom from unacceptable harm to people and environment. Security is resistance to deliberate attack — the threat catalogue below lives here. Privacy covers both classic data protection and the AI-specific twist that models can memorise and leak their training data, so the model itself becomes personal data risk.

Controllability & accountability — can humans stay in charge?

Controllability: humans (or supervising systems) can intervene, override, and switch off — the engineering substrate beneath every human-oversight requirement you will meet in law. Accountability: responsibility for the system’s behaviour is assigned to identifiable actors and evidenced through logs, documentation, and audit trails. Notice the pairing: controllability without accountability is a kill switch nobody is obliged to press.

Where the TR 24028 threats strike the ML pipeline

1. Training data

   Data poisoning strikes here: corrupt or manipulated training examples implant biased or backdoored behaviour. Microsoft’s Tay chatbot (2016) was poisoned in sixteen hours by coordinated toxic input to its live-learning loop.

2. Training & objective

   Specification gaming lives here: the model optimises the literal objective, not the intent — the CoastRunners boat that circled collecting points instead of finishing the race is the canonical demo. A design-time threat, not an attack.

3. Trained model

   Model stealing / extraction: an attacker reconstructs the model or its training data by systematically querying it. Also where memorised personal data leaks — a privacy threat from the model itself.

4. Inference / deployment

   Adversarial examples (evasion) strike here: inputs perturbed to force misclassification. Researchers made stop signs read as speed-limit signs with a few stickers (Eykholt et al., 2018).

5. Operation over time

   Unpredictability and drift: emergent behaviour in novel situations, silent decay as the world shifts. Not an attacker — the environment itself.

6. Hardware & system layer

   Classic vulnerabilities never went away: compromised dependencies, GPU faults, insecure APIs, supply-chain tampering. TR 24028 insists AI security sits on top of ordinary system security, never instead of it.