Key takeaways
- Score ideas on value, data readiness, risk and effort before building anything.
- The best early AI features remove tedious work rather than replace judgement.
- Prototype fast, measure against a baseline, and have a clear rollback plan.
AI is now cheap to prototype and easy to demo, which makes it easy to build the wrong thing. The question is no longer “can we use AI here?” but “should we, and is now the right time?”.
Start with the job, not the model
Look for tasks your users or staff already do repeatedly, that take real time, and where a good-enough answer is genuinely useful: summarising documents, drafting replies, classifying tickets, extracting data from forms or searching internal knowledge. These are where AI tends to pay off first.
A four-part scoring method
We score every idea from 1 to 5 on four dimensions:
| Dimension | Question to ask |
|---|---|
| Value | How much time, money or friction does this remove, and for how many people? |
| Data readiness | Do we have the data or documents it needs, and are we allowed to use them? |
| Risk | What happens when it's wrong? Can a human easily check the output? |
| Effort | Can we prototype in weeks, and run it at a sensible cost? |
Ideas that score high on value and data readiness, and low on risk and effort, go first. Anything where a wrong answer could cause real harm needs a human in the loop, or should wait.
The best first AI feature is usually boring: it saves someone an hour a day and nobody notices it's AI.
Protect your data
Before sending anything to an AI service, be clear about where data goes, how long it's kept and who can see it. Use enterprise agreements or private deployments for sensitive data, strip personal information where you can, and document your choices so you can explain them to customers.
Prototype, then prove it
- Pick one high-scoring idea and define success in numbers, for example “reduces average ticket handling time by 20%”.
- Build a thin prototype in two to four weeks using real (safely handled) data.
- Test it with a small group against the current way of working.
- Decide: scale, iterate or stop. Stopping is a perfectly good outcome.
Written by
Itrowin Data Practice
Data & AI engineers. We share what we learn building engineering teams and software for clients across the UK and beyond.