Our original 2024 article explored what AI could make possible in content, communication and everyday work. It also asked a question that is still worth answering before choosing a tool: why do we want to use AI here?
A demonstration can make a capability look exciting. A useful introduction starts with a problem your organisation actually needs to solve and a clear idea of what a good result would be.
Start with a bounded job
Choose a task with a clear input, output and owner. That might be preparing a first draft from approved material, organising notes for review or helping someone find relevant information. Keep the first test small enough that you can inspect what happens.
Write down the current process. Include the time spent checking and correcting work, because those steps still count when you compare an AI-assisted version.
Decide what improvement would justify continuing. Faster completion may matter, but so might clearer communication, fewer omissions or a more accessible format. Do not assume those benefits have arrived simply because the tool produced an answer.
Apply it to your work
Bound the AI trial before widening its use
- Purpose
Name one bounded job and its expected result.
- Review
Decide who checks the output and how.
- Information
Set deliberate limits on data and access.
- People
Include those affected and review the result before expanding.
Make review part of the design
Generative AI can produce plausible content that is wrong. The UK Government's AI Playbook highlights this limitation and the need for meaningful human control at appropriate stages.
Decide who checks the output, what they are checking and when they can stop or change the process. The level of review should reflect the consequences of an error. An internal outline and advice that affects another person need different treatment.
Give reviewers the source material and enough time to use it. A required approval is only useful if the person can assess the result.
Be deliberate about information and access
Before using real work in a tool, establish what information the organisation has approved for that use. Check the service's terms and settings, and get the appropriate privacy or security review where needed.
Use approved or non-sensitive material for an early trial. Give an integration only the access it needs for its job. Make it clear who can change that access and who owns the tool once the trial ends.
These questions become more important when a system can take actions as well as generate text. Specify which actions require approval and how the team can stop the process.
Include the people affected
Ask the people doing the work where assistance would be useful and where it might create another checking task. Test with different users and realistic examples. A result that works for the project team may be less useful to someone with different knowledge or accessibility needs.
Explain how the tool is intended to support the work. Provide a route for reporting problems, and act on that feedback. Avoid promising a particular effect on roles or workload before the evidence supports it.
Review the result before expanding
At the end of the trial, compare quality, completion time, correction effort and user feedback with the starting point. Record the failures as well as the successes.
Then choose deliberately: improve it, expand it, keep its scope small or stop. A test that shows a tool is a poor fit can save a much larger implementation mistake.
If you are deciding where AI could be useful, talk to Yopla about the work you want to improve and the safeguards it needs.
Originally published by Yopla in 2024. Refreshed for the current library.
All insights