People Don't Fear AI. They Fear Losing Agency.

An AI product can save someone time while taking away control over their work. An assistant becomes evidence that their job is unnecessary. A search tool supplies an answer they cannot verify. A chatbot makes a promise the company later disputes.

Resistance to these products is not something better messaging can always fix. Users have reasonable questions about who decides, who checks, and who pays for mistakes.

KPMG and the University of Melbourne’s 2025 global study illustrates the gap: 66% of respondents used AI regularly, but only 46% were willing to trust it.[1] Product teams need to account for that distinction before treating adoption as approval.

The fear of job displacement

Pew found that U.S. workers were more worried than hopeful about AI’s future in the workplace.[2] A tool sold to leadership as a way to reduce headcount gives employees good reason to question whose interests it serves.

Klarna announced that its AI assistant did the work of 700 customer-service agents. It later renewed its emphasis on human service and customers’ ability to reach a person.[3]

IKEA offered a different account of the transition. Reuters reported in 2023 that the company had retrained 8,500 call-center workers as interior-design advisers while its assistant, Billie, handled routine queries.[4]

These examples do not settle the employment question. They do show why a product team should specify what happens to people’s work after automation. Which tasks disappear? Which responsibilities expand? What training and authority will people need?

The fear of lost agency

More than half of U.S. adults told Pew they wanted more control over how AI was used in their lives. Only 14% felt they had a great deal or quite a bit of control.[5]

For a user, that becomes three practical questions:

Did I agree to involve AI here?
What did it access, store, or change?
Can I stop it and recover from a mistake?

Microsoft Recall makes the tension clear. Helping people find something they previously saw on their PC is useful. Saving screenshots of their activity raises a different set of concerns. Recall’s controls include opting in, local storage, authentication, and the ability to pause, filter, or delete snapshots.[6]

Those decisions belong in the product design from the start. Ask users where they want assistance, where they want automation, and where they want to retain judgment. Research on workers’ preferences for AI agents provides a useful way to make those distinctions explicit.[7]

The fear of losing purpose

Repetition does not make a task meaningless. Some repeated work is where people exercise judgment, build relationships, or develop a skill. Treating all of it as drudgery can remove the part of a job someone values.

The paper Are We Automating the Joy Out of Work? examines this problem.[8] A product team needs to ask which parts of the work people want to hand over, even when the model could do more.

There is also the work automation adds. Users supply context, verify answers, rerun prompts, and repair outputs. Glean’s Work AI Index calls this “botsitting.”[9] An estimate of time saved that excludes those tasks overstates the gain.

A user who becomes the system’s permanent editor and exception handler may reasonably dislike a feature that looks productive on a dashboard.

The fear of missing accountability

A generative AI error can arrive as a fluent, finished answer. The interface may provide no obvious sign that it needs checking. Showing uncertainty and evidence can help, but a generic “AI can make mistakes” label still leaves the user to do the verification.[10]

When Air Canada’s chatbot gave incorrect advice about bereavement fares, the company argued that the customer should have checked elsewhere. The tribunal held the airline responsible for the information on its website.[11]

If an AI product speaks for a company, the company needs a way to correct its advice and resolve the consequences. Users should not have to work out which component made the mistake before they can get help.

Control, evidence, and recourse

These concerns translate into concrete product requirements:

Control: Users can tell when AI is involved and can limit what it sees, remembers, and changes.
Evidence: A consequential summary or recommendation points to the material supporting it and identifies uncertainty.
Recourse: Users can correct, undo, appeal, or escalate an error, with a clear owner responsible for resolving it.

Adding a toggle for every risk is not enough. Most people live with the defaults. Sensible limits and reversible actions matter more than a settings panel few users will visit.

Measure how people recover

Before building, identify whose work changes, where human judgment must remain, and how someone can intervene once the AI acts.

After launch, track more than usage. Measure reversals, unresolved errors, time to reach a person, appeal resolution, and how completely a wrong action can be undone. Review those results when deciding whether to expand the feature’s authority.

People may use a product because it is the default or because they have no practical alternative. Earned trust requires evidence that the product will protect their ability to decide and recover.

I describe the implementation side of these boundaries in my MCP evaluation case study, including the difference between enforcing a permission and testing whether the model stops after denial.