Acceptable use: what staff may and must not do

Home › Acceptable use: what staff may and must not do

This is the part of the policy your staff will read most, so make the examples concrete and local, and keep the boundaries firm.

What staff may do

Set out the low-risk, genuinely helpful uses you want to encourage: drafting and adapting resources, summarising, planning, routine administrative writing. Always through approved tools and organisation accounts, and always with a person checking the output before it’s used.

What staff must not do

• Use AI tools that haven’t been approved, or try to get around filtering or monitoring to reach a blocked service.
• Enter personal or special-category data, meaning information about real, identifiable people, into an AI tool, unless it’s been approved for that specific purpose.
• Let AI make a decision about a person. In sensitive areas, even assistive use is prohibited unless it’s been expressly authorised, with a named person making and owning the decision.
• Pass off AI-generated material as their own unaided work where that would mislead, or break the JCQ rules on AI in assessments (which also rule out relying on AI as the sole marker of a student’s work).
• Upload third-party copyrighted or licensed material, such as published schemes of work, textbooks or exam papers, without the rights to do so.

Why it’s important

In my experience, by far the most common way personal data ends up in an AI tool isn’t a technical breach. It’s a well-meaning colleague pasting a name, a report or a case note into a chatbot to save a bit of time.

A common misconception makes this worse: that once a tool has been through a DPIA, personal names and details can go into it. That isn’t what approval means. A DPIA approves a tool for specific, defined processing — if entering personal data wasn’t part of that assessment, it isn’t approved, however safe the tool feels to use.

And the reasons for keeping personal information out go well beyond compliance. A name on its own can skew what a model produces: names carry signals about gender, ethnicity, religion and background, and outputs can shift with them — a difference in treatment nobody would accept from a member of staff, and no more acceptable from a tool. Then the data protection problems stack on top: once information about a real person is inside a tool you don’t control, you can’t reliably retrieve or delete it, you may have no lawful basis for putting it there, and the person it describes has no idea it’s happened.

So the working rule is simple, and worth teaching explicitly: no personal information goes in. Draft with initials, pseudonyms or placeholders, and add the personal detail after the output comes back. That’s why the rule on what goes in is the one boundary you shouldn’t soften locally — and why the high-risk prohibitions exist: these are the decisions where an automated shortcut can cause the biggest problems.