How to Navigate AI Transformation

The AI mandate often arrives in operations as a destination rather than a plan: apply AI, improve productivity, show results this year.

The instruction is understandable. The starting point is not. Operations leaders are asked to choose technology before anyone has agreed which work should change, which decisions can be delegated, or what a good outcome looks like after the demonstration ends.

That creates two predictable responses. One team launches a broad search for use cases and produces a long list with no operating owner. Another selects a visible task, adds a chatbot, and calls the result transformation. Both can create activity without changing how the enterprise runs.

A better starting point is narrower. Treat AI transformation as the redesign of specific operational decisions. For each decision, define the evidence required, the person accountable, the action the system may take, the exceptions it must recognise, and the outcome the business can measure.

This approach works whether the target is claims operations, financial-crime review, customer service, procurement or enterprise GTM. It gives operations a way to move before every strategic question is settled, while keeping the work grounded in controls the enterprise already understands.

The mandate is too broad to operate

“Apply AI” describes a technology preference. It does not identify a business problem. Operations needs to translate the mandate into a portfolio of decisions and handoffs that can be observed in the current process.

The operational decision is the useful unit of transformation because it has boundaries. It happens at a point in a process. It consumes evidence. It produces an action. It can be accepted, rejected, overridden and measured.

A model has none of those properties on its own. It becomes operational only when the surrounding system gives its output meaning and authority.

Choose the first workflow by value, repetition and controllability

The largest cost centre is not always the best place to begin. Large processes often contain many policy decisions, legacy dependencies and irreversible actions. A first production workflow should be valuable enough to matter, frequent enough to generate evidence, and bounded enough to control.

Look for work where operators repeatedly gather the same evidence, apply recognisable rules and route exceptions to a smaller group of experts. That pattern creates leverage without pretending every case is standard.

Avoid choosing solely by enthusiasm. A willing sponsor helps, but the workflow still needs a source owner, an accountable operator, access to the required systems and enough volume to evaluate performance. Otherwise the pilot depends on exceptional people and manual preparation that will disappear in production.

Map the real work before designing the AI

Process documentation usually records the approved path. Transformation depends on the path people actually use: the spreadsheet maintained outside the core system, the inbox where documents arrive, the senior reviewer who resolves ambiguous cases, and the call made when the data is incomplete.

Observe a sample of cases from arrival to outcome. Record where evidence comes from, who changes it, which judgement is made, how long the queue waits, and what happens when the normal path fails. Include rejected, reopened and escalated cases. They reveal more about the operating system than a clean example.

Do not clean up the map too early. If an operator checks three systems because none is trusted, that is part of the requirement. If a manager uses judgement that is absent from policy, capture the judgement and investigate its basis. AI applied to the official process will fail when production exposes the unofficial one.

Set the automation boundary explicitly

Many projects jump from manual work to full automation. There are several useful operating modes between those states. Choosing one should depend on consequence, confidence, reversibility and organisational risk tolerance.

Human review is not a permanent virtue. Poorly designed review can become ceremonial, with operators approving outputs faster than they can assess them. Measure review time, override reasons and whether reviewers have enough evidence to disagree.

The boundary can move as evidence accumulates. A workflow may begin with retrieval, progress to recommendations and automate a narrow class of low-risk cases later. Moving the boundary should require measured performance and an accountable decision, not confidence produced by familiarity.

Define an evidence contract

An AI workflow needs a contract for evidence before it needs a prompt library. The contract states which sources may be used, which entity each fact belongs to, how fresh it must be, how conflicting facts are handled, and what must be shown to the operator.

This is where many promising prototypes break. The demonstration uses carefully selected documents. Production receives duplicates, stale records, inaccessible attachments, inconsistent identifiers and fields whose meaning changed after a system migration.

The contract makes vendor and model choices easier. Instead of asking whether a tool can “understand our data,” the team can test whether it retrieves the right source, resolves the correct entity, identifies missing evidence and declines to act when a gate is not met.

Measure the operation, not the demonstration

Prototype metrics describe the model in a prepared environment. Operations metrics describe the whole system under normal conditions. Both matter, but only the second group can justify transformation.

Set the baseline before changing the workflow. If current handling time, error rate and exception volume are unknown, the project will default to easier measures such as prompts run, summaries generated or users trained.

Measure by case type and consequence. An average can improve while a small, important segment gets worse. In claims, that segment might be vulnerable customers or complex losses. In banking, it may be a jurisdiction with different documentation rules. In GTM, it may be the strategic accounts where a poor inference damages credibility.

Governance belongs inside delivery

Governance should determine how the workflow is built and operated, not arrive as a final approval meeting. The operating team needs risk tiers, accountable roles, testing requirements, incident routes and change controls while the system is still being designed.

The NIST AI Risk Management Framework Playbook organises work across Govern, Map, Measure and Manage. NIST is explicit that the playbook is not a universal checklist. That is useful for operations: the controls should be proportionate to the workflow and its consequences.

For organisations building a management system across many use cases, ISO/IEC 42001 provides requirements for establishing, maintaining and continually improving an AI management system. Its value is organisational consistency: common policies, objectives and improvement processes rather than a new governance design for every project.

A practical risk tier should change the delivery path. Low-consequence internal drafting may need sampling and standard access controls. A recommendation affecting eligibility, financial decisions, customer treatment or regulated activity needs stronger evidence, testing, review and monitoring. If every workflow receives the same process, governance will be too weak for some and too slow for others.

Move from mandate to production in four stages

The stages are not a procurement sequence. Teams may use existing tools during framing and design, then choose technology once requirements are concrete. This prevents a platform contract from defining the problem after the fact.

Keep the first scope narrow enough that the operation can run it end to end. Ten disconnected assistants do not create more transformation than one complete workflow. A single production loop teaches the organisation about data access, controls, adoption, support and measurement in a way that a catalogue of prototypes cannot.

The companion article, Why most AI pilots don’t become systems, examines the organisational work required after a prototype succeeds. The same lesson applies here: production is a property of the operating system around the model.

What operations leaders should do in the first 30 days

Start by naming an accountable operations owner and selecting two or three candidate decisions. Do not begin with an enterprise-wide request for ideas. Ask teams where repeated evidence gathering, judgement and rework constrain an outcome the business already measures.

For each candidate, review twenty to fifty representative cases, including failures and exceptions. Establish the baseline, map the actual process and identify the systems and permissions required. Eliminate candidates whose critical evidence is unavailable or whose outcome cannot be observed.

Choose one workflow. Write its decision statement, evidence contract, automation boundary, risk tier and exit criteria. Agree who can stop the workflow, who reviews incidents and what performance is required before expanding scope.

Only then should the team compare models, vendors or build approaches. The technology evaluation will be faster because the questions are concrete, and the result will be harder to distort with a polished demonstration.

Frequently asked questions

Where should an enterprise start with AI transformation?

Start with one frequent operational decision that creates visible friction, uses accessible evidence, has a measurable outcome and allows a controlled review or rollback. Map the current workflow and baseline before selecting technology. The first objective is a complete production loop, not a long list of use cases.

How should operations prioritise AI use cases?

Prioritise on business value, repetition, decision clarity, evidence availability, reversibility and outcome visibility. Weight consequence as well as benefit. A high-value workflow with unavailable evidence or irreversible actions may be a poor first deployment even if its theoretical return is large.

When should AI be allowed to act without approval?

Only for a defined class of cases where evidence gates are met, performance is demonstrated, consequences are limited, monitoring is active and rollback or remediation exists. Keep uncertain and high-consequence cases on a review or escalation path. Reassess the boundary when the workflow, data or model changes.

Who should own enterprise AI transformation?

A central team can provide standards, platforms and specialised expertise, but the operating outcome needs a named business owner. Data, technology, risk, security and legal should shape the system according to its risk tier. Ownership fails when the central AI team is accountable for benefits it cannot operationally control.

Transformation starts when a decision changes

An enterprise does not become AI-enabled because employees have access to a model or because a steering committee has approved a portfolio. The change becomes real when a recurring decision is made with better evidence, at lower cost or higher speed, under controls the organisation can sustain.

Saber’s operations solution is built around that operating layer: turning fragmented evidence and manual judgement into governed workflows that can be measured and improved.

Start with one decision, carry it all the way into production, and use what it teaches to build the next. That is slower than announcing dozens of use cases and considerably faster than supporting dozens of pilots that never become part of the business.