A DPO puts a dashboard in front of the auditor. Three charts: detections per month, a split across applications and a figure of 86 per cent. The auditor takes a look and asks one question: which period does this cover, and what is it evidence of? The conversation that follows is not about the figures themselves, but about everything that is missing around them.
This article is about that second step: from figures you understand to an overview someone else can check. How to read the figures themselves is covered in our article on the AI metrics that actually tell you something.
Which period does it cover?
A dashboard keeps moving. Tomorrow the numbers will be different, and a tool with a recorded decision today may not have had one last month. So an auditor always asks about a defined period: what applied in the third quarter, and what happened then?
Good evidence therefore starts with a fixed period, a month or a quarter, and an overview recorded at the end of it. Six months later you can show exactly what you showed then, including the decisions as they stood at the time.
Which control does this figure support?
A percentage showing how much critical data was adjusted before sending might say something about data minimisation (GDPR Article 5(1)(c)) or about appropriate security (Article 32). That link needs to be written down. Otherwise the reader has to work out what the figure is for, and an auditor will not do that for you.
So for each figure, note which control it supports, citing the provision and what it requires. This is also where you need to be straight about targets. No law says 90 per cent of critical data must be adjusted. If you want to set a bar, fine, but it is your bar: "we aim for 90 per cent, reached 86, and here is what we are doing about it" is a defensible sentence. "We meet the standard" is not.
What exactly does the figure cover?
This is where most overviews fall short. BeeSensible's help with sensitive data is available only in certain apps. So 86 per cent describes those apps, not all AI use in your organisation. That is fine, as long as it says so.
The same goes for visibility of AI tools. It covers the tools seen in the browser on workstations where BeeSensible runs, not what someone does on a personal phone. And figures only appear once a minimum number of users is active, so nobody can be identified from them.
Keep two kinds of figures apart, too. Seeing which tools are in use and whether a decision has been made about them covers hundreds of services. Helping with sensitive data happens in a smaller set of apps. Merge the two into one score and you hide exactly the distinction a regulator asks about.
What do the figures not show?
An overview that names its own limits earns trust. One that does not invites the question of what was left out.
Write one sentence per topic on what falls outside it. For example: whether employees are sufficiently trained is not something these figures show. Or: a tool still under review does not count as a decision. Next to it, note what does cover that part, such as the training you run or the data processing agreements recorded in your AI register.
A figure that does not exist should stay missing, too. If a feature was switched off, or there was nothing to calculate a percentage from, write "no measurement data" and give the reason. Never a zero, because a zero reads as a result.
What this looks like in practice
In BeeSensible, the Accountability screen is built exactly this way: three topics over a month or quarter, each with two figures and a sentence on scope, and for each topic an explanation of what the law says, what BeeSensible contributes and what falls outside its scope. There are no statuses or targets; a report for a period is recorded so that it cannot change afterwards.
