Is AI literacy training legally required?

For most organisations, effectively yes. The EU AI Act's Article 4 has required providers and deployers in scope to ensure a sufficient level of AI literacy among the people using AI on their behalf since 2 February 2025, and it is not limited to high-risk AI. If you are aligning to ISO 42001, clause 7.2 (competence) and 7.3 (awareness) require the same thing. There is no standalone UK law mandating a "training course", but between the AI Act, ISO 42001 and UK GDPR's accountability expectations, an organisation using AI on anything that touches people or their data needs to be able to show its people are equipped to use it responsibly.

What should an AI literacy programme cover?

At minimum, and proportionate to each role: what the tools can and cannot do, the real risks (inaccuracy and hallucination, bias, data leakage, over-reliance), your own AI policy and acceptable-use rules, where a human must stay in control, and when and how to escalate a concern. People who build or oversee higher-risk systems need more depth: risk classification, evaluation, monitoring and the specific obligations that attach to their systems. It is a level of competence proportionate to what someone actually does with AI, not one fixed course everyone sits.

Who needs AI training in an organisation?

Anyone who uses, builds, procures or oversees AI in the course of their work, which in practice is most of the organisation. The content should be role-based rather than uniform: general staff need safe, responsible everyday use; power users and builders need depth on risk, evaluation and oversight; leadership and the board need enough to set direction and accept risk knowingly. The literacy duty explicitly covers people operating or using AI "on your behalf", so it can reach contractors and outsourced staff too.

How often should AI literacy training be refreshed?

On a schedule and on change. Build it into onboarding so no one starts using AI untrained, refresh at planned intervals (annually is the common default), and trigger an ad-hoc update whenever something material changes: a new tool or capability, a new regulation or deadline, a new high-risk use, or an incident. AI and the rules around it move quickly, so a single point-in-time course is out of date within a quarter. The programme has to be a standing capability, not a one-off event.

How do you evidence AI literacy for an audit or regulator?

Keep records that connect people to competence: who was trained, on what, when, and to what level, mapped to their role and the AI they actually touch. Pair completion records with a light competence check (not just attendance), an acknowledgement of the AI policy, and a link to your training in the policy and management review. For ISO 42001 this is what clause 7.2 expects as evidence of competence; for the EU AI Act it is how you show you took measures to ensure literacy "to your best extent". Attendance alone is weak evidence; role-mapped competence is strong.

Is generic AI e-learning enough to meet the EU AI Act?

Usually not on its own. A generic, one-size course can be a component, but Article 4 asks for literacy that is sufficient and proportionate to the role, the context and the AI in use, and ISO 42001 expects competence tied to actual responsibilities. A single generic module with no role tailoring, no link to your own policy and tools, and no evidence of competence is the most common way organisations technically "do training" while meeting neither the spirit nor, arguably, the letter of the duty.

How to build an AI literacy programme that sticks

AI literacy is no longer an optional bit of staff development. It is a duty: the EU AI Act’s Article 4 has required it since 2 February 2025, and ISO 42001 expects it through its competence and awareness clauses. And yet the way most organisations meet it, a single generic e-learning module rolled out once and forgotten, changes almost nothing about how people actually use AI. The single most important thing to understand is this: AI literacy is a standing capability you maintain, not a course you run once. A programme that sticks is role-based, tied to your own policy and tools, evidenced, and refreshed as things change.

This post is how to build that programme: who needs what, what the content should actually be, how to prove it, and how to keep it from going stale.

Why “a programme”, not “a course”

A course is an event. A programme is a system. The distinction matters because the duty you are meeting is ongoing, and because the risk you are managing, people using powerful tools they do not fully understand, does not go away after a 45-minute module.

Treating literacy as a one-off fails on its own terms within a quarter: a new model ships, a new tool gets adopted, a new obligation lands, someone joins, and the training everyone “completed” no longer reflects reality. A programme, by contrast, has an owner, a role-based curriculum, a refresh cycle, and evidence. It behaves like the rest of your AI management system, because it is part of it.

The two duties that make it non-optional

You do not have to take literacy on trust as good practice. Two frameworks require it outright.

The EU AI Act, Article 4. If you operate in or sell into the EU, Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among their staff and anyone else using AI on their behalf. Three things make it easy to underestimate:

It has applied since 2 February 2025, well ahead of most of the high-risk obligations, so it is already live, not a future deadline.
It is not limited to high-risk AI. If you deploy AI of any kind in scope, the literacy duty attaches to the people using it.
It reaches people acting on your behalf, which can include contractors and outsourced staff, not just employees.

The heavier duties, the human-oversight, logging and transparency obligations for high-risk systems, land later (the bulk on 2 December 2027), but literacy is the one you owe now. We cover the article in depth in AI literacy: the EU AI Act’s Article 4 duty, in practice.

ISO 42001, clauses 7.2 and 7.3. If you are aligning to the AI management standard, competence is not optional either. Clause 7.2 requires you to determine the competence people need, ensure they have it, and retain evidence of it. Clause 7.3 requires awareness of the AI policy and of each person’s contribution to it. This is the same duty as Article 4, expressed as a management-system requirement, and it comes with an evidence bar attached.

The practical upshot: literacy is where two of the frameworks you are most likely to be measured against overlap. A programme built once, deliberately, satisfies both.

Start from your AI use, not a generic syllabus

The most common mistake is buying a generic “AI awareness” course and calling it done. It fails because literacy under both frameworks is meant to be proportionate to the role and the AI in use, and a generic course is proportionate to nobody.

Start instead from your AI system register and your risk classification. They already tell you what AI your organisation uses, who touches it, and how risky each system is. That is the raw material for a curriculum: map roles to the AI they actually use and the risk that carries, and the training writes its own brief. No register yet? Building one is the first move anyway, because you cannot train people responsibly on systems you have not catalogued.

Role-based tiers: what each group needs

Uniform training over-serves most people and under-serves the ones who need depth. Tier it. A workable structure for most organisations:

Tier	Who	What they need
Everyone	All staff who use AI at all	Safe, responsible everyday use: what the tools can and cannot do, the core risks, your acceptable-use rules, what never to paste in, when to check output and involve a human
Power users	Heavy day-to-day users, prompt-writers, automators	The above plus deeper risk awareness (bias, data flows, over-reliance), disclosure duties, and how to spot when a use has crossed into higher risk
Builders & product	People building, integrating or shipping AI	Evaluation, guardrails, monitoring, human oversight in practice, and the obligations that attach to what they build
Leadership & board	Executives, risk owners, directors	Enough to set direction, approve the policy, own the risk knowingly, and ask the right questions, covered in AI governance for the board
High-risk overseers	Anyone operating or overseeing a high-risk system	Role-specific competence for the system’s obligations: oversight, logging, incident handling, the lot

Most people sit in the first tier. The point of tiering is that the people carrying the most risk, builders and overseers, get training matched to it, instead of everyone getting the same shallow pass.

What actually changes behaviour: the core curriculum

Whatever the tier, the content that moves the needle is concrete and tied to your own rules, not abstract AI theory. The everyday-use core:

What the tools can and cannot do. Enough of a mental model to use them well and distrust them appropriately, without pretending everyone needs to understand transformers.
The real risks, named. Inaccuracy and hallucination, bias, data leakage, and over-reliance, with examples from work people actually do.
Your AI policy and acceptable use. The rules that apply here: what data may go into which class of tool, what is prohibited, and why. Train on your policy, not a generic one.
Human oversight and verification. AI output is a draft, not an authority; which decisions must keep a person in control, and how to check before acting.
When and how to escalate. The single most valuable behaviour: recognising a situation that is above your pay grade, a new high-risk use, a possible incident, and knowing exactly who to tell.
Disclosure. Where AI use has to be declared, including the AI Act’s transparency duties for chatbots and synthetic media.

Two design rules make this stick. Teach principles and data classes, not tool names, so the training does not break the moment a vendor changes. And make it practical: short, role-relevant, scenario-based, and connected to the actual tools people use, rather than a compliance video watched at 2x with the tab in the background.

Evidence it, or it did not happen

Both frameworks care about proof, and this is where one-off training fails hardest. You need records that connect people to competence, not just attendance:

Who was trained, on what, when, and to what level.
A role mapping: this person, in this role, touching this AI, received this training.
A light competence check, not just a completion tick, so you can show people actually got it.
An acknowledgement of the AI policy alongside the training.
A link from your policy and management review to the programme, so it is visibly governed.

For ISO 42001, clause 7.2 wants exactly this as evidence of competence. For the EU AI Act, it is how you demonstrate you took measures “to your best extent”. We will go deeper on evidencing in a follow-up post; the rule of thumb is that attendance is weak evidence and role-mapped competence is strong.

Keep it current: onboarding and refresh triggers

A programme that sticks is one that does not decay. Three mechanisms keep it live:

Onboarding. No one starts using AI untrained. Literacy is part of joining, not a thing that happens to people who were already here.
Scheduled refresh. A planned interval, annually is the common default, so the whole organisation resets to current.
Change triggers. An ad-hoc update whenever something material shifts: a new tool or capability, a new regulation or deadline, a new high-risk use, or an incident. The same triggers that should prompt a policy review should prompt a training update.

This is also how you keep shadow AI in check: people who understand the rules and have a sanctioned route to new tools are far less likely to route around you.

Common mistakes

A one-off course. Completed once, never refreshed, stale within a quarter.
Generic content. Not tied to your policy, your tools or your risks, so it meets neither the spirit nor arguably the letter of the duty.
No role mapping. Everyone gets the same shallow pass; the people carrying the most risk get the least relevant training.
Attendance as evidence. A completion tick with no competence check proves someone sat through a video, not that they can use AI responsibly.
Tool-specific training. Built around a named product, so it dates the moment the product changes.
No owner. Nobody maintains the curriculum, tracks completion, or updates it on change.
Leadership left out. The board approves the policy but never learns enough to own the risk, so governance has no informed top.

The minimum viable programme

If the full picture looks heavy, start where the leverage is. The smallest programme that genuinely satisfies the duty is: a short, practical core module for everyone built on your own policy and data-classification rules; a deeper add-on for builders and overseers; a named owner; completion and a light competence check recorded against role; and a refresh built into onboarding and triggered by change. That closes the gaps most organisations have, no role fit, no link to reality, no evidence, and gives you something you can stand behind with an auditor or regulator. Depth scales from there as your AI use grows.

The short version

AI literacy is a duty now, not a nicety: the EU AI Act’s Article 4 has required it since February 2025 and ISO 42001 expects it through clauses 7.2 and 7.3. The way to meet it is not a one-off course but a programme, role-based, built from your own register and risk classification, taught on your own policy and tools, evidenced against role, and refreshed on a schedule and on change. Do that and your people use AI responsibly and you can prove it. Roll out a generic module once and you have a completion certificate and none of the capability it is supposed to represent.

Want help designing a programme that fits your organisation and stands up to audit? See our AI literacy and training service, or get a quick read on where your wider governance stands with the free AI governance readiness assessment. For the full picture, start with the AI governance guide.