Before you roll out an AI agent, plan for this. A veteran adjuster will double-check every file it touches. Someone else will go quiet in meetings. Neither will say a word against the tool directly, and if you only prepare for one kind of pushback, the other four will catch you off guard.
One widely cited analysis puts a number on that gap. Seventy percent of what determines success comes down to people, process, and change management, not the technology.
Why insurance staff resist AI comes down to one of five specific causes. You won't stop all five from showing up, but you can walk in with a plan for each one instead of improvising in the moment.
A manager who responds to all five the same way ends up fixing none of them. Here's what each one looks like, and what to plan for before it shows up.
1. Skepticism about accuracy. Expect this from your most experienced staff first, and don't mistake it for resistance. It's professional judgment doing its job. They've seen tools overpromise before, and they'll apply the same standards that make them good at their work. They won't trust the output until they've watched it be right on real files, and no amount of reassurance up front will substitute for that.
Plan to show your work rather than assert perfection. Before launch, decide how you'll surface the error rate and the review process to skeptics directly. Build a plan to let your most experienced staff watch accuracy hold up on their own files early, because once they see it, they tend to become your most credible advocates.
2. Fear of being replaced. Plan for this to hide well. It shows up as quiet disengagement, not open objection, and it's easy to mistake for indifference if you're not looking for it. Almost nobody raises a hand in a team meeting to say they're worried about their job.
Plan to say the quiet part out loud before your staff do. Decide in advance exactly what the AI agent takes over and what stays with the person, and have that answer ready on day one rather than figuring it out reactively. Line up the higher-value work people will move into, concretely, so it's real the moment someone asks. Vague reassurance won't hold up here. Specifics will.
3. Workflow disruption. Expect complaints that sound like general grumbling but are really about one new step in an old process. This person isn't against the tool. Their process worked before, and now there's friction in the middle of it.
Plan to get close early rather than wait for a complaint to escalate. Build in time in the first weeks to sit with a few people, watch the new flow, and catch the small stuff, a handoff that moved, a screen that added two clicks, a notification that stopped firing. These are fast fixes once you see them, but they'll feel enormous to the person living with them daily if nobody's watching for them.
4. Falling behind. Plan on this one staying invisible unless you go looking for it. It's a quiet worry about being the one who doesn't get it, and it's uncomfortable enough that people won't raise it as a real concern on their own.
Plan to say out loud, before launch, that everyone is starting from the same place, including you. Build in explicit permission to ask basic questions at any point, not just in week one. Line up real training tied to how each specific role changes, not a generic tool walkthrough, and treat that training budget as non-negotiable rather than the first budget line you cut when timelines tighten.
5. Distrust from a past rollout. If your team has been through a project that didn't deliver, plan for that history to show up here whether or not it's fair. Staff will assume this rollout goes the same way, and that distrust has nothing to do with this specific tool.
Plan to name the last rollout directly instead of pretending this is a clean slate. Decide ahead of time on one concrete way this project is different, and be ready to point to it early. This group needs proof more than promises, so plan for the proof to come from early results, not from messaging.
Same reaction on the surface can come from any of these five causes, and a single all-hands announcement or blanket communication plan won't address more than one of them at a time. Leadership support is one of the strongest predictors of whether a team's trust in a new tool holds or collapses. Plan for change management, not just deployment, and build the plan around telling these five causes apart before you need to.
Here's the part most rollout plans get backward. It's not the launch communication that determines whether resistance fades. It's what happens the first time someone flags a problem, so build your plan around that moment rather than around the announcement.
If a staff member raises an issue in the first month and someone fixes it, or even just gives them a real answer, they keep engaging. They'll forgive plenty of rough edges while the tool settles in. If that same issue vanishes into a void, they stop raising their hand and quietly go back to the old way, and no amount of communication three months later wins them back. Plan a fast response path before launch, not after the first complaint arrives.
That's true across all five causes above. An accuracy skeptic who reports a bad extraction and gets a real answer starts trusting the review process. A person worried about falling behind who asks a basic question and gets a straight answer stops worrying about looking behind. The cause is different every time. The plan that protects against all five is the same. Build in a fast, visible response path for the first month, before you need it.
Responsiveness beats polish. A leader who barely communicates but always responds when something's wrong will do better than one who nails the launch messaging and then goes quiet.
None of this takes new tooling or a bigger budget. It takes building a plan for five specific reactions before you need one, instead of discovering them one at a time after go-live. Get the plan right, and most of this resistance resolves itself within a few real files and a few honest conversations.