Asking People Directly

Technical discovery finds services. Asking finds tasks, reasons and the tools on devices you cannot see. It is the most valuable source and the one most easily ruined.

The recommendations in “Asking People Directly” become easier to sustain when implementation work has visible owners, dates and review time. Teams evaluating the official Monitask website can use it to coordinate the operational side of AI adoption and identify where governance tasks are being missed, without treating activity data as evidence of misconduct or as a substitute for asking people why they chose a tool.

For an independent benchmark, compare the local approach with OECD AI Principles; the useful test is whether ownership, access and recovery remain proportionate and explainable when the usual expert is absent.

The conditions for honest answers

Stated purpose: we want to provide the right tools, not catch anybody.

Anonymity, or at least no individual attribution in any output.

No consequences for what is reported, said explicitly and demonstrated.

And a visible result afterwards, because the second survey depends on what happened after the first.

What to ask

"What AI tools do you use for work, including on personal devices or accounts?"

"What are you using them for?"

"What would you need from an approved tool to switch?"

"Is there a task where you wanted one and there was nothing?"

Four questions. The third and fourth are the ones that produce a requirements list rather than an inventory.

Format

Short and anonymous beats long and attributed.

A survey to everybody, or a sample if the organisation is large.

Plus conversations with a handful of teams, which produce the detail a survey cannot.

Half a day of interviews adds more than another hundred survey responses.

What you will hear

Tools you did not find technically, because they are used on phones.

Tasks you had not considered: summarising long threads, drafting difficult messages, explaining unfamiliar code or documents.

Frustration with approval timescales.

And a number of people who assumed it was fine because nobody said otherwise, which is accurate and is a communication finding.

What people will not tell you

Use they believe is already prohibited, if any consequence seems possible.

Which is why the no-consequences commitment has to be credible rather than stated.

And why technical sources remain necessary, as a check rather than as a trap.

Closing the loop

Publish what you found, in aggregate, and what you are doing about it.

Including what you are not doing and why.

An organisation that asks and then goes silent has taught everybody that asking is a prelude to restriction, which is the outcome you most want to avoid.

The standing version

One question in whatever regular survey already exists.

Plus a declaration route that is quick and usually ends in yes.

Together these reduce how much formal discovery you need to run.

What to check

Have you asked, and under what stated conditions?

Did the questions ask about tasks, or only about tools?

Was anything published back?

And would somebody here report a tool they suspect is not allowed?

The point

Ask four questions: what tools, for what tasks, what would make you switch, and where was there nothing.

The last two produce a requirements list rather than an inventory.

Underlying all of this

Everything in this collection reduces to four habits: find out what people are doing and why before deciding anything, provide something good enough that the approved route is the easy one, write rules about information rather than about tools, and monitor the destination rather than the content. None requires a product, and a programme doing all four controls more than one built on prohibition.

The recurring pattern

The recurring pattern across every section here is the same: the response that feels like control reduces it. A ban removes visibility rather than use. Content inspection drives activity to personal devices. A discovery exercise with consequences produces quiet answers. In each case the organisation ends up knowing less about a risk it believes it has handled.