From Sandbox to Standard: Governing Subsidiary AI Without Stifling It
Photo: Kenneth Allen, CC BY-SA 2.0, via Wikimedia Commons
As generative AI moves from pilot to procurement, many UK groups are discovering that subsidiary teams have already chosen tools of their own. The pattern is familiar: a local marketing team subscribes to a writing assistant, a sales subsidiary adopts a chatbot for lead qualification, and a shared service centre experiments with document summarisation. Each decision looks sensible in isolation. Taken together, they can create a patchwork of shadow tools, inconsistent data handling and vendor terms that the group has never approved.
The governance challenge is not to stop experimentation. It is to make experimentation safe enough to scale. That requires a group-level approval framework with a clear policy spine and enough local discretion to avoid turning central review into a bottleneck.
Why the group view matters
Subsidiaries see local benefit; the group carries aggregate risk. A tool that processes customer records in one subsidiary may create a UK GDPR issue, a contractual liability or a data residency problem that surfaces only when a customer asks the wrong question. Vendor terms may allow model training on group data, or permit subprocessors in jurisdictions the group has not assessed. The board does not need to approve every subscription. It does need assurance that someone is looking across the portfolio.
A policy spine, not a chokehold
The most workable model is tiered. The centre sets mandatory boundaries: prohibited use cases, data classes that may not enter external models, minimum vendor terms, human sign-off requirements and reporting obligations. Subsidiaries then choose tools and use cases within those boundaries, with faster approval for lower-risk patterns and escalation for higher-risk ones. The aim is a common rulebook, not a single buying queue.
Start with data classification
AI governance begins with knowing what data is in scope. A simple four-tier classification is often enough: public, internal, confidential and restricted. Each tier should map to permitted AI use. Restricted data, such as special category data, personal data in high-risk processing or commercially sensitive contract terms, should require explicit approval from the group data protection officer and legal team before any external tool is used. Confidential data should be limited to vendors that meet minimum terms on training, retention and residency. Internal data can move more freely, but still within an approved tool set. The classification should be published, short and enforced through procurement rather than left to judgement.
Procurement and vendor terms
A central vendor register is the practical lever. It allows the group to negotiate once, assess once and then let subsidiaries buy from an approved list. The assessment should cover whether the vendor trains models on customer data, where data is stored, how subprocessors are governed, breach notification timelines, model change notification, intellectual property indemnities, audit rights and exit assistance. Inconsistent terms are a hidden cost: one subsidiary may accept liability caps that another has spent months negotiating away. A standard questionnaire and a small approved list will usually do more for risk than a long policy document.
Model risk and human sign-off
Not all AI use cases carry the same risk. A drafting assistant that summarises internal notes is different from a model that scores credit applications or screens job candidates. A three-tier model risk approach helps. Low-risk uses can be approved locally against a checklist. Medium-risk uses need a named business owner, testing evidence and a monitoring plan. High-risk uses need group review, human sign-off in the workflow and documented escalation. The point is not to create a second bureaucracy but to match oversight to impact. Human sign-off should be real: a named person who can explain the decision and stop the process.
Where central policy ends and local initiative begins
The centre should own the policy, the vendor register, prohibited uses, group training, incident reporting and board reporting. Subsidiaries should own use case selection, implementation, first-line risk management and budget. Escalation triggers should be explicit: any restricted data, any customer-facing decision, any high-risk use case, any vendor outside the register and any incident. This split gives local teams room to move while keeping the group view intact.
Board reporting that earns its place
A quarterly AI dashboard should be short enough to read and specific enough to challenge. Useful measures include the number of active tools, the data classes they touch, high-risk use cases, incidents and near misses, exceptions to policy, vendor concentration and training completion. The board should ask three questions: where could this cause reputational or regulatory harm, are we dependent on a small number of vendors, and could we exit a tool at short notice if we needed to? Those questions turn AI from a curiosity into a governance item.
A pragmatic first 90 days
Groups starting now can take a measured sequence. Inventory existing tools and subscriptions. Publish a one-page policy with data tiers and prohibited uses. Stand up an approved vendor list and a standard questionnaire. Select two or three low-risk pilots with named owners. Introduce a simple quarterly dashboard. Review exceptions after the first quarter. The framework will improve with use, but the group needs a starting point before local adoption outpaces central visibility.
The goal is not to centralise every chatbot. It is to ensure that when a subsidiary wants one, the group already knows the rules, the risks and the reporting line. That is how local initiative becomes a group capability rather than a governance surprise.
