The Article 4 AI Literacy Duty and the Evidence Behind It

Your organisation has rolled out an AI assistant to several hundred staff. It is not high-risk, it is not on any Annex III list, and your AI register — if you have one — records it as low-risk and closed. Then someone in finance pastes a supplier contract into it, someone in HR drafts a performance note with it, and a manager uses its summaries to decide which cases to escalate. None of them were told what the tool does badly, and none can tell you where its output came from.

That is the situation Article 4 of the EU AI Act addresses, and it is why the duty catches far more organisations than the high-risk regime does. Article 4 has applied since 2 February 2025 — earlier than most of the Act — and it does not depend on risk classification, sector or system size.

What Article 4 actually requires

Article 4 requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and other persons dealing with the operation and use of AI systems on their behalf. Those measures must take account of the people's technical knowledge, experience, education and training, the context of use, and the persons on whom the systems are used.

Two features of that wording do real work. First, "to their best extent" is a proportionality standard, not a fixed curriculum — a twelve-person consultancy and a 4,000-person insurer are not held to the same programme. Second, the duty is explicitly contextual: generic awareness training saying AI can hallucinate does not discharge it. The literacy must be about the systems those people operate and the people affected by them.

The Act's definition of AI literacy (Article 3(56)) frames it as the skills, knowledge and understanding that allow informed deployment and awareness of the opportunities, risks and possible harms of AI. The test is not whether staff attended a session; it is whether they can make a defensible decision about when to rely on a system and when not to.

Who the duty falls on

Article 4 binds both providers and deployers. That is unusual: most substantive obligations sit on providers, with deployers picking up a narrower set under Article 26. Article 4 is symmetrical, so a company that only buys and uses AI cannot point at its vendor.

The population covered is broader than your payroll. It reaches "staff and other persons dealing with the operation and use of AI systems on their behalf" — on a plain reading, contractors, agency workers, seconded staff and outsourced providers operating a system for you. If your claims triage runs at a BPO partner on a tool you selected, those operators are within scope of your duty, and you need a contractual mechanism to reach them.

Territorially, the duty follows Article 2: providers placing systems on the EU market wherever established, deployers established or located in the EU, and providers and deployers in third countries where the system's output is used in the EU. A UK-headquartered group with an EU subsidiary, or one whose AI-generated output lands with EU customers, is realistically in scope. There is no free-standing UK equivalent — the UK continues with a regulator-led, principles-based approach — but UK GDPR accountability, automated decision-making rules (being reformed by the Data (Use and Access) Act 2025, commencing in stages) and sector regulators' senior-manager expectations create a similar evidential demand.

When a deployer becomes a provider

Article 25 is the trap. A deployer, distributor, importer or other third party is treated as the provider of a high-risk AI system — picking up the full Article 16 obligations — where it puts its own name or trade mark on a high-risk system already on the market, makes a substantial modification to a high-risk system that keeps it high-risk, or modifies the intended purpose of a system (including a general-purpose AI system) so that it becomes high-risk. White-labelling a vendor's screening engine, or repurposing a general assistant into a shortlisting tool, crosses that line. Article 4 applies either way, but the literacy you must evidence deepens once you are the provider, because you now also owe risk management, data governance, technical documentation and post-market monitoring.

What "sufficient" looks like by role

Population	What they must be able to do	Evidence that shows it
General workforce with tool access	Recognise an AI system; know approved and prohibited uses, what not to input, how to escalate	Dated completions tied to named tool versions; acceptable-use acknowledgement
Operators of a specific system	Understand intended purpose, known limitations, error characteristics, when to override	Briefing mapped to the provider's instructions for use; competency check
Overseers of high-risk systems	Interpret output, detect automation bias, intervene and stop the system	Named individuals, authority recorded, oversight logged (Article 26(2))
Procurement, legal, risk, DPO	Classify systems, allocate provider or deployer roles, spot Article 25 triggers	Classification decisions with reasoning; vendor contract clauses
Contractors and outsourced operators	Same as the equivalent internal role	Contractual obligation plus attestation or shared records

The evidence behind the duty

Article 4 does not prescribe a record-keeping format, which is precisely why organisations struggle to prove compliance. Build the file you would want to hand over cold:

• An inventory of AI systems in use, each with intended purpose, provider, role classification and the population that operates it.
• A role-to-literacy map showing which population needs which competence, and why — your proportionality argument in writing.
• Versioned training content retained as issued, so you can show what a person was taught on a given date, not what the current module says.
• Dated completion and refresh records covering joiners, movers and contractors, with a trigger for re-training when a system materially changes.
• Competency evidence beyond attendance — scenario tests, sign-offs or supervised-use periods for higher-risk roles.
• Escalation and incident records showing people recognised problems and raised them. Nothing proves literacy better than a documented catch.
• Contractual coverage of third parties operating systems on your behalf, with a right to evidence.
• A governance minute naming the programme owner and the last review date.

How this is enforced, and what is still unsettled

Be precise here, because there is a lot of loose commentary. Article 4 is not among the provisions in the Act's up-to-3%-of-global-annual-turnover penalty tier, which covers specified provider, deployer, importer, distributor and transparency obligations; prohibited practices sit in a separate tier of up to 7%. Member States must set penalty rules for infringements the Act does not enumerate, so direct exposure for Article 4 depends on national implementing law, still emerging. The Commission's AI Office has published question-and-answer material and a repository of AI literacy practices; that is guidance, not law.

The practical teeth are indirect. Article 26(2) requires deployers of high-risk systems to assign human oversight to natural persons with the necessary competence, training and authority — and Article 26 does sit in the up-to-3% tier. A literacy failure that produces an unqualified overseer is therefore enforceable. Where the system processes personal data, inadequate training also feeds into accountability findings under UK and EU GDPR, whose top tier is up to 4% of global annual turnover.

Where this guidance stops

This is a general explanation of a fact-specific duty, not legal advice. Whether a system falls within the Act's scope, whether your role is provider or deployer, and whether a modification is "substantial" are legal determinations that turn on your contracts, configuration and intended purpose. National penalty regimes, Commission guidance and harmonised standards continue to develop, so some detail here may change. Take specialist advice before white-labelling or materially modifying a third-party system, before relying on a classification that keeps a people-affecting system outside the high-risk regime, and if a regulator, works council or affected individual has already raised a question.