Redesign the work, don’t just adopt the technology

Laufey’s Falling Behind captures a familiar and increasingly visible anxiety in financial services: “Everybody’s falling in love and I’m falling behind.”

Competitors are experimenting with AI. Employees are already using it. Vendors are embedding it into existing platforms. Boards, Responsible Managers, advisers and compliance teams are being told that AI will transform everything.

In that environment, doing nothing can start to feel like surrender. But “we need to do something with AI” isn’t a strategy.

ASIC has already seen what happens when fear of falling behind becomes part of the rationale for adoption. In Report 798, Beware the gap: Governance arrangements in the face of AI innovation, ASIC described a licensee using an AI model to assess consumer credit risk despite limited understanding of the third-party platform, incomplete documentation, poor governance and inadequate monitoring. Even after identifying deficiencies, the licensee still planned to expand its use because it feared being left behind by competitors.

The problem isn’t experimentation. It’s confusing activity with progress.

Start with the business problem

A technology strategy shouldn’t begin with the technology.

That sounds obvious, but AI adoption often works backwards. Someone discovers a tool. A pilot begins. The pilot demonstrates an interesting capability. Management then looks for somewhere to use it. Compliance is asked how to control it.

That’s a technological solution looking for a business problem.

Clayton Christensen’s Jobs to Be Done theory offers a better starting point: begin with the job to be done.

For a licensee, that means identifying what actually needs to improve. What should become faster, safer, cheaper, more consistent or more effective? Only then should management ask whether AI has a role.

This matters because a capable AI system may still be a poor fit for an incapable organisation.

There’s little value in sophisticated analysis if client information is fragmented across systems, if nobody knows which data the model relied upon, if outputs can’t be reliably incorporated into the client record, if staff can’t recognise when the system is wrong, or if management can’t monitor how it’s being used.

The AI may be capable, but the organisation may not be.

Don’t automate jobs. Examine the work.

The more useful unit of analysis isn’t the job, but the task.

An adviser’s role contains many different activities: gathering information, summarising meetings, researching products, modelling scenarios, identifying inconsistencies, drafting documents, explaining alternatives, recognising vulnerability, resolving ambiguity and exercising judgement.

AI may materially improve some of those tasks without being able to safely perform the role.

The same is true in compliance. AI can review thousands of documents, identify repeated language, detect anomalies, compare files against criteria and connect information across datasets. Those capabilities can improve monitoring.

But an AI-generated alert, classification or risk score is still evidence, not a conclusion.

Management must decide whether the observation matters, whether further investigation is required and what should happen next.

Technology can expand what people can see, but it doesn’t remove their responsibility for deciding what it means.

That’s why “human in the loop” means very little if the human simply approves whatever the system produces. The person needs the knowledge, authority, information and willingness to exercise genuine judgement.

Be careful what you make faster

There’s another problem with adopting AI before redesigning the process: automation scales weaknesses as efficiently as strengths.

As Eminem warns: be careful what you wish for.

A poor manual process produces errors at human speed. Technology can reproduce them industrially.

An adviser who misunderstands a disclosure requirement may create a handful of problematic files. An automated process based on the same misunderstanding could affect hundreds. A reviewer might overlook a recurring problem, while an AI monitoring system using the wrong criteria could misclassify the same issue across an entire population.

Scale is one of AI’s principal advantages. It’s also one of its principal governance risks.

So, before accelerating a process, establish that the process deserves to be accelerated.

What should an AI strategy look like?

For most licensees, it doesn’t require a 70-page board deck. It simply requires clear answers to a few basic questions:

• What problem are we solving? 
• What work needs to change? 
• What happens when the AI is wrong? 
• Is the organisation capable of supporting the use case? 
• What must remain human? 
• Who owns the outcome? 
• What evidence would justify scaling it? 

Those questions also help distinguish an AI policy from an AI strategy.

A policy tells employees how AI can be used. A strategy explains why the organisation is using it, which activities should change, what it will not automate and what capabilities are needed to support those decisions.

These differences are important because existing obligations don’t disappear when AI is involved. Licensees still need adequate resources, competence, risk-management systems, compliance arrangements, oversight and accountability.

Outsourcing the technology doesn’t outsource the responsibility.

None of this means licensees should avoid experimentation. The sensible approach is to contain it.

Start with use cases where the potential benefit’s meaningful, the consequences of error are limited and outputs can be independently checked. Test them. Learn where they fail. Improve staff capability. Strengthen vendor assessment. Capture evidence. Then decide whether to scale.

Standing still has consequences, but so does mistaking enthusiasm for sustainability. The objective isn’t to make innovation difficult. It’s to make innovation deliberate. Don’t start with AI. Start with the business problem instead.

Sean Graham is managing director of Assured Support.