UK SME AI governance: manage workflows, not just tools

The UK AI governance gap is operational, not merely documentary

The central AI-governance challenge for many UK SMEs is not the absence of a policy document. It is the absence of a reliable view of where AI is already changing work: what information is entered into a tool, what systems it can reach, who acts on its output and who remains accountable when the process fails.

This is increasingly important because adoption is moving from experimentation into ordinary business activity. In June 2026, 35% of UK businesses with 10 or more employees reported using at least one AI technology, compared with around 12% in late 2023. Businesses using AI reported 1.6 technologies on average (ONS, 2026) ↗. The pattern is consistent with AI arriving through a mix of embedded software features, subscriptions and narrow team-level applications, rather than through a single enterprise transformation programme.

Formal governance has not become visible at the same pace. The UK Business Data Survey found that 17% of AI-using businesses had AI policy or guidance and 5% had a formal written policy. It also found that 21% had integrated AI tools into existing systems in 2025–26 (DSIT, 2026) ↗. Integration can create value by reducing repetitive administration, improving access to knowledge or speeding up customer responses. It also raises the stakes: a poor output, a misconfigured permission or a supplier problem can then affect a repeatable business process rather than an isolated trial.

These figures should not be overstated. The ONS measure excludes businesses with fewer than 10 employees, while the surveys use different populations, questions and definitions. Nor does the lack of a written policy prove that a firm has no controls. The defensible conclusion is narrower, but important: AI is becoming part of business infrastructure before management practices are consistently observable.

For smaller firms, this is a commercial as well as a technical issue. Owner-managers often retain close oversight of service delivery, customer relationships and reputation. If a workflow is poorly understood, the result may be rework, inconsistent quality or avoidable loss of trust at precisely the point where a business is trying to build capacity. The immediate response should be basic guardrails combined with a practical discovery exercise—not a lengthy policy programme detached from everyday work.

Why the workflow is the unit that needs managing

An approved-tool list is a useful baseline, but it is not a risk assessment. The same generative AI product may be a low-consequence aid for an internal first draft and a fundamentally different proposition when it prioritises job applicants, drafts customer communications, interprets sensitive material or initiates activity in a finance system.

The product may be the same; the workflow is not. A workflow brings together a purpose, the information supplied, system permissions, the degree of staff reliance, people affected, the decision that follows and the consequences of error or interruption. Mapping it makes the management questions concrete: what initiates use; what data, instructions and access enter the process; where outputs travel; who checks them; and how work continues if the tool is wrong or unavailable.

This approach avoids two weak defaults. Blanket prohibition can drive useful experimentation into personal accounts or informal workarounds, leaving leaders with less visibility rather than more control. Blanket permission assumes that all use is routine, including activity that is customer-facing, repeatable, integrated with business systems or influential in significant decisions. A more credible approach differentiates between low-consequence assistance and uses where access, scale or impact justify greater scrutiny.

There is good reason to discover actual practice rather than assume it. More than half of employees reported using AI for work or education in May–June 2026, while around one-third of businesses with 10 or more employees reported using at least one AI technology in June (ONS, 2026) ↗. The measures are not directly comparable and do not establish unauthorised use. They do support a management hypothesis worth testing: organisational leaders may not have a complete picture of individual experimentation, personal accounts or locally developed workarounds.

That hypothesis is especially plausible in smaller organisations, where adoption can start with an employee solving a local problem: preparing a proposal, researching a market, drafting a customer email or cleaning a spreadsheet. Such initiative can be valuable. But it becomes durable productivity improvement only when the firm can judge whether the workflow should be scaled, redesigned, constrained or stopped.

Policy matters, but operating controls determine whether it works

Written guidance has a clear role. It can establish approved services, restrict particular forms of information sharing, set expectations for human review and tell staff when to seek help. But guidance does not, by itself, demonstrate that an organisation understands the activity it is trying to govern.

A firm may have an acceptable-use policy while lacking a current picture of staff-built automations, connected accounts, information entered into third-party tools or workflows that have shifted from internal drafting to external communication. In that circumstance, policy is principally a communication device, not an operating control. The danger is false assurance: leaders believe AI is governed because a document exists, although nobody has reviewed how the relevant process works in practice.

Policy-only approaches are also poor at handling change. A supplier can alter functionality, terms or data settings; a successful pilot can become a routine part of service delivery; and a tool used for internal copy can later gain access to a customer relationship management system or shared document store. Governance therefore needs review triggers as well as initial permission. Sensible triggers include a new category of information, new system access, external-facing use, greater dependence on outputs, use in a consequential decision, a supplier change or an incident.

The accountability question should be equally specific: which named manager owns the business outcome in this workflow? It may be a customer-service lead, a partner responsible for professional delivery or a recruitment manager. Suppliers and technical advisers can offer expertise, but they cannot take the organisation’s place in deciding whether a process should operate and under what constraints.

The counterargument is valid. A small business should not turn every prompt into a compliance exercise. Materiality is the appropriate threshold. Sanctuary’s judgement is that firms should maintain a concise record for uses that are repeatable, connected, customer-facing, sensitive or consequential. This is more useful than treating every low-risk drafting task as a formal project, and more defensible than relying on a general policy where the operational impact is substantial.

UK guidance supports accountable, proportionate records

UK guidance points towards evidence, accountability and proportionate management rather than generic claims of “responsible AI”. The government’s AI Management Essentials guidance is intended for organisations that develop, provide or use AI systems, including SMEs and start-ups. Its focus on internal processes, risk management and communication recognises that responsible deployment is not solely a concern for model developers (DSIT, 2026) ↗.

The accompanying tool describes an AI system record as an inventory of documentation, assets and resources relating to an AI system. Depending on context, this can include technical documentation, risk and impact assessments, model analysis and data records (DSIT, 2026) ↗. This is not a call for enterprise-scale documentation for every low-risk internal task. The transferable principle is practical: retain enough information to understand what a material deployment does, why it is used, what it can access and how the business will respond if it goes wrong.

Data protection is a particularly important boundary. The ICO states that organisations should be able to justify, document and demonstrate their approach to AI. Where processing is likely to create a high risk to individuals’ rights and freedoms, a data protection impact assessment is required; where an organisation concludes that a DPIA is unnecessary, it should document that assessment (ICO, n.d.) ↗. A workflow record is not a substitute for a DPIA. It can, however, identify the facts needed to decide whether further assessment is required: the personal data involved, the processing undertaken, the people affected and the decisions that follow.

The government’s Code of Practice for the Cyber Security of AI is principally aimed at developers and system operators, so its expectations do not transfer wholesale to a small firm using a third-party product. Its underlying discipline remains relevant to connected or higher-impact uses: limit access to what is necessary, examine supplier assurances and retain evidence that would help investigate an incident. The code’s attention to documented risks, requirements, supplier due diligence and audit trails is a useful challenge to casual integration (DSIT, 2025) ↗.

A proportionate workflow record turns principles into decisions

For material deployments, Sanctuary recommends a concise AI workflow record embedded in existing procurement, quality, information-security, HR or service-design routines. It is a management instrument, not a new legal test. More formal assessment and specialist advice may be needed for regulated services, employment decisions, safety-critical activity or higher-risk personal-data processing.

A useful record should answer six questions:

1. Purpose and value: What task, service or decision is being improved, and how will benefit be measured?

2. Workflow boundary: What triggers use, what enters the tool, what is produced and where does the output go next?

3. Data and permissions: Does the workflow use personal, confidential, commercially sensitive or third-party information, and is each permission necessary?

4. Accountability and judgement: Which manager owns the outcome, who checks outputs, and which decisions require escalation or must not be automated?

5. Supplier and security: Which provider, model and integration are used, and what configuration, contractual and access checks have been completed?

6. Evidence and review: What testing, feedback, incidents and performance measures will be retained, and what changes trigger reassessment?

The purpose is not paperwork for its own sake. The record converts a broad question—“Do we govern AI?”—into decisions about access, oversight, fallback arrangements and commercial value. It can also expose weak business cases before a business acquires a new cost and supplier dependency without solving a meaningful problem.

Tiering should be explicit. A low-consequence internal drafting task may require an approved-tool list, basic staff guidance and ordinary human checking. A customer-facing assistant, recruitment shortlisting workflow or finance-system agent warrants fuller testing, tighter access controls, supplier scrutiny, relevant data-protection analysis and a credible route for challenge or override. This applies the government’s emphasis on AI system records and the ICO’s expectation of demonstrable accountability without treating all AI use as equally risky ↗ ↗.

The real trade-off is speed versus unmanaged dependency

Governance creates work, and badly designed governance can impose a disproportionate burden on a small firm. An owner-manager dealing with cash flow, staffing and customers should not need a separate bureaucracy to use a drafting assistant. This objection is strongest where use is genuinely low consequence, disconnected from sensitive information and subject to normal human review.

But the alternative is not frictionless innovation. It can be unmanaged dependency: a repeatable process reliant on an external service whose data settings, permissions, supplier position and human fallback have not been considered. The initial time saving may then be offset by rework, customer dissatisfaction, security exposure or reduced staff ability to recognise weak output. For high-street and local service businesses, where repeat custom and trusted relationships are valuable assets, these effects can exceed the apparent significance of the technology.

Management capability is likely to shape whether adoption becomes durable. Among businesses expecting to adopt AI, the ONS found that 48% in the highest management-score decile adopted in the following year, compared with 31% around the median and 17% in the second-lowest decile (ONS, 2025) ↗. This is an association, not proof that management quality alone causes adoption: skills, finance and digital infrastructure may explain part of the pattern. It nonetheless supports a practical conclusion: access to tools alone is unlikely to deliver sustained productivity gains. Firms need the capacity to select, test, supervise and adapt technology within real work.

Data confidence is part of that same task. The UK Business Data Survey found that 73% of businesses handling digitised data would be uncomfortable with business-owned data being used to train external AI models (DSIT, 2026) ↗. That is not an argument to halt experimentation. It is an argument to establish the relevant supplier terms, data-use settings, retention arrangements and permissions before a trial becomes routine.

The practical sequence is therefore modest: discover current use without a punitive tone; set baseline rules for approved tools and data; map a small number of high-value or higher-impact workflows; and decide whether each should be scaled, redesigned, paused or prohibited. For UK SMEs, workflow mapping is not an alternative to policy. It is the discipline that connects policy, accountability and investment decisions to the work AI is actually changing.