Free AI Policy Template (UK): Every Rule Has a Control

Thu, 29 Oct 2026 07:53:03 +0000

This article was originally published on korixinc.com.
Read the canonical version at: https://korixinc.com/learning-center/ai-policy-template-uk

Free AI Policy Template (UK): Every Rule Has a Control

A policy is only as strong as the control behind each rule. This free UK AI policy template pairs every clause with the control that enforces it and the evidence you would show.

If a client asked how you know your staff are not pasting their data into ChatGPT, a signed policy would not answer them. This free AI policy template for UK businesses is built so you can: every rule comes with the control that enforces it and the evidence you would show. Copy the clauses, name an owner for each control, and you have an answer.

You almost certainly need one already. Microsoft research carried out by Censuswide in October 2025 found that 71% of UK employees have used unapproved consumer AI tools at work, and 51% do so every week, across a sample of 2,003 UK employees. Only 32% said they were concerned about the privacy of the company or customer data they put into those tools. Your team is using AI whether or not anyone wrote a rule about it; the policy decides whether that use is visible and defensible.

Most firms have not caught up. In ISACA's 2026 AI Pulse Poll of more than 3,400 digital trust professionals, only 38% of organisations had a formal, comprehensive AI policy, up from 28% in 2025. Another 30% had a limited policy and 25% had none at all, while 90% of respondents believed employees in their organisation were using AI.

A note on who wrote this, because it matters for how you read it. KORIX builds governed AI systems for UK service firms, so we have a commercial interest in AI being done properly. The template below is free, it works without us, and nothing in it requires you to buy anything. It is not legal advice either: if you are regulated by the FCA, the SRA or a similar body, have your compliance lead or adviser check the final version against your own obligations.

What should an AI policy include?

An AI policy should cover which tools are approved, which data can never go into them, when a human must check AI output, who owns AI risk and what happens when something goes wrong. Each of those needs a control that enforces it, not just a sentence that describes it.

Most templates you will find online stop at the sentence. They tell staff not to paste client data into public AI tools, ask them to sign, and file the signed copy. That gives you a record that you told people, which is useful after an incident, but it does nothing to stop the incident. The question a client, an insurer or the ICO will actually ask is not whether you had a policy, but how you knew it was being followed.

KORIX defines an enforceable AI policy as one where every rule names a control, an owner and the evidence that proves the control is working. Those three parts are what turn a document into a system:

The control is the mechanism that makes the rule hard to break: a blocked website, a business account with the right settings, an approval step in a workflow, a log that records what happened.
The owner is one named person, not a department, who is accountable for the control working.
The evidence is what you would show someone to prove it: an admin report, an approval log, a training record, a review date that actually happened.

If a rule in your policy has all three, it will survive scrutiny. If it has only the sentence, treat it as a wish and either add a control or accept the risk openly.

The free AI policy template (copy and adapt)

Copy the clauses below into your own document and replace the bracketed parts. Each clause has the policy wording first, then the control that enforces it and the evidence to keep.

Section 1. Purpose and scope

Policy wording: This policy sets out how [Company name] staff, contractors and anyone acting on our behalf may use artificial intelligence tools, including generative AI chatbots, writing assistants, transcription tools, coding assistants and AI features built into software we already use. It applies to all work for the company and all company or client data, on any device.

Control: The policy is issued through your normal HR or onboarding system and acknowledged by every person in scope.

Evidence: the acknowledgement record, kept with the policy version number.

Section 2. Approved tools

Policy wording: Staff may only use the AI tools listed in the Approved AI Tools Register, through company-managed accounts. Using personal accounts or unlisted AI tools for company work is not permitted. Anyone may request that a tool be added; requests go to [AI owner].

Control: Keep the register as a single live document with an owner. Provide business accounts for the approved tools so staff have a sanctioned option that is as easy as the consumer one. Where your IT setup allows it, restrict access to unapproved AI sites on managed devices.

Evidence: the register with dates of each approval, and the admin console showing who has an account.

The request route matters as much as the ban. If asking for a tool is slow or unclear, people will use the consumer version quietly, which is exactly the problem this clause exists to solve.

Section 3. Data you must never put into an AI tool

Policy wording: The following must never be entered into any AI tool unless that specific tool and use has been approved for it in the register: client personal data; special category data such as health information; financial account details; passwords, keys or access credentials; information covered by a confidentiality agreement; and unpublished company financial information.

Control: Use business tiers of approved tools and read their terms on whether your inputs are used for training and how long they are retained, then record what you found in the register. For higher-risk data, use data loss prevention rules in your email and endpoint tools if you have them.

Evidence: the register entry showing the data classes each tool is approved for, and any data loss prevention alerts reviewed.

Section 4. Human review of AI output

Policy wording: AI output must be checked by a competent person before it is sent to a client, published, used to make a decision about a person, or relied on for advice. The person who sends or uses the output is accountable for it, not the tool.

Control: For any workflow where AI drafts something that reaches a client, build the review into the workflow itself as an approval step that cannot be skipped, rather than relying on memory.

Evidence: the approval log showing who approved what, and when.

Section 5. Decisions about people

Policy wording: AI must not be used to make, or substantially make, decisions with legal or similarly significant effects on individuals, such as hiring, credit, pricing or eligibility, without a documented assessment approved by [AI owner] and, where personal data is involved, a data protection impact assessment.

Control: A short intake form for any new AI use case, which routes anything touching decisions about people to the AI owner.

Evidence: the completed form and the DPIA where one was required.

Section 6. Transparency

Policy wording: Where AI has materially produced content or analysis that a client relies on, we will be open about it if asked, and we will not present AI output as the personal work of a named expert who has not reviewed it.

Control: A standard line staff can use when clients ask how work was produced.

Evidence: the line in your client communication templates.

Section 7. Ownership and accountability

Policy wording: [Name, role] is the AI owner and is accountable for this policy, the Approved AI Tools Register and the handling of AI incidents. Line managers are responsible for their teams following it.

Control: The AI owner is written into the role description, not just this document.

Evidence: the role description and the owner's quarterly review notes.

Section 8. Incidents and stopping a tool

Policy wording: Anyone who believes client or company data has gone into an AI tool it should not have, or that AI output has caused harm, must report it to [AI owner] the same day. The AI owner can suspend any AI tool or workflow immediately while it is investigated.

Control: A named reporting route, and a documented way to switch off each approved tool or automated workflow, tested once before you need it.

Evidence: the incident log and the date the switch-off was last tested.

Section 9. Training

Policy wording: Everyone in scope will complete short training on this policy when they join and when it changes materially.

Control: Training tied to account access: no business AI account until the training is complete.

Evidence: completion records.

Section 10. Review

Policy wording: This policy is reviewed by the AI owner at least once a year and whenever we adopt a significant new AI tool, our regulator issues new guidance, or an incident shows a gap.

Control: A recurring calendar entry owned by the AI owner.

Evidence: the version history showing each review actually happened.

Do UK businesses legally need an AI policy?

There is no UK law that says every business must have a document called an AI policy. But UK GDPR, sector regulation and your client contracts already apply to how you use AI, and a policy is the simplest way to show you are meeting them.

The ICO publishes guidance on AI and data protection covering accountability, lawfulness, transparency and fairness when AI processes personal data, including what to consider in a data protection impact assessment. As at October 2026 the ICO notes that this guidance is under review following the Data (Use and Access) Act, so check it again before you finalise your policy. Under UK GDPR, a DPIA is required where processing is likely to result in a high risk to individuals, which many AI uses involving client data will be.

The stakes are not abstract. Under the ICO's fining guidance, the higher maximum fine is 17.5 million GBP or 4% of total worldwide annual turnover, whichever is higher. The ICO's standard maximum is 8.7 million GBP or 2% of turnover. Fines at that level are rare and reserved for serious failings, but the point stands: data you lose through an AI tool is still your data protection problem.

If you are FCA-regulated, the Consumer Duty requires you to evidence good customer outcomes, and you cannot evidence an outcome shaped by an AI tool nobody logged. Public bodies have their own reference point: the government's AI Playbook, published in February 2025, sets out 10 principles for using AI in government, including meaningful human control at the right stages and using AI securely. It is written for the civil service, but it is a useful sense check for any private-sector policy.

Should you ban ChatGPT and other AI tools at work?

A blanket ban rarely works, because it pushes AI use onto personal phones and accounts where you can see none of it. A short approved list with a fast way to request new tools gives you far more control than a ban.

Ethan Mollick, the Wharton professor who writes the One Useful Thing newsletter, called staff who quietly use AI at work "secret cyborgs". His argument was that bans make people hide their use because they do not want to get into trouble, and that firms should build targeted policies for specific types of use rather than blanket bans. The Microsoft figures above suggest that is exactly what has happened in many UK workplaces.

The risk of hidden use is now on analysts' radar too. Gartner predicts that by 2030 more than 40% of enterprises will experience security or compliance incidents linked to unauthorised shadow AI, according to its November 2025 analysis of generative AI blind spots. We have written separately about what shadow AI looks like inside a firm and how to make it auditable.

There are cases where a narrow ban is right. If a particular tool's terms allow it to train on your inputs and there is no business tier, banning that tool for client work is sensible. The difference is that you are banning a specific risk, and offering a sanctioned alternative, rather than banning AI.

How do you enforce an AI policy once it is written?

You enforce it by turning the riskiest rules into systems that make breaking them difficult and visible. Signatures and reminders do not enforce anything on their own.

Start with the two clauses that carry most of the exposure: approved tools and prohibited data. Give people a business account that is as easy to use as the consumer tool, and most of the shadow use disappears because the sanctioned route is now the convenient one. Then make the review step real for any AI output that reaches a client.

This is a common gap. ISACA found that 56% of respondents did not know how long it would take to halt an AI system after a security incident, and 39% did not know whether they had a documented process for shutting down or overriding AI systems at all. Section 8 of the template exists for exactly this reason: if you cannot switch something off, you do not control it.

In the systems KORIX builds, the review rule is not a sentence in a policy; it is part of the architecture. In our own lead intelligence system, no message can be sent without a human approving it. That is true by design, not by measurement: there is no send path that skips the approval step, and if one were ever added the claim would stop being true the same day. That is the standard to aim for with your highest-risk workflows. The rule and the control are the same thing.

For the controls that cannot be fully automated, keep the evidence light but regular. A quarterly ten-minute review by the AI owner of the tools register, the approval logs and any incidents is a sensible starting point for a firm of twenty to a hundred and fifty people. If you want the wider picture of how this fits into governance, our guide to what governed AI means in practice covers the full model, and the AI compliance checklist maps the main frameworks.

Does the EU AI Act change what goes in a UK AI policy?

It can, if you sell into the EU. The EU AI Act can apply to UK firms whose AI systems are placed on the EU market or whose AI output is used in the EU, as set out in Article 2 of the regulation.

For most UK service firms using AI internally for drafting, summarising and admin, the practical effect on this policy is small: the template already covers transparency, human review and decisions about people, which are the areas the Act cares most about. If you build AI products for EU customers, or use AI in areas the Act treats as high risk such as recruitment or credit, take specific advice, because the obligations and their timing are detailed and still being finalised.

How much does an AI policy cost to put in place?

The template costs nothing, and adapting it means filling in the bracketed parts and naming owners. The real cost is in the controls: business accounts for approved tools, a little IT configuration, and an owner's time each quarter.

For a typical firm of twenty to a hundred and fifty staff, the main recurring cost is business licences for the AI tools you approve, which you were probably going to need anyway, plus a few hours of the AI owner's time each quarter. If you already have managed devices and a business email platform with data loss prevention, much of the technical control is configuration rather than new spend.

The bigger cost appears when you want AI to do real work inside client-facing workflows, because that is where review steps, logging and a way to switch things off have to be built into the system rather than written into a document. That is the work KORIX does. Our 21-day governed AI pilot has a published range of 15,000 to 40,000 USD depending on scope, and if the system is not in production by Day 21 you do not pay the second half of the fee. You do not need a pilot to use this template; you need one only when you want a governed workflow built and running.

Who is this template not right for?

It is not the right fit if you build AI products for others, operate in a high-risk area under the EU AI Act, or need a policy that will stand up as a formal regulatory submission. In those cases use it as a starting checklist and get specialist advice.

It is also not ideal for a firm that has no intention of naming an owner or providing approved tools. A policy that bans consumer AI without offering a business alternative will be ignored, and an ignored policy is arguably worse than none, because it creates a written record that you knew about the risk. Be honest with yourself about this trade-off before you publish anything to staff.

And it is not a substitute for knowing where AI is already being used. If you do not yet know which tools your team relies on, start with a short anonymous survey or an honest team conversation; the register in Section 2 should describe reality, not an aspiration. Our article on whether you need a head of AI governance covers who should own this as you grow.

What should you do this week?

Name an AI owner, write down the tools your team actually uses, and decide which ones become approved business accounts. Those three steps make the rest of the template workable.

Monday: appoint the AI owner and give them this template.
Tuesday to Wednesday: list the AI tools in real use and decide approved, replaced or banned for each.
Thursday: adapt Sections 1 to 10, with a named control and evidence for each.
Friday: issue it, set up the business accounts, and put the first quarterly review in the calendar.

If one of your AI uses already touches clients and you want it running with the review step and audit trail built in rather than written down, book a free 30-minute consultation and we will tell you honestly whether it needs a pilot or just better configuration. For a view of what goes wrong when it is left ungoverned, see AI agent risks.

About this template: written by KORIX, the governed AI practice founded by Shishir Mishra. It reflects our reading of current UK guidance as at October 2026 and is not legal advice.

The bottom line: A policy is only as strong as the control behind each rule. Copy the template, then go clause by clause and name the control, the owner and the evidence. Any rule without all three is a wish. Start with the approved-tools list and the data you never paste in, because that is where most exposure sits.

What is governed AI? — AI that is observable, auditable, human-supervised, rollback-ready and owned by your team.
AI governance vs governed AI — the rulebook versus the system that enforces it at runtime.
AI compliance checklist (SOC 2, HIPAA, GDPR) — the nine controls to have in place before AI touches regulated work.
Shadow AI: making staff AI use safe — your team already uses AI for client work; how to make that use auditable.
Do you need a head of AI governance? — who should own AI decisions in your firm.

Shishir Mishra — Founder & Systems Architect (AI), KORIX. 19 years building enterprise software, now deploying governed AI agents across finance, healthcare, logistics, and real estate. KORIX deploys AI agents inside the tools your team already uses — not on top of yet another platform. Learn more about Shishir.

Originally published at korixinc.com — read with the full design + comments.

Tags: AI, AI Governance, Templates

Route to Rise: Code as the Global Language

Wed, 13 May 2026 11:45:00 +0000

Route to Rise: Code as the Global Language

Closing thesis: Local-first and stateless inference are portable ideas — they travel farther than any single city’s hype cycle. This serial tied every claim to how the product is actually built.

What we proved (Parts 1–9)

Theme	Where it lives
Stateless AI	Pocket Analyst chat API
Context compiler	Client-side `buildPortfolioContext`
Guest vault	Browser local storage for unsigned-in users
Referrals	Referral events + completion API
Growth ops	Internal analytics dashboard
Brand system	Amber Terminal email (inline HTML tokens)

Geography is a story, not a SLA

GA4 maps show traffic concentration — useful for narrative, useless for regulatory footprint without separate facts. Label charts: “web users, 28d” — not “revenue by city.”

How Parts 10–11 fit the arc

Part 10 — Statement PDFs: roadmap until end-to-end ingestion exists in the product.
Part 11 — Institutional gateway: vision—lead with data minimization and integration shape, not implied shortcuts through legal or model-risk work.

What “Route to Rise” means here

Build defensible architecture in public, explain it with concrete implementation detail, and let distribution (blog, community, referrals) compound. The product is the proof.

Part 12 of Sovereign Engineering.

Read the full Sovereign Intelligence book or try the app.

Coder Legion - Recent posts tagged uk

Free AI Policy Template (UK): Every Rule Has a Control