The plumbing beneath the AI policy: making responsible AI routine in UK mid-market firms

Many UK organisations can now produce an AI policy. Far fewer can show that it changes what happens on a Tuesday afternoon when an employee wants to summarise a customer complaint, a manager wants to screen CVs or a finance team wants to forecast cash flow. The policy is signed; the plumbing is missing.

The gap between signature and behaviour

Governance theatre is easy to recognise. It is a policy on the intranet, an annual attestation and a list of banned tools. It may be well written. But it does not tell staff which tools are approved, which data may be entered, who approves a new use case, what gets logged or how a vendor is checked. Governance that changes behaviour is less polished and more useful.

The distinction matters because AI use is rarely a single decision. It is a series of small ones: trying a browser extension, pasting a document into a chatbot, accepting a supplier’s new feature, using a model to draft a response. Controls must be close to those moments.

Five control layers for a mid-market firm

A pragmatic operating model has five layers. They do not need a large team, but they do need ownership.

1. An approved tool and model register. List the AI tools and models the organisation permits, the business owner, the data classification allowed, the vendor, the contract reference and the next review date. If a tool is not on the list, it is not approved. The register should be short enough to be credible.

2. Data access and classification. Staff need simple rules: public, internal, confidential and personal or special category. Default-deny for the most sensitive categories in public tools. Use data loss prevention where it is proportionate. The question is not whether a tool is ‘AI’; it is what data is going into it and what the vendor does with it.

3. A use-case intake and approval route. A one-page form should capture purpose, data, users, vendor, human review and expected benefit. Low-risk uses can be approved by a line manager with a checklist. Higher-risk uses need data owner, security and legal or procurement review; personal data brings in the DPO. The route should be fast enough that people use it.

4. Logging and monitoring. Log the metadata that matters: user, tool, data category, purpose and date. Avoid logging sensitive content unless there is a clear lawful basis and retention rule. For high-risk uses, require human review of outputs. Monitor for shadow AI through network and SaaS discovery, but treat findings as a design problem rather than only a disciplinary one.

5. Vendor controls. Procurement should check whether the supplier uses customer data to train models, where data is processed, which subprocessors are involved, what audit rights exist, how incidents are notified and how data is deleted on exit. UK GDPR processor terms and international transfer mechanisms are baseline. For AI features added to existing software, check the change control and terms rather than assuming the original contract covers them.

Specific checks for UK mid-market organisations

• Is there a named AI owner with authority across IT, data and procurement?
• Can the organisation produce a register of live AI use cases within 24 hours?
• How many unsanctioned AI tools are in use, and is that number falling?
• Are contracts updated for model training, output ownership, indemnity and deletion?
• Do staff know how to report an AI-generated error or a data leak?
• Has a vendor exit been tested for a critical AI-enabled service?
• Is training role-specific, or is it an annual e-learning module?
• Are personal data and special category data covered by the approval route?

Procurement’s role is not to say no

Procurement adds most value when it makes the risk visible before signature and the exit possible afterwards. Key clauses include restrictions on using customer data for model training, clarity on output ownership and indemnities, service levels for accuracy and availability where appropriate, change control for model updates, audit rights, subcontractor approval, security obligations, incident notification and deletion on termination.

Supplier questionnaires should be risk-based. A generic ‘AI questionnaire’ sent to every supplier produces generic answers. A focused set of questions for tools that touch personal data, make decisions about people or integrate with core systems will produce better evidence.

A quarterly operating rhythm

The model does not need a large programme. A quarterly cycle can work: refresh the register, review the approval queue, sample high-risk use cases, check vendor contract coverage and report a small set of metrics to the executive team. Useful metrics include the proportion of AI use covered by the register, time to approve a use case, number of high-risk uses with human review, incidents and contract coverage for critical suppliers.

The board does not need a technical appendix. It needs to know whether the organisation can evidence control over its most material AI uses. That is a one-page question, not a model demonstration.

Start with three live use cases

Choose three AI uses already happening. Map the data, the approval route, the logging, the vendor terms and the human review. Fix the gaps in those three before designing an enterprise framework. The lessons will be more useful than a policy refresh.

The unglamorous plumbing — registers, data rules, approval routes, logs and contracts — is what turns a signed policy into responsible practice. In 2026, that is the work that distinguishes organisations that govern AI from those that simply have a view about it.