
Begin with the work, not the model
AI is useful when it improves a real decision, workflow or customer experience. Starting with a model name or a fashionable feature usually reverses that logic: the team searches for somewhere to place the technology instead of deciding what should become better.
A stronger starting point is a plain description of the work. What information arrives? Who interprets it? What decision follows? Where does time, consistency or context get lost? Those questions reveal whether the opportunity needs AI at all.
Four patterns where AI can earn its place
The strongest opportunities usually involve language, documents or varied inputs that are difficult to handle with rigid rules alone. AI can help make that information usable without pretending it is always correct.
- Knowledge retrieval: finding relevant answers across approved policies, manuals or project records, with sources shown for verification.
- Document triage: classifying, extracting or summarising incoming material before a person reviews the result.
- Assisted drafting: preparing a first version of a response, report or structured record using known context and clear review steps.
- Decision support: organising evidence, options and exceptions so a responsible person can make the final decision more efficiently.
Where conventional software is usually better
Not every intelligent-looking task needs AI. If the rules are stable, the inputs are structured and the correct result must be identical every time, conventional automation is often faster to test, cheaper to operate and easier to audit.
AI is also a poor shortcut for an undefined process, unreliable source data or an ownership problem. It can make an unclear system more difficult to understand because the uncertainty is now hidden behind a fluent response.
- Use deterministic rules for exact calculations, permissions and required compliance checks.
- Fix the underlying process before automating a workflow nobody owns.
- Avoid autonomous action when a plausible mistake could create unacceptable financial, legal, safety or customer harm.
- Do not build a custom AI system for a low-volume task that a clear template or existing product already handles well.
Score the opportunity before building
A short opportunity assessment can eliminate weak ideas early and turn promising ones into a testable brief. The aim is not to produce a perfect business case; it is to expose the assumptions that matter.
- Outcome: name the change in time, quality, capacity, risk or customer experience.
- Frequency: confirm the task happens often enough for improvement to matter.
- Variation: identify where human interpretation is required and where rules remain stable.
- Evidence: list the trusted information the system may use and how freshness will be maintained.
- Tolerance: define acceptable errors, prohibited errors and when a person must intervene.
- Ownership: name who reviews performance, exceptions and future changes.
- Measurement: choose a baseline and a small number of signals that can show whether the pilot helped.
Pilot the smallest honest version
A useful pilot should test the risky part of the idea with real examples. It might operate on a limited document set, support one team, or make recommendations without taking action. That boundary is a strength: it creates evidence before the system receives wider access or responsibility.
Measure the whole workflow, not just model accuracy. Time spent correcting results, missing context, user confidence, escalation frequency and operational support can decide whether the system creates value in practice.
What a good first brief contains
A technical specification is not required. A useful first brief can fit on one page: the current workflow, the people involved, the desired change, example inputs, trusted sources, unacceptable outcomes and the evidence that would justify continuing.
That is enough to compare AI with rules, integration, process redesign or an existing product. The right outcome may be an AI system, a simpler automation, or a decision not to build. All three can be valuable conclusions.
