You decide what the tools are for, job by job, and write it down once. Consistency is a specification problem before it is a training problem.
Almost every business I see arrives here the same way. One person got good at AI on their own time. Everyone else is either not using it or using it differently, and nobody chose either outcome.
The instinct is to fix it with training, a policy, or standardising on one tool. All three help a little. None of them is the thing that works.
Why does AI work brilliantly for one person and not the rest?
Because what they know is tacit, and nobody has asked them to write it down.
The person who is good at it has built a method through trial and error. Which tool for which job. What to feed it. What it reliably gets wrong. When not to bother. None of that is written anywhere, and if you asked them to explain it they would probably say “I just use ChatGPT”, because the useful part is invisible even to them.
Everyone else is starting from scratch on a tool that will confidently produce something plausible no matter what you give it. That is the whole problem. A keyword search that misses gives you a page of results you can see are wrong. A model that misses gives you something that reads well, and you cannot always tell.
So the work spreads out. A car dealership I worked with was already using AI, for social posts and for staff training, and had been for a while. What they did not have was any two people doing it the same way, so nothing they put out sounded like it came from one dealership. Two quotes written the same week have the same problem. That is the cost people notice first, and it arrives long before anything a regulator would care about.
The second cost is quieter. You cannot improve something you cannot see. If nobody knows how the good version is produced, nobody can make it better, and it walks out the door when that person does.
Is the answer more training?
Partly, and not in the way most people mean it.
Training helps, and I have written separately about what AI training should actually cover. The problem is that the standard curriculum teaches people about the technology rather than what to do with it on Monday. Where it does get practical, it tends to reach for prompt technique, which is the least durable part of this. Models change, and the wording that worked in March needs rewriting.
Two people given identical training still produce different work if nobody told them what the job is. Train ten people on prompt technique and you get ten more skilled people making ten different decisions.
The part worth teaching is narrower and duller: what this tool is for in this business, what goes into it, what gets checked before it leaves. That survives a model upgrade.
Do you have too many tools?
Probably, though the number matters less than whether any of them has a job.
The usual picture is a set nobody chose. Each one arrived with a different person, two of them overlap, and one was a trial that quietly renewed.
The fix is not consolidation for its own sake. Some businesses genuinely need a writing tool and a meeting tool and something inside their own system. The fix is that each one has a stated job and someone who owns it. A tool with no assigned job produces inconsistency by default, because everyone assigns it a different one.
The opposite case is just as common and worth naming. A plumber I spoke to ran his business through a trade platform that genuinely did most of what he needed, and a lawyer told me the same about her practice management system. Neither was wrong. What both were missing was everything happening around the edges of that platform, which is usually where the week actually goes.
There is a practical test. Ask three people which tool they would use to draft a client proposal. Three answers means the tools have no jobs, not that you have too many.
What should everyone actually agree on?
Less than you would think, and it needs to be written down.
For most firms I work with the shared list runs to a handful of lines:
What client information can go into which tool. This is the one that matters most and the one most often unstated. Some of your legal obligations sit here, and others sit in what the tool then does with the output, which I have covered in whether Australian businesses still need AI governance.
Which tool is for which job. Named, so the question stops being asked.
What gets checked before it goes out. Not everything needs checking. Decide which things do.
Who to tell when it gets something wrong. Without this you never find out, because the person who caught it just fixed it quietly and moved on.
That is the whole document for most small and mid-sized firms. If yours runs longer, it was written for a different company.
When does AI stop being an experiment?
When something specific is expected to work the same way twice, and somebody owns it.
The experiment stage is fine and necessary. The failure is staying there. A pilot that works in controlled conditions, run by the person who is enthusiastic about it, on examples they chose, tells you almost nothing about whether it survives an ordinary Tuesday.
What moves it across is unglamorous. The job is named. The inputs are consistent. Someone is accountable for the output. It is in the actual workflow rather than beside it, so using it is easier than not using it. That last point does more than any policy: if the agreed way is slower than the workaround, people take the workaround, and they are right to.
There is a standard for managing AI at an organisational level, ISO/IEC 42001, adopted here as AS ISO/IEC 42001:2023. It is written for organisations of any size, though certifying to it is rarely proportionate for a small or mid-sized firm. Know it exists anyway, because the place you are most likely to meet it is a larger client’s supplier questionnaire rather than a standards catalogue.
How do you know if any of it is working?
Pick the small number of things you can actually see, and be honest that some of what you want to measure is out of reach.
Genuinely visible in a small business:
Is it being used? Not licence counts. Whether the job it was bought for is now done that way.
How long the job takes now. You need a rough before figure, which means writing one down before you start. Almost nobody does, and it is the cheapest thing on this list.
How often it is wrong. This only exists if you built the reporting step above. It is the most useful number you will have and the one most businesses never collect.
Whether people trust it. Ask them. It tells you whether people believe it, not whether it is any good, and those two come apart in both directions. A team quietly working around a tool is still a real result.
Harder, and worth being honest about: attributing revenue to AI. In a business with a handful of deals a month there is no clean way to separate the tool from the market, the season, or the person. I would rather you measured four things properly than built a dashboard that implies a precision you do not have.
What does this look like in a business of ten people?
A conversation, a page, and one person who owns it.
At that size there is usually no governance function and there does not need to be, unless your work is caught by the obligations in the piece linked above. The whole thing is: agree what goes in, agree which tool does what, agree what gets checked, write it on one page, and revisit it when something changes.
The bigger the business, the more this becomes real work. Multiple teams, systems that talk to each other, people who never meet. The principle holds and the effort does not scale down as neatly as the page does.
Where do you start?
With the person who is already good at it.
Sit with them for half an hour and get the method out of their head. Which tool, what they feed it, what they check, where it fails. Write it down as they talk. That half hour is usually worth more than a training day, because it is specific to your work and it already survives contact with your clients.
Then pick one job. Not a category, one job. Quotes, or client updates, or meeting notes. Make that one consistent, with a named owner and a check step, and see what it takes. What you learn on the first one is what tells you whether the second is worth doing.
One job made repeatable teaches you more than a plan for ten. You can see what that looks like as an engagement in AI automation, or talk it through on a call.
FAQ
How do I stop everyone in my team using AI differently?
Give each tool a stated job and write down what goes into it and what gets checked. Most inconsistency comes from people filling a specification gap themselves, not from a lack of skill. A single page covering which tool for which job, what client information is allowed, and what gets reviewed will resolve more than a training session.
Should we standardise on one AI tool?
Not necessarily. The problem is rarely the number of tools, it is that none of them has an assigned job. Two tools with clear purposes cause less inconsistency than one tool everybody uses differently. Consolidate when you find two doing the same job, not on principle.
Is prompt engineering worth training my team on?
Some, but it is the least durable part. Models change and the wording that worked last quarter stops mattering. Time is better spent on what the tool is for, what information goes into it, and what gets checked before the work leaves the business.
How do we measure whether AI is actually working?
Track whether the job is now done that way, how long it takes compared with a before figure, how often the output is wrong, and whether the team trusts it. Write down the before figure first, because it is the cheapest measurement you will ever take and it disappears once you start.
Our AI pilot worked but never spread. Why?
Pilots usually run on chosen examples, with the enthusiastic person running it, in conditions that do not repeat. What moves something out of pilot is a named job, consistent inputs, an accountable owner, and being inside the workflow rather than beside it. If the agreed way is slower than the workaround, people use the workaround.
Do we need an AI policy for this?
For most small firms, one page covering what information goes into which tool, which tool does what, what gets checked and who to tell when it is wrong. That is enough for consistency. Whether you have separate legal obligations is a different question, and it depends on whether you are covered by the Privacy Act and what your AI touches.
How do I capture what our best AI user knows?
Sit with them for half an hour and write it down as they talk. Which tool for which job, what they feed it, what they check, where it fails. Most of it is tacit and they will not volunteer it, so ask about a specific piece of work rather than their method in general. That half hour is usually worth more than a training day, and it stops the knowledge leaving when they do.
General information only, not legal advice. Current as at August 2026.
