What should a UK shadow AI policy template cover in 2026?

In brief: this is a ready-to-adapt shadow AI policy template for UK organisations — tool registry tiers, data classification rules, a 48-hour intake process, and an ICO-aligned enforcement clause you can start editing this week. It pairs a written policy with a governed workspace: see AI governance consulting if you want a board-ready framework, or move staff onto ChatGPT Business so the policy has somewhere safe to point people.

If you searched for “shadow AI policy template UK”, “generative AI acceptable use policy”, or “ChatGPT policy template GDPR”, you are almost certainly staring down a deadline: a board question, an ICO enquiry risk, a new starter asking whether they can paste a contract into ChatGPT, or an audit finding that says, in effect, “you have no documented control over generative AI use.” This article gives you a complete, clause-by-clause template — not a one-paragraph acceptable-use addition bolted onto an existing IT policy, but a working document covering tool tiers, data rules, intake, review, enforcement, vendor due diligence, and international transfers. Copy the clauses, adapt the specifics to your risk appetite, and keep the structure — it is built around how UK GDPR and ICO guidance actually expect organisations to reason about AI risk, not around generic “don't misuse company IT” language.

What is shadow AI, and why a policy alone will not stop it

Shadow AI is staff using personal or unapproved generative AI tools — ChatGPT free or Plus, Gemini, Claude, DeepSeek, a personal Copilot licence, a browser extension, a free transcription tool — for work tasks, entirely outside IT visibility, security review, or a signed vendor contract. It is a specific, sharper version of the “shadow IT” problem security teams have managed for a decade: with an unapproved SaaS tool, the risk is usually the account and its access; with an unapproved AI tool, the risk is what gets typed directly into the prompt box, often verbatim confidential text, client data, or personal information about colleagues and customers.

It happens for entirely ordinary reasons. Staff already know how to use ChatGPT from home. Procurement for an approved alternative moves slowly. Nobody has explicitly said no — so, reasonably, people assume yes. A policy that only says “do not use unauthorised AI tools” without naming an approved alternative simply pushes the same behaviour further underground, because the underlying task (draft this email, summarise this report, translate this contract) still needs doing today.

• Drafting client emails or proposals in a personal ChatGPT account rather than an approved workspace.
• Pasting board minutes, financial figures, or strategy notes into a browser summarisation extension.
• Uploading a spreadsheet containing staff or customer personal data to a personal Claude or Gemini account for analysis.
• Running a candidate's CV through an unauthorised screening or scoring tool during recruitment.
• Translating a supplier or client contract using a free, consumer-grade AI translation tool.
• Using a personal AI meeting-notes app that records and transcribes an internal or client call.

A written policy is necessary but not sufficient. Most organisations we support through AI governance consulting need the clauses below and a live decision, made in the same week, about which tools are actually available to staff on day one — otherwise the policy is a ban with nothing to replace the thing it bans.

Why a template beats a blank page — and beats a generic AI acceptable-use clause

Generic legal-marketplace acceptable-use templates are usually one or two paragraphs bolted onto an existing IT or internet-use policy, often written before current-generation generative AI tools existed in their present form. They rarely address tiering, a defined intake process, or the ICO's accountability principle in any operational sense — they simply restate “use good judgement”, which is exactly the standard that already failed to stop shadow AI from spreading in the first place.

A template built specifically for shadow AI forces the right questions in the right order: which tools are we actually going to allow, how fast can a new request be assessed, who signs off, what data may never be pasted anywhere, and how do we know any of this is working six months from now. It also compresses the internal debate that usually stalls governance projects — legal wants a DPIA on everything, IT wants a blanket ban, operations wants speed regardless. Pre-written tiers and a committed intake turnaround give each stakeholder an answer instead of a starting-from-scratch argument.

If you would rather have this validated against your sector and risk appetite than adapt it solo, that calibration work is exactly the gap AI governance consulting closes.

How to use this template

Read the whole document once before editing anything, then work through it clause by clause with whoever owns data protection, IT security, and one operational leader in the room. Replace every bracketed placeholder — [ROLE], [named owner/inbox], [30 days], [intranet location] — with your actual answers rather than leaving generic wording, and keep the clause numbering intact so the document stays easy to reference in training, audits, and incident write-ups.

• Assign a single named owner for the whole document before you edit a word — Clause 10 gives a starting RACI.
• Run one internal review workshop before publishing. Friction usually surfaces first in Clause 3 (data classification) and Clause 7 (enforcement) — better to argue about wording there than after an incident.
• Write for the least technical reader in the organisation; a policy people stop reading halfway through protects nobody.
• Version the document from day one (v1.0, v1.1) and log every change, per Clause 12.
• Do not publish a clause your organisation cannot actually enforce. An unenforced ban is worse than no policy at all, because it creates false assurance for auditors and insurers who take the document at face value.

Clause 1 — Tool registry and tiers

The centre of this policy is a living Tool Registry that classifies every generative AI tool staff might reasonably encounter into one of three tiers: Tier 1 (Approved) tools are sanctioned, contracted, and workspace-managed — for most UK teams this is a single governed workspace such as ChatGPT Business. Tier 2 (Conditional) tools are permitted for specific, named, low-risk use cases with an approver on record. Tier 3 (Prohibited) covers everything else by default, including personal or free-tier consumer AI accounts used for any task involving company, client, or personal data. The registry itself should be a living spreadsheet or intranet page, not just prose in this document, and it should be updated at least monthly as new requests are assessed under Clause 4.

• 1.1 The organisation maintains a Tool Registry listing every generative AI tool assessed for workplace use, its tier, approved use cases, and named business owner.
• 1.2 Tier 1 (Approved) tools may be used for any task within the data classification limits set out in Clause 3, without further sign-off.
• 1.3 Tier 2 (Conditional) tools may be used only for the specific use cases recorded in the registry, and only with data classified Public or Internal.
• 1.4 Tier 3 (Prohibited) tools, including personal or free-tier consumer AI accounts, must not be used for any work task involving company, client, or personal data.
• 1.5 Any tool not listed in the registry is treated as Tier 3 until it has been assessed under Clause 4.
• 1.6 The Tool Registry is reviewed at least monthly and published at [intranet location].

Most UK teams start Tier 1 with a single governed workspace rather than a long tool list — see how ChatGPT Business fits that role in Clause 2 below, and how AI governance consulting helps size the wider registry to your actual risk profile rather than a generic list copied from elsewhere.

Clause 2 — Approved tools and the role of ChatGPT Business

Most shadow AI policies fail without a real Tier 1 alternative, because staff still need somewhere sanctioned to go for the task in front of them. A governed workspace such as ChatGPT Business gives the organisation admin ownership, configurable business data protections (including a training opt-out that personal accounts do not offer by default), domain-based account provisioning, and audit visibility that a personal login simply cannot provide. Without that workspace in place, this policy is not really a policy — it is a ban with nowhere to redirect the demand it is trying to control.

• 2.1 [Organisation name] provides [ChatGPT Business / equivalent enterprise workspace] as its default Tier 1 generative AI tool for drafting, research, summarisation, and analysis tasks.
• 2.2 Workspace accounts are provisioned and de-provisioned through the standard joiner–mover–leaver process; personal email addresses must not be used to create workspace seats.
• 2.3 Business data protection settings — training opt-out and retention configuration — are enabled by default and reconfirmed at each Clause 12 review.
• 2.4 Staff who need a capability not available in the Tier 1 workspace must request an assessment under Clause 4 rather than sourcing a personal alternative themselves.

AI Build Group's ChatGPT Business rollout support and AI governance consulting are designed to work together: the workspace gives staff somewhere approved to go, and the policy gives IT and legal something concrete to point to when asked how that workspace is controlled.

Clause 3 — Data classification and paste rules

This clause is where most real-world arguments about the policy actually happen, because it turns abstract “use good judgement” language into a concrete rule: information is classified Public, Internal, Confidential, or Restricted before it goes anywhere near an AI tool, and the tier of tool permitted narrows sharply as classification rises. Restricted data — personal data of staff, clients, or third parties, special category data, health data, financial account details, or anything covered by a client confidentiality agreement — should never reach a Tier 2 or Tier 3 tool, and only reaches Tier 1 once the checks below are satisfied.

• 3.1 All information is classified Public, Internal, Confidential, or Restricted before use in any generative AI tool, in line with the organisation's existing data classification policy where one exists.
• 3.2 Public and Internal data may be used in Tier 1 tools without further approval.
• 3.3 Confidential data (unreleased financials, strategy, unpublished client work) may only be used in Tier 1 tools with business data protection settings confirmed active, and never in Tier 2 or Tier 3 tools.
• 3.4 Restricted data must not be pasted into any generative AI tool unless a Data Protection Impact Assessment has been completed and signed off under Clause 4.
• 3.5 Staff must assume that anything typed into a prompt box may be logged, stored, or reviewed, and must apply the same judgement they would to an email sent outside the organisation.
• 3.6 Screenshots, screen-shares, voice dictation, and file uploads into AI tools are subject to the same classification rules as typed text.

Getting the classification thresholds right for your sector — what genuinely counts as Restricted for a law firm versus a construction contractor versus a healthcare provider — is one of the first working sessions in AI governance consulting, because a threshold copied from a different industry either blocks normal work or misses the risk that actually matters to your regulator.

Clause 4 — 48-hour new tool intake

Staff will find new AI tools faster than procurement can formally review them. A slow assessment process does not prevent shadow use — it guarantees it, because the tool gets used while the review sits in someone's inbox. This clause commits to a short, defined turnaround so that raising a new tool is genuinely faster and easier than quietly adopting one without asking.

• 4.1 Any staff member may request assessment of a new AI tool by submitting the Tool Intake Form to [named owner/inbox], including intended use case, data types involved, and vendor name.
• 4.2 The reviewing owner responds with a decision — Approved, Conditional, Rejected, or Escalated for DPIA — within 48 working hours of submission.
• 4.3 A tool pending assessment is treated as Tier 3 (Prohibited) and must not be used with company, client, or personal data during the review window.
• 4.4 Assessment covers, at minimum: vendor data handling terms, whether inputs train the model by default, the sub-processor list, hosting location, and whether a DPIA is triggered under Clause 3.4.
• 4.5 Approved tools are added to the Tool Registry (Clause 1) with tier, use case, and review date within one working day of approval.
• 4.6 Rejected requests receive a written reason and, where possible, a pointer to an already-approved tool that meets the underlying need.

A 48-hour turnaround only works if someone owns it full-time or part-time with real authority to say yes. Clause 10's RACI and AI governance consulting both exist to make that person's decisions fast and defensible, not just fast.

Clause 5 — Human review and logging

No AI output should leave the building unchecked, and the accountability principle behind UK GDPR expects organisations to be able to show how decisions were reached, not just what the final output was. This clause keeps a named human in the loop for anything external-facing, legal, financial, medical, or safety-relevant, and asks staff to log significant AI-assisted work so there is a trail if a claim, figure, or decision is later questioned.

• 5.1 Output from any generative AI tool used for external-facing communication, legal, financial, medical, or safety-relevant content must be reviewed and approved by a named human before use or publication.
• 5.2 Staff must not represent AI-generated output as independently verified fact without checking sources, figures, and named claims.
• 5.3 Where the Tier 1 workspace supports conversation logs or audit exports, these are retained for [X months] and made available to the Clause 10 owner on request.
• 5.4 Use of AI tools for decisions producing legal or similarly significant effects on an individual — recruitment shortlisting, credit decisions, disciplinary recommendations — requires documented human review and is never fully automated, in line with UK GDPR Article 22.
• 5.5 Staff log significant AI-assisted work — first drafts of contracts, policy documents, or public statements — in [system of record], noting the tool used.

Designing a logging approach that staff will actually maintain, rather than one that looks thorough on paper and gets ignored within a month, is a common early task inside AI governance consulting engagements.

Clause 6 — Training and AI literacy

Both the ICO and the GOV.UK AI regulation framework treat AI literacy as an accountability expectation rather than a nice-to-have. A policy nobody has been trained on is, in practical terms, a policy that does not exist. Training needs to cover the tiers, the classification rules, how to raise an intake request, and — just as importantly — how to spot AI errors and hallucinated content before it goes anywhere near a client or a decision.

• 6.1 All staff complete AI literacy induction training within [30 days] of starting, covering this policy's tiers, data classification rules, and intake process.
• 6.2 Refresher training is delivered at least annually, or sooner following a material policy change under Clause 12.
• 6.3 Role-specific training is provided for staff in legal, HR, finance, and client-facing roles, reflecting the higher-risk data they typically handle.
• 6.4 Training completion is recorded against each staff member and reported to [owner] as part of Clause 11 metrics.
• 6.5 New joiners are not issued a Tier 1 workspace seat until induction training is recorded as complete.

Designing role-specific training content — the difference between what a finance team and a construction site team actually need to know — is part of the rollout support offered alongside AI governance consulting.

Clause 7 — Enforcement and incidents

Enforcement language is where most draft policies quietly lose credibility. Too harsh, and it will not survive the first genuine mistake made by an otherwise good employee; too soft, and staff correctly conclude the whole document is decorative. This clause distinguishes a first-time, low-impact slip from a wilful or repeated breach involving Restricted data, and routes any suspected personal data exposure straight to the Data Protection Officer so the organisation's regulatory clock starts on time rather than late.

• 7.1 Use of a Tier 3 (Prohibited) tool with Confidential or Restricted data is a policy breach, managed under [organisation]'s disciplinary policy, proportionate to intent and impact.
• 7.2 Any suspected exposure of personal data through an unapproved AI tool is reported to the Data Protection Officer / [named role] within 24 hours of discovery, to allow assessment against the 72-hour UK GDPR breach notification clock.
• 7.3 First-time, low-impact breaches — for example, pasting a public document into a Tier 2 tool without registering it — are addressed through coaching and a reminder of Clause 6 training, not disciplinary action.
• 7.4 Repeated or wilful breaches, or any breach involving Restricted data, escalate to [HR/Legal] for formal review.
• 7.5 Incidents are logged in the AI incident register maintained by the Clause 10 owner, including root cause and any policy or registry change made as a result.
• 7.6 No staff member is penalised for reporting a suspected AI-related data incident in good faith, even where they caused it.

This clause is usually the one that most benefits from an outside read before publication — AI governance consulting reviews enforcement wording against how your organisation actually runs disciplinary process, not how a template assumes it does.

Clause 8 — Vendor due diligence, DPAs and Article 28

Any AI vendor processing personal data as a processor on the organisation's behalf needs a Data Processing Agreement that meets UK GDPR Article 28 requirements before it can move beyond Tier 3. That review should confirm the purpose and duration of processing, the current sub-processor list and notification rights, security measures, deletion or return of data on termination, audit rights, and — specifically for generative AI — whether customer input trains the underlying model by default and how to disable that if it does.

• 8.1 No AI vendor may be added to Tier 1 or Tier 2 without a signed Data Processing Agreement meeting UK GDPR Article 28 requirements, where the vendor processes personal data as a processor.
• 8.2 The DPA review confirms: purpose and duration of processing, sub-processor list and notification rights, security measures, deletion or return of data on termination, and audit rights.
• 8.3 Vendors must confirm in writing whether customer input is used to train underlying models by default, and how to disable this where applicable.
• 8.4 A due diligence summary is retained for each Tier 1/Tier 2 vendor and refreshed at each Clause 12 review, or on material vendor change — a new sub-processor, ownership change, or security incident.
• 8.5 Free-tier or personal-account versions of a vendor's product are not covered by the organisation's DPA and remain Tier 3 regardless of the enterprise product's status.

The NCSC's [guidelines for secure AI system development](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development) are a useful reference when framing the security questions in 8.2, and AI governance consulting can run this vendor review as a fixed-scope exercise if you do not have in-house procurement capacity to do it for every request.

Clause 9 — International transfers and data residency

Many mainstream AI vendors process or host data in the United States or other jurisdictions outside the UK, which means any personal data reaching an approved tool needs a lawful transfer mechanism on file — a UK adequacy decision, an International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses. Choosing a UK or EU hosting region where a vendor offers one reduces exposure, but it does not by itself remove the need for a documented transfer basis for Restricted data.

• 9.1 Where an approved AI vendor transfers personal data outside the UK, the transfer is documented against a recognised mechanism — a UK adequacy decision, an International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses.
• 9.2 Where a vendor offers a UK or EU data residency or processing region option, this is selected by default for Tier 1 deployment.
• 9.3 Restricted data (Clause 3) is not sent to any AI tool without a documented, current transfer mechanism on file.
• 9.4 Transfer risk assessments are refreshed if a vendor changes hosting region, sub-processors, or transfer mechanism, and at each Clause 12 review.

If your organisation operates across multiple jurisdictions, or a client or regulator has asked pointed questions about where AI-processed data actually sits, this is precisely the kind of transfer analysis AI governance consulting is built to stress-test before it becomes a live incident rather than a paperwork exercise.

Clause 10 — Roles, ownership and RACI

A policy with no named accountable owner is the single most common reason governance documents are published once, admired briefly, and never enforced. This clause sets out who is accountable for the policy as a whole, who is responsible for the DPIA and breach decisions that carry the most legal weight, and who staff should actually go to with a question — rather than leaving it to a generic “IT” or “compliance” reference nobody can act on.

• Policy Owner (e.g. Head of Operations / COO): accountable for the document, chairs the Clause 12 review, and approves the Tool Registry.
• Data Protection Officer / Privacy Lead: responsible for DPIA sign-off (Clauses 3.4 and 4.4), breach assessment (Clause 7.2), and transfer mechanisms (Clause 9).
• IT/Security Lead: responsible for workspace provisioning (Clause 2), technical controls, and vendor security review (Clause 8).
• Line Managers: responsible for ensuring their team completes training (Clause 6) and raises intake requests (Clause 4) rather than adopting tools informally.
• All staff: responsible for following tiers and classification rules day to day, and for reporting suspected incidents (Clause 7.6) without fear of blame.
• Executive sponsor: accountable for resourcing the Policy Owner's time and backing enforcement decisions (Clause 7) when they are unpopular.

Naming these roles honestly — and confirming the people named actually have the time and authority the clauses assume — is usually the first gap closed in AI governance consulting engagements, well before any clause wording changes.

Clause 11 — Monitoring and metrics

A policy that is never measured is a policy nobody can honestly claim is working. This clause commits to reporting a small set of metrics that show whether the approved workspace is actually being adopted, whether intake requests are meeting the Clause 4 turnaround, and whether unregistered tool use is rising or falling — the practical signal that tells you whether the governance programme is succeeding or quietly being bypassed.

• 11.1 The Policy Owner reports at least quarterly on: active Tier 1 workspace users versus total headcount, average intake turnaround against the Clause 4 target, training completion rate, and logged incidents by severity.
• 11.2 Where technically available, network or SaaS-discovery tools are used to identify AI tool use outside the registry, without monitoring the content of individual staff communications beyond existing lawful monitoring policy.
• 11.3 A rising trend in unregistered tool discovery, or falling Tier 1 adoption, triggers a review of whether the approved tool set actually meets staff needs.
• 11.4 Metrics are reported to [executive sponsor / board] to keep AI governance a standing item, not a one-off launch.

Setting up a lightweight metrics report that survives beyond the first quarter — rather than a dashboard nobody maintains after month two — is a recurring theme in AI governance consulting reviews.

Clause 12 — Review cycle and version control

AI vendor terms, ICO guidance, and the tools staff want to use all change faster than most policy review calendars assume. This clause sets a minimum six-monthly cadence, plus specific triggers that bring the review forward — a significant incident, a material change in ICO or GOV.UK guidance, a genuinely new category of AI tool entering common use, or a business change such as a merger or new regulated activity.

• 12.1 This policy is formally reviewed at least every six months by the Policy Owner, DPO, and IT/Security Lead.
• 12.2 An early review is triggered by: a Clause 7 incident of medium severity or above, material new ICO or GOV.UK AI guidance, a new AI tool category entering common use, or a business change such as merger, acquisition, or new regulated activity.
• 12.3 Each review produces a version-numbered document (e.g. v1.0, v1.1) with a change log summarising what changed and why.
• 12.4 The current version is published at [intranet location] and superseded versions are archived, not deleted, to support audit trails.
• 12.5 Staff are notified of material changes and, where the change affects their obligations, asked to reconfirm acknowledgement.

Review-cycle discipline is usually the first clause organisations skip under time pressure — and the first one an auditor asks to see evidence of. AI governance consulting can run this review on a retained basis if a six-monthly internal cycle is not realistic yet.

UK GDPR and ICO mapping: how this template lines up with the law

This template is not a substitute for legal advice on your specific risk profile, but the mapping below lets a DPO or legal reviewer trace each clause back to the UK GDPR principle or ICO expectation it is answering — which makes the review conversation faster and the eventual sign-off more confident.

• Accountability (Article 5(2) and Article 24): Clauses 1, 10, 11 and 12 — a documented registry, named owners, and reported metrics are the paper trail the ICO expects when asking how an organisation demonstrates control over AI use. See the ICO's [guidance on AI and data protection](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/).
• Lawfulness, fairness and transparency (Article 5(1)(a)): Clause 3's classification rules and Clause 5's human-review requirement stop personal data being processed in ways staff or data subjects would not reasonably expect.
• Data minimisation and purpose limitation (Article 5(1)(b)–(c)): Clause 3's paste rules and Clause 1's tiering stop Restricted data being fed into tools with no defined, limited purpose.
• Data protection by design and by default (Article 25): Clause 2's default business-data-protection settings and Clause 9's default residency selection build the principle into the workspace configuration rather than relying on staff discretion alone.
• DPIAs (Article 35): Clauses 3.4 and 4.4 trigger a DPIA wherever a new tool or use case involves personal data likely to result in high risk — the ICO's [DPIA guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/data-protection-impact-assessments/) sets out when this is required.
• Processor obligations (Article 28): Clause 8 requires a compliant DPA before any AI vendor processing personal data is approved.
• International transfers (Articles 44–49): Clause 9 requires a documented transfer mechanism, following the ICO's [international transfers guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/).
• Automated decision-making (Article 22): Clause 5.4 keeps a human in the loop for decisions with legal or similarly significant effects on an individual.
• Wider policy context: the ICO's [generative AI guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/generative-ai/) and the [GOV.UK AI regulation white paper](https://www.gov.uk/government/publications/ai-regulation-a-pro-innovation-approach/white-paper) principles — safety, transparency, fairness, accountability, and contestability — sit behind the tiering and enforcement logic used throughout this template. The NCSC's note on [ChatGPT and large language models: what's the risk](https://www.ncsc.gov.uk/blog-post/chatgpt-and-large-language-models-whats-the-risk) is useful background for Clause 3's paste rules and Clause 8's vendor questions.

None of this replaces a conversation with your own DPO or external counsel about your specific risk profile — but it gives that conversation a starting document instead of a blank page. This gap-analysis step is exactly what AI governance consulting covers before a policy goes anywhere near staff.

Decision matrix: which tier does a new tool actually belong in?

There is no single-column table that captures every AI tool decision fairly, so treat the sequence below as the decision matrix behind Clause 4 — walk a new request through each question in order, and stop as soon as one answer forces a tier.

• Does the tool process any personal, client, or commercially sensitive data? If no, and the vendor's general terms are acceptable, it is a Tier 2 candidate for low-risk internal use once logged in the registry.
• Is there a signed Article 28 DPA and a clear answer on whether inputs train the model by default? If no, the tool cannot move beyond Tier 3, regardless of how useful it is for the requested task.
• Does the intended use case involve Restricted data (Clause 3.4) or a decision with legal effect on an individual (Clause 5.4)? If yes, a DPIA is required before any tier above Tier 3 is considered.
• Does the vendor offer UK/EU hosting or a documented transfer mechanism (Clause 9)? If no, treat the request as higher risk and require executive sign-off before Tier 1.
• Is there already an approved Tier 1 tool that does the same job? If yes, the default answer is “use the existing approved tool”, because tool sprawl is itself a governance risk, not a convenience.
• Has the vendor had a security incident or ownership change in the last 12 months? If yes, re-run Clause 8 due diligence before approval, even for a previously approved product.

In practice, most requests resolve to one of two outcomes: “already covered by the existing ChatGPT Business workspace” or “not yet, pending DPIA” — and both are perfectly good outcomes as long as the decision is written down, which is the actual point of the matrix, not the specific answer reached. If you want this matrix pressure-tested against real requests your teams are already raising, that calibration work is part of AI governance consulting.

Rollout checklist: 30 days from draft to enforced policy

A policy that sits in draft for months while the “right” wording is debated protects nobody. This checklist sequences the template into a live, enforced document within thirty days, without skipping the steps that make enforcement fair.

• Week 1 — Draft and align: adapt this template's bracketed placeholders, confirm the Policy Owner (Clause 10), and run one review session with the DPO, IT/Security, and one operational leader.
• Week 1 — Baseline honestly: identify the current default AI tool situation — which personal accounts, browser extensions, or free tools staff already rely on — using the shadow AI examples above as a prompt for an honest internal audit.
• Week 2 — Provision Tier 1: confirm or roll out the approved workspace, such as ChatGPT Business, so the policy has a real alternative to point staff toward from day one.
• Week 2 — Build the registry: populate the initial Tool Registry (Clause 1) with the Tier 1 workspace, any existing Tier 2 tools already in legitimate limited use, and a first-draft Tier 3 list naming common consumer tools explicitly.
• Week 3 — Publish and train: publish the policy as a controlled v1.0 document, deliver the first AI literacy training session (Clause 6), and open the intake channel (Clause 4).
• Week 3 — Set up logging: agree where incidents (Clause 7) and intake requests (Clause 4) will be logged, even if it starts as a simple shared form and spreadsheet rather than dedicated software.
• Week 4 — Go live on enforcement: start applying Clause 7 from this date, with a documented grace period for first-time low-impact issues while training embeds across the organisation.
• Week 4 — Schedule the first metrics report and the six-month Clause 12 review date, so governance stays a standing item rather than a one-off launch exercise.

Running this thirty-day sequence alongside a partner compresses the internal back-and-forth considerably — most AI governance consulting engagements complete this exact sequence within the same window, with sector-specific calibration built in rather than added afterwards.

When to get consulting help instead of adapting this alone

This template will take most organisations a meaningful step forward on its own. It is not, however, a substitute for outside review in every situation — some signals genuinely warrant bringing in support before staff start relying on the document.

• You operate in a regulated sector — financial services, healthcare, legal, education, public sector — where a regulator may ask to see this document, not just hear that one exists.
• You have already had a near-miss or confirmed incident involving an AI tool and personal, client, or commercially sensitive data.
• You do not currently have a Data Protection Officer or equivalent capacity to own Clauses 3, 4, 8, and 9 with confidence.
• You operate across multiple UK sites, or across the UK and EU or other jurisdictions, and need the Clause 9 transfer analysis to actually hold up under scrutiny.
• Your board, insurer, or a major client has asked for evidence of AI governance as a condition of a contract, renewal, or cover.
• You would rather have an external reviewer stress-test the enforcement clause (7) and decision matrix before staff start relying on it in a real incident.

At a high level, an AI governance consulting engagement covers a gap analysis against current ICO and GOV.UK guidance, tailored clause calibration for your sector, RACI and rollout support, and — where useful — pairing the finished policy with a ChatGPT Business workspace so it has a real Tier 1 destination from day one rather than a promise to “sort the tooling out later”.

Related reading

• AI governance consulting — tailor this template to your sector and risk appetite.
• ChatGPT Business — provision the Tier 1 workspace this policy assumes.
• Shadow AI is already in your business — how to spot and measure shadow AI before writing policy.
• Shadow AI risks for UK businesses: security and compliance — the identity, audit, and compliance gaps this template's clauses close.
• Don't ban AI, control it — why blanket bans widen the gap this policy is designed to close.