Give the Team an AI Operating Policy Before Automating More Work

Do not approve an automation until you can explain what happens to the expertise it displaces.

“Can we automate this?” usually decides what an organisation is prepared to lose in exchange for speed or lower cost: judgment, accountability, and sometimes a career.

A repeated task can still contain the work that keeps a process safe: judging exceptions, reading incomplete information, protecting a customer relationship, or knowing which rule is safe to bend. The visible sequence is often the smallest part of the job.

I have sat close enough to this decision to know how quickly it becomes a spreadsheet question: a specialist with decades in a narrow role, close to retirement on their own terms, and a system able to handle most of the visible work well enough. The spreadsheet records a saving; the person facing it sees a late-career demand to become employable somewhere else. Automation can still be the right call, but it is bigger than a software comparison.

“Reskill the person” makes that disruption sound cleaner than it is. Someone in their late fifties or early sixties may have spent thirty or forty years building expertise inside one specialised function, expecting to retire from it on their own terms. Removing the role can suddenly ask them to rebuild their employability past the age when they expected to stop. The consequences behind that disruption can be much darker than a transition plan admits, even when the financial case for automation looks straightforward.

The automation may not remove the expertise either; it can move the same judgment onto a digitised interface. Someone still has to recognise an error while the work is moving, understand what caused it, and decide whether to intervene before it spreads. A business can remove the role, discover later that it still needs the knowledge, and then pay to reconstruct what it discarded.

The role is not the unit of analysis

When a team says it wants to automate a role, it often means it wants to automate only part of one. The shortcut hides the real choice.

One role can hold repetitive handling, decisions, escalation, customer trust, and workarounds that exist because the official process fails in predictable places. A team that does not separate those parts before adding AI risks encoding the most visible work and losing the judgment that made it reliable.

A local automation can then create a larger operating problem. The first version looks efficient because the happy path moves faster; the cost arrives when a customer has an unusual request, an external partner changes a handoff, a regulation introduces a condition nobody modeled, or an experienced person who used to spot the issue has already left the loop.

I see this risk most clearly in workflow-heavy B2B environments, where one process crosses technical teams, non-technical operators, external vendors, field staff, and several systems of record. A Dubai or Abu Dhabi team can have the same decision moving through office staff, remote specialists, a delivery partner, and a founder who becomes the final escalation point. Automating one step without understanding the state passed between those people makes missing context travel faster.

The customer often becomes the person forced to trace that missing ownership. They arrived to solve their own issue, then find themselves navigating a company problem: one department sends them to another, nobody can name the full responsibility, and each team understands only the part that reaches its own screen. I see UAE companies trying to automate across that gap before they have mapped the baseline underneath it. The ambition is not the issue; the missing starting point is.

Treat the decision inside the work as the unit of analysis, not the job title.

Map from the outcome back to the baseline

When a founder tells me, “We should automate this,” my first question is why.

What outcome are they trying to reach: lower handling time, fewer errors, better customer response, more capacity, or less dependence on one person? Automation is a method, not the goal. A team that starts with the tool can make the current workflow faster without deciding whether that workflow should survive.

Once the outcome is named, I work from both ends. What is the actual baseline today, including the unofficial workarounds, bottlenecks, decision points, and information moving between people? What should the target workflow produce, and what must it continue protecting? The work in between is a mapping exercise: decide what can move directly into the automated flow, what needs to be streamlined first, where the blockers sit, and which decisions need a human gate.

That baseline matters because a team cannot jump from zero to one when it has not agreed what zero contains. Without it, there is no reliable way to tell whether the automation improved the work, moved the failure somewhere else, or simply made an undocumented process harder to challenge.

Cost savings can create a different business cost

Payroll savings fit neatly into a quarterly plan. The effects of a poor automation decision surface elsewhere: customer support, quality failures, churn, rework, stalled exceptions, lost institutional knowledge, or a workforce that no longer trusts the next change.

A company can lower its own labour cost while weakening conditions it still depends on: capable customers, stable partners, service quality, and the trust that keeps people in the relationship. That outcome is neither inevitable nor an argument against every automation. It means headcount reduction cannot be the only measure of success.

In the decisions I have seen, people closest to the work are asked for input after the tool is selected and the business case is written. By then the conversation has become adoption: how do we persuade people to use this? Ask earlier what work should change, what expertise should remain visible, and who owns the consequences when the system is wrong.

My earlier essay on the human side of AI adoption argued for taking the people side seriously. The more useful extension is operational: good intentions about retraining do little once the design has already treated people as a cost line. Make the policy before the adoption plan.

Four decisions an AI operating policy has to make

A short operating policy can make four decisions inspectable before a team turns a capability into a workflow.

1. Is the work stable enough to encode?

AI becomes useful when the underlying task has enough consistency to describe, test, and improve. A process that changes every week, relies on unspoken exceptions, or has no agreed outcome needs diagnosis before automation.

A model producing an answer matters less than the organisation defining a good one, knowing when to reject it, and showing someone how to tell the difference.

2. What judgment is being moved, not just what task is being removed?

Every automation transfers some decision-making. Sometimes that transfer is appropriate: routing a standard request, extracting fields from a known document, drafting a first response, checking a routine condition. Sometimes it is premature: deciding an exception, interpreting a customer relationship, resolving conflicting evidence, or making a call with legal, financial, or reputational consequences.

Teams need to name the point where a person must still decide. “Human in the loop” says too little on its own: name the person, define what they receive and can overturn, and decide what happens when the system is uncertain. A real policy does this before a customer finds the gap for you.

3. What happens to the knowledge and the person?

Replacing repeated handling can give an experienced person more room for difficult work, while also removing the path through which a newer team member learns how the business actually runs. Each future needs a different design.

Before a workflow changes, capture the judgment that currently makes it work. Ask the person doing it where the official process breaks, which inputs they distrust, how they detect an unusual case, and what they do when the system of record is wrong. Then decide whether their role moves toward higher-value decisions, quality control, customer support, oversight, or something else entirely. “Reskill” is not a transition plan when nobody can say what the next role contains.

4. Who remains responsible for the outcome?

The system may generate an answer, but it cannot own the promise made to a customer, partner, employee, or regulator. Someone must be accountable for the output, the exception path, the data behind it, and the decision to change the policy when the work changes.

A pilot becomes fragile when a tool that works in isolation reaches a live process with unclear ownership. Customers cannot get an answer, operators do not know whether they can override the result, and managers assume the vendor owns the failure because nobody designed the handoff.

The failure belongs to the operating design.

Start with one workflow, not an AI transformation programme

An AI operating policy stops teams from automating confusion.

Pick one recurring function that is expensive, frustrating, or visibly slow. Map the current task, its decision points, the state handed between people and systems, the exceptions, and the outcome the business is trying to protect. Then decide which part should be automated, augmented, remain human, or be redesigned before any tool is added.

The team should leave that exercise with a decision map, not a general recommendation to “use AI.” It should show the current and target workflows, the automation boundaries, exception paths, owners, human gates, and the reason each boundary exists. It should also separate what can be automated now from what might earn automation later if the first stage works under real conditions.

Start with the quick wins where failure carries the lowest cost, and cost here is not limited to money. Ask what happens when the automation is wrong, how far the error can travel, who notices it, and whether the system can recover without harming a customer, employee, partner, or regulated decision. Put the safeguards around those failure points first. If the initial stage holds, the team can automate more with evidence rather than optimism.

A bounded pilot gives a team evidence before it commits to a broader change. It should show whether the work was stable enough to encode, whether the exception path holds, how people use the new system, and whether the promised business result is real.

AI workflow implementation begins there: establish whether AI belongs in the workflow, then define what remains accountable once it does.

One function is enough to begin. Make the work, judgment, exception path, and human consequence visible before anything is built. An automation earns its place when the organisation can account for what it removes, what it preserves, and who remains responsible.