You can train people to use AI. You cannot expect them to trust it if you will not tell them what you intend to do with it.
The licenses are bought, the training is under way, and the AI champions have been appointed. In the boardroom, the rollout looks healthy. In the sales team, usage barely moves. So the company schedules more demos, refreshes the internal communications, and repeats the reassurance: AI is here to help people, not replace them.
But people are not just evaluating the software. They are trying to work out what its arrival means for them. Will their expertise still matter? Will they be held accountable for mistakes they did not make? Will the productivity gains make their jobs better, or make some of their jobs unnecessary? Until those questions are addressed, another training session is unlikely to change much.
01Stop calling it resistance to change
“Resistance to change” is a convenient diagnosis. A rep avoids the new assistant? Resistance. A manager challenges an automated recommendation? More resistance. The label puts the problem with the employees and saves the organization from examining what it is asking them to accept.
Consider a sales rep shown an agent that can prepare account briefings, draft emails, analyze the pipeline, and recommend next steps. They may recognize its value immediately and still wonder what happens to their role when that agent starts dealing with customers directly. That is not technophobia. It is a reasonable question about their professional future.
Before trying to win them over, identify the actual concern. Unreliable software needs fixing. A skills gap needs training. Uncertainty about the future of a role needs an answer from leadership. Putting all three into the same change-management program is not a comprehensive response. It is a failure to distinguish the problems.
02The decisions a technical project cannot make
AI projects bring together engineers, data specialists, business owners, lawyers, and security teams. They should. But getting the system to work does not settle every question raised by handing part of our analysis and decision-making to it.
If a manager routinely approves the model’s recommendations, are they still exercising judgment? If an employee is expected to check an answer without the time or information to verify it, what does that oversight actually achieve? And if a team no longer handles the situations through which people learn their craft, how will it develop the expertise needed to challenge the system later? These are questions about responsibility, autonomy, and knowledge. They may sound philosophical. Their consequences are operational.
That is where a philosopher could earn a place on a transformation team. Not to deliver a lecture on Kant, and not to overrule the people who understand the business. The contribution is to surface choices that a technical delivery plan tends to leave unresolved — choices the organization will eventually have to own.
03Ethics is not the obstacle. Ambiguity is.
Ethics often enters the project late, as one more sign-off alongside security and compliance. By then, the important design decisions have been made. The exercise becomes a search for reassurance that the rollout can proceed.
Addressed earlier, it forces useful clarity: which data the system may use, which actions it may take independently, which require human approval, and who is accountable when it gets something wrong. For a sales agent, drafting an email is not the same as sending it. Recommending a discount is not the same as authorizing one. People need to know those boundaries before an incident reveals them.
Clear rules do not guarantee trust. They give people a basis for it. Employees can understand when to rely on the system, when to challenge it, and when to intervene. Without that clarity, they have to infer the company’s intentions. There is little reason to assume they will reach the most reassuring conclusion.
04Nobody believes that nothing will change
AI will eliminate some tasks and reshape some roles. It may reduce demand for certain skills, increase the value of others, and allow some work to be done with fewer people. Telling everyone they will simply be “augmented” does not address that reality. Employees can see what the tools are capable of.
Leadership does not need to pretend it knows exactly what the organization will look like in three years. It does need to explain what is known, what remains undecided, and how those decisions will be made. If cost reduction is the objective, say so. Presenting it as a project to make employees’ lives easier only creates a credibility problem when the consequences become visible.
The point is not to preserve every existing task. Few people will mourn a report nobody reads. The harder question is what the organization wants to retain: professional judgment, customer relationships, opportunities to learn, and the ability to challenge a decision. Those are leadership choices. No AI vendor can make them for you.
05Before you automate, ask what the work is for
Too often, the tool’s capability sets the agenda. An agent can write meeting summaries, so meeting summaries get automated. It can populate the CRM, so data entry becomes the next use case. Whether the work is necessary comes second to whether the technology can do it.
Start at the other end. Who reads the summary? What decision does it support? If nobody can answer, producing it in thirty seconds rather than thirty minutes does not make it useful. Remove work that no longer serves a purpose, simplify what remains, and only then decide where AI belongs.
Apply the same test to human oversight. A manual approval matters only if the person has the information, time, and authority to exercise real control. Otherwise, the organization has retained a signature, not a safeguard. “Human in the loop” can become a comforting phrase for a responsibility nobody is equipped to discharge.
06Make the human role a deliberate choice
A philosopher on a transformation team may be an unfamiliar idea. It is not a substitute for technical expertise or knowledge of the business. But it can help challenge assumptions that otherwise pass without discussion: that every task we can automate should be automated, that a faster recommendation produces a better decision, or that keeping a human involved automatically settles accountability.
“The question is not just what AI can do. It is what the business chooses to delegate — and what it keeps under human responsibility.”
This is the work I want to help organizations do: examine how work actually gets done, challenge the processes, remove or simplify what no longer earns its place, and define clear roles for AI and people. Assign responsibility explicitly, then measure whether the changes improve how the business operates.
The technology matters. But when a team cannot see where the company is taking it, asking people to adopt the tool is asking them to endorse a plan whose implications remain unclear. Making those choices explicit before deployment is not an abstract precaution. It is part of getting the project to work.