An AI conversation becomes easier when it has a clear task at its centre. Instead of beginning with an organisation-wide ambition, choose a recurring piece of work that a team can describe and evaluate.
That might be preparing a summary for a reviewer, finding relevant information in an approved set of documents, or drafting the next step in an operational process. The first question is what useful assistance would look like to the person doing the work.
Choose a bounded task
A good starting brief names the user, the input and the intended output. It also explains what happens after the output appears. If the task is to help review a document, who receives the result and what must they check before acting on it?
Write down what is outside the boundary. An assistant that prepares a recommendation does not automatically need permission to send it, alter a business record or contact a customer. Those are separate decisions about the workflow.
Collect representative examples
Bring examples of the information the system will encounter. Include ordinary cases and the awkward ones: an incomplete document, conflicting records, an unfamiliar term or a question that the available sources cannot answer.
The examples should reflect the task and the people affected by errors. A useful evaluation asks whether the output gives the reviewer enough evidence to reach a decision, and whether missing information is made visible.
Avoid treating a successful demonstration as the final decision. A demonstration is an opportunity to ask better questions about the range of situations the system will face.
Decide what a person reviews
Human review needs a place in the interface and an owner in the organisation. Define what the person sees, what they can correct and when they should reject the suggestion or take a different path.
The review experience should show the information that matters to the task. Depending on the workflow, that could include source excerpts, the original document, unresolved fields or a proposed change before it is applied.
The amount of automation can then follow what the team learns. It should remain a deliberate choice rather than an accidental consequence of connecting another tool.
Test the whole journey
An answer on its own is only one part of the experience. Consider access to source information, delays, failures, review and the final handoff to another application or person.
Agree how the pilot will be assessed before expanding it. Useful questions include: can the team recognise when the output needs correction? Does the assistance fit into the existing workflow? Is the review effort acceptable? Are there cases that should remain entirely manual?
Make the next decision explicit
A pilot can lead to several reasonable outcomes. It may be ready for a limited rollout, need a narrower task, require better source information, or show that conventional software is a better fit.
That is useful learning. The point of a first step is to make the next investment decision with more clarity about the task, the behaviour of the system and the people responsible for it.
Explore applied AI at Kerning and how we approach engineering.