Since 2 February 2025, Article 4 of the EU AI Act has required providers and deployers of AI systems to ensure a sufficient level of AI literacy among the staff who operate or use them, taking account of their technical knowledge, their role, and the context the systems are used in. It is the obligation most UK businesses have missed, because it reads as soft and arrived before the headline provisions. It is also the easiest to meet, and meeting it is what makes governed access to AI tools safe to open.
Who it covers
Any organisation that deploys AI systems in the EU, or whose systems affect people in the EU, which for a UK business means most manufacturers selling into Europe and most businesses with EU customers, suppliers or staff. “Deployer” is broad: a business whose staff use Copilot or Claude for work is deploying an AI system. The duty attaches to the staff who use it, not only to the people who build it.
What “sufficient” means
The Act does not prescribe a syllabus. It asks that literacy be proportionate to the role and the risk: a leadership team deciding on AI investment needs to understand what the technology can and cannot do; a customer-service team using an assistant needs to know when to check its output and how to escalate; an engineer building an agent needs the technical understanding to make it safe. One generic e-learning module for everyone does not meet the spirit of it, and regulators have said as much in guidance.
What meets it in practice
| Audience | What they need to understand | Format |
|---|---|---|
| Leadership | What AI is and is not, the four levels, the Opportunity Pyramid, the regulatory map, how to read an AI business case | A tailored awareness session, half or full day |
| Everyone with access to AI tools | The usage policy: what may be shared with which tool, how to check output, how to report a problem | A short mandatory session, the gate before access is opened |
| Functional teams | How to use the rolled-out tools on their own tasks, and where the tools are unreliable | Hands-on enablement per function |
| Engineers and builders | Retrieval, evaluation, confidence scoring, escalation, prompt-injection defence | Developer enablement |
| Roles near high-risk uses | The specific obligations: human oversight, documentation, transparency | Targeted training in scope |
Record who attended what and when. The record is the evidence, and it is also the thing most businesses cannot produce when asked.
Why it is the useful obligation
A trained workforce is the control that makes every other control work. Enterprise licences protect the data contractually; classification protects it technically; but it is the person who decides whether to paste the contract into the tool, and whether to check the answer before sending it to a customer. Literacy is where governance meets behaviour, and it is cheap: a day for leadership, an hour for everyone, half a day per function.
It is also the obligation that turns a blanket block into a defensible policy. “We opened governed access and trained everyone” is a position a regulator, an auditor or a customer can inspect. “We blocked it and hoped” is not, particularly when the staff are using personal accounts anyway.
The UK position
The UK has no equivalent statutory duty yet, but the ICO’s guidance on AI and data protection, the government’s AI assurance work and sector regulators all point the same way, and any business in scope of the EU Act is covered regardless. Treat Article 4 as the standard.
Sources: EU AI Act, Article 4 · ICO guidance on AI and data protection
The training formats are described under training and enablement; the governance model they sit inside is under AI governance and the EU AI Act.