Someone wants AI to tidy a customer email. Someone else wants it to read the whole shared drive. A policy that treats both requests as simply “using AI” won't help either person make a sensible decision.
Your staff need to know which tools they can use, what information they can share and where they must stop. Those answers should be easy to find during an ordinary working day.
The NCSC's September 2026 article on shadow AI makes a useful point: understanding why people use unapproved services helps an organisation offer safer alternatives. Start by asking what work your team is trying to finish.
Write around real requests
Ask a few colleagues for examples of tasks they'd like help with. Include someone handling customer enquiries, someone working with finances and someone responsible for staff information.
Then decide what is allowed for each task. Our suggested format is a short rule followed by an example:
“You can use the approved writing tool to improve public product descriptions. Check the result against the current product information before publishing.”
That gives someone a tool, a purpose, an information boundary and a check. “Use AI responsibly” gives them none of those.
Keep the policy alongside an up-to-date list of approved tools. Include the account or subscription that has been approved. Permission to use a business account shouldn't be read as permission to upload the same documents to a personal account with different settings.
Make the information rules specific
List examples from your own business. Staff are more likely to recognise “a spreadsheet of customer names and invoices” than an abstract reference to sensitive data.
As a practical starting point, distinguish between:
- Public information that the approved use genuinely needs.
- Internal material that needs permission before being shared with a service.
- Information that staff must keep out of that tool, such as passwords or access keys.
Personal information needs particular care. Don't assume that removing a name makes a document anonymous. A detailed complaint, job title, address or unusual set of circumstances may still identify someone.
The ICO's own internal AI policy is a useful example of an organisation setting approval rules for tools and information. It governs ICO staff. It isn't a template that automatically satisfies another business's legal duties.
Your rule should say who can authorise a new use involving customer or employee records and what they need to check. Until that assessment is complete, staff should use fictional examples or material already cleared for the task.
Decide who checks the result
A colleague who sends a quotation should check the figures against the price list. Someone who publishes a help article should open the sources and check that the instructions work. A person preparing an employment letter needs someone qualified to approve its substance.
Write these checks into the relevant work process. They are easier to follow there than in a long AI document that people read once.
Consider an imagined request to summarise a customer complaint. Your rule could require the handler to compare the summary with the original message before making a decision. Check that the summary preserves dates, requested remedies and anything the customer disputes. A neat paragraph can still leave out the point that matters most.
Explain what happens when checking takes longer than doing the task directly. Staff should be free to use the ordinary process. Approval to use AI isn't an instruction to use it for everything.
Separate suggestions from permission to act
Some tools can send messages, edit records or move files. Approval to draft an answer doesn't automatically authorise sending it, and access to a folder doesn't mean every connected service should receive that access.
The NCSC's August 2026 guidance on agentic AI recommends controls proportionate to the autonomy and possible consequences. It also warns against relying on prompts alone.
For a small business, a practical rule might be that a tool can prepare a refund recommendation while an authorised person makes the payment. Enforce that boundary through the available permissions and approval settings. Give someone responsibility for stopping the service if it behaves unexpectedly.
Keep an approval route for new connections. Adding access to an inbox, accounts package or shared drive changes what the tool can see and do, even if its name hasn't changed.
Explain how this fits the EU AI Act
First check whether your activities fall within the Act's scope. Having a workplace policy doesn't establish compliance, and being based in the UK doesn't by itself decide whether the Act applies.
For providers and deployers within scope, amended Article 4 requires measures supporting the development of AI literacy. The Commission's current explanation says the measures should reflect people's experience, the context and those affected. It doesn't require a particular level of literacy for each individual.
A policy gives people instructions they can refer to. They also need help applying those instructions. Use practical training exercises to test where your wording is unclear.
Give people a route for mistakes and exceptions
Name a contact for questions and accidental sharing. Tell staff to report the tool used, roughly when the incident happened and the type of information involved. Don't ask them to spread the sensitive content further while reporting it.
An exception request can be equally simple: what task, which tool, what information and what action? Give the requester an answer and record any conditions.
Review the policy when a tool gains a new capability or someone proposes a new purpose. Keep examples people actually recognise, remove rules that refer to retired tools and put the review date where colleagues can see it.