An AI automation project can work perfectly in a demonstration and still fail inside the organisation that paid for it.
The model may classify documents accurately. The assistant may produce useful answers. The workflow may move data between systems exactly as designed. Then employees find ways around it.
Some continue using the old process because it feels safer. Others copy information out of the new system and check it manually. Managers discover that staff do not understand when the AI can be trusted. Customers become frustrated when an automated interaction makes it harder to reach a person.
Months later, the technology is technically still operating but barely influencing how work gets done. The problem is easy to misdiagnose as resistance to change.
Sometimes the more uncomfortable explanation is that the project was designed around what the technology could do rather than what people actually needed.
This distinction matters as Australian organisations move from experimentation towards deeper AI adoption. The National AI Centre reported in June 2026 that 43 per cent of Australian small and medium enterprises had adopted AI to some degree across the December 2025 to February 2026 quarter. Yet trust remained a major barrier among businesses that had not adopted it, with around 65 per cent citing distrust in AI decision-making or a preference to retain human control.
AI capability is advancing quickly. Human confidence, organisational readiness and workflow design do not automatically advance with it. That is why successful automation needs more than a technical strategy. It needs a human-centred one.
Begin With the Person Whose Work Is Supposed to Improve
Automation projects often begin with an efficiency statement.
- “We can reduce handling time.”
- “We can automate 70 per cent of these requests.”
- “We can eliminate repetitive administration.”
Those may be worthwhile goals, but they describe the process from the organisation’s perspective. Ask a second question.
What becomes better for the person doing the work?
Suppose staff currently review customer emails and categorise them before sending them to specialist teams. An AI system could automate much of that classification. From management’s perspective, the value appears obvious.
For the employee, however, the change may introduce new responsibilities. Instead of reading straightforward requests, they now receive only the unusual cases the AI could not resolve.
Their work becomes less repetitive but potentially more cognitively demanding. That can be a positive change if the role, training, workload and expectations are redesigned around it.
It can be a frustrating one if leadership simply assumes that 70 per cent automation means 70 per cent less work.
The remaining work may be the hardest 30 per cent. Human-centred automation begins by understanding that shift.
Automation Changes Jobs Even When It Does Not Remove Them
Much of the public discussion about AI and work is framed as a binary question: will jobs be automated or not?
Real workplace change is usually less tidy. Jobs contain tasks. AI may perform some tasks, accelerate others and create entirely new ones.
Jobs and Skills Australia’s national Gen AI Capacity Study concluded that generative AI is more likely to augment human work than simply replace it across the Australian labour market. Its adoption analysis also emphasises that organisational capability depends on factors such as leadership, skills, governance and digital maturity.
This matters for project design. Imagine an insurance employee who currently spends part of the day reading long customer documents, extracting important facts and preparing a case for assessment.
AI might reduce the extraction work significantly. That does not make the employee unnecessary. It changes where their attention goes.
They may spend more time investigating contradictions, reviewing unusual cases or communicating decisions to customers.
If the organisation treats AI solely as a tool for removing minutes from a process, it can miss the more important job-design question:
What should people do with the capacity the technology creates?
Without an answer, productivity gains can remain theoretical.
Map the Real Workflow, Including the Workarounds
Process documentation often shows how work is supposed to happen. Employees know how it actually happens. Those two versions are rarely identical.
A formal diagram might show a customer request arriving through a form, entering CRM and moving to a service queue. Ask the service team and you may discover several extra steps.
Employees copy key details into a spreadsheet because CRM search is unreliable. They message a colleague on Teams when particular requests arrive. They keep their own reference notes because the official knowledge base is difficult to navigate.
These workarounds are not simply bad habits. They often contain useful information about where the official process fails.
Automating the formal workflow while ignoring those behaviours can remove the very mechanisms employees use to make the process function. Before designing automation, observe how people complete the task in reality.
Where do they pause?
What information do they look for?
Which decisions require experience?
When do they seek help from another person?
What do they double-check?
Where does information routinely go missing?
The answers help distinguish genuinely repetitive steps from work that only appears repetitive when viewed from a process diagram.
Do Not Confuse Adoption with Access
Buying an enterprise AI tool does not mean people are using it well. Providing access is only the beginning.
Gartner reported in June 2026 that 38 per cent of Australian employees in its survey were expected to use AI in their roles. Among those workers, 85 per cent had access to enterprise AI tools, yet 86 per cent also reported using personal AI tools to improve efficiency or handle more complex tasks. That tells organisations something important.
Employees will often find their own routes to useful technology when approved tools or processes do not meet their needs.
The response should not be to assume that employees are the problem. Shadow use can indicate unmet demand.
Perhaps the approved tool is difficult to access. Maybe employees do not know what they are allowed to use it for. Perhaps the enterprise system solves a management-defined use case while workers have discovered more valuable everyday applications.
Governance is necessary, particularly where sensitive information is involved. But governance works better when it is informed by what employees are trying to accomplish.
Trust Is Built Through Specificity
Employees are frequently told that AI is intended to “support, not replace” them. That statement may be reassuring for a meeting. It does not tell someone how their working day will change. People want more concrete answers.
What will the system do?
Which decisions will remain mine?
When should I check its output?
What happens if I disagree with it?
Will AI use be measured as part of my performance?
Who is responsible if an automated recommendation is wrong?
What information can I safely enter?
What happens to the data?
Trust grows when organisations answer these practical questions. It weakens when employees are asked to trust a system whose boundaries remain vague.
This aligns with current Australian adoption evidence. The National AI Centre’s 2026 reporting identifies trust as a major barrier and points specifically to concerns around AI decision-making and maintaining human control.
A human-centred strategy does not treat that concern as irrational resistance. It treats it as a design requirement.
Design the Human Role before Designing the Automation
“Human in the loop” has become standard language in AI governance. It can mean almost anything. A human may approve every output.
They may review only uncertain outputs. They may audit a sample. They may deal with exceptions after the automation has already acted. These are very different operating models.
If human oversight matters, specify what the person is expected to do. Consider an AI system that drafts customer responses. One design could require a service employee to read the entire original request, inspect all source material and rewrite the answer where necessary.
Another could present the draft alongside the specific information used to produce it, highlight areas of uncertainty and give the employee clear options to approve or amend. Both technically include a human. Only one may substantially reduce work.
Current NIST AI risk-management work explicitly recognises human factors and human-AI teaming as important areas in managing AI risk.
The lesson is practical. Do not bolt a person onto the end of an automated process and assume oversight has been solved. Design the interaction between people and AI as part of the system.
Customers Need a Human-Centred AI Strategy Too
Internal adoption attracts much of the attention, but customers experience automation differently. They do not care that an organisation has deployed an advanced model.
They care whether they can solve their problem. A chatbot that instantly answers simple questions can be useful.
A chatbot that prevents someone with an unusual problem from reaching an employee can make the experience worse. The difference is not AI capability. It is journey design.
Customer-facing automation should begin with the circumstances in which automation is genuinely helpful. Routine status questions may be well suited.
Simple appointment changes may be appropriate. Finding relevant information across a large help centre could also improve significantly. More sensitive interactions need greater care.
A customer disputing an important decision, dealing with financial hardship or explaining circumstances that do not fit standard categories may need flexibility, empathy and judgement.
That does not mean AI can play no role. It might retrieve information for the employee, summarise previous interactions or reduce administrative preparation. The automation moves behind the experience rather than replacing the human relationship.
The Fastest Journey Is Not Always the Best Journey
Efficiency metrics can distort customer automation. Suppose an automated service reduces average interaction time from eight minutes to three. That looks successful.
But perhaps more customers now need to contact the organisation twice because the first interaction did not fully resolve their issue.
Average handling time improved. Customer effort increased. The same issue can occur internally.
An AI tool may shorten the time required to draft a report but increase the time senior staff spend checking whether the content is reliable.
Human-centred measurement looks beyond the automated step. For customers, that may include task completion, repeat contact, escalation and satisfaction.
For employees, it could include total handling time, rework, cognitive load, exception volume and confidence in the system. The goal is not simply to make one stage faster. It is to improve the overall experience.
Employee Research Belongs in AI Discovery
Many organisations already accept that customer research should influence digital products. Employee-facing automation deserves the same discipline. Before selecting a solution, speak with the people performing the work.
Interviews can identify frustrations, tacit knowledge and exceptions. Observation can reveal steps employees no longer think to mention because they have become routine.
Workflow mapping can show where information moves awkwardly between teams. Prototype testing can reveal whether the proposed automation actually reduces effort. These methods are particularly useful because employees often adapt to inefficient systems.
Ask someone whether a process works and they may say yes. Watch them perform it and you discover they have three browser windows open, a spreadsheet beside them and several memorised workarounds.
The process “works” because employees compensate for it. AI should not automate those compensations without understanding why they exist.
Choose Problems With Employees, Not Only for Employees
One of the strongest ways to improve adoption is to involve staff in identifying opportunities. Employees who perform a process every day often know precisely where time disappears.
They can distinguish irritating administrative tasks from work that looks repetitive but actually requires judgement. They also know which automation would genuinely improve their role.
Leadership may assume report writing is the problem. Employees may say finding accurate information is harder. Management may want to automate customer responses. Service teams may point out that the real bottleneck is copying customer information between two systems.
This does not mean every employee suggestion should become a project. It means use-case discovery should include the people closest to the work. That turns AI adoption from something being done to the workforce into something being designed with it.
Integration Determines Whether AI Feels Like Help
An AI tool that sits outside normal work can create another place employees have to visit. That matters.
Suppose staff must copy a customer request from CRM, paste it into an AI tool, retrieve the result and paste it back into CRM.
The model might save thinking time. The workflow adds handling. At small scale, employees may tolerate it. At large scale, the extra interaction becomes friction. Useful automation should appear at the point where the work happens whenever practical.
This is where integrated web and digital development can matter as much as model selection. AI becomes more useful when it is connected appropriately to forms, customer portals, content platforms, internal systems and existing workflows rather than operating as an isolated demonstration.
Integration also helps establish context. Instead of asking employees to manually provide information the business already holds, the system may be able to access approved information through controlled connections.
The less employees have to work around the automation, the greater its chance of becoming normal work.
Automation Should Reduce Friction, Not Move It
Every project should ask where the work goes after automation. Consider an AI system that automatically extracts information from incoming documents. Before automation, employees spend 10 minutes reading and entering data.
After automation, data entry takes seconds.
- Success?
- Possibly.
But perhaps one in five documents contains an ambiguity requiring investigation. Employees now need to open a separate exception queue, work out what the automation attempted and repair records where incorrect information was entered.
The original workload has not disappeared. It has changed shape. This is why exception design deserves serious attention.
How will employees know an exception occurred?
Will they have enough context to resolve it?
Can they easily correct the system’s output?
Does correction feed useful information back into future improvement?
Will difficult cases arrive in manageable volumes?
A strong automated workflow handles failure gracefully. A weak one makes humans clean up after it.
Change Management Should Begin Before Launch
Change management is often scheduled near the end of an AI project. The technology has been selected. Workflows have been designed. Development is nearly complete.
Then someone prepares training. That is too late. Change begins as soon as employees hear that AI is being introduced. People form opinions early.
They wonder whether their role is at risk, whether management understands their work and whether the new tool will make their job easier or simply add monitoring.
Those concerns influence later behaviour. A human-centred change strategy should begin during discovery. Explain the problem being investigated. Include affected employees in research and testing.
Be clear about what has and has not been decided. Share what the automation is intended to improve. This does not mean promising that roles will never change. It means communicating honestly enough that employees can understand the direction of travel.
Training Needs to Cover Judgement, Not Just Buttons
Software training traditionally teaches people how to use features. AI requires another layer. Employees need to understand when to rely on an output and when to question it. They need examples of appropriate and inappropriate use.
They should understand common limitations relevant to their work, not an abstract lecture about artificial intelligence. Consider someone using AI to summarise internal documents. Training should cover more than how to upload or select the documents.
What should they do if two sources conflict?
How should sensitive information be handled?
What kinds of summaries require checking against the source?
Can the output be sent directly to customers?
Who should they ask when uncertain?
This is operational literacy. The better employees understand the boundaries, the less likely they are either to distrust everything the system produces or trust it too readily.
Managers Need Training as Much as Employees
AI adoption creates new management problems.
If a task becomes faster, should expected output increase?
If employees use AI differently, how should quality be compared?
If one person finds a highly effective workflow, how should it be shared?
What happens when an employee decides that an approved AI system is unsuitable for a particular case?
Managers need answers too. Otherwise local management practices can undermine the broader strategy. One team encourages careful experimentation.
Another tells employees they are expected to use AI for every relevant task. A third quietly discourages use because the manager does not trust it. The organisation technically has one AI policy but effectively operates three adoption models. Human-centred implementation therefore includes managers as a distinct user group.
Build Confidence Through Small, Visible Wins
Large transformation programmes can make AI feel abstract. Employees are often more persuaded by a small improvement they can experience themselves. Imagine a team spends time every week turning lengthy meeting notes into a structured action list.
Automating the initial draft may be low risk, easy to review and immediately useful. That kind of use case can help employees understand what AI is good at without asking them to trust it with high-consequence decisions.
Successful early applications also produce practical learning. Teams discover how training needs to work. Security questions emerge.
Integration requirements become clearer. Employees begin suggesting better use cases. The purpose of a small pilot should not simply be proving that AI works. It should build organisational capability.
But Do Not Mistake Popularity for Value
Employees may enjoy using an AI tool. That does not automatically mean the business case is strong. A feature can feel helpful while producing little measurable improvement.
Likewise, employees may initially dislike a change that ultimately removes significant frustration once they become familiar with it. Adoption metrics therefore need context. Track use, but also examine outcomes.
Does the tool reduce total processing time?
Is output quality maintained?
Does it decrease rework?
Are customers receiving faster or clearer service?
Do employees report greater confidence after training?
Are exceptions manageable?
A human-centred strategy is not simply about making people happy with technology. It is about understanding whether the technology improves the work in ways people can sustain.
Give Employees a Way to Challenge the System
People working with AI will encounter behaviour the project team did not predict. They need a simple way to report it.
That may include incorrect recommendations, awkward workflow behaviour, missing information or situations where the automation is technically correct but operationally unhelpful.
Feedback mechanisms should not disappear into a general IT ticketing queue with no visible outcome. Close the loop.
Tell employees when a reported issue has led to a change. Explain when something cannot be changed and why. This has two benefits.
- First, it improves the system.
- Second, employees see that their judgement still matters.
Trust is easier to maintain when people experience the automation as something that can be improved rather than something imposed as finished technology.
Human-Centred Does Not Mean Human Everywhere
There is a potential misunderstanding in this argument. Human-centred AI does not mean keeping a person involved in every automated action. That would undermine many legitimate efficiency gains.
Some workflows are low risk and highly predictable. Once properly tested and monitored, they may operate with minimal intervention.
Human-centred design instead asks whether the degree of human involvement matches the consequence, uncertainty and needs of the people affected.
A routine internal categorisation may require little oversight. A consequential customer decision may need substantial review. A low-confidence output could automatically escalate to an employee. A high-confidence, low-risk task might continue without interruption. The human role should be proportional, not ceremonial.
Strategy Should Connect Technology, Experience and Organisational Change
AI projects often cross boundaries that organisations manage separately. Technology teams focus on systems. Operations focuses on productivity.
HR focuses on workforce impacts. Legal and risk teams focus on governance. Customer experience teams focus on journeys.
If these groups work independently, they can optimise different parts of the same system in conflicting ways. A technically efficient automation might create a poor customer experience. A tightly controlled governance process may make the tool too cumbersome for employees to use.
An ambitious productivity target might encourage inappropriate automation of work that requires judgement. This is why successful AI automation strategy needs to connect technical feasibility with people, process, governance and measurable organisational outcomes. The work is multidisciplinary because the consequences are multidisciplinary.
Measure Adoption as a Journey
Adoption is not a single launch metric. Employees typically move through stages.
- First they become aware of the tool.
- Then they understand what it is for.
- They try it.
- They decide whether it helps.
- They develop habits.
Eventually, if the tool proves useful, it becomes part of ordinary work. Projects can fail at any stage. Low awareness suggests communication problems. High awareness but low trial may point to access, confidence or trust issues.
High trial followed by abandonment often suggests the tool was less useful in real work than expected. Regular use combined with heavy manual checking may reveal a confidence problem. These patterns are more informative than a dashboard showing total logins.
Adoption data should be combined with interviews, workflow observation, support requests and performance measures. Numbers can show where behaviour changed. People can often explain why.
Watch for the People Who Carry the Hidden Cost
AI transformation can create invisible work. Someone maintains the knowledge base. Someone reviews incorrect outputs. Someone explains new workflows to colleagues. Someone deals with frustrated customers when automation fails. Someone investigates unusual cases.
That work may not appear in the original productivity calculation. Pay attention to who performs it. If one operations team gains efficiency while another inherits exception handling, the organisation may have moved cost rather than removed it.
The same applies to emotional and cognitive effort. If employees must constantly decide whether an AI output is trustworthy without adequate context, the new process may be faster on paper but more exhausting in practice. Human-centred evaluation includes these less obvious effects.
Design for the Employee Who Is Not an AI Enthusiast
Early pilots often attract volunteers who are already interested in AI. They are useful participants. They are not representative of everyone who will eventually use the system.
An employee who enjoys experimenting with new technology will tolerate ambiguity and find workarounds that another colleague will not.
At scale, systems encounter people with different confidence levels, abilities, roles and attitudes. Good design should not require enthusiasm. Instructions should be understandable. The workflow should make sense.
Boundaries should be clear. Support should be available. Employees should not need to become prompt-engineering hobbyists to complete routine work. The more normal the system feels, the more sustainable adoption becomes.
A Practical Human-Centred AI Framework
Before approving an automation initiative, organisations can ask six groups of questions.
- The customer
Does this make an important customer task easier?
Could automation introduce frustration or remove access to appropriate human support?
How will customers recover when the system cannot help?
- The employee
Which tasks change?
Does the remaining work become easier, harder or simply different?
What expertise does the employee need to exercise?
- The workflow
Where does the automation sit inside the complete process?
What systems must it connect with?
What happens when information is missing or ambiguous?
- Trust and control
When is human review necessary?
How can employees challenge or correct outputs?
Who remains accountable for consequential decisions?
- Change
Which roles are affected?
When will employees be involved?
What training, communication and management support are required?
- Value
What is the current baseline?
Which customer, employee or business outcome should improve?
How will the organisation know whether the automation created value rather than merely increasing AI usage?
If those questions cannot be answered, the project may not be ready for development.
The Real Test Comes Six Months After Launch
Launch day can make almost any digital initiative look successful. The system is live. Employees have completed training. Leadership sees the demonstration.
Usage numbers rise because everyone has been asked to try it. The more revealing moment comes months later.
Are people still using it when nobody reminds them?
Have employees incorporated it into their natural workflows?
Do customers complete tasks more easily?
Has the organisation reduced work or simply created different administrative tasks?
Are managers confident about when the system should and should not be used?
Have employees developed better judgement around AI rather than blind dependence on it?
That is adoption. It does not come from software access alone. It emerges when technology, workflow, human judgement and organisational expectations fit together well enough that using the new system makes more sense than avoiding it.
AI automation is often described as a technology transformation. For the people expected to live with it, it is a change to how work is performed, how decisions are made and sometimes how customers experience the organisation.
Those dimensions cannot be addressed after the technical work is finished. They are the project. The AI initiatives that last will not necessarily be the ones using the most advanced models or attempting the highest percentage of automation.
They will be the ones where people understand the purpose, can see how their work improves, know where their judgement still matters and have enough confidence in the system to make it part of everyday practice. That is what turns an AI pilot into organisational capability.
