What does the assessment actually examine?
It examines processes rather than technologies. For each candidate: what the process does today, who touches it, where the data lives and how clean it is, how often it runs, what an error costs, and whether anyone could tell if the output were wrong. That last question eliminates more candidates than any other. A process nobody can check is a poor place to introduce a system that is occasionally confidently mistaken.
Why not just start with a pilot?
Pilots are cheap to start and expensive to stop. They tend to select the most demonstrable process rather than the most valuable one, and they answer “can this work?”, which is almost always yes — instead of “is this worth owning for five years?”. An assessment costs less than a pilot and rules out the work you were going to abandon anyway. Where a pilot is the right answer, the assessment says which one and what it has to prove.
What if the answer is that we don’t need AI?
That is a common and useful outcome. A great deal of what gets framed as an AI problem is an integration problem: two systems that do not talk, so a person moves data between them. Connecting them is cheaper, more reliable and easier to reason about than predicting the same data. We will say so, and we would rather say it at the assessment stage than eighteen months into a programme.
| Signal | Good candidate | Poor candidate |
|---|---|---|
| Checkability | A wrong answer is obvious | Nobody would notice |
| Data | Exists, and someone owns it | Would have to be created first |
| Frequency | Often enough to matter | Quarterly, by one person |
| Failure cost | Recoverable | Regulatory or financial |
| Alternative | No simpler fix exists | An integration would solve it |