How to write an AI acceptable use policy for a regulated firm

An AI acceptable use policy is the document that tells employees how they may use artificial intelligence at work. In a regulated firm it does a second job: it is evidence that you have set clear expectations and organised your affairs responsibly.

Most firms now need one. This article sets out what it should cover and how to make it work in practice.

Why a dedicated AI policy

Your existing policies — information security, data protection, communications, conduct — already apply to AI. But they were not written with generative AI in mind, and staff rarely connect “information security policy” with “pasting a client letter into a chatbot”. A dedicated policy makes the connection explicit and gives you one place to update as tools change.

It also supports your obligations under SYSC 4.1, which requires robust governance arrangements and internal controls, and the individual conduct rules in COCON, which apply to most staff of SM&CR firms.

What the policy should cover

Scope

State who the policy applies to (employees, contractors, temporary staff) and what counts as AI. A practical definition covers generative AI tools, AI features inside existing software, browser extensions, and AI agents that can take actions.

Approved tools

List the AI tools that are approved for firm work, and say clearly that anything not on the list is not approved. Where approval is by role — for example, only advisers may use a tool for client-facing drafting — say so.

Permitted and prohibited uses

Give concrete examples rather than abstract principles:

• Generally permitted: drafting internal documents, summarising non-confidential material, research, coding help.
• Needs approval: financial promotions, client communications, anything that informs a decision about a customer.
• Not permitted: personal recommendations by people not authorised to give them, automated decisions about customers without approved controls, and any use that would breach your conduct or data rules.

Data rules

This is the section that prevents the most harm. Tie it to your data classification scheme:

• Which classifications may be used with which approved tools.
• That client identifiers, account and card numbers and other restricted data must never be entered into AI tools unless an approved control handles them.
• That confidential documents need extra care, and what “extra care” means.

Our article on protecting client data covers the controls behind these rules.

Accuracy and human review

AI output can be wrong, incomplete or invented. The policy should require people to check output before relying on it, and say which outputs must be reviewed by a second person. The FCA’s good practice publication warns against human review becoming a box-ticking exercise, so describe what a real review involves.

Agents and actions

If staff can use AI that takes actions — sending emails, updating systems, making payments — require documented human approval before any action, and say who can approve.

Reporting problems

Tell people how to report an AI incident or concern, including confidentially, and make clear that reporting a mistake is expected and supported.

Accountability and review

Name the policy owner and the senior manager accountable, set a review date, and say how changes are communicated.

Making the policy work

Keep it short

Aim for a document people can read in ten minutes. Put detail in guidance notes or training, not the policy itself.

Version it and record acknowledgements

Every version should have an effective date. Record each person’s acknowledgement against the version they read. When the policy changes, ask people to acknowledge the new version. This creates the record SYSC 9.1 expects you to keep.

Back it with controls

A policy that relies only on memory will be broken, usually by accident. Controls that apply automatically — approved models by role, sensitive-data detection, approval workflows — make the policy the default rather than a hope.

Test understanding

Training with short knowledge checks, followed by periodic attestations, shows that people understood the policy, not just clicked “accept”. Attestations should let people declare exceptions honestly. See AI training for staff.

Common mistakes

• Banning everything. A blanket ban without an approved alternative pushes use underground. See shadow AI.
• Copying a generic template. A policy written for a technology company will not reflect your client data, permissions or regulatory obligations.
• No owner. A policy without an accountable owner and review date goes stale quickly.
• No link to evidence. If you cannot show who acknowledged which version, the policy is hard to rely on.

How Dutira helps

Dutira’s policy library publishes versioned AI policies, records each person’s acknowledgement, and links policies to the rules applied to every AI request — so the policy and the control stay in step. See Policy & Control.