<!-- The AI Stairway™ AI policy skeleton, from the drafting-ai-policy skill's template, version 0.9.0 (law
pointers checked on 29 October 2026). Source: https://aistairway.scorchsoft.com/guides/ai-policy-template -->

> **About this skeleton.** These are the headings, sample wording and placeholders of a UK AI use policy. It is not a
> policy ready to adopt. Replace every {{placeholder}} with your organisation's facts, mark anything you don't
> know as [TO CONFIRM: what is missing], consult your staff, and have a suitably qualified person review it. Fill in
> the date in the notice at the end, and keep the notice until that review is complete.

# {{Organisation name}}: AI use policy

> **Guidance:** Replace every {{placeholder}} with your organisation's facts. Where a fact is missing, write [TO CONFIRM: what is missing] (the same words each time the same fact is missing) and add it to the gap list at the end. Never fill a gap with a guess about a period, role, process, existing policy or reassurance. Keep each safe default's label, "(default: change if you decide otherwise)", until the owner signs the policy off. Delete these guidance notes before you share the draft. Keep the notice at the end, word for word.

**Version:** 0.1 (draft) · **Owner:** {{policy owner (role)}} · **Next review:** {{date, or "within 90 days of adoption"}}

## 1. Purpose and scope

This policy sets out how we use AI tools at work: which tools, for what, with which information, and who is
responsible. It applies to everyone who does work for {{Organisation name}}: employees, workers, contractors,
agency staff and volunteers, on work devices and on any personal device used for work. *(default: change if you
decide otherwise)*

It sits alongside our {{existing policies to link to, e.g. data protection, information security, IT acceptable
use, monitoring, disciplinary and whistleblowing policies}}. Where they overlap, {{which policy takes precedence}}.

{{Regulator, or delete: "We are regulated by <regulator>. [TO CONFIRM: <regulator> requirements on AI use]"}}

> **Guidance:** Every confirmed fact appears in the draft, where it belongs: a named regulator or professional body goes in the sentence above, with its [TO CONFIRM] for that body's own rules. Every open fact appears as its [TO CONFIRM]. If the regulator isn't known, write [TO CONFIRM: regulator, if any]; delete the sentence only if there is none.

## 2. What we mean

- **AI tool:** software that generates text, images, audio, code or summaries, or that takes actions, in response to
  instructions.
- **Approved tool:** an AI tool on the approved list in section 4, used through the account named there.
- **Personal account:** an AI account you set up yourself, free or paid, that the organisation doesn't control.
- **Connector:** a link that lets an AI tool read from or act in another system, such as email, files or a calendar.
- **MCP (Model Context Protocol):** a standard way of connecting AI tools to other systems. A connection made this
  way is also called a connector; the program at the other end is an MCP server.
- **Agent:** an AI tool that can take steps on its own, such as sending, booking, deleting or paying.
- **Bot:** an AI tool that talks to clients, service users or the public for us, such as a chatbot on our website.
- **Guardrail:** a limit or check built into a tool or a process that holds whatever the AI is asked.
- **Personal data** and **special category data** have their meanings in UK data protection law. Special category
  data includes health, ethnicity, religion, trade union membership and biometric data.

## 3. Principles

1. **AI touches tasks; people carry outcomes.** Whoever uses AI for a piece of work is responsible for the result.
2. **Be open about it.** Say what AI did and what you checked. Using an approved tool well is never something to hide.
3. **Check in proportion to the stakes** (section 7).
4. **People decide about people** (section 9).

## 4. Approved tools and accounts (the trust check)

> **Guidance:** List a tool as approved only if the organisation has approved it. A tool people use that nobody has approved goes in as "<tool>: in use; [TO CONFIRM: whether <tool> is approved]".

The approved AI tools, and the accounts to use them through, are: {{approved tools, account type and approved uses,
or where the list is kept}}.

To ask for a new tool, contact {{who approves new tools}}. Before a tool is approved, we answer the **trust check**,
seven questions: who runs it; where our data is stored; whether it trains on our data; how long it's kept; which
terms apply; what it can reach and do; and whether our data protection lead would approve this use, for this data.

A tool nobody has assessed is not approved. While any of the seven questions is unanswered, use it for public
information only. *(default: change if you decide otherwise)*

AI built into a tool we already use (an AI feature added to our email, documents or other software) gets the trust
check too. We run the trust check again when a tool changes in a way that could change its answers: new features
such as memory, connectors or agents, a new model, new terms, or a new place where our data is stored. *(default: change if you decide otherwise)*

## 5. Personal accounts and devices

Don't put work information into a personal AI account, free or paid. *(default: change if you decide otherwise)* If
a personal tool is useful for your work, tell {{who approves new tools}} so we can assess it and, if it passes,
approve a work account.

## 6. What information goes where (the tramlines)

We sort information into three lanes before it goes into any AI tool:

> **Guidance:** Use the organisation's own examples. Where you use generic ones for now, label each "(generic example)". With EU staff, customers or personal data, add after the next paragraph: [TO CONFIRM: EU GDPR and <country> data protection law].

| Lane | What it means | Examples here |
|---|---|---|
| Green: go | Public or invented information, with nothing private in it; your own non-confidential work writing on an approved account | {{green examples}} |
| Amber: with care or approval | Internal information, on an approved tool, for an approved use | {{amber examples}} |
| Red: don't | Information that must not go into an AI tool unless {{data protection lead}} has approved that tool for exactly that use | {{red examples}} |

Client information, personal data and special category data are red until a data protection impact assessment
(DPIA) or {{data protection lead}} says otherwise. *(default: change if you decide otherwise)*

**Memory, projects and saved instructions** keep information from one chat to the next. Red information never goes
into them. *(default: change if you decide otherwise)* Whoever owns a shared project or saved instruction reviews what it holds when roles change or someone
leaves, and removes what is no longer needed. *(default: change if you decide otherwise)* On approved accounts, {{IT lead}} checks the memory and
training-on-your-data settings when the account is set up and at each review of this policy. *(default: change if you decide otherwise)*

Before you press Enter, take **three seconds**: Which account am I in? Would I be OK if this were read out? Can this
AI act, or only answer?

## 7. Checking in proportion to the stakes (the stakes ladder)

The higher the stakes, the harder you check. Ideas and first drafts need a read. Notes others rely on need checking
against what happened. Anything that goes out in your name or the organisation's needs every claim checked. Anything
about someone's care, money or rights needs each fact checked against its source.

A person reviews anything AI helped produce before it leaves the organisation. *(default: change if you decide
otherwise)*

**Pass up the conclusion, not the pile.** Don't share or forward AI output you haven't read and judged. Send what you
concluded, with the detail as supporting evidence. *(default: change if you decide otherwise)*

**Check sources one by one.** Before you rely on a citation, reference, quotation or figure that AI gave you, open
the source and check that it exists and says what the output claims. *(default: change if you decide otherwise)*

## 8. Being open about AI use

- Tell colleagues what AI did and what you checked when you share AI-assisted work.
- Tell {{clients / service users / customers}} when {{when we tell them, or [TO CONFIRM: when we tell clients about AI use]}}.
- **Meetings:** before AI records, transcribes or summarises a meeting, tell everyone in it. Whoever ran the meeting
  corrects the recap before it's sent. Transcripts are records that may contain personal data: keep them only as
  long as {{retention period}}.
- **Real people's images, voices and likenesses:** we use AI to create or change an image, a voice or a likeness of a
  real person only with that person's consent. *(default: change if you decide otherwise)*
- **Labelling:** AI-generated images, audio, video or text that we publish is labelled as AI-generated wherever
  readers could otherwise be misled. *(default: change if you decide otherwise)*

> **Guidance:** With EU staff, customers or personal data, add after the meetings point: [TO CONFIRM: EU GDPR and <country> data protection law].

## 9. Decisions about people

AI never makes, or in effect makes, a decision about a person on its own. *(default: change if you decide
otherwise)* This covers recruitment, performance, pay, promotion, discipline, dismissal, {{eligibility / care /
other decisions about people here}}.

Where AI helps with such a decision, a person with the knowledge and authority to overrule it reviews the case
properly, not as a formality, and records the reasons for the decision. We check AI-assisted decisions for unfair
effects on people with protected characteristics, and make reasonable adjustments, which may include AI tools as an
adjustment for disabled staff. *(default: change if you decide otherwise)*

UK rules on automated decisions changed on 5 February 2026. Our reviewer confirms whether and how they apply to us
before this policy is adopted. [TO CONFIRM: reviewer's view on automated decision rules]

## 10. Monitoring

> **Guidance:** Write "We do not monitor individual use of AI tools" only if it is true. Otherwise describe what you do, or write [TO CONFIRM: whether and how AI use is monitored].

{{What we collect about AI use, why, who sees it and how long it's kept}} Monitoring of AI use is never covert.
*(default: change if you decide otherwise)* We never use the amount someone uses AI as a target or a measure of
performance. If we monitor AI use, the monitoring is covered by our {{monitoring policy}} and assessed for a DPIA
first. *(default: change if you decide otherwise)*

{{EU sentence on prohibited practices, or delete}}

> **Guidance:** Only with EU staff, customers or output, the EU sentence reads, word for word: "The European Commission's AI Act page lists practices the EU AI Act prohibits (Article 5), such as using AI to infer people's emotions at work: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. [TO CONFIRM: whether any of our AI uses is affected by Article 5 of the EU AI Act]". Never write that the organisation does or doesn't use such practices unless that has been checked.

## 11. Intellectual property and confidentiality

Client and third-party material stays confidential: it is red unless an approved tool is approved for it. Check
AI output for copied text and for claims you can't support before you use it. {{Who owns work produced with AI help,
per existing terms}}.

## 12. Connectors and MCP servers (the lethal trifecta)

A connector lets an AI tool read from, or act in, another system. MCP (Model Context Protocol) is a standard way of
making these connections. For each connector and MCP server:

- Connectors stay off unless {{who approves new tools}} has approved them; we use only approved connectors and MCP
  servers, from known sources. *(default: change if you decide otherwise)*
- Connect read-only first, with the least access the task needs. *(default: change if you decide otherwise)*
- Third-party MCP servers, plugins and skills go through the trust check (section 4) before anyone connects them.
  *(default: change if you decide otherwise)*
- **The lethal trifecta.** A tool that can read private data, read outside content (emails, documents or web pages
  from other people) and send things out (by email, message, link or web request) needs explicit approval from
  {{who approves new tools}} and a guardrail that breaks one of the three (section 14). *(default: change if you decide otherwise)*
- Treat instructions hidden in emails, documents and web pages that an AI tool reads as a risk (prompt injection).
- Connector access is reviewed {{how often connector access is reviewed}}, and removed when someone leaves or a
  project ends. *(default: change if you decide otherwise)*

> **Guidance:** Write "Not applicable: we don't use bots or agents that act without a person" in section 13 only if the organisation said so. Otherwise keep the section and list the bots and agents in use or planned, or write [TO CONFIRM: bots and agents in use or planned].

## 13. Fully automated AI: bots and agents that act without a person (the control ladder)

This section covers chatbots and assistants that talk to clients, service users or the public, and agents and
scheduled or background tasks that act without a person approving each step. Ours are: {{each bot or agent, what
it does, its owner and its trust level}}.

- None goes live without approval by {{who approves bots and agents}}. *(default: change if you decide otherwise)*
- Each has a named owner, by role, who carries its outcomes: AI touches tasks; people carry outcomes. *(default: change if you decide otherwise)*
- Before it goes live, its owner writes down its scope: what it may do, what it may not do, which systems and
  information it may reach, and what it must hand to a person. *(default: change if you decide otherwise)*
- It starts on "draft and ask": it drafts or proposes, and a person approves before anything happens. The control
  ladder (read, draft, ask before acting, or never) sets its ceiling by what's at stake. *(default: change if you decide otherwise)*
- Its trust level on the trust scale is set at approval: how much of its work a person still checks. It starts on L-plates, where a
  person checks everything, and is raised only after its owner has reviewed a run of its work on that task. *(default: change if you decide otherwise)*
- There is a way to stop it at once, and its owner and {{who else can stop it}} know how. *(default: change if you decide otherwise)*
- It keeps a log of what it did, which its owner checks. *(default: change if you decide otherwise)*
- People are told when they are dealing with AI, and can always reach a person. *(default: change if you decide otherwise)*
- It never makes, or in effect makes, a decision about a person on its own (section 9). *(default: change if you decide otherwise)*
- Anything that can't be undone (money moving, records deleted, messages sent outside, changes to someone's care)
  keeps a person's approval, whatever its trust level. *(default: change if you decide otherwise)*

## 14. Guardrails (the layers of control)

A prompt can ask; code can make sure. We use the layers of control: a prompt asks; a skill shapes; a permission is
enforced; checks built into the process make sure.

- Rules that must always hold (a spending limit, what information may leave, who may be contacted) are enforced by
  permissions and checks built into the tool or the process, not left to instructions. *(default: change if you decide otherwise)*
- A bot, agent or connector that can spend, send or change records has limits set in the tool: spending limits,
  rate limits, blocked actions, and a person's approval for anything that can't be undone. *(default: change if you decide otherwise)*
- An approval counts only if the person approving can see what they're approving. *(default: change if you decide otherwise)*
- Guardrails are tested before go-live, and again after any change to the tool, its instructions or what it
  connects to. *(default: change if you decide otherwise)*
- The owner reviews what the guardrails caught {{how often guardrail logs are reviewed}}, and fixes the cause. *(default: change if you decide otherwise)*

## 15. Shared prompts, skills and agents

Every shared prompt, skill or agent has an owner, a version and a review date. *(default: change if you decide
otherwise)* The owner of shared AI tools is {{owner of shared skills}}. Use third-party skills and plugins only from
the approved list.

> **Guidance:** In section 16, put each point for the reviewer about suppliers' or clients' contracts in the gap list as a question.

## 16. Suppliers, contracts and AI terms (the trust check, when we buy)

When we buy or renew any software or service, {{who buys software}} asks whether it uses AI on our data, and runs the
trust check (section 4) on its AI features. *(default: change if you decide otherwise)*

We read the supplier's AI and data terms, and record the answers to these questions: *(default: change if you decide otherwise)*

- Does it train on our data, or let anyone else do so?
- How long does it keep our data, and what the AI produces?
- Which sub-processors see our data, and where is it stored?
- Who owns what the AI produces?
- Will it tell us, with notice, before it changes its models, its terms or where our data is stored?
- What does the contract say about liability for errors made by its AI?
- How are its connectors secured, and what can they reach?

Where personal data is involved, we get the supplier's data processing terms, and {{data protection lead}} reviews
them. *(default: change if you decide otherwise)* We run the trust check again at renewal, and whenever the supplier changes its terms, its model or where
our data is stored. *(default: change if you decide otherwise)*

When we tell our own clients that we use AI on their work, we first check what our contracts with them say about it.
*(default: change if you decide otherwise)*

> **Guidance:** Section 17's optional lines go in only if the organisation has decided its position, in its own words; otherwise delete them. Never write a position for it.

## 17. New ideas for AI (the 90-day test)

Anyone can suggest a new use of AI: tell {{who receives new ideas}}. *(default: change if you decide otherwise)*

Before a new use spreads beyond a small test, we run a 90-day test: a baseline (how the task is done now, how long
it takes and how often it goes wrong), controlled use on an approved tool, the cost per finished task, and a stop
rule agreed before it starts. At the end we scale it, change it or stop it. *(default: change if you decide otherwise)*

{{Optional: what the time AI saves is for, or delete}}

{{Optional: pace and wellbeing when working with AI, or delete}}

{{Optional: how we think about the energy AI uses, or delete}}

## 18. AI literacy and training


Everyone who uses an approved AI tool has {{training}} first, and we keep a record. *(default: change if you decide
otherwise)* {{EU sentence on AI literacy, or delete}}

> **Guidance:** Only with EU staff, customers or output, the EU sentence reads, word for word: "Article 4 of the EU AI Act, on AI literacy, may apply to us: https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers. [TO CONFIRM: whether Article 4 of the EU AI Act applies to us]". Never say it applies.

## 19. Reporting problems without blame

If something goes wrong with AI (wrong information sent, data put in the wrong place, a tool doing something
unexpected), tell {{reporting contact}} within one working day. *(default: change if you decide otherwise)* Honest
mistakes reported promptly are not disciplinary matters: we want to hear early so we can fix them. Concerns about wrongdoing can also be raised under our
{{whistleblowing policy}}. What happens after a report is in section 20.

## 20. AI incidents

An AI incident is anything where AI use goes wrong in a way that matters. For example: *(default: change if you decide otherwise)*

- wrong information sent out;
- information put into the wrong tool;
- a bot or agent doing something unexpected;
- a guardrail failing;
- a suspected prompt injection;
- a complaint about a decision AI helped with.

What happens:

1. Stop or pause the tool if you can, and tell {{reporting contact}} within one working day (section 19). *(default: change if you decide otherwise)*
2. Keep what happened (screenshots, logs, prompts and outputs), and don't share it beyond the people handling it.
   *(default: change if you decide otherwise)*
3. Our data protection lead ({{data protection lead}}) decides whether personal data is involved and whether anything
   must be reported. The ICO's page on personal data breaches:
   https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/
4. The owner of the tool fixes the cause, not just this output: fix the machine, then check the fix. *(default: change if you decide otherwise)*
5. We share the lesson without blame (section 19), and record the incident in {{where AI incidents are logged}}.
   *(default: change if you decide otherwise)*

> **Guidance:** Section 20 is the organisation's own procedure. It gives no legal time limit and never says whether anything must be reported: that is for the data protection lead. A past incident stays out of the policy (see the guidance in section 21).

## 21. Breaches

We distinguish a good-faith error from deliberate or reckless misuse. Deliberate misuse may be handled under our
{{disciplinary procedure}}. Nobody is disciplined for using AI before an approved route exists, and past use
reported at any time before this policy is adopted, including before this draft was written, is not a disciplinary
matter. *(default: change if you decide otherwise)*

> **Guidance:** If personal or confidential data may already have gone into an unapproved tool, this section doesn't describe it or say what to do: it goes in the gap list as [TO CONFIRM: lead's view on data already in <tool>].

## 22. Roles

| Role | Responsible for |
|---|---|
| {{Policy owner}} | This policy, its review and the approved list |
| {{Data protection lead or DPO}} | Data decisions, DPIAs, moving information between lanes |
| {{IT lead}} | Accounts, connectors, MCP servers, settings |
| {{Owner of each bot or agent}} | Its scope, trust level, log, guardrails and outcomes |
| {{Who buys software}} | The trust check on suppliers' AI terms, at purchase and renewal |
| {{Reporting contact}} | Receiving reports and starting the steps in section 20 |
| Managers | Making sure their team knows the policy and its one-page team rule |
| Everyone | Following the policy, checking their work, reporting problems |

## 23. Review and version history

This policy is reviewed within 90 days of adoption, then at least every 12 months, and whenever the law, regulator
guidance or our tools change. *(default: change if you decide otherwise)*

**Next review:** {{date, or "within 90 days of adoption"}}

| Version | Date | Change | Drafted by | Consulted |
|---|---|---|---|---|
| 0.1 | {{date}} | First draft | {{role of whoever drafted it}} | {{who was consulted, or "not yet"}} |

> **Guidance:** A redraft of an existing policy starts again at 0.1, whatever the old version; its Change column says "Redraft of <old policy's name and version>".

> **Guidance:** In "How staff were consulted", give the reasons for the consultation path only from confirmed facts: never "under 50 people" or "no union" just because that describes the usual light path. While nobody has said whether there is a recognised union or consultation agreement, say the path is provisional and add [TO CONFIRM: union or ICE agreement]; once that is answered, drop "provisional".

### How staff were consulted

{{The path taken and what changed, or:}} Not yet. Before adoption, staff see a one-page summary of this draft and
are asked what's unclear, what would stop them following it and what we've missed. They have two weeks to comment.
*(default: change if you decide otherwise)* We record what we changed, and why, in a "what we changed" log by role,
not by name.

> **Guidance:** Section 24 is optional. Include it only if the organisation asked to map to a framework. Head it "mapping, not certification".

## 24. Mapping to frameworks (optional; mapping, not certification)

{{If asked: a short table of which section supports which ISO/IEC 42001 clause or NIST AI RMF function. Otherwise
delete this section.}}

## Items to confirm before adoption

> **Guidance:** One flat list, no sub-headings. List every [TO CONFIRM] in the draft, word for word and once each, then every default taken, then every point for a lawyer, HR or the data protection officer (DPO). Each [TO CONFIRM] is a short phrase, eight words at most, on one line. Put each point for a reviewer as a question.

- [TO CONFIRM: reviewer's view on automated decision rules]
- {{other items to confirm, defaults taken and points for the reviewer}}

**Drafting and review notice** (keep this notice until the review below is complete)

This is an illustrative template from a training exercise, The AI Stairway™ AI policy skeleton, filled in by hand on [date] (drafting-ai-policy version 0.9.0, law pointers checked on 29 October 2026). It is a starting point for your organisation's own policy, based on the answers given: not a finished policy, and not legal, data protection, employment, HR or other professional advice. The exercise comes from The AI Stairway™, practical AI training for people at work, at https://aistairway.scorchsoft.com. If you and your team haven't taken it, it teaches the habits this policy asks of people. This draft may be incomplete or out of date, and it may not suit your organisation, sector or jurisdiction. Scorchsoft has not seen or reviewed it and accepts no responsibility for its use. Adopting it does not by itself make any use of AI lawful or compliant. Before anyone relies on it, a suitably qualified person must review it against your circumstances and the law in force, and resolve every item marked [TO CONFIRM].

Reviewed by: ________ Role and qualification: ________ Date: ________

Approved by: ________ Policy version: ________ Next review: ________
