The UK’s AI Divide Is Not About Access. It’s About Adoption Support 

Gleb Tsipursky, PhD, is a behavioral scientist and CEO of Disaster Avoidance Experts, called the “Office Whisperer” by The New York Times. He is regularly featured in Harvard Business Review, Fortune, and Forbes. His new peer-reviewed Georgetown University Press book, The Psychology of AI Adoption at Work, examines the psychological factors that determine whether AI projects succeed or fail.

By Gleb Tsipursky, PhD, Behavioral Scientist and CEO, Disaster Avoidance Experts 

Organizations are investing heavily in enterprise AI, giving employees access to increasingly capable tools and expecting productivity, efficiency, and innovation to follow. 

But access alone does not determine whether AI adoption succeeds. 

The same technology can produce radically different outcomes across organizations, departments, and even teams. The difference often has less to do with the capability of the AI itself and more to do with the management environment surrounding it: whether employees have permission to experiment, whether leaders are willing to learn publicly, how organizations respond to mistakes, and whether employees believe becoming more productive will ultimately work for or against them. 

Understanding those dynamics is becoming essential as organizations move beyond AI pilots and begin asking a harder question: how do we turn access to AI into sustained organizational capability? 

Why Similar AI Deployments Produce Different Outcomes 

One pattern I have seen repeatedly, including in insurance-sector work, is that organizations can give leaders access to the same enterprise AI tools and still get sharply different outcomes because the management environment around those tools differs. At one insurance organization, executives entered an AI workshop with very different levels of familiarity and confidence even though they had access to the same technology. The important shift came when leaders stopped treating AI as a software rollout and started working through concrete recurring tasks together. 

Managers who encouraged experimentation, asked people to bring real workflows, and made room for questions created much more engagement than managers who treated AI proficiency as something employees should figure out privately. The gap came from practice, permission, and management behavior rather than the underlying tool. That is why I advise leaders to measure adoption support, not simply access. Two teams can have identical licenses while one has coaching, examples, psychological safety, and time to practice and the other has ambiguity and pressure to perform immediately. 

A practical sign of divergence is what happens after the first successful experiment. On a well-supported team, the employee shows colleagues what worked, explains where the output failed, and turns the lesson into a repeatable workflow. On a poorly supported team, the experiment stays private and disappears when the original employee becomes busy. The technology can be identical while the organization either compounds or loses the learning. 

What Status and Identity Threat Look Like in Practice 

Status threat rarely appears as someone saying, “I am afraid AI will make me less valuable.” It usually arrives disguised as a respectable operational objection. A senior professional may repeatedly redirect AI discussions toward edge-case failures, insist that the tool cannot understand the nuances of the work, delegate every experiment to junior staff, or demand a level of certainty from AI that the organization does not demand from ordinary human work. 

Managers may also praise AI publicly while avoiding using it in front of their teams because being visibly inexperienced threatens the expert identity on which their authority rests. One useful signal is selective skepticism: the person identifies real risks, but every proposed safeguard produces another reason not to try the tool. The answer is to make learning status-neutral. Senior leaders should experiment publicly, discuss mistakes, and define AI competence as good judgment about when and how to use the tool rather than effortless mastery of an interface. 

Why Hidden AI Use Emerges and How to Govern It 

Hidden AI use often reflects a mismatch between employee demand and organizational permission. Employees discover that a tool helps them draft, summarize, analyze, or prepare faster, but they do not know whether management will view that use as initiative, laziness, a security problem, or evidence that their role is easier than leaders assumed. Some also fear that revealing a productivity gain will simply result in more work or fewer positions. Those incentives push useful experimentation underground. 

The strongest response I have seen replaces the binary choice between prohibition and unrestricted use with governed experimentation. Give employees a clearly defined safe zone: approved tools, prohibited data types, tasks that require human verification, and an easy path for disclosing useful experiments without punishment. Then ask teams to bring successful use cases into shared sessions where colleagues can examine the workflow, the prompt, the verification step, and the failure modes. This turns private experimentation into organizational learning while preserving firm boundaries around sensitive data and consequential decisions. 

The critical governance mechanism is a low-friction disclosure path. If employees need three approvals to report a useful experiment, they will keep it quiet. If they can document the task, data involved, verification step, and observed failure modes in a few minutes, leaders gain visibility without turning every experiment into a compliance project. 

What Separates Training That Changes Work From Training People Forget 

Most AI training fails because it teaches the tool rather than redesigning the work. A demonstration can make people impressed without making them capable. Training becomes durable when participants use AI on a recurring task they actually own, compare the old and new workflow, practice verification, and leave with something they will use again the following week. 

In my workshops, I focus on three layers. First, people learn a small number of practical prompting and reasoning patterns. Second, they apply those patterns to their own work rather than generic examples. Third, managers establish what happens after the session: which workflows should be tested, what risks require review, what results should be shared, and how employees can get help when an experiment fails. Repetition matters more than novelty. Reusable artifacts such as prompt libraries, workflow examples, checklists, and shared agents also matter because they convert a training event into infrastructure for continued practice. 

I also look for a transfer test. A participant should be able to take a principle learned on one task and apply it to a different task without waiting for another class. If the person can only reproduce the exact demonstration, the training produced familiarity rather than capability. 

What Leaders Should Measure Beyond Licenses, Logins, and Usage 

I recommend measuring AI at the task and workflow level. Start with a baseline for cycle time, quality, error rate, and human effort before AI enters the process. Then measure the full AI-enabled workflow, including prompt preparation, verification, correction, escalation, and downstream rework. A five-minute draft that creates twenty minutes of checking is a twenty-five-minute workflow, not a five-minute one. 

I would track at least six categories: total cycle time, first-pass quality, verification and correction time, material error or escalation rate, employee confidence using and checking the tool, and managerial support. I also look at whether employees can transfer what they learned to a new task without starting from zero. That is a stronger signal of capability than raw usage. Finally, leaders should distinguish adoption breadth from adoption depth. Ten people opening a tool once a week may matter less than three people redesigning a recurring process so that it becomes faster and better without increasing risk. 

The Finding That Most Changed My Thinking 

What surprised me most was how often apparent resistance reflects a rational response to the organization rather than a negative attitude toward technology. Employees pay close attention to incentives. If management says AI will make work easier while simultaneously discussing head-count reduction, people have a reason to hide what they learn. If leaders demand experimentation but punish visible mistakes, employees will experiment privately. If managers cannot explain how AI changes performance expectations, workers will protect the routines that currently make them look competent. 

That shifted my attention toward psychological safety, status, incentives, and manager behavior. I initially expected tool quality and individual technical comfort to explain more of the adoption gap. They matter, but the social environment often determines whether people convert access into sustained use. Hidden AI became especially interesting to me as an organizational diagnostic because it can reveal strong employee demand and weak institutional trust at the same time. 

The more useful leadership question becomes: What signals are our policies, incentives, and managers sending about what happens to people when they use AI well? 

About the Author 

Gleb Tsipursky, PhD, is a behavioral scientist and CEO of Disaster Avoidance Experts, called the “Office Whisperer” by The New York Times. He is regularly featured in Harvard Business Review, Fortune, and Forbes. His new peer-reviewed Georgetown University Press book, The Psychology of AI Adoption at Work, examines the psychological factors that determine whether AI projects succeed or fail. 


Inside Telecom provides you with an extensive list of content covering all aspects of the Tech industry. Keep an eye on our Press Releases section to stay informed and updated with our daily articles. 

Join our WhatsApp Channel WhatsApp Channel