Adoption
Adoption is the hard part
The hardest part of putting AI to work in an industry is not getting a pilot to perform. In my experience leading large technology and platform programs, the pattern is consistent: a team shows that a model can do something useful on a bounded set of cases, the room is impressed, and then, a few months later, the work is still being done the old way. The pilot did not fail. It simply never became the way the organization works.
A pilot answers a narrow question: can this capability handle this kind of work, under these conditions, with this group of people watching closely? Adoption answers a different one: will the people who do this work every day use the new path when no one is watching, and will the organization notice if they do not?
Those are organizational questions, not model questions. They are also where most of the value sits. A capability that works in a demo and is ignored in the workflow is an expensive curiosity. A slightly imperfect capability that becomes the default path, with a human review where it matters, can change how a function operates.
Why pilots stall
When I look back at programs that stalled after a promising start, the causes rarely had much to do with accuracy in the lab. The new path was optional. The old path was familiar, and it still worked well enough. Managers continued to measure the team the way they always had. The people closest to the work had been asked to “try the tool,” not to help redesign the process. And when the first awkward cases appeared — and they always do — there was no agreed way to handle them, so people quietly went around the system.
Cross-team adoption is even more fragile. A platform can be technically ready and still sit unused if neighboring teams do not trust it, do not see themselves in the workflow, or are rewarded for staying inside their own tools. I have seen shared platforms scale when a few teams had a sharp reason to depend on them, a clear owner, and a path for exceptions. I have also seen capable platforms stall because they were offered as a service and no one was responsible for making them the default.
Habits
Adoption is, first, a habit problem. People will not change a weekly rhythm because a slide said the new way is better. They change when the new path is easier for the common case, when it is what their peers do, and when going back to the old path takes more effort than staying with the new one.
In a pilot, a motivated group will tolerate extra steps. In everyday use, extra steps are fatal. If the system asks someone to leave their existing workspace, re-enter context, or wait without knowing what happens next, they will only use it when they are being observed. The practical work is to make the new path the path of least resistance for the cases you actually want it to handle, and to be honest about the cases it should not handle yet.
Incentives
Habits will not hold if incentives pull the other way. If a team is measured on volume, they will not spend time reviewing uncertain outputs. If a team is measured only on speed, they will bypass a control that slows them down. If a leader is rewarded for launching pilots, you will get pilots. If no one is rewarded for retiring a tool that is not used, you will keep it on life support.
In my experience, the incentive question is the one teams skip because it feels political. It is also the question that predicts whether a program will last. You do not need a perfect scorecard. You do need a clear answer to this: what do we want people to do when the system is unsure, and do our measures make that behavior the rational one?
Review
The third piece is review. An AI-supported process needs an owner who is still accountable after the launch emails are forgotten. That person should be able to say what good looks like, what an exception looks like, and when the system should be limited or stopped.
Review is not a single gate at the end of a pilot. It is a cadence: looking at real cases, including the uncomfortable ones, and changing the workflow when the pattern requires it. Without that, quality becomes anecdotal — a compliment or a complaint — and no one can tell whether the system is drifting. I have learned to ask a blunt question at the start of a program: who will still be looking at this in six months, and what will they have the authority to change? If the room cannot answer, we are planning a demonstration, not a practice.
Treat adoption as the program
If I am honest about what I have learned leading this kind of work, it is this: treat adoption as the program, and the model as one input to it. Before you start, name the habit you want to change, the incentive that might fight you, and the person who will review the work after the excitement fades. If you cannot name those things, you are not ready to pilot. You are ready to keep exploring, which is a different and perfectly respectable activity.
The interesting question is rarely “can it work?” It is “will the organization actually use it, and use it well?” The programs that last are the ones that take that second question as seriously as the first.