Explainability

Accessible Communication

Use simple, plain words when the agent produces outputs people use every day.

Phase: Design · Build
Applies to: End users, content designers
Oversight: Human in the loop and on the loop
Key factor: Oversight capability

Overview When to use Questions to ask Example Anti-patterns to pay attention to References Related

Overview

Explainability is the precondition that makes an agent actionable. Without explanation that goes beyond a simple “accept or reject”, human oversight becomes performative compliance. Accessible Communication governs how individual outputs, confidence signals and system states are put into clear, everyday language, so non-technical users can make informed decisions. Technical mechanics are explained in plain words at the point of action, with deeper detail available one level down when needed.

Attention

How confidence scores are calibrated and explained can live in the “About” section of the agent's system.

When to use

Use when

A product introduces confidence signals, flags or AI modes that new users haven't seen before.
The agent's reasoning isn't obvious: the output alone doesn't tell the reviewer how the agent got there.
A user needs to challenge or verify the output, not just approve it, and regulation requires decisions to be explainable.

Not needed when

The output is low-stakes, and the reviewer's decision is binary with no need to question it.
The agent's logic is simple, deterministic and already visible from the output.

Questions to ask

Ask these at kickoff, when design work starts. Tick them off as your team answers.

What does this reviewer need to understand to make a real decision, not just read an output?
Which factors did the agent weigh most heavily, and are those visible to the reviewer?
How much explanation is too much for this context? A routine approval flow can't absorb a reasoning trace; a compliance review can.
When the agent is uncertain, does the explanation say what it couldn't resolve, not just what it could?
Is the explanation the same for all users, or does its depth vary by role?

Example

The first time a confidence note appears in someone's meeting summary, and what they see if they ask how it works.

First-time tip → How is this worked out?Do

Sam to send the revised budget by Friday, 24 October

New: confidence notes

When the assistant isn't sure about something, it highlights that part and tells you why. Here, two people mentioned different dates. Check it before you share the summary.

Got itHow this works

How does this work? ▾

The assistant compared what each person said in the meeting. Two people agreed on Friday; one said Monday later on. When people in the transcript disagree, it marks the detail as unsure instead of picking one.

It can't tell you which date is right, only that they conflict.

Technical detail ▸

The explanation is specific to this result, in everyday words, and says what the system can't tell you. The technical layer is one click further down.

Anti-patterns to pay attention to

Confidence signals appear with no explanation the first time.
Raw probabilities or thresholds without plain-language framing.
Full detail is always visible, or explained only in a sign-up tour.

References

Current guidelines · EU AI Act, ISO/IEC 420013 references

For orientation only, not legal advice. Applies to high-risk systems. EU AI Act links open a readable version of the official text published on EUR-Lex; ISO/IEC 42001 is a paid standard.

EU AI Act Art. 13(3)(b)(iv) Instructions for use cover the system's technical capabilities to explain its output. A plain-language explanation is the point-of-use surface for that.
EU AI Act Art. 86 People affected by certain decisions based on high-risk AI outputs have a right to a clear and meaningful explanation, not a generic disclaimer.
ISO/IEC 42001 A.8.2 Give users plain-language information about capabilities, limits and failure modes. Explaining a specific uncertainty is more useful than a general capability statement.