II · The method

mature ~16 min read ch. 6/6 updated: 2026-09-23

Psychology of adoption

One Tuesday, near the end of the workday, a Distribuidora Norte salesperson gets an alert. The system indicates that one of their regular customers is highly likely to stop buying. The recommendation seems simple: call them. The salesperson has known that customer for years and knows they are in the middle of moving premises, so the drop in purchases is no cause for concern. They glance at the screen, mark the alert as resolved and move on to something else.

From the central dashboard, that behavior admits several readings. It may be expert judgment: the person contributed context the model did not have. It may also be rejection, carelessness or a way of keeping the system from recording their performance. If the flow does not let them explain why they dismissed the alert, all those possibilities collapse into the same data point: “recommendation not accepted”. The organization knows less after measuring.

Now imagine another salesperson in front of the same screen. They do not know the customer as well and accept the recommendation only because they assume the computer must have seen something important. They make an unnecessary call and force a sales conversation at a bad moment. On the dashboard, that behavior looks like adoption: the acceptance rate goes up. In the actual work, the system may have just damaged a relationship.

The psychology of adoption stretches between those two scenes. Counting users, sessions or clicks is not enough. One has to understand what it means for a person to receive an instruction from a machine, how much they trust it, what they think will happen if they contradict it and what part of their professional identity they feel is at stake.

Diffusion theories, with Rogers at the forefront, explain why an innovation does not reach innovators, the early majority and more cautious people in the same way, and why initial enthusiasm does not guarantee mass adoption. But an aggregate curve cannot say what the salesperson feels on Tuesday at five in the afternoon, and that concrete experience is what the method needs to get close to.

Using is not trusting

In everyday conversation, adoption and trust are often confused. A tool is said to have been adopted because many people use it. But one can use something with distrust, out of obligation or in secret; one can also trust too much and stop checking what it delivers.

The global study by the University of Melbourne and KPMG published in 2025 makes that gap visible. It gathered responses from more than 48,000 people in 47 countries. 66% said they used artificial intelligence regularly, but only 46% said they were willing to trust it. The opening of those scissors, high use and considerably lower trust, matters more than either percentage on its own.

Other results make the picture more uncomfortable. 58% used it at work, but 57% hid that use; 66% admitted trusting its answers without checking them, and only 47% had received training. Many people distrust the technology in the abstract and, at the same time, accept concrete outputs without verifying them. They use it, but would rather no one found out. The organization sees activity and does not see the mix of anxiety, convenience and risk underneath.

These are international averages, not a prediction for every Argentine small business. They help recognize the shape of the problem: trust is not distributed along a line running from little to a lot. It can be misplaced, with too much trust in tasks that require review and distrust of low-risk aids that could free up time.

The design goal, then, is calibrated trust: that the person knows when they can rely on the recommendation, when they should doubt it and what to do if they find an error. That requires showing limits in an understandable way. A generic warning at the bottom of the screen (“AI can make mistakes”) transfers all the responsibility to the user without helping them decide. It is more useful to explain what information the system considered, how uncertain the case is and which signals justify human review.

Calibration also depends on how the organization reacts to disagreement. If whoever contradicts the model has to fill in a long form, or fears being recorded as the person who held up automation, human control exists only in the diagram. For it to be real, it has to be accessible and socially legitimate.

The reflex to obey

Automation bias appears when a recommendation gains authority simply because it comes from the system. Under time pressure, people stop checking even what they know well. It is not necessarily naivety. It can be a rational response to how responsibility was distributed: if accepting the recommendation never requires an explanation and rejecting it demands justification, the flow has already decided which behavior is easier.

The bias becomes especially dangerous in high-impact tasks. A civil servant who receives a risk classification, a health professional who sees a priority flag or someone assessing credit may formally keep the final decision and still become the human signature on an automated conclusion. Having a person in the loop does not guarantee human judgment.

One possible response is to set aside moments of mandatory human judgment. The system can stay silent until the person forms a first impression, ask them to record an observation of their own or show alternatives instead of a single answer. The point is not to add friction on principle, but to keep the interface from supplanting reasoning at the points where mistakes are costly.

Incentives also need reviewing. If the organization rewards speed and penalizes every deviation, no talk about critical thinking will get people to spend time examining a recommendation. Psychology is not locked inside the individual: it responds to rules, metrics and power relations.

How much control is enough

Faced with fear of automation, a common response is to offer many options: settings, explanations, buttons to review every step. The intention is to give back control. The result can be exhausting. If people constantly have to decide how much autonomy to grant, the tool hands them one more administrative task.

That is the control paradox. Too little control produces alienation: the system acts and the user merely watches. Too much produces burden and anxiety. The right measure depends on the role, the frequency and the risk. No one needs to manually confirm every spelling correction; no one should lose the ability to review a decision that affects a right.

That is why intervention mechanisms are not designed as a universal switch. They are placed where human experience adds context, where the model shows uncertainty or where a consequence would be hard to reverse. In routine, low-risk tasks, a clear undo option may be enough. In others, the system will have to stop and escalate the case.

Reversibility changes the psychological experience. It is easier to explore a tool when one knows the result can be corrected, an earlier version recovered and an exception explained. When every action feels final, caution grows and use becomes mechanical or is avoided altogether.

What the tool says about who I am

Work is not only a sequence of tasks: it also organizes an identity. People recognize themselves as good salespeople, careful analysts, mechanics who hear a noise before the fault appears or administrative staff who know how to resolve the exception no manual covers. When a tool enters that territory, the question is no longer only “does it help me?”. It is also “what does it say about the value of what I know?”.

Identity threat appears when AI is presented as a superior judge or when the organization announces that it has come to eliminate human error. Whoever hears that message may conclude that their experience, including the ability to spot difficult cases, has become a defect to be replaced. The resistance that follows is not explained by a lack of technological understanding. It is explained by the fact that accepting the tool seems to require accepting an impoverished version of oneself.

The project’s language matters. Saying that a model “decides which customers are at risk” is not the same as saying it “identifies signals so the team can prioritize conversations”. The second phrasing should not be a cosmetic device: it has to match a design in which the salesperson’s knowledge can change the action and flow back into the system as learning.

What gets celebrated also matters. If the final presentation shows only accuracy and hours saved, it makes invisible the judgment that made it possible to correct errors or recognize exceptions. A respectful adoption records the human contribution: it lets the person say “this does not apply, for this reason” and lets that reason improve institutional memory.

Not every threat is imaginary. Sometimes automation does cut jobs, fragment a craft or intensify control. Asking for trust in those cases without discussing the consequences is manipulation. The method does not use psychology to persuade people to accept any change. It uses it to understand what the change does and to design, where possible, a fairer distribution of benefits, responsibilities and learning.

Learning when AI does the hard part

There is a loss less visible than the elimination of a job. It happens when technology performs the tasks through which a person used to learn the craft. The work still exists and productivity even improves, but the organization stops training the people who could become experts.

Matt Beane studied this phenomenon in settings such as operating rooms and warehouses, and developed it in The Skill Code (2024). His analysis identifies three conditions for deep learning. The first is challenge: facing tasks slightly beyond one’s current ability. The second is complexity: seeing how the task relates to the whole problem. The third is connection with an expert who observes, corrects and passes on judgment in context.

All three can weaken at once. If an intelligent system takes over the entry-level tasks, the novice loses the place where they practiced. If they receive a finished result, they see less of the problem. And if they no longer need to work close to the expert, a relationship that conveyed much more than formal instructions is cut.

What this book calls the erosion of the scaffold is that decay of the path by which an organization builds its own future expertise. The metaphor works because a scaffold is temporary and, at the same time, indispensable. Entry-level tasks may look inefficient if one looks at the immediate result; if one looks at learning, they are what supports growth.

The tension is not resolved by rejecting automation. It forces a decision about which experiences should be preserved even though a machine could produce the result faster. Perhaps the novice first formulates their own diagnosis and then compares it with the model’s. Perhaps they work on complex cases alongside an expert instead of receiving only pre-sorted exceptions. Perhaps what gets measured is the ability to explain a decision, and not only the number of tasks completed.

The discussion reaches experts too. If their entire workday is reduced to correcting the rare cases the AI could not resolve, the work can become more intense and less satisfying. Automation removes the routine but concentrates the difficulty. The promise of freeing up time has to be weighed against the real experience of receiving, one after another, the most ambiguous and conflictive situations.

The anxiety of working in a gray zone

Generative AI brought a particular kind of technostress. It does not always come from a complex interface. It comes from not knowing whether using it is allowed, what information can be shared, who answers for an error or whether leaning on it too much will end up weakening one’s own ability.

In 2025 Högemann and colleagues studied young professionals, a group usually assumed to be naturally comfortable with these tools. They found stressors tied to ambiguity: fear of exposing data, doubts about intellectual property and a perceived dependence expressed in an intimate question, “do I still know how to do this without the AI?”. Neither age nor digital skill removes that uncertainty.

The gray zone gets worse when official discourse and practice contradict each other. The organization celebrates innovation but publishes no rules; it hands out licenses to some people and leaves the rest with personal accounts; it demands productivity without acknowledging the tools that make it possible. In that context, hiding use is a logical adaptation.

A clear policy reduces part of that stress, provided it can actually be applied. It has to say which uses are allowed, with what kinds of data, what review is expected and where to ask for help. It also has to admit that the criteria will change. A rule that tries to anticipate every tool is outdated in months; one based on risk, data sensitivity and consequences keeps pace with change better.

The conversation about dependence should not be settled with a motivational phrase. Some people will indeed delegate too much and will need to regain practice. Others will discover capabilities they could not exercise before. The organization has to watch both movements and create spaces where it is possible to work without assistance, compare results and talk about mistakes without shame.

When the shape of the team changes

Adoption does not happen only inside each person. A tool can change who talks to whom, which specialties need to work together and how recognition is shared.

The field experiment by Dell’Acqua and colleagues, published in 2025, worked with 776 professionals at Procter & Gamble. In the tasks studied, individuals assisted by AI reached performance comparable to that of teams without AI. The result stands out because it suggests that one person can access capabilities that used to require collaboration.

The second finding is even more interesting for a sociotechnical reading. Without assistance, people from research and development tended to propose technical solutions, and those from the commercial side, commercial ones. With AI, both profiles produced more balanced answers. The tool seemed to lend each of them part of the other side’s vocabulary.

That can break down silos and let more people take part in whole problems. It can also lead to a hasty conclusion: if an assisted individual performs like a team, the team is redundant. The experiment does not show that. Working relationships serve functions that are not exhausted by the output of a task: they pass on tacit knowledge, provide emotional support, challenge assumptions and form judgment. The connection Beane considers necessary for learning could be lost if the organization replaces collaboration with private conversations with a model.

There is another nuance. Participants reported more positive emotional responses when working with the conversational interface. AI can cover part of a colleague’s social role: it keeps company, answers without judging and offers immediate first feedback. That can help someone who is afraid to ask. But a colleague who always answers and never takes responsibility does not replace a professional community.

These results come from a large company, with resources and well-bounded tasks. They do not promise that a small business will get the same numbers. What they offer is a design question: what new collaboration does the tool enable, and what valuable bond could it erode if the organization mistakes assistance for self-sufficient isolation?

Change arrives by thresholds

The ADKAR model, developed by Prosci, organizes individual adoption into five thresholds: awareness of why something is changing, desire to take part, knowledge of how to do it, the real ability to do it during the workday, and enough reinforcement to sustain it. The sequence does not perfectly describe every experience, but it helps stop talking about “resistance” as if it were a single thing.

A person may understand the need and not want to take part because they anticipate a loss of autonomy. They may want to and not have been trained. They may finish the course and lack the time, permission or access during actual work. They may use the tool well for two months and go back to the spreadsheet because no one reviewed the new flow. Each blockage calls for a different response.

The distinction avoids a common mistake: answering everything with training. Teaching buttons does not create desire, does not change incentives and does not resolve an ambiguous policy. Sometimes the right intervention is a conversation about roles; other times, redesigning a screen, changing a metric or recognizing that the tool does not yet deserve to be adopted.

Teams also get tired. When a transformation is announced every quarter and none of them settles in, people learn to wait: they keep the old process because they assume the novelty will pass. That change fatigue is not fixed with a more enthusiastic campaign. It is fixed by closing fronts, retiring the tools left half-done and letting one habit settle before opening the next.

Designing permission to disagree

Human-centered AI, as Ben Shneiderman formulates it, challenges a common opposition: high automation and human control need not exclude each other. A system can do a great deal and, at the same time, preserve meaningful forms of intervention. The key lies in designing them according to the risk and the experience of whoever will use them.

In agentic systems, human judgment shifts. If the agent executes thousands of actions, reviewing each transaction by hand is no longer possible, and part of the judgment has to be built in earlier: in limits, permissions, tests and escalation conditions. Even so, someone needs to be able to stop, audit and revoke. A control hidden behind twelve steps satisfies a documentary requirement and fails as an experience.

The bridge asks where AI should stay silent, where it should explain and where it should ask for help. It also asks whether the person has real permission to say no. That permission does not live only in the interface. It lives in the team’s culture, in the way incidents are investigated and in what happens to whoever detects an uncomfortable error.

Psychology comes in from link 1. Interviews reveal scars from earlier pilots, fears about the craft and reasons for withholding information. During construction, those observations turn into language, confirmations, correction mechanisms and ways of showing uncertainty. During sociotechnical hygiene, workarounds and excessive obedience reveal that trust has become miscalibrated even when usage metrics look healthy.

An organization does not adopt when it gets its people to stop complaining. It adopts when the tool enters the work without demanding blind obedience, when people understand what they can delegate and what they must keep, and when the system lets itself be corrected by the experience it means to help. That relationship takes time because it is not only about learning a technology: it is about renegotiating who knows, who decides and who answers for it.