What to Do When Your Team Doesn't Trust the New AI System

When a team does not trust a new AI system, the problem is usually the distance between the rollout and the work. Closing that gap takes more than reassurance. It requires a sequence that starts with a problem employees want solved, gives them a role in building the solution, makes oversight visible, and produces evidence they can use.

Why teams resist AI even when the technology works

Leaders and employees can experience the same AI rollout as two different events. Leaders see a new capability, while employees face a change in how they work, how their judgment is used, and what might happen to their jobs. McKinsey’s August 2026 article argues that AI transformation cannot proceed solely from the top down because value emerges as employees experiment, identify use cases, and redesign their workflows. A system can function correctly without earning that participation.

Prudential’s 2026 Benefits & Beyond study documents the mismatch. Employers view AI far more positively than employees do and underestimate concerns about privacy, accuracy, job impact, and trust. The study finds that one in four employees cites a general lack of trust in AI as a concern, while only a fraction of employers recognizes it.

Privacy and security, reliability, moral and ethical questions, and job impact all shape whether people feel it makes sense to use a system. McKinsey also describes employees as deciding whether they trust leadership enough to make a fundamental change in how they work. Resistance under those conditions can be a rational response to ambiguity. Distrust is information about what the introduction missed.

What makes the trust gap widen after launch

Once the system is live, ambiguity acquires consequences. Where employees are uncertain about AI policy, they must supply their own account of what is permitted and expected. A team that does not know where the boundaries are has little reason to expect fair treatment when mistakes happen.

The workload paradox gives that skepticism firmer ground. Employees may be told that AI will save time, then get more tasks that have to be done faster. In that situation, the promise and the experience diverge. The tool may save time on an individual task while the person using it feels more pressed than before. Another message about productivity cannot resolve a contradiction built into the work.

When employees conceal their use or present AI-generated work as their own, honest discussion about how work gets done becomes harder. McKinsey argues that employees are more willing to experiment and share results when leaders show genuine interest in learning. Without that signal, useful feedback can disappear from view. Distrust then becomes self-reinforcing, because the organization loses the information needed to correct the conditions producing it.

Why transparency is necessary but not sufficient on its own

Transparency helps only if it makes the situation clearer. Employees need an honest account of how AI supports decisions and how that account matches their experience. More disclosure is not automatically more useful. Complexity that employees cannot act on can erode confidence. The useful standard is actionable clarity, including room to question outputs and challenge automated decisions.

Prudential’s study offers a foundation for that approach. The large majority of employees who report AI having some impact on their role say that impact was not negative. Yet talking about those experiences cannot build trust if the system is used unfairly, people cannot see the human oversight, or feedback changes nothing. Communication should connect to a change employees can judge, beginning with a task they already want handled better.

Starting with the bottleneck the team already complains about

The team can start with the bottleneck that already forces it to hire, wait, or turn work away. For a small or medium-sized business, this keeps the build tied to an operational constraint. The distinction is easy to lose in a demonstration. Something can be impressive without being useful to the people expected to adopt it.

McKinsey says that much of AI’s value comes from employees finding high-value use cases. That makes the team’s account of the problem essential, rather than a courtesy after the selection has been made. Starting with one small problem employees feel in their work gives them a first chance to judge whether AI makes that work better. Broader use can grow from that evidence rather than from an instruction to find more things to automate.

SANSA offers an example of this diagnostic-first approach. Its model begins with an audit of operations to identify the highest-leverage AI opportunities, putting the search for the constraint before the build. The relevant principle is the order of operations. A team in that position should begin with the work that is already causing friction, because removing that obstacle answers a question employees actually have. A presentation about future possibilities answers a different one.

Involving the team in building the system, not just using it

Choosing the right problem does not settle how to solve it. The next move is to pair an AI engineer or implementation partner with the internal staff who do the work. Those employees know where the formal description and the actual workflow part company. Their knowledge belongs in the construction of the system. A person who points out that a needed step is missing is helping build the system as well as beta testing someone else’s finished idea.

Prudential identifies employee involvement in the adoption journey as a way to build workforce trust and competency. McKinsey likewise argues for employees to experiment and continually refine AI’s application in their daily work. Both positions go beyond asking whether people like the result. Co-building gives employees a role in determining what the result should be, while a feedback exercise may leave the important choices untouched. That distinction is where skepticism can begin to turn into ownership.

If only the builder understands how the system relates to the workflow, future changes require another trip back to the vendor. The team remains a recipient, even if the first delivery works well. Internal capability to iterate should be part of the engagement. To take ownership, the team needs to know enough to shape the next change as well as have permission to ask for it.

Making governance visible enough that people can trust the guardrails

Participation addresses who helps build the system, but it does not by itself establish the limits of its authority. Employees also need to see where human judgment applies and what happens when the system is wrong. Otherwise, an apparently useful tool can look like a way to outsource judgment to an algorithm. Both the quality of an output and who remains responsible for acting on it matter.

For a small or medium-sized business, the practical response need not be a formal compliance infrastructure. It can begin with a one-page document stating what the system decides, what it only recommends, and whom the team contacts when it is wrong. A fifty-slide deck on AI strategy is a less convenient object to consult when something looks off. Length is not a substitute for an answer.

These guardrails belong in the build phase, before the system is fully live. Their timing tells employees whether oversight was designed in or added after trouble. Visible human-in-the-loop mechanisms also give substance to the promise that people can challenge a result. People can more easily judge what is fair when the boundaries are clear. Governance then serves as a reason to trust the system, rather than a separate obligation that arrives after adoption.

What the first working prototype does that a rollout plan cannot

A working prototype changes the basis of the conversation. Until that point, employees have been asked to assess intentions, explanations, and plans. Now they can assess something built around their work. A narrow prototype can show that their description of the problem affected the design, which is a different kind of proof from showing that the technology functions. It demonstrates that participation had a consequence.

Speed helps make that consequence visible while the build is still open to correction. A system the team can interact with in week three creates opportunities for feedback and investment that an architecturally perfect system delivered in month six postpones. This is an argument for discovering faults with the people who know the workflow, while changes still belong naturally to the process. A missing step found during a live test is a debugging problem, whereas the same discovery after a full rollout can become a credibility crisis.

SANSA’s documented examples show what a concrete result can look like. An insurance broker reduced manual data entry by a large margin, while a freight SMB reclaimed 160 hours each month. Those outcomes give employees something firmer to evaluate than a promise of efficiency. Those gains matter beyond the figures in a business case because they improve work the team has to do. The first win can therefore become evidence for engaging with the next build.

A prototype that solves something nobody found painful enough to care about is more likely to produce indifference than trust. McKinsey reports that organizations where trust is higher get more enterprise value from AI. Early visible wins can also help build the trust needed for subsequent work.

How trust compounds from first win to new capability

Once employees trust the first system enough to use it fully, they can start identifying the next constraint themselves. McKinsey argues that trust helps organizations learn faster because employees share what works and what does not. Feedback loops shorten as a result. The compounding mechanism is therefore not just an improvement in AI capability, but an improvement in how the organization discovers and applies it. The people closest to the work become active participants in deciding what changes next.

That participation can move a business beyond task-level assistance. Adding AI to an existing workflow may make a step faster, while rebuilding the workflow changes how the underlying work gets done. Most organizations remain at the first stage. For a five-person team, moving to the second could mean quoting faster, taking on a service line it could not previously staff, or making decisions that once required an unaffordable specialist.

SANSA’s embedded model is designed around that progression, treating the first system as proof that opens the way to addressing the next bottleneck before it forces a hire or a wait. A successful first build should leave the team better able to recognize what comes next. That is a different outcome from accepting a tool selected elsewhere. A team still waiting to be told what AI to use next has not yet taken ownership. The clearest sign that the trust gap has closed is the team asking for the next build.