AI governance sized for a business, not a bank.

Most AI governance material is written for organisations with a risk committee, a data protection officer and a compliance budget. A founder-led business has a Monday morning. The good news is that proportionate governance is not diluted governance: a one-page policy, enforced, beats a forty-page framework that nobody has read.

One qualification before anything else: this article is operational guidance on process and controls. It does not constitute legal advice, and firms should confirm their specific obligations with their legal and data protection advisers.

Why governance should fit on a page

Governance fails in SMEs for the same reason AI projects stall: it is nobody's job and it is too heavy to carry. An enterprise framework transplanted into a 40-person business produces a document that is technically impressive and operationally dead. The test of SME governance is not comprehensiveness; it is whether a new hire can read it in five minutes and know what they may and may not do.

The risk of having nothing is not hypothetical either. If the business has no written position, every employee is already improvising one: pasting customer data into free tools, accepting outputs unchecked, signing up for trials with company email addresses. A policy does not create the AI use; it makes the existing use visible and governable.

The minimum viable AI policy

Six sections cover what matters. Each can be a short paragraph or a bulleted list; the whole thing should fit on one page.

• Approved uses. Name the tools and the tasks the business sanctions: drafting, summarising, coding assistance, the specific workflows that have been built and controlled.
• Prohibited uses. State the hard lines: no customer personal data in unapproved tools, no AI-only decisions on hiring, credit or anything with legal effect, no confidential data in free-tier products that train on inputs.
• Data rules. Which categories of data may go into which tools, in plain English. If the team cannot classify data quickly, give examples rather than definitions.
• Human sign-off points. Which outputs must a named person review before they act on the world: anything sent to a customer, anything that moves money, anything that changes a record of account.
• Incident route. One named person to tell when something goes wrong, and an instruction that reporting a mistake early is always the right call.
• Review cadence. A date, an owner and a trigger list: review the policy on a set cycle and whenever a new tool, workflow or regulation arrives.

The UK regulatory reality

The UK has, to date, taken a principles-based route rather than a single AI statute. The government's 2023 white paper, A pro-innovation approach to AI regulation, set out cross-sector principles to be applied by existing regulators rather than a new AI law. The practical consequence for an SME is that AI use is governed mainly by the law that already applies to the activity: data protection, consumer protection, employment law, sector rules.

For most SMEs the operative regime is data protection. The Information Commissioner's Office publishes guidance on AI, including detailed guidance on AI and data protection, and specific guidance on rights related to automated decision-making, including profiling. The core point to hold: UK GDPR restricts decisions made solely by automated means that have legal or similarly significant effects on individuals, which is one of several reasons Clerq builds human sign-off into consequential workflow steps as standard.

On the EU side, Regulation (EU) 2024/1689, the EU AI Act, entered into force in 2024 with obligations phasing in over time. It can reach businesses outside the EU in certain cases, such as placing AI systems on the EU market or where a system's outputs are used in the EU. A UK firm selling into the EU should keep this on its adviser agenda rather than assume it is out of scope. The details are jurisdiction-specific and evolving, which is exactly the kind of question to confirm with counsel rather than a blog post, including this one.

DPIAs in plain English

A data protection impact assessment sounds like enterprise machinery. It is actually a structured way of writing down three things before you process personal data in a risky way: what you are doing, why it is necessary, and what could go wrong for the people in the data, with mitigations. UK GDPR requires one where processing is likely to result in a high risk to individuals, and the ICO's DPIA guidance explains when that threshold is met; many AI uses involving personal data will meet it.

For an SME, the working rule is simple: if a new AI workflow touches personal data, run the DPIA exercise. It takes hours, not weeks, at SME scale, it forces the data-flow mapping you need for the build anyway, and it leaves an audit trail that protects the business later. When in doubt, do one.

Supplier due diligence for AI vendors

Most SME AI risk arrives through vendors, not through models you host yourself. The questions are the same ones you would ask any data processor, sharpened for AI. The National Cyber Security Centre's supplier assurance questions and the ICO's guidance on contracts between controllers and processors are the right starting frames. Ask, at minimum:

• Where is our data stored and processed, and under what legal terms does it leave the UK?
• Is our data used to train your models, and can that be switched off contractually, not just in a settings toggle?
• Which sub-processors touch our data, and how are we told when the list changes?
• What security accreditations do you hold, and what are your breach notification commitments in hours, not intentions?
• What happens on exit: data return, deletion evidence, and continuity if you are acquired or shut down?
• How does your product support human review, audit trails and configurable controls, or does it assume we trust it blind?

Governance you can execute: controls in the workflow

A policy document governs people. Workflow-level controls govern the system, and they are the part of governance that runs at 2am without anyone remembering to apply it. This is how Clerq treats governance in practice: the control layer is designed into each build rather than written alongside it. Three mechanisms do most of the work.

• Approval gates. Steps where the workflow stops and a named human approves before anything consequential happens: a payment released, an email sent, a ledger entry posted.
• Audit trails. Every automated action logged with its inputs, outputs and timestamps, so any result can be traced and any dispute settled from evidence rather than memory.
• Exception review. Items the automation cannot confidently resolve are routed to an owned queue with a deadline, not silently dropped or silently guessed.

Designed this way, the policy and the workflows reinforce each other: the policy names the sign-off points, and the build makes them physically unavoidable. The same structure is applied in practice in Clerq's customer service triage framework, and the sequencing of controls across a programme of builds is covered in the 90-day implementation roadmap.

A starter policy outline

Headings only, as guidance for drafting your own. Keep each section short enough that the whole document stays on one page.

• 1. Purpose and who this policy covers
• 2. Approved AI tools and uses
• 3. Prohibited uses
• 4. Data rules: what may go into which tools
• 5. Human review and sign-off points
• 6. Buying or building new AI: approval and vendor checks
• 7. Incidents: who to tell and what happens next
• 8. Ownership, review date and version history

A one-page policy that runs beats a forty-page framework that sleeps.

Where to start

Sequence matters less than starting. Write the one-page policy this week, using the outline above. Run the DPIA exercise on the first workflow that touches personal data. Put the six vendor questions to your existing AI suppliers at the next renewal. And if you are choosing which workflow to govern and automate first, the selection logic is set out in why AI projects stall in UK businesses. For an independent, structured review of the AI tools, workflows and controls already in the business, an AI audit establishes the current position before anything new is built.

Frequently asked questions