The five questions every leader should be able to answer
Who owns it. Who could be harmed. Did we test it. Can we explain it. Who is watching it. Five questions about an AI system your organization has already deployed — rate the fifteen statements honestly and see which of the five is your weakest link. That is the gap to close first.
About 4 minutes · fifteen statements · nothing stored
Do you assess who could be harmed before the system goes live?
Risk to the organization and impact on people are different assessments. The second is the one most often skipped, and the one an auditor asks for first.
An impact assessment on people is completed before deployment, not after
Impacts on individuals and groups assessed per system, dated before go-live
You identify which specific groups could be affected, including people who are not your users
Named groups — not "the public" — including those subject to a decision rather than making one
There is a threshold at which you would not deploy, and someone empowered to say no
A documented stop condition, and a person whose refusal actually halts the project
Has the system been independently tested before you trusted it?
A vendor benchmark is a sales document. Testing means your own evidence, on your own population, disaggregated far enough to show who the system fails.
Performance is verified by someone other than the supplier before you rely on it
Your own evaluation, on your own data, before the system carries real decisions
Accuracy is examined by subgroup, not reported as one overall number
Results broken down far enough to show who the system fails, and both error types considered separately
You can answer where the training data came from and who it represents
Provenance, quality and representativeness documented for the data behind the system
Question 4 of 5 · ISO/IEC 42001 — Clause 7.5 · Annex A.8 · EU AI Act Art. 13, 50, 86
Can we explain it?
Could you explain a single decision, in public, to the person it affected?
The test is not whether your data scientists understand the model. It is whether an affected person receives an explanation they can act on — and whether the record still exists months later.
You can explain one specific decision in plain language to the person it affected
A particular case, explained to a non-technical person, not a description of the model in general
People are told when AI is materially involved in a decision that affects them
Disclosure that reaches the affected person, not a line in a policy nobody reads
Decisions and their inputs are logged well enough to reconstruct months later
Records that survive a complaint, an audit, or a court — including model version and inputs
Is someone monitoring the system now that it is live?
Performance drifts as conditions change. A system approved once and never re-examined is governed on the day it launched and ungoverned every day after.
Performance is monitored after go-live against defined thresholds
Live measurement against numbers set in advance, with someone reading them
Each system has a scheduled review date and falls within internal audit scope
A date in the calendar, and AI inside the audit program rather than beside it
A person can challenge an outcome, and there is a defined way to switch the system off
A working appeal route, an incident process, and an off switch someone is authorized to pull
The scale
0
No — nothing in place
1
Partly — started, informal
2
Mostly — in place, thin evidence
3
Yes — in place and evidenced
Rate what is true today across the systems you actually run — not what the policy says should be true.
Indicative guidance only, based on your answers. Not a legal determination, a conformity assessment, or a substitute for advice from qualified counsel in the relevant jurisdiction. Regulatory requirements, effective dates, and enforcement practice change; verify current obligations before acting. Nothing you enter here is transmitted or stored.
