A practical structure for an AI policy covering permitted use, disclosure, data protection and malpractice, with a sensible review cycle.
A surprising number of FE providers still do not have a written AI policy, relying instead on informal guidance passed between staff or a single paragraph bolted onto an existing IT acceptable use policy. That gap is a genuine risk: without a clear policy, learners and staff are left guessing what is allowed, and any malpractice or data protection incident becomes much harder to handle fairly and consistently.
The good news is that a workable AI policy does not need to be long or technical. It needs to be clear, specific to your context and actually read by the people it applies to.
Why you need one even if AI feels "not relevant yet" to your provision
Even providers who have not actively introduced AI tools will have learners and staff using them anyway, often without saying so. A policy is not really about permitting or introducing AI, it is about setting expectations that already need setting.
Core sections to include
1. Purpose and scope
State plainly what the policy covers: staff use, learner use, which qualifications or provision it applies to, and how it fits with your existing policies on plagiarism, data protection and safeguarding. This stops it reading as a standalone document nobody connects to anything else.
2. Permitted use
Be specific rather than vague. "AI tools may be used to..." followed by a real list works better than a general statement of principle. For example:
- Generating drafts, outlines or ideas that are then substantially reworked by the learner or member of staff
- Explaining a concept or checking understanding
- Improving grammar and structure of the learner's own writing
- Accessibility support, such as text to speech or translation
And equally clearly, what is not permitted:
- Submitting AI-generated text as a learner's own unedited work without disclosure
- Using AI to complete assessed tasks that are meant to test independent ability, such as timed exams
- Uploading learner personal data or safeguarding information into public AI tools
3. Disclosure requirements
Set out exactly how and when learners and staff should declare AI use. Many providers now ask for a short declaration statement on submitted coursework, naming the tool used and describing what it was used for. This is only useful if learners know what counts as reportable, so give examples rather than leaving it open to interpretation.
4. Staff use of AI
Cover marking, feedback, lesson planning and administrative use separately from learner use, because the risks differ. Staff should know:
- Which tools (if any) have been approved by the organisation, ideally ones with an enterprise or education agreement that clarifies data handling
- That learner personal data, including full pieces of learner work with names attached, must not be pasted into public AI tools
- That AI-assisted marking still requires the assessor to check and take responsibility for the final decision, never to accept AI output as the grade itself
5. Data protection
This section deserves its own heading rather than being folded into "staff use", because it is where most real-world incidents happen. Key points to include:
- A reminder that most free AI tools may use submitted text to train future models, so nothing confidential or personal should go in
- Guidance on anonymising examples before using them in a prompt
- Reference to your organisation's data protection officer or lead for any questions about specific tools
- A note that safeguarding concerns must never be discussed with or summarised by an AI tool
6. Malpractice process
Link directly to your existing malpractice policy rather than duplicating it, but be explicit that undeclared AI use is treated as academic malpractice in the same way as plagiarism or collusion, in line with JCQ and awarding body guidance. Detail on running these investigations fairly is covered in AI and academic malpractice: how to spot and prevent AI written work.
7. Roles and responsibilities
Name who owns the policy, who staff should raise questions with, and who is responsible for keeping it updated. Without this, policies quietly go stale.
8. Review date
Set a review date no more than twelve months out. This area is moving fast enough that anything older than a year risks being out of step with current tools, awarding body guidance and staff practice.
A simple table to summarise expectations
| Area | Expectation |
|---|---|
| Drafting and ideas | Permitted with disclosure |
| Final assessed submission | Must be the learner's own work, edited from any AI draft |
| Learner personal data | Never entered into public AI tools |
| Marking and grading decisions | Human assessor makes and owns the final decision |
| Safeguarding information | Never processed through AI tools |
Getting staff and learner buy-in
A policy nobody has seen is not a policy. Build it into induction for both staff and learners, refer to it in assessment briefings, and put a short, plain-English summary on your VLE rather than only the full document. Training staff to apply the policy consistently, especially around disclosure and malpractice, works better through structured CPD than a single briefing email; see our qualifications and CPD courses for options that build this in.
Do not aim for permanence
Treat your first version as a working draft you expect to revise. The technology, the awarding body guidance and your own staff's practice will all shift over the next year, and What AI in education will look like in five years is worth reading alongside this if you want a sense of the direction things are heading before you lock in language that might date quickly.
A clear, honest, specific policy protects learners, staff and your provider's assessment integrity all at once, and it is one of the few AI-related tasks in FE that genuinely can be finished, at least until the next review date arrives.
Add this to your CPD log
Sign in to save what you've read - we'll create a free CPD log for you.