A Catalogue, Not a Checkpoint: Giving UK Group Boards Sight of Local AI Use

Artificial intelligence rarely arrives in a group through a single decision. It arrives as a subscription bought by a marketing team, a transcription tool trialled by a subsidiary’s HR function, or a coding assistant adopted by an engineering unit before the centre has heard the supplier’s name. The result is not necessarily reckless. It is simply invisible.

For UK group boards, the question is not whether local teams should experiment with AI. In many cases they should. The question is whether the centre can see what is happening, understand where data is going and intervene early enough when a use case carries more risk than the team realised. A group AI register is a practical answer, provided it is designed as a catalogue rather than a checkpoint.

Visibility without a permission queue

An AI register is often imagined as a gate. Teams submit a proposal, the centre reviews it, and work begins only after approval. That model suits a small number of high-risk activities. It does not suit the dispersed, fast-moving pattern of AI adoption now visible in many multi-entity groups. It also tends to produce the wrong behaviour: teams either avoid the register or populate it with cautious descriptions that reveal little.

A better model is a register that records what is already in use, who owns it and what it touches. The centre gains a map. Entity leaders retain the ability to make local decisions. The register becomes a source of shared intelligence rather than a bottleneck.

This distinction matters in a group structure. A subsidiary may have its own customers, its own operating rhythm and its own tolerance for risk. A central function may have a group-wide view of legal exposure, supplier concentration and reputational consequence. The register connects those perspectives without pretending they are the same.

Five fields that earn their place

A register should be short enough to complete in minutes and specific enough to be useful. Five core fields cover most of the ground.

• Use case. Describe in plain language what the tool does and what decision or task it supports. Avoid product names alone. ‘Summarises customer complaint emails for the service team’ is more useful than ‘AI assistant’.
• Owner. Name a role, not a department. The owner is the person who can explain why the tool is used, what data it receives and when it will be reviewed. A named owner creates accountability without creating a central approval step.
• Data touched. Record the categories of data involved: internal documents, customer personal data, employee data, financial information, special category data or confidential client material. The register does not need a data protection impact assessment in every row, but it should show where one may be needed.
• Supplier. Identify the provider, the hosting location and whether the supplier’s terms allow the group’s data to be used for model training. This is often the field that turns an invisible experiment into a manageable risk.
• Review date. Set a date for the owner to confirm the entry is still accurate. A register without review dates becomes a historical record within months.

Groups may add fields for entity, function, spend, status or contract reference. The test is not completeness for its own sake. The test is whether a board member or central risk lead can read the row and understand the exposure.

Escalation triggers, not approval gates

A register should not imply that every AI use requires central permission. It should specify the circumstances in which a local entry must be escalated. Clear triggers are more workable than blanket approval because they preserve local discretion while directing attention to the cases that matter.

Typical triggers include:

• personal data is processed at scale, or special category data is involved;
• the tool informs automated decisions affecting customers or employees;
• outputs are customer-facing or published without human review;
• the supplier’s terms permit training on the group’s data;
• data is transferred outside the UK without an established legal basis;
• the use case sits within a regulated activity or a safety-critical process;
• the spend or supplier dependency is material to the entity.

When a trigger applies, the entry moves to a named central contact for review. That review should have a stated purpose and a reasonable timeframe. It should not become a general veto. The register records the escalation and the outcome, which gives the board an audit trail without turning the centre into a queue manager.

A second trigger is silence. If an entity has no entries after repeated prompts, the group should ask why. The absence of AI use may be genuine. It may also indicate that teams are using tools outside the register. Either way, the conversation is useful.

A 2026 review rhythm

A register succeeds through rhythm, not through a single launch email. For the 2026 calendar, a four-quarter cycle is proportionate for most UK groups.

In each quarter, entity leads update their entries and confirm review dates. The central function collates the register and flags exceptions: missing owners, overdue reviews, new suppliers, unclear data categories. The group risk or legal function reviews only the escalated entries and the exceptions. The board receives a short summary, not the full register.

Once a year, the group should test the register itself. Sample a handful of entries and ask whether the description matches actual use. Check whether supplier terms have changed. Confirm that leavers and role changes have not left owners stranded. This is assurance of the register, not a audit of every AI tool.

The rhythm should align with existing reporting cycles. A group that already asks entities for risk updates each quarter should add AI to that process rather than create a parallel exercise. The aim is to make the register ordinary. A register that takes ten minutes to update will be updated. A register that requires a project plan will not.

Making it work across entities

Two practical points determine whether the register survives contact with a group structure. First, the centre should explain what it will do with the information. If entries are used only to build a central report, entities will treat the exercise as a tax. If entries lead to useful feedback, shared supplier insight or early legal guidance, the register earns its place.

Second, the register should be visible to the people who need it. A spreadsheet locked in a central folder is not visibility. A simple shared table with clear ownership and a short quarterly summary is often enough. The board does not need to see every row. It needs to know that the rows exist, that someone owns them and that exceptions reach the right people.

AI adoption in UK groups will continue to be local, incremental and uneven. That is not a failure of governance. It is a condition to be governed. A lightweight group AI register gives the centre a catalogue of experiments, a set of escalation triggers and a review rhythm that respects entity autonomy while keeping the board informed. It is not a brake on innovation. It is a way of knowing where the innovation is.