Here's a scenario that plays out at asset managers and fund administrators more often than anyone likes to admit. Operations wants to roll out a compliance monitoring tool. It watches regulatory feeds, flags anything relevant, maybe even drafts a first response. The business case is obvious: less manual monitoring, faster reaction times, fewer things falling through the cracks.

And the compliance team, the people this tool is meant to help most, are the ones dragging their feet.

It's tempting to read that as resistance to change, the usual "we've always done it this way" friction that shows up whenever you introduce new technology. But that's the wrong diagnosis, and it leads to the wrong fix. Compliance teams aren't being stubborn. They're being rational.

Why this isn't a normal adoption problem

Under the Senior Managers and Certification Regime, individual accountability doesn't disappear just because a machine made the call. If a compliance monitoring system misreads a regulatory change, or fails to flag something it should have caught, the senior manager responsible for that area is still the one answering for it. Not the vendor. Not the developer. Them.

So when a CCO hesitates before signing off on a new AI tool, they're not failing to grasp the benefits. They've correctly worked out that they're being asked to accept personal risk for a system they had no hand in building and can't fully see inside. That's not resistance to overcome with a better slide deck. It's a legitimate concern that needs a legitimate answer.

Most change management playbooks assume the problem is comfort. Run some training sessions, get a few respected team members using it early, let confidence build. That approach works fine for a new CRM or a scheduling tool. It falls apart for anything compliance facing, because the barrier was never a skills gap. It was accountability.

This matters more broadly too. RAND's 2024 research into enterprise AI found that roughly 80% of AI projects fail, about twice the failure rate of ordinary IT projects, and pinned much of that on skipped groundwork: unclear ownership, thin evaluation, nobody quite sure who was accountable for what the system did. Compliance teams tend to spot exactly that kind of gap before anyone else in the building does. If anything, their caution is a useful early warning system, not an obstacle.

What actually earns trust here

If comfort isn't the lever, what is? In practice, four things make the difference between a compliance team that engages with a new system and one that quietly works around it.

Explainability beats accuracy claims. Telling a CCO a system is "99% accurate" tells them almost nothing useful. What they need is the reasoning behind a flagged item: what it saw, what rule or pattern triggered the flag, and why it concluded this was worth their attention. A system that shows its working gets trusted faster than one that just produces a verdict, even a very good verdict.

Authority should be earned in stages, not granted on day one. Start in shadow mode, where the system runs alongside existing processes and its output gets compared against what a human would have done, with no live consequences either way. Move to assisted mode, where it flags and drafts but a person makes every call. Only once a track record exists does supervised autonomy become a reasonable next step. Jumping straight to "let it act" is exactly the kind of thing that turns a cautious compliance officer into an immovable one.

The audit trail isn't a nice to have, it's the whole point. For a regulated function, being able to show exactly what a system saw, concluded and did, at any point in the past, isn't optional. If a tool can't produce that cleanly, it isn't ready for compliance work, no matter how well it performs on paper.

There needs to be a real escalation path, not a theoretical one. "Human in the loop" is a phrase that gets used a lot and means very little on its own. What matters is a defined route to an actual person, one that gets used in practice and reviewed periodically so the firm can see how often it's triggered and whether the outcomes were right. A checkbox on a slide isn't a control.

Building the rollout around the right person

Zuko's build engagements follow a discovery, build, embed pattern, and for a compliance deployment each stage needs to bend around this specific problem. Discovery should map, in detail, which decisions the system will be trusted to make on its own and which ones it should never touch, agreed with compliance up front rather than presented to them afterwards. Embed should train compliance staff not just to use the tool, but to audit it: how to pull the reasoning behind a decision, how to check the escalation log, how to challenge an output they disagree with.

None of this is about winning compliance over. It's about designing a system that a specific, named, personally accountable individual can look at and reasonably decide they're willing to stand behind. That's a much higher bar than "the team seems comfortable with it," and it's the one that actually matters.

If you're weighing up a compliance or risk automation project and want an honest read on whether it's ready to build, and what a phased, accountable rollout should look like for your specific setup, that's exactly what an AI audit is for. It's a structured look at feasibility and risk before anyone commits to a build, not a sales pitch dressed up as one.

Sources: RAND Corporation, "Why AI Projects Fail and How They Can Succeed"