Group AI strategy and the governance underneath it
I co-authored the group’s 2026 AI strategy, now in execution as more than 70 initiatives across 19 divisions, together with the governance model it depends on - data residency, model approval and release gating, aligned to the NIST AI Risk Management Framework and ISO/IEC 42001.
Hover any capability to preview it below; click to keep it open. Each one carries what it means, why it matters, and where the effort actually goes.
Zero-touch operations
Bought, then finished in-houseWhat it is
Routine, high-volume transactions that run end to end without a person in the path - captured, validated, matched, posted and closed automatically, with people reached only when something genuinely does not fit.
Why it earns its place
The headline ambition for the back office, and the only one worth stating as a target. Partial automation still requires someone to watch it, so the saving stays theoretical; work only truly leaves a team's plate when the default path has no human in it at all. It is also the most honestly measurable thing in the portfolio - the share of transactions nobody touched is a number that cannot be argued with.
Bought, then finished in-house — the call
The transactional systems already automate the easy middle. What has to be built is the judgement around it: the reading of unstructured input at the front, and the handling of everything the rules did not anticipate at the back.
Document understanding
Bought, then finished in-houseWhat it is
Extraction and validation over the documents that start a process - invoices, statements, forms, correspondence, scans of varying quality, in more than one language.
Why it earns its place
Most back-office automation historically stopped at the front door, because the input arrived as a document and someone had to key it in. Removing that step is what makes the rest of the automation reachable, which is why it comes first rather than as a refinement.
Bought, then finished in-house — the call
Bought where a specialist vendor is genuinely better at the extraction, in-house for the validation rules and the confidence thresholds that decide when a human is asked.
Exception handling
Built in-houseWhat it is
Triage of everything the automated path could not complete: what went wrong, what the likely resolution is, and the context needed to decide, presented to a person who then only decides.
Why it earns its place
The exceptions are where the remaining effort really sits once the straightforward cases are automated, and they are the part every automation programme underestimates. Handling them well is also what keeps zero-touch honest - a high automation rate that quietly buries a queue of unresolved cases is not an efficiency gain.
Built in-house — the call
Built, because an exception is only meaningful against your own rules. This is where the human decision stays by design.
Process simplification
Built in-houseWhat it is
Using what the automation reveals about how work actually flows to delete steps, approvals and handoffs rather than to encode them.
Why it earns its place
Included deliberately, because it is the step most often skipped. Automating a process that should not exist makes a bad process permanent and considerably harder to change later. The cheapest step is always the one removed.
Built in-house — the call
Not a technology decision at all. It is organisational work that the visibility from automation makes possible.
Research agents
Bought, then finished in-houseWhat it is
Agents that gather, read and synthesise across large bodies of material - internal documents, market and regulatory sources, prior work - and return a cited synthesis rather than a list of links.
Why it earns its place
Corporate functions are bound by reading capacity more than by anything else. The value is not that the agent writes the answer; it is that the ground it can cover before a person starts thinking is far larger than a person could cover alone. Citations are the condition of use - an uncited synthesis cannot be checked, so it cannot be relied on.
Bought, then finished in-house — the call
Bought models and search, in-house grounding. The differentiating half is the connection to internal material, which is exactly the half no vendor has.
Specialised data analysis
Bought, then finished in-houseWhat it is
Analysis against governed, certified data - a question asked in plain language, resolved into a query, executed, and returned with the working shown.
Why it earns its place
Moves analysts off the production of numbers and onto the interpretation of them. The whole thing rests on a governed semantic layer, though: without one certified definition of each measure, this produces confident answers that reconcile to nothing, which is worse than no answer at all.
Bought, then finished in-house — the call
Bought query engines, in-house semantic layer. The semantic layer is the work and it is not optional.
Predictive analysis
Built in-houseWhat it is
Forecasting, risk scoring and anomaly detection over operational and financial data, surfaced early enough to be acted on rather than reported after the fact.
Why it earns its place
Included as a reminder that plenty of high-value work does not want a language model. Conventional models on tabular data are cheaper, faster and more accurate for most forecasting, and treating every problem as a prompt is how AI programmes end up expensive and unimpressive.
Built in-house — the call
Built, and the layer with a real maintenance cost - a model in production is a commitment, so the bar for creating one is a task that is genuinely stable and genuinely high-volume.
Scenario simulation
Bought, then finished in-houseWhat it is
Modelling the consequences of a decision across scenarios - sensitivities, second-order effects, and what would have to be true for a plan to hold.
Why it earns its place
The most interesting capability in this domain and the hardest to prove. Its worth is in the quality of the questions it forces, not in the accuracy of any single projected number, so it is funded as capability rather than against a return. Claiming a hard financial case here would undermine the cases made elsewhere, which are real.
Bought, then finished in-house — the call
Bought modelling tools, in-house assumptions. The assumptions are the intellectual property and they need an owner.
Multilingual by default
Bought, then finished in-houseWhat it is
Every customer-facing capability working natively in the languages customers actually use, with quality verified independently in each rather than assumed from the strongest one.
Why it earns its place
In this region a language is not a feature toggle. Treating one language as primary and the other as a translation produces a visibly second-class experience for half the customer base. The hard part is evaluation rather than generation - public benchmarks are thin for Arabic, so native review is the signal worth trusting.
Bought, then finished in-house — the call
The models are bought and increasingly good. The evaluation is in-house, because that is the part nobody else will do to the standard required.
No app to download
Bought, then finished in-houseWhat it is
Service delivered through the channels customers already use every day - messaging first - rather than through a destination application they have to find, install, and be persuaded to open again.
Why it earns its place
The single largest constraint on adoption, and it is a distribution problem rather than a technology one. An excellent assistant behind an install prompt reaches a fraction of the people a good assistant in an existing messaging thread reaches. Choosing the channel correctly outweighs almost every refinement made after it.
Bought, then finished in-house — the call
Bought channel infrastructure, in-house conversation design. Designing for a messaging thread is a genuinely different discipline from designing for a screen, and it is not a port.
One customer record
Bought, then finished in-houseWhat it is
A single resolved identity for a customer across channels, products and operating businesses, so history and context follow them wherever they arrive.
Why it earns its place
The prerequisite the other three depend on. Without it, an assistant cannot recall a conversation from a different channel, cannot see a request already raised, and asks a customer to repeat themselves - the exact failure that makes people give up on automated service. It is also the least visible item here and the most consequential.
Bought, then finished in-house — the call
Bought resolution tooling, in-house data model and stewardship. Overwhelmingly a governance problem rather than a technical one; the technology is the easy part.
Integrated experience
Built in-houseWhat it is
A single point of entry that understands intent and routes to whichever capability is needed, rather than a menu of narrow assistants a customer has to choose between.
Why it earns its place
Customers do not know or care how a company is organised internally, and an interface that requires them to is an internal structure leaking outward. Making one entry point cover many capabilities is precisely what the orchestration layer of the platform exists to do, which is why this is the clearest link between the strategy and the architecture.
Built in-house — the call
Built on the platform's orchestration. The routing rules describe the organisation and change whenever it does.
Data and AI platform
Bought, then finished in-houseWhat it is
The shared architecture every capability above draws on - agent framework, gateway, integration, models, data foundation and observability, supplied once rather than rebuilt per initiative.
Why it earns its place
The reason three quite different domains can be pursued at once instead of one at a time. Each capability inherits integration, controls, evaluation and monitoring rather than solving them again, which is what turns a collection of pilots into a delivery pipeline. Its component-level breakdown is a diagram of its own.
Bought, then finished in-house — the call
Bought where the market is mature and built where the estate is specific. The full breakdown is on the AI platform page.
Governance and adoption
Built in-houseWhat it is
Use-case and model approval, cost attribution, residency and risk review against recognised external frameworks, and the training that decides whether any of it is used.
Why it earns its place
The organisational half, and reliably the harder one. Gates work when they are executable checks rather than review meetings, because a portfolio of any size cannot pass through one reviewer without that reviewer becoming the bottleneck. Adoption, not availability, is the measure of whether a platform works.
Built in-house — the call
In-house, mapped to external frameworks so the bar is not self-set. Teams do not grade their own work.
Three domains, not one bucket
The diagram above is a view of where enterprise AI actually pays off, written at the level of capability rather than of any particular programme. The reason it is split three ways is that the domains want genuinely different things from the platform underneath them, and a strategy that treats them as one bucket ends up serving none of them well.
Back office is about simplicity and operational efficiency, and the target worth stating is zero-touch: the transaction completes without anyone opening it. Partial automation still needs someone watching it, so the saving stays theoretical - work only truly leaves a team’s plate when the default path has no human in it. The two things that make it reachable are reading the documents at the front of the process and handling the exceptions at the back, and the second is the part every automation programme underestimates. Worth saying plainly: the cheapest step is the one you delete rather than automate.
Corporate functions want reach rather than efficiency - research agents that read more than a team can, analysis against governed data, prediction, and scenario simulation. Two caveats I would put in writing. A lot of the highest value work here does not want a language model at all; conventional models on tabular data are cheaper and more accurate for most forecasting. And simulation, the most interesting capability of the four, is funded as capability rather than against a hard return - claiming a financial case for it would undermine the cases made elsewhere, which are real.
Customer experience is a distribution problem before it is an AI problem. Multilingual has to mean Arabic and English as equals, verified independently rather than assumed from the stronger one. The channel matters more than almost any refinement made after it - an excellent assistant behind an install prompt reaches a fraction of the people a good assistant in an existing messaging thread reaches. And underneath both sits the least visible and most consequential item: one customer record. Without it the assistant cannot recall a conversation from another channel and asks the customer to repeat themselves, which is exactly the failure that makes people give up on automated service.
The part that decides whether any of it lands
Sequencing and scope are the easy half. The governance underneath is what makes a portfolio survivable: a named business owner and a measured outcome before anything counts as delivered, an external bar rather than self-grading, and gates written as executable checks wherever a claim can be turned into a test. A portfolio of any size cannot pass through one reviewer without that reviewer becoming the bottleneck - which is the failure mode most governance models produce while believing they are preventing risk.
All three domains draw on the same foundation, drawn component by component on the AI platform page. That is what makes pursuing them concurrently realistic rather than optimistic: each capability inherits integration, controls and evaluation instead of rebuilding them.