Secure. Global.
Enterprise AI.

What Scale Actually Changes

A small team automating a task is making a tooling decision. An organisation automating the same task is changing a process that other processes depend on.

The same volume that makes the business case attractive also makes the consequences of a quiet, systematic error much larger. A person handling two hundred cases a week notices drift. A system handling twenty thousand does not, unless you built something that watches.

This is not an argument for moving slowly. It is an argument for choosing a first process whose blast radius you can describe in one sentence.

Where It Lands First

The early candidates in a large estate are consistent: high volume, document-heavy, spread across systems, and already staffed by people doing work below their capability.

1. 01

   Document-Heavy Back Office

   Invoices, claims, applications, contracts, onboarding packs — work that arrives as a document and ends as a record in a system.

   AI reads, extracts, classifies and checks against what is already held, then hands the result to the workflow that was going to run anyway.

   Examples

   • Invoice and payment matching
   • Application review
   • Contract clause extraction
   • Reconciliation
   • Exception handling

   This is where most enterprise programmes start, because the volume is known and the before-and-after is measurable without a new reporting layer.

2. 02

   Service Desks, Internal and External

   Both IT and customer service carry a long tail of requests that repeat with variation.

   AI can classify the request, draft the response from material the organisation already publishes, and escalate what does not fit.

   Examples

   • Ticket triage and routing
   • Drafted responses
   • Knowledge-base answers
   • Summarising a case for the next agent
3. 03

   Questions That Cross Business Units

   Reporting is rarely the problem. The problem is the question nobody can answer without three teams exporting data to each other.

   AI sitting over governed data can turn that into an answer, provided the governance was done first.

   • Which of these contracts carry the clause we are worried about?
   • Where is the same customer treated differently by two systems?
   • What changed in this process after the policy update?
   • Which sites are outliers, and on what measure?
4. 04

   Monitoring, Risk and Compliance

   Controls generate more signal than any team can read. The work is separating what matters from what merely happened.

   AI can rank, group and explain, leaving analysts to judge rather than to sift.

   Examples

   • Alert triage
   • Policy change impact
   • Anomaly review
   • Evidence gathering for audit
5. 05

   The Engineering Estate Itself

   Legacy modernisation, test coverage, documentation and migration are perpetually deferred because they take skilled attention and produce no feature.

   They are also unusually well suited to a first pass by machine and a review by a person.

   Examples

   • Legacy code explanation
   • Test generation
   • Migration assistance
   • Documentation from code

How Much Autonomy to Grant

The same capability can be deployed at three levels of risk. In a regulated or audited environment, the level is usually not yours alone to choose.

• It acts within defined limits, logging every decision for review.
• It prepares the decision and a named person approves it.
• It assembles the evidence and a person decides and acts.

Start at the level your auditors would accept today, not the one you hope to reach. Earning the next level is a conversation about evidence, and evidence takes months to accumulate.

What Your Existing Controls Already Cover

Large organisations often treat AI as an entirely new governance problem. Much of it is not. The questions already have owners:

• data classification and retention — your information governance already defines this
• access control and segregation of duties — already defined per system
• change management and release approval — already defined
• vendor assessment and data processing terms — already defined
• audit trail and evidence — already defined

What is genuinely new is narrower: a system that can be confidently wrong, that behaves differently as inputs drift, and whose reasoning is not legible the way a rule is.

Framing it that way shortens the approval conversation considerably, because most of the questions turn out to be ones the organisation has answered before.

What It Will Not Do

• It will not resolve a process that two departments disagree about. It will encode the disagreement.
• It will not clean your data. It will expose how uneven it is.
• It will not reduce headcount on its own. It changes what the work is.
• It will not be explainable the way a rule is, so some decisions should stay rules.
• It will not survive without an owner once the programme team moves on.

Write the Scope Down to One Page

One page that the process owner, the data owner and the risk reviewer can all sign without a meeting. If it takes more than a page, the scope is still too wide.

• the exact process step, and where it begins and ends
• the systems it reads from and writes to
• the decision it makes, and the decision it must not make
• what happens when confidence is low
• who approves the output during the pilot

Measure the Current Process Before You Change It

Take a real baseline: volume, cycle time, error rate, rework, cost. Take it from the systems rather than from what people believe it to be.

Organisations consistently discover the baseline is worse than assumed. That is not an embarrassment — it usually strengthens the case and sharpens the target.

Run It in Shadow Before It Touches Anything

The first deployment should change nothing. The process runs as it always has; the system runs beside it on the same inputs, and its outputs are recorded and compared.

• production inputs, at production volume
• a period long enough to include month-end and the awkward cases
• every output stored with the input that produced it
• disagreements with the human result reviewed, not just counted

Shadow running is the cheapest evidence you will ever present to a risk committee, and the only kind that costs no one a bad outcome.

Review the Disagreements With the People Who Do the Work

Sit with the team and go through the cases where the system and the person differed. The interesting ones are rarely the obvious errors.

• Where was it confidently wrong, and would anyone have caught it?
• Which cases does it handle better than we do?
• What would you need to see before you stopped checking every one?
• Which cases should never be automated, whatever the accuracy?

The last two answers become your release criteria and your permanent exclusions. Both are more credible coming from the team than from the programme.

Roll Out by Narrowing Supervision, Not by Adding Scope

There are two dials: how much of the volume it touches, and how much supervision each case gets. Move one at a time.

• start with every output approved by a person
• move to approval by exception, with a defined confidence threshold
• widen to the rest of the volume in the same unit
• only then consider a second business unit
• keep the off switch reachable by the process owner, not only by IT

A second business unit is a new integration, new data owners and often new regulation. Treat it as a new deployment that happens to reuse a component.

Hand It Over Properly

The deployment is not finished at go-live. It is finished when somebody outside the project team is accountable for it and has what they need.

• a named owner in the business, not only in technology
• a quality measure reported on the existing cadence
• an alert when correction rates move
• a documented path to switch it off and revert
• a review date in the calendar, with the authority to stop it

A system nobody owns will keep running long after it has stopped being right. That, rather than a failed pilot, is the expensive outcome.