The pilot went well, it never spread — why?
Short answer
If an AI tool is not sticking in a team, the cause is usually not the tool itself. Three things happen most often. One: the tool is introduced without being attached to work anyone already does, so "when am I going to use this?" goes unanswered. Two: after the first wrong answer nobody knows what to do, and the tool is declared unreliable. Three: because no boundary was drawn around data, the cautious person never uses it and the incautious one uses it where they should not. None of the three are about tool choice — they are about how the tool was introduced to the team.
The pilot worked, it never spread
A familiar picture: a small group tries the tool, the result is good, everyone is pleased. Then the tool is opened to the team and within a few weeks usage fades. A successful pilot does not mean it will spread, because the people in the pilot were the curious ones already.
A curious person attaches the tool to their own work themselves; does not give up after the first wrong answer; builds their own boundary when none was drawn. The rest of the team does none of those three — not because they cannot, but because nobody showed them.
Cause 1 — The tool was never attached to the work
Learning what a tool can do and knowing which task on your own desk to use it for are not the same thing. An introduction gives you the first and not the second. The gap in between closes with the sentence "seems good, but it does not fit my work."
The only thing that closes it properly is the person having done one example from their own work with the tool, end to end. Once. After that the connection is made and the second use arrives on its own.
Cause 2 — The first wrong answer
At some point the tool says something wrong; that is not a surprise. The surprise is that the person has no way of checking it at that moment. An experienced user verifies the output, goes to the source, reframes the question. An inexperienced one either takes the result as it is or abandons the tool entirely.
Both are expensive. The first puts wrong information into the work, the second puts the tool on a shelf. The reflex in between — "how do I trust this, how do I check it" — is teachable, and usually is not taught.
The equivalent in learning to code is reading the error message: the beginner closes it, the experienced developer reads it. With AI tools the picture is the same.
Cause 3 — No boundary was drawn
If which data must not go into the tool is not written down, every person on the team makes their own call. The result collects at two extremes: some avoid the risk by never using it, and some paste in the document they should not have.
The fix here is not more warnings but a clearer rule. "Be careful" is not a rule; "documents with a client name in them do not go into the tool, and if they must, they are anonymised like this" is a rule.
What works: a small, visible win
Spread happens not through a grand transformation story but through a small win the team can see with its own eyes. You pick a repetitive task everyone finds tedious, you build it with the tool, and the result sits in the middle of the team.
After that point nobody needs convincing for the second and third use. That is why the aim of a corporate day is not "introducing the tools" but "having finished one piece of work".
Frequently asked
Does tool choice not matter at all?
It matters, but less than you think. Several tools do the same job, and in most teams what decides is not which one was chosen but whether the chosen one got attached to a piece of work. Switching tools does not rescue a usage that is not sticking.
There is resistance on the team — what should we do?
Most resistance is practical rather than ideological: people fear less that they will lose their job than that they will learn something new and still not be as fast as before. The antidote is not persuasion but the person seeing one small win on their own work.
Can we solve this in-house?
Often yes, especially if someone on the team is curious about the subject. Where an outsider helps is usually this: the curious person can attach it to their own work, but attaching it to somebody else’s work and setting boundaries is a separate job.
