Skip to content
Engineering Practice 19 June 2026

Your AI feature works. Nobody's using it.

Building an AI feature that works and getting people to use it are two different achievements, and the second is where most of the value quietly leaks away. The published gap between access and use is now around 60 percentage points, and it is not a technology problem.

There is a quieter kind of AI adoption failure than the one that makes headlines. Nothing breaks. The model is good, the feature works, the launch went smoothly, the demo landed. Then you check the usage three months later and a handful of people are touching it. The thing you built is fine. The thing you wanted, people using it to do their work differently, never happened. The build succeeded and the adoption failed, and because the build is the part that feels like the achievement, most teams treat the launch as the finish line when it is actually the start.

This post is about the gap between a working AI feature and an adopted one, why that gap is enormous, and what closing it actually takes. The short version: the work that gets people to use AI is mostly not engineering work, and the teams that produce real returns are the ones who understood that before they shipped.

The gap is real, large, and measured

The most quotable number on this came from IBM's 2026 Global CEO Study. Across the organisations surveyed, around 85% of employees now have access to AI tools at work, and only about 25% use them regularly. That is roughly a 60-point gap between capability and behaviour. It is not a hardware problem and not a software problem; the licences are bought, the platforms are deployed, the infrastructure is in place. The gap is the harder thing: the distance between what is available and what actually gets used.

This is the distinction that change-management practitioners hammer in 2026, and it is worth stating bluntly: deployment is not adoption. McKinsey's data through 2025 showed near-universal AI deployment sitting alongside thin profit impact: companies had rolled the tools out and were not getting the value, because rolling out is not the same as taking up. A seat provisioned is not a habit changed. Every idle licence is money spent on capability that produces nothing, and the dashboards that count provisioned seats will tell you everything is going beautifully right up until someone asks what it actually changed.

Why people don't use a tool that works

The instinct, when a feature goes unused, is to assume the feature is not good enough, and to go back and improve the model. That is almost always the wrong move, because the reasons people do not use working AI tools have very little to do with model quality.

Gallup's February 2026 study of more than 23,000 employees is the clearest evidence here. The two factors that most strongly separated frequent AI users from non-users were not technical: employees used AI when it fitted naturally into their existing workflows, and when their managers actively supported its use. Where those two conditions were missing, the tools went unused even when they were available and good. Alongside that, employees reported the familiar discouragements: doubts about whether it was actually useful for their specific job, concerns about ethics and data security, the fear of using it wrong and being blamed, and the simple gravity of established habits.

None of those are technology problems. They are adoption problems, and they respond to adoption work, not to another round of model tuning. The single most striking input in the change-management research is training: by most counts, only around 13% of workers have received any employer training on the AI tools they have been given. Training is consistently the largest lever on adoption, and almost nobody pulls it. We have watched teams spend a quarter improving a model that was already good enough, when the thing standing between them and adoption was an afternoon of showing people how it fits into their Tuesday.

Two failure shapes, both bad

Unused AI shows up in two forms, and they look opposite but have the same root cause.

The first is the sanctioned tool nobody uses: the 25%. Built, deployed, announced, and then ignored, because it did not fit how people actually work and nobody helped them make the shift. It sits in the corner of the software estate as a line item with no return.

The second is the opposite-looking problem: shadow AI. By several 2026 estimates, a large majority of employees (figures around 78% appear in the change-management literature) route around the sanctioned tools to use whatever unofficial AI they prefer. It is tempting to read this as a discipline failure and respond with a ban. That is the wrong reading. People routing around your official tool to an unofficial one are giving you a precise product signal: the sanctioned thing does not fit the work, and they found something that does. The right response is to treat shadow AI as a product-gap report, not a compliance infraction, while also recognising it as a genuine security exposure, since a meaningful share of organisations now believe they have already leaked data through unapproved tools. Both failure shapes say the same thing: the tool and the work did not meet.

Trust is an adoption lever, not a soft concern

Underneath fit and support sits trust, and AI trust is more fragile than most rollouts assume. People do not adopt what they do not trust, and surveys put employee trust in their own organisation's responsible use of AI strikingly low: in one 2025 study, only around a quarter of working adults said they fully trusted their employer to use AI responsibly. Worse, trust is asymmetric: a single confident, wrong answer early in someone's experience of a tool can end their use of it permanently, no matter how good the average output is.

This is where the engineering and the adoption stories meet. A system whose answers are reliable, and whose reasoning a person can inspect and understand, earns trust and gets used. A system that occasionally produces a confident falsehood it cannot explain does not, and no amount of change management rescues it, because the distrust is rational. Building AI so that it is reliable and explainable, so the truth comes from something a person can check rather than from a model's unaccountable say-so, is not only an engineering virtue. It is one of the most powerful adoption levers you have. The teams who get adoption right tend to have got the trustworthiness right first.

What actually drives adoption

The work that closes the gap is unglamorous and consistent, and it is mostly the work of product and change management rather than engineering. The levers that move adoption, in roughly the order they pay back:

  • Bring the AI to where people already work. The single biggest fit problem is asking people to go to a new destination. Surfacing AI inside the tools and the moments people already inhabit (their inbox, their existing dashboard, the chat channel they already watch) beats the best standalone product nobody opens.
  • Get visible support from managers. Gallup's data is clear that managerial support is one of the strongest predictors of use. A leader who visibly uses the tool and expects their team to use it is worth more than a launch email.
  • Train people for real. Not a one-off webinar. Role-specific, hands-on, repeated. It is the largest lever and the most neglected one.
  • Answer "what's in it for me", role by role. Generic enrolment fails. A person uses AI when they can see what it does for their job this week, not what it does for the company this year.
  • Name the job-fear honestly. Resistance rooted in fear of replacement does not respond to cheerful messaging. It responds to a straight, honest answer about what the tool is and is not for.
  • Earn trust by being reliable from day one. The first month sets the relationship. A tool that is right and explainable when it matters early gets a second chance; one that is confidently wrong does not.

Measure AI adoption, not deployment

The reason so many teams do not do this work is that their metrics never tell them it is needed. If you measure deployment (seats provisioned, tools rolled out) you will see a green dashboard while the value leaks away, because deployment is the easy thing to count and the wrong thing to count.

The metrics that actually tell you whether AI is being taken up are behavioural. Monthly active usage. Depth of use: are people using it for the thing it was meant for, or poking it once and leaving? The shadow-AI rate, watched as an early-warning signal that your sanctioned tool is losing to an unofficial one. And, underneath all of it, periodic re-measurement of the trust gap and the training coverage, because those are the inputs you can actually fix. A useful discipline: for every AI feature, before launch, write down the behaviour you expect to change and how you will see it. If you cannot name the behaviour, you are measuring deployment and calling it success.

The build is the easy part

There is a number from the change-management research that reframes the whole exercise: of the difficulty in making an AI initiative succeed, roughly 38% is human proficiency and around 16% is technical. The model, the integration, the engineering (the part that feels like the work) is the smaller share of the problem. The larger share is people, process, and habit. This is consistent with the wider pattern we keep returning to: the model was the easy part. So is the feature.

The teams that get real returns from AI in 2026 are not the ones with the most capable models. They are the ones who treated the launch as the start of the work rather than the end of it: who fitted the tool to how people actually work, trained them properly, earned their trust by being reliable, and measured whether behaviour actually changed rather than whether a tool was technically available. The rest ship something that works, congratulate themselves, and quietly watch it gather dust. Closing that gap, treating adoption as the deliverable rather than the demo, is exactly the work good AI consulting does.

"Your AI feature works" is the first half of the sentence. Whether anyone uses it is the half that decides whether you built anything worth building. When that half goes badly, the explanation offered internally is usually that staff resisted the change; we took that apart in employee resistance to AI is usually a rational response.


References

  1. IBM: Global CEO Study 2026 (AI access vs. regular use; the adoption gap), summarised by MindStudio. https://www.mindstudio.ai/blog/ai-adoption-gap-ibm-2026-study
  2. Gallup: AI in the Workplace: What Separates Adopters and Holdouts (February 2026 study of 23,717 U.S. employees). https://www.gallup.com/workplace/704252/workplace-separates-adopters-holdouts.aspx
  3. Digital Applied: Change Management for AI Adoption: A 2026 Playbook (synthesis of Prosci, Gallup, WalkMe, Deloitte and McKinsey data, including McKinsey's deployment-vs-profit finding and the ~38% human / ~16% technical split). https://www.digitalapplied.com/blog/change-management-ai-adoption-2026-overcoming-resistance-playbook
  4. Gallagher: 2026 AI Adoption and Risk Benchmarking (employee trust and change resistance). https://www.ajg.com/news-and-insights/features/ai-adoption-and-risk-benchmarking-2026/
  5. HR Dive: US Workers Report a "Major AI Trust Gap" (SHL survey on responsible-use trust). https://www.hrdive.com/news/us-workers-report-a-major-ai-trust-gap/806151/
  6. WRITER: Enterprise AI Adoption in 2026: Why 79% Face Challenges Despite High Investment (shadow AI, disappointment, ROI gap). https://writer.com/blog/enterprise-ai-adoption-2026/
  7. ISHIR: Enterprise AI Adoption in 2026: Common Pitfalls, Risks and Proven Strategies. https://www.ishir.com/blog/321254/enterprise-ai-adoption-in-2026-common-pitfalls-risks-and-proven-strategies-for-success.htm

Written by JP, Sixees Labs. Last reviewed June 2026.

JP

Co-founder, Sixees Labs

Co-founder of Sixees Labs. Engineer and systems thinker focused on shipping AI that actually works in production.

We use cookies to understand how you use our site so we can improve it. Choose Necessary only to decline analytics. See our cookies policy for details.