When an organisation decides to use AI, the question put to consultants and transformation teams is rarely technical. It sounds more like: where do we start, on what, with whom, and how will we know it works. Answering it does not require training a model. It requires connecting a business problem, an organisational constraint and a technical capability whose limits you understand.
This guide is for consultants, transformation leads, change managers and business analysts who support these projects without being engineers. It does not argue that you should become an AI engineer. It describes what to understand, what to ask for, and what to organise so that an AI project produces something other than a successful demo.
Start with a problem, not with a technology
Many projects begin with an intention stated backwards: we want AI in this area. The job of consulting is to turn that intention into an observable problem, with a before and an after that the people doing the work can recognise.
- What work actually happens today, including the informal steps nobody documents?
- Who does it, with what workload, expertise and room for judgement?
- What is expensive: time, waiting, quality variance, reworking errors?
- Which decisions are made in this process, and when do they become hard to reverse?
- How much of the volume is exceptions that fall outside the nominal case?
- What happens when the output is wrong: who sees it, who fixes it, who answers for it?
A problem that cannot be described without the word AI is probably not a problem yet: it is an appetite for a solution.
Turn an ambition into a workable use case
A workable use case comes down to a few explicit elements. While they are missing, conversations with engineering stay vague and trade-offs get made on instinct.
- 1
Name the task, not the domain
framingHelping customer service is not a task. Drafting a reply from the customer history and the knowledge base is one: it has an input, an output and a recipient.
- 2
Describe the available input
dataWhat information really exists, in what form, at what quality, with what access rights and what sensitive areas. An impressive capability on data the organisation cannot use is worth nothing.
- 3
Define what a good result is
qualityWho judges, against which criteria, with examples of acceptable and unacceptable outputs. Without this, evaluation shrinks to a shared impression in a meeting.
- 4
Place the human
accountabilityWhat the system proposes, what a person checks, what can go out unreviewed, and what never will in this context.
Questions worth asking engineering teams
You do not need to know how to build a system to question it usefully. A handful of questions surfaces the real dependencies, and they are legitimate coming from a non-technical profile.
- What sources does the answer rely on, and what happens when the information does not exist?
- How is a doubtful output recognised, and what is planned for that moment?
- What have you measured, on which sample, and does that test set resemble real work?
- Which data leaves the organisation's perimeter, and for how long?
- What breaks if volume grows, or if the process changes in six months?
- Which part of this will need maintaining, and by whom?
A good framing question is not there to catch anyone out: it makes an implicit assumption visible before it turns into an expensive dependency.
Demo, pilot and deployable use
Confusing these three states is one of the more common ways projects fail, because the enthusiasm of a demo turns into a deployment commitment without anything being checked in between.
What a demo shows
The system can produce a convincing result on selected cases, in a controlled environment, in front of an audience that carries no responsibility for checking the output.
What deployable use shows
The system holds on unselected cases, exceptions included; its errors are detectable; the review process exists and is sustainable; accountability for the final decision is written down somewhere.
That is exactly what a pilot is for. It only has value if it runs on real work and allows the conclusion that you should not go ahead.
An illustrative scenario
The scenario below is fictional. It exists to show a sequence of decisions, not to describe a client or an observed outcome.
A legal department wants to use AI on supplier contracts. Framing reveals that the real pain is not drafting but reviewing non-standard clauses in contracts received as PDFs, often at quarter end. The use case becomes: flag deviations from a reference clause library and present them to a lawyer, never concluding on compliance.
That shift changes everything downstream: the input is identified, the quality criterion becomes no material deviation left unflagged, the decision stays legal, and the pilot can run on contracts already processed whose outcome is known. The conversation with engineering stops being about models and becomes one about recall, source traceability and the ergonomics of review.
Organise human accountability and adoption
Make accountability explicit
A probabilistic system carries no responsibility. So write down who checks what, at which point, with what level of control depending on risk, and who answers for the result sent outside. That document is a consulting deliverable in its own right, often more useful than another framing deck.
Support users on the limits
The most useful training is not about the interface but about the situations where the system does not help: out-of-scope cases, missing information, plausible but wrong outputs. A user who can name two or three of those develops calibrated trust, which is the actual goal.
- Provide an escalation path when a result looks doubtful.
- Treat workarounds as information about the process, not as misbehaviour.
- Look at what people actually do rather than what they report in a workshop.
- Be willing to narrow the scope of use when observation justifies it.
Challenge without claiming you could build it
The strongest posture is to own the boundary: you are not designing the system, you are accountable for the fact that what gets built solves a real problem in an organisation able to sustain it. That requires understanding the vocabulary, the orders of magnitude and the trade-offs — not implementing them.
Consulting and engineering are not opposites: they fail together whenever nobody connects the real work, the technical solution and accountability for the decision.
Before starting an AI initiative in an organisation
A short list to run through at framing stage, whatever the maturity of the company.
- The problem is described without using the word AI.
- The target task has an identified input, output and recipient.
- The required data exists, is accessible, and its use is permitted.
- What counts as a good result is written down, with acceptable and unacceptable examples.
- What the system proposes and what a human decides is explicit.
- The level of review is proportionate to the risk of the use case.
- The pilot runs on real work and allows a negative conclusion.
- Someone is named accountable for the final result that goes out.
Key points
- The consulting role is to connect a business problem, an organisational constraint and a technical capability — not to build the system.
- A workable use case has a named task, an available input, a quality criterion and a clear place for the human.
- A few well-chosen questions are enough to surface the real dependencies of a solution.
- Demo, pilot and deployable use are three distinct states and should not be conflated.
- Accountability for a decision cannot be delegated to a probabilistic system: it has to be written.
- Adoption is measured in observed work, not in stated intentions.
- Adoption
- Use-case framing
- AI literacy
- Human-in-the-loop