The AI Literacy Duty for Staff

Article 4 of the EU AI Act obliges providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf. It has applied since 2 February 2025, it applies to every AI system regardless of risk band, and it is the obligation most organisations are quietly in breach of.

What the obligation says

The wording matters because three qualifiers in it do real work. Providers and deployers “shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used”.

• “To their best extent” is a proportionality standard, not an absolute one. A ten-person company is not held to a bank’s programme.
• “Sufficient” is relative to role and context. The sufficient level for a recruiter using a screening tool is different from the sufficient level for the engineer who configured it.
• “Taking into account … and considering the persons on whom the systems are to be used” is the clause that makes generic training inadequate where the system affects people. If your system makes decisions about customers or candidates, the training has to reflect that.

The definition of AI literacy in Article 3 is broader than “knows how to write prompts”. It covers the skills, knowledge and understanding that allow deployers and affected persons to make an informed deployment, to gain awareness of the opportunities and risks, and to understand the possible harm the system can cause. Risk and harm are named in the definition; capability is not.

Who it binds, and who it reaches

It binds providers and deployers. Since almost every organisation using any AI system professionally is a deployer, and many are also providers without realising it, the practical answer is: nearly everyone.

It reaches further than employees. “Other persons dealing with the operation and use of AI systems on their behalf” covers contractors, agency staff and outsourced operators. If your customer service is run by a BPO using a model you provided, the people in that BPO are within the reach of your obligation.

It does not reach your customers or the public. Informing affected individuals is a different duty and lives in Article 26 and Article 50. Conflating them produces a training programme aimed at the wrong audience.

What it does not require

This section exists because the vendor market around Article 4 has moved faster than the text.

• No certification. The Act does not establish an AI literacy certificate, does not accredit training providers, and does not require an examination. Anyone selling “AI Act certified training” is selling their own certificate.
• No fixed number of hours. There is no minimum duration, no annual refresh requirement in the text, and no attendance threshold.
• No universal curriculum. The obligation is explicitly contextual. A single company-wide e-learning module delivered identically to everybody is arguably the one design the text argues against, because it ignores technical knowledge, experience and context.
• No separate register. There is no filing, no notification and no database entry for AI literacy.

How it is enforced

Article 4 sits in Chapter I, which is not among the provisions listed in the penalty article’s specific tiers. The consequence is that there is no headline fine attached to Article 4 on its own, and Member States set penalties for provisions where the Act does not.

That is not a reason to ignore it, for two reasons that are more practical than the fine would be. First, it is the cheapest thing for a market surveillance authority to ask about in an initial enquiry, and a blank answer sets the tone for everything that follows. Second, and more importantly, human oversight under Article 14 and the deployer duty to assign oversight to people with the necessary competence under Article 26 both depend on the oversight person actually understanding the system. A failure of literacy shows up as a failure of oversight, and the oversight failure is in the tier that carries the 3% ceiling.

A training outline that satisfies it

Three tiers, differentiated by role, because the text asks for differentiation. Total delivery for a mid-sized company is a couple of hours for most people and a day for the small group that needs it.

Tier 1 — everyone who touches an AI system (45–60 minutes)

• What the systems in use here actually are, listed by name. Not “AI” in the abstract — the four tools your staff open.
• What a language model does and does not do: it produces a likely continuation, not a retrieved fact. Confident and wrong is a normal output, not a malfunction. Link this to a real example from your own domain.
• The company’s rules on what may be pasted in, where outputs may be used unreviewed, and what must never go near a model. This is where your internal AI policy gets read by people rather than filed.
• How to report something that went wrong, and to whom, with the actual address.

Tier 2 — people who make decisions with AI output (2–3 hours)

• The specific system: its intended purpose as stated by the provider, its known limitations, and the populations it is less reliable on. The instructions for use are the source document.
• What meaningful human review looks like for this system, and what rubber-stamping looks like. Automation bias, named and illustrated, because it is the mechanism by which oversight becomes fictional.
• The authority to override and the authority to stop. Both must be real; oversight without the power to halt use is not oversight.
• The rights of the people affected: what you must tell them, and what they can ask for.

Tier 3 — builders, procurers and oversight owners (a day)

• The role determination: provider, deployer or both, per system, and the Article 25 traps that move it.
• Classification against Annex III and the Article 6(3) derogation, with your own systems as the worked examples.
• Evaluation and monitoring: how you would detect that the system had got worse, and what you log to make that possible.
• The interaction with data protection law — lawful basis, impact assessments, transfers — because in practice the two regimes are audited together.

The evidence to keep

Since there is no register and no certificate, the evidence is ordinary record-keeping. Four artefacts are enough:

1. The materials themselves, versioned and dated. Slide decks or written notes; whatever was actually delivered.
2. An attendance record per tier, with dates, so you can answer “who has had which training and when” without reconstructing it.
3. A short note on why the tiers are drawn where they are, referring to roles and systems. Two paragraphs. This is what shows you took technical knowledge and context into account rather than buying a module.
4. An onboarding hook, so a new joiner in a Tier 2 role gets Tier 2 content. A programme that only ever ran once is evidence of a project, not of a measure.

File these with the rest of the compliance evidence pack. They are the least expensive item in it and the one most likely to be asked for first.