Financial services needs to redesign the work, not simply adopt the technology
“Everybody’s falling in love and I’m falling behind.”
In Falling Behind, Laufey captures a familiar anxiety: everyone else seems to be moving forward while you’re standing still. That sentiment seems widespread in financial services, and a client recently admitted that:
“Technology in this space is moving quickly, and I want to make sure we are keeping pace and not being left behind.”
This is an entirely reasonable concern. Your competitors are experimenting with AI. Your employees are already using it. Vendors are embedding it into existing platforms. Boards, Responsible Managers, advisers, and compliance teams accept that AI will change how financial services businesses operate. Every conference agenda seems to contain someone explaining why AI will transform everything.
In this environment, doing nothing can start to feel less like a deliberate choice and more like surrender, failure and obsolescence. It’s understandable to respond by declaring that we need to do something with AI, the problem is that this isn’t a strategy.
In highly regulated industries like financial services, anxiety about falling behind is a particularly poor foundation for deciding where, why and how AI should be deployed. ASIC has already seen what that looks like. In Report 798, Beware the gap: Governance arrangements in the face of AI innovation, ASIC described a licensee that deployed an AI model used in assessing consumer credit risk despite limited understanding of the third-party platform, incomplete model documentation, poor governance and inadequate monitoring. The licensee later identified many of those deficiencies itself, yet still planned to expand its use of AI because it feared it would otherwise be “left behind” by competitors.
That makes the issue more complicated than a simple choice between adopting AI and resisting it. The competitive risk of ignoring AI may be real. So is the regulatory and governance risk of adopting it simply because everyone else appears to be doing so. The challenge for licensees isn’t to keep pace with every technological development. It’s to work out which developments matter to their business, where AI can genuinely improve the work, and whether the organisation can use it safely and effectively.
That requires strategy.
We’ve seen this movie before
Technology enthusiasm tends to follow a familiar pattern.
A useful explanation appears in Kurt Shuler’s discussion of the Gartner Hype Cycle and Geoffrey Moore’s Technology Adoption Lifecycle. They describe different phenomena. The Hype Cycle focuses on changing expectations around emerging technologies. The adoption lifecycle focuses on how different groups actually adopt them.
The Hype Cycle moves conceptually from a technology trigger through inflated expectations and disillusionment before experience produces a more realistic understanding and productive application. The Technology Adoption Lifecycle describes the movement from innovators and early adopters towards mainstream users seeking dependable improvements rather than experimentation.
It would be wrong to use Shuler’s 2012 article to declare that generative AI currently occupies some particular point on Gartner’s curve. The broader lesson is still useful: excitement about a technology and productive adoption of that technology are not the same thing.
That’s particularly relevant to AI. The public conversation can move very quickly from AI can do extraordinary things, to our competitors are using AI, to we need AI, and finally to what can we use AI for? By that point the sequence is backwards. A technology strategy shouldn’t begin with the technology.
Start with your organisational reality
A January 2026 Harvard Business Review article, Match Your AI Strategy to Your Organization’s Reality, makes that point. Cyril Bouquet, Christopher Wright and Julian Nolan argue that organisations need to match their AI ambitions to their operating reality, what parts of the value chain they control, and what technologies they can integrate effectively. They identify approaches ranging from focused applications to more integrated or platform-based strategies.
Their opening example is instructive. General Motors used generative design to create a seat bracket that was substantially lighter and stronger than its conventional equivalent. The technology worked, but the surrounding organisation couldn’t economically manufacture what it had designed because GM’s production system had been built for something else. The innovation didn’t stall because the AI had failed, but because the organisation wasn’t configured to realise the benefit.
Licensees might encounter the same problem. There’s little value in an AI system capable of sophisticated analysis if relevant client information is fragmented across incompatible systems, if nobody can establish which data the model relied upon, if outputs can’t reliably be incorporated into the client record, if employees can’t recognise when the output is wrong, or management can’t monitor how the system is actually being used. Similar problems arise if third-party providers can’t explain how information is handled or nobody is clearly accountable for the consequences.
The AI may be capable, but the organisation may not be.
An AI policy isn’t an AI strategy
A lot of licensees have approached AI primarily as a compliance problem. That’s understandable and even commendable. A sensible AI policy might identify approved tools, prohibit certain uses, establish privacy requirements, prescribe human review, address record-keeping and set limits around client-facing outputs. Those controls are important, but they’re not an AI strategy.
A useful governance distinction is that policy defines the boundaries of permitted use, while strategy determines which uses deserve organisational investment. A licensee can therefore have a comprehensive AI policy and still lack a coherent basis for deciding what to automate, augment or leave unchanged.
A policy tells employees how AI can be used. A strategy explains why the organisation is using AI, what problems it’s trying to solve, which activities should change, what it won’t automate and what organisational capabilities are needed to support those decisions.
Without that strategic layer, adoption tends to work backwards. Someone discovers a tool. A pilot begins. The pilot demonstrates an interesting capability. Management looks for somewhere to use it. Compliance is then asked how to control it.
That’s a technological solution looking for a business problem.
The better approach, as Clay Christensen argued, starts with the job to be done.
An edited version of this article was published by Professional Planner and titled “Redesign the work, don’t just adopt the technology“.
Don’t automate jobs. Examine the work.
That fundamental principle is reinforced by another Harvard Business Review article AI Transformation Requires Redesigning Work, Not Cutting Roles. In that article, authors Faisal Hoque, Tom Davenport and Paul Scade argue that organisations are moving faster on AI-related workforce decisions than the evidence presently supports. Their central proposition is that businesses should start by breaking roles into their component tasks and determining
- where AI genuinely improves performance,
- where humans remain necessary and
- how workflows should be redesigned around the combination.
That approach is especially relevant for advice licensees because most professional roles are bundles of very different activities. Consider a financial adviser. The adviser is expected to collect information, summarise meetings, analyse strategies, research products, model scenarios, identify inconsistencies, draft documents, explain alternatives, recognise vulnerability, resolve ambiguity, exercise judgement and manage competing client objectives. It’s inarguable that AI could materially improve some of those tasks without being capable of safely performing the role.
The same applies to compliance. AI might review thousands of documents, identify repeated language, detect anomalies, compare files against defined criteria and connect information across different datasets. Those capabilities could materially improve monitoring. But, as we have previously argued in AI Can Improve Monitoring. It Can’t Perform Governance, an AI-generated alert, classification or risk score is still evidence rather than a conclusion. Management must decide whether the observation is meaningful, whether further investigation is required and what should happen next.
Technology can expand what people can see. It doesn’t remove their responsibility for deciding what it means.
The unit of analysis should be the task, not the person
This gives licensees a much better starting point for AI adoption. Instead of asking which jobs can AI replace?, ask which tasks should AI perform, assist, monitor or leave alone?
For each material task, record four things: the consequence if the AI is wrong, whether its output can be independently verified, the judgement the human reviewer must exercise and who remains accountable for the outcome. That turns task analysis into a governance control rather than a workforce-planning exercise
Some tasks may be suitable for automation because they’re repetitive, relatively predictable and readily checked. Others are better suited to augmentation, where AI improves human performance without replacing the decision-maker. Research summaries, file-review support, identifying inconsistencies, preparing meeting notes and detecting patterns may sit in this category.
Other activities depend heavily on context, professional judgement, ethical reasoning, interpersonal understanding or the reconciliation of competing objectives. AI can inform those activities without being the decision-maker. Even where considerable automation is technically possible, someone still needs to own the process, challenge the evidence and remain accountable for the outcome.
But, let’s be honest with ourselves. “Human in the loop” means very little if the human merely approves whatever the system produces. The person needs the knowledge, authority, information and willingness required to exercise genuine judgement.
AI should redesign processes before it reduces people
There’s an important practical consequence to starting down this road. If management simply introduces AI into an existing workflow and removes people, it may remove the very expertise needed to supervise the technology. The more sophisticated the automation becomes, the more important it may be to retain people who can identify when it has failed.
The Redesigning Work article notes that some early workforce reductions attributed to AI have failed to produce their expected benefits and have exposed organisational knowledge gaps and new requirements for human oversight. That’s why the authors advocate gradual workforce change while businesses learn what the technology actually does well.
For licensees and practices, the better sequence is generally: understand the work → redesign the workflow → introduce AI → test the result → change resourcing where justified. It’s not, and shouldn’t be, buy AI → remove people → discover what work they were actually doing.
That’s as much a governance issue as an operational one.
Not every licensee needs to become an AI company
Another useful implication of the January HBR framework is that organisations don’t all need the same AI strategy. A large bank with significant proprietary data, engineering capability, integrated systems and substantial scale can reasonably contemplate things that would be absurd for a 20-adviser AFSL. That’s not a competitive weakness for the smaller business. It is simply a different operating reality.
For many small and mid-sized AFSLs and Australian Credit Licensees, the biggest opportunities will likely come from focused applications of AI to activities they already understand. A financial advice licensee might use AI to assist with meeting records, knowledge retrieval, preliminary file analysis, compliance monitoring, research synthesis or administrative workflows. A credit licensee might use it to identify inconsistent application information, recurring broker-review deficiencies, lending concentrations, complaint patterns, hardship themes or unusual conduct.
These applications don’t require the business to become an artificial intelligence company. They require it to understand its existing work well enough to know where AI can improve it.
Be careful what you make faster
There’s another problem with adopting AI without redesigning the process first. Automation scales weaknesses just as effectively as strengths. As Eminem warns us “So be careful what you wish for, cause you just might get it”
A poor manual process normally produces errors at human speed. Technology can reproduce them industrially. An adviser who misunderstands a disclosure requirement might create a handful of problematic files, but 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 might misclassify the same problem across an entire population. A poor marketing process might occasionally produce an inappropriate claim. Generative AI can produce variations of it continuously.
Scale is one of AI’s principal advantages, and one of its principal governance risks.
This connects directly with The Compliance Measurement Trap. More data, more alerts and greater analytical capacity don’t necessarily improve oversight. AI can simply allow a business to measure the wrong things more efficiently. It may be obvious, but given that obvious strategies are often overlooked, before you accelerate a process, you must first establish that the process deserves to be accelerated.
Obligations don’t disappear because AI is involved
There’s no special exemption from compliance requirements or conventional governance because a process is automated.
Section 912A of the Corporations Act 2001 imposes general obligations on AFS licensees, including obligations to maintain competence and, subject to statutory qualifications, have adequate resources and adequate risk-management systems. Credit licensees similarly have obligations under s 47 of the National Consumer Credit Protection Act 2009, including adequate compliance arrangements and, subject to the statutory qualifications, adequate financial, technological and human resources and adequate risk-management systems. Those arrangements are assessed having regard to the nature, scale and complexity of the credit activities.
AI sits within those systems. Outsourcing the technology doesn’t remove the licensee’s obligations or turn the consequences of its use into somebody else’s governance problem.
As we argued in Innovation’s All About Governance, technological innovation increasingly makes accountability, oversight, explainability, vendor management and effective challenge more important rather than less important.
So what does an AI strategy actually look like?
You probably have an AI strategy problem if different teams are already using AI, nobody has a reliable inventory of those uses, pilots are being approved tool-by-tool, or management can explain what the technology does but not what business outcome it’s meant to improve.
An effective AI strategy doesn’t necessarily require a 70-page VC-ready deck. For most licensees, the best starting point is asking themselves seven questions.
1. What problem are we solving?
Identify the business outcome first. What needs to become faster, safer, cheaper, more consistent or more effective? If the answer is “we’re falling behind”, stop.
2. What work needs to change?
Break the relevant process into tasks. Determine what should be automated, what should be augmented and what still requires human judgement. Don’t assume the existing workflow should survive unchanged.
3. What happens when the AI is wrong?
Risk should determine control intensity. An inaccurate internal meeting summary isn’t equivalent to an error affecting financial advice, a lending decision, complaint resolution or the treatment of a vulnerable consumer.
4. Is the organisation capable of supporting the use case?
Consider data quality, systems integration, employee capability, vendor dependency, privacy, records, monitoring and escalation. A technically impressive use case may simply be ahead of your current capability.
5. What must remain human?
Identify decisions involving significant judgement, context, empathy, ethical considerations or regulatory accountability. Do this deliberately rather than discovering the answer after implementation.
6. Who owns the outcome?
Every material use case should have an accountable business owner. Someone needs to understand what the technology is intended to do, monitor whether it does it and have authority to intervene.
7. What evidence would justify scaling it?
Define the expected benefit and then measure it. Has processing time actually fallen? Has quality improved? Are errors increasing or decreasing? Has employee capacity been released? Are clients receiving better outcomes? What new exceptions have appeared? If the evidence does not support expansion, don’t expand it merely because the technology remains fashionable.
Define failure criteria as well as success criteria. A pilot should identify in advance which error rates, control failures, unexpected behaviours or client impacts would cause the use case to be modified, suspended or abandoned.
Experimentation and governance aren’t opposites
None of this requires you to wait until AI is mature, perfectly understood or risk-free. That would create its own strategic problem.
The Hype Cycle and technology-adoption frameworks help explain why. Businesses that experiment early learn things that can’t be obtained from watching others, but early adopters also operate when expectations are less reliable and implementation knowledge is less mature. The sensible response isn’t to avoid experimentation but to contain it.
Start with use cases where the potential benefit is meaningful, the consequences of error are understood and limited, and outputs can be independently checked. Internal research, knowledge retrieval, drafting assistance, meeting preparation, administrative workflow, preliminary monitoring and pattern identification are obvious examples. Test them. Learn how employees actually use them. Understand where they fail. Develop AI literacy. Improve vendor assessment. Establish monitoring. Capture evidence. Then consider higher-consequence applications.
This isn’t moving slowly. It is learning quickly without exposing the entire business to the consequences of experimenting.
From informal use to controlled use
Don’t be naïve. There’s also little point pretending employees will wait for the corporate AI strategy. AI is already entering financial services businesses through browsers, software integrations, meeting tools, search products, CRMs and other applications.
The immediate governance task isn’t simply deciding whether the business will “adopt AI”. In reality, that question has probably already been answered for you. The more useful questions are what is being used, by whom, for what purpose, with what information, what outputs are being relied upon, where those outputs are recorded, who reviews them and what happens when they are wrong.
That’s why From Risk Registers to Real Controls argued for moving from informal to controlled AI use, including registers, approved and prohibited uses, data restrictions, vendor due diligence, human-review requirements, monitoring and escalation.
The strategy sits above those controls. It decides where the organisation wants to go. Governance is what makes that direction sustainable.
Competitive risk cuts both ways
Licensees may be right to worry about missing the opportunity AI presents. Businesses that use it intelligently may become faster, more consistent and better informed. They may identify risk earlier, reduce administration, and allow advisers, compliance professionals, and managers to spend more time on activities requiring expertise, judgement, and human interaction.
Standing still has consequences. But confusing activity with progress has consequences too.
ASIC’s concern in Report 798 was not that licensees were experimenting with AI. ASIC expressly recognised its potential to improve efficiency, accessibility and tailoring in financial services and credit. Its concern was that AI adoption could accelerate faster than the governance supporting it.
The objective should not be to make innovation difficult. It should be to make innovation deliberate. Match your AI ambition to organisational capability. Redesign work around what humans and technology each do well. Don’t confuse enthusiasm with evidence.
For financial services businesses, that produces a relatively straightforward proposition. Don’t start with AI, start with the business problem.
Understand the work. Decide what should change. Identify what must remain human. Build the controls. Experiment. Measure the result. Then scale what works.
AI magnifies outputs. It can make a well-designed business faster, more informed, and more scalable, but it can do the same to a poorly designed one.
The ultimate outcome will depend on your strategy.
If your AI controls exist on paper but you cannot readily show who reviewed an issue, what was decided and whether the resulting action was completed, use [complye] to turn AI governance actions into assigned, trackable and reviewable compliance evidence.
Further reading
Frequently Asked Questions
An AI strategy should connect specific business problems to specific changes in work, rather than starting with a list of AI products the business wants to deploy.
For each material use case, the licensee should be able to explain the outcome sought, the tasks being changed, the information the system requires, the consequences if it is wrong, the role of human judgement and who owns the resulting outcome. It should also establish what evidence would justify continuing, modifying or scaling the use case.
That distinction matters because an AI policy and an AI strategy perform different jobs. A policy can define approved tools, data restrictions, human-review requirements and prohibited activities. It does not establish whether a use case improves the business or deserves to exist.
Practically, management should be able to describe every material AI initiative without first describing the technology. If the business problem, intended outcome and success measure cannot be stated clearly, the use case probably requires further design before deployment.
Yes. Using AI does not displace the existing obligations applying to AFS and credit licensees.
For AFS licensees, s 912A of the Corporations Act includes obligations concerning competence and, subject to statutory qualifications, adequate resources and risk-management systems. Credit licensees have corresponding obligations under s 47 of the National Consumer Credit Protection Act, including adequate compliance arrangements and systems and, subject to the statutory provisions, adequate financial, technological and human resources and risk-management systems.
ASIC’s REP 798 makes the practical relevance clear. Its review of 23 AFS and credit licensees identified the risk of AI adoption moving faster than the governance and risk-management arrangements supporting it. ASIC has urged licensees to ensure governance keeps pace with adoption.
The practical question is therefore not simply whether the AI itself works. Licensees should examine whether its deployment leaves their overall resources, competence, controls, monitoring, accountability and risk-management arrangements adequate for the activity being undertaken.
No. A human approval step provides little assurance if the reviewer cannot understand, question or override the AI-supported conclusion.
Meaningful human oversight depends on capability and authority. The reviewer needs enough information to understand what the system was asked to do, what information it used or could not access, its known limitations and what would justify rejecting or investigating its output. A person who routinely accepts the model’s answer may be physically present in the workflow without exercising meaningful judgement.
This distinction becomes increasingly important as outputs appear more sophisticated. An alert, classification or risk score can provide evidence for a decision; it does not necessarily establish the conclusion management should reach. Assured Support’s existing monitoring analysis makes the same distinction: technology can improve what management sees while accountability for interpreting and acting on that information remains human.
For material AI-supported decisions, retain evidence of the output, limitations considered, challenge applied, decision reached, accountable decision-maker and any follow-up required.
Start with the consequence of error and the degree of judgement required, rather than with what the technology is technically capable of doing.
Tasks that are repetitive, reasonably predictable and independently verifiable may present stronger candidates for automation. Tasks where AI can improve speed, coverage or analysis while a person retains the substantive decision may be better candidates for augmentation. Activities involving significant contextual judgement, competing client objectives, vulnerability, ethical considerations or regulatory accountability warrant substantially greater caution.
The distinction should be documented at task level because professional roles combine very different activities. An adviser, for example, may use AI to organise meeting information or identify inconsistencies without delegating the judgement required to reconcile competing client objectives.
Before implementation, map the workflow and classify each material task as automate, augment, human-led or prohibited. Then document the reason, failure consequence, required review and accountable owner. That creates a much more defensible basis for adoption than approving an AI tool in the abstract.
A licensee should require evidence that the use case produces the intended improvement without creating unacceptable new risks or weakening existing controls.
That means measuring outcomes rather than activity. The number of prompts, users, documents processed or alerts generated demonstrates adoption, not effectiveness. Relevant evidence might instead include processing time, error and exception rates, output quality, remediation volumes, false positives and negatives, employee capacity released, client outcomes and previously unidentified risks.
REP 798 demonstrates why this matters. ASIC described a credit-risk model where deficiencies included limited understanding of the third-party platform, incomplete documentation, poor governance and inadequate monitoring. The licensee subsequently replaced it with a simpler model to support explainability.
Before scaling, management should therefore specify its success and failure criteria in advance. The governance record should show what changed, whether expected benefits materialised, what unexpected consequences emerged and why management concluded that expansion was justified.
