It comes up in almost every early conversation about AI in the business. Someone on the team has been using ChatGPT, Copilot, or Grammarly for months. A question surfaces: should we have a policy on this? The answer is yes. But the next question is where many owner-managed businesses lose another six months: what exactly is a policy, and how is it different from a procedure?
Getting it wrong leaves you with either a glossy document nobody reads or a list of steps with nothing behind them to explain why they exist. Neither protects you, and neither will satisfy a client, an insurer, or the ICO when something goes wrong.
What is an AI policy, and what is an AI procedure?
A policy is the document that sets what your firm believes about AI, what’s permitted, and who’s accountable when something goes wrong. It covers scope, approved tools, data expectations, and governance roles. A procedure is the step-by-step instruction that turns those principles into actual behaviour: what you do, in what order, before you paste client data into a tool.
The way to think about it: your AI policy is a 3 to 6 page document you could show to a client, an insurer, or a regulator. It answers the question “what does your firm stand for when it comes to AI?” Your AI procedures are short checklists embedded into the places where work actually happens: your onboarding process, your proposal templates, your client intake flow, your content review steps.
UK government guidance from the DWP makes the distinction explicit. A policy sets high-level direction and principles. The procedures sit underneath it and define the operational controls: what staff are required to check before using a tool, how to handle a suspected data incident, what the approval process looks like for a new AI application.
That separation matters practically. If a member of staff pastes confidential client data into a public AI tool, the policy tells you why it shouldn’t have happened. The procedure tells you what should have happened instead. You need both to have a defensible answer.
Why does the distinction matter for your business?
UK regulators expect documented policies and procedures for AI use. The ICO requires governance, accountability, and documented processes as part of UK GDPR compliance. The FCA expects firms using AI models to have clear policies aligned to existing controls. A 2023 KPMG survey found that 61% of UK CEOs had implemented or planned AI governance mechanisms within three years.
The practical consequence: not having any written AI policy or procedure increasingly reads as poor governance. Procurement teams at larger clients are asking suppliers for evidence of AI policies. Being unable to produce a document is now an active signal, not a neutral absence.
The Samsung case from 2023 is the clearest illustration. Engineers pasted confidential source code and meeting notes into ChatGPT on three separate occasions within 20 days. The data became part of OpenAI’s training. A short procedure, even a single-page checklist, would likely have stopped at least two of those incidents. A policy with no procedure behind it, or a procedure with no policy, leaves a gap that real events can fall through.
For a firm handling client data, the gap has a cost. IBM’s 2023 data breach study reported an average UK breach cost of £3.8 million, with 82% of breaches involving data stored in cloud systems. Mis-use of AI tools that push data into external models fits that pattern.
Where will you actually meet these documents in practice?
In an owner-managed services firm, your AI policy is most likely to surface when a client asks for it during procurement, when you renew cyber insurance, or when a new member of staff joins. Your procedures show up wherever the work happens: in onboarding checklists, in SOPs, in the guidance attached to your client intake forms.
Practitioners consistently note that procedures work better when embedded inside processes that already exist. If your firm has an SOP for proposal creation, an AI procedure slots naturally into it: strip personal data before using AI tools, check generated text against source documents, flag AI-assisted drafting in your internal notes.
The same logic applies to tool adoption. When a member of staff wants to trial a new AI application, that’s the moment a procedure earns its keep. What’s the tool’s data storage location? Have you reviewed its terms of service? Does it require a security review or a Data Protection Impact Assessment? Without a procedure, each person answers these questions differently. With one, the firm is consistent.
The NCSC guidance on generative AI stresses that AI tools commonly log user prompts and may train on them. A procedure that simply asks “is there personal or confidential information in this input?” before submission catches many issues before they become incidents.
When does “keep it simple” stop being enough?
A micro-business using AI only for rough internal notes, with no client data involved, can often manage with a few written rules rather than a formal policy. The appropriate level of governance depends on what data you handle, who you work with, and what your sector requires. A firm handling health or financial data has a materially different baseline from one producing marketing copy.
The thresholds where a lighter approach stops being sufficient are fairly clear. If you process personal data about clients or employees using AI, UK GDPR expectations apply regardless of firm size. If your sector is regulated, the FCA or ICO may have specific requirements beyond good intentions. If you’re using AI outputs to make decisions about individuals, Article 22 of UK GDPR is in play and you need documented human oversight procedures.
There’s also a practical trigger: if a client, a prospective insurer, or a lender has asked for your AI policy. At that point, the question has moved from “should we?” to “what do we say?”
The error many owner-managed businesses make is treating this as a single-document problem. Writing an AI policy without procedures to back it up, or drafting procedures without any principles behind them, produces documents that don’t hold up. The ICO’s enforcement history shows the gap between written policies and operational reality is where many compliance failures actually sit.
What connects this to the rest of your governance picture?
An AI policy doesn’t sit in isolation. It connects to your existing UK GDPR obligations, your Data Protection Impact Assessment process, sector-specific rules from the FCA or SRA, and your client contracts. The most practical starting point is to treat it as an extension of what you already have, not a new compliance layer invented from nothing.
The EU AI Act is worth naming here, even for UK firms. If you serve EU clients, the Act’s obligations apply to some degree from 2025 onwards, with the main requirements phasing in through 2026. High-risk AI categories, including credit scoring and recruitment tools, carry documentation, logging, and human oversight requirements that a policy and procedures framework is designed to meet.
UK law firm Arbor Law notes that a documented AI acceptable-use policy helps demonstrate compliance with data protection duties, manage IP risk, and support both client contracts and supplier agreements. Insurance brokers now routinely ask about AI governance controls during renewals. Having a short, dated, sensible policy and a set of embedded procedures is the minimum the professional environment is starting to expect.
The practical approach GRC Solutions recommends is four steps: map current AI use across your team, draft a short policy, write three to five key procedures, and assign ownership with a review date every six to twelve months. The whole programme is achievable in under two weeks when someone is driving it.
