Article 4 has applied since 2 February 2025 and binds every provider and deployer of AI — not just high-risk ones. What the obligation covers and how to meet it.
An obligation that is already in force, and that almost everyone is in scope of
Article 4 is short, and that brevity is why it is routinely overlooked. It requires providers and deployers of AI systems to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other people dealing with the operation and use of AI systems on their behalf.
Three features make it unusual:
- It applies to all AI, not just high-risk. Almost every other substantive duty in the Regulation is gated on risk classification. This one is not.
- It has applied since 2 February 2025. While the high-risk obligations were deferred to 2027 and 2028 by the Digital Omnibus, Article 4 was not.
- It reaches beyond employees. "Persons dealing with the operation and use of AI systems on your behalf" pulls in contractors, agency staff and outsourced operators.
If your organisation uses a commercial AI assistant, a CV-screening tool or an AI feature embedded in existing software, you are a deployer and Article 4 binds you today.
What "sufficient" means
The Regulation does not define a syllabus. It defines the factors that make a level of literacy sufficient. Measures must take into account:
- the technical knowledge, experience, education and training of the people concerned
- the context in which the systems will be used
- the persons or groups of persons on whom the systems will be used
That last factor is the one most often missed. Literacy is calibrated partly by who is affected, not only by who operates. A tool that screens job applicants demands a higher standard than one that drafts internal meeting notes, even if the operator is the same person.
The recital gloss is that AI literacy should equip people to make informed deployment decisions and to understand the opportunities, risks and possible harms of AI — including how to interpret output, and when not to rely on it.
A workable interpretation
Because Article 4 sets an outcome rather than a curriculum, the defensible approach is role-based rather than universal.
| Group | What they need to be able to do |
|---|---|
| All staff | Recognise when they are interacting with an AI system, understand that output can be wrong or biased, know the internal rules on what may be entered into which tool |
| Operators / business users | Interpret output correctly, understand the system's limitations and intended purpose, know the escalation path when something looks wrong |
| Human oversight roles (Art. 14) | Understand the system's capacity and limits well enough to monitor it, detect anomalies and automation bias, and override or stop it |
| Procurement and legal | Distinguish provider from deployer duties, identify Annex III use cases, know what documentation to demand from vendors |
| Developers / data teams | Data governance duties, documentation requirements, logging, accuracy and robustness expectations |
| Executives | Accountability structure, risk appetite, penalty exposure, the classification of the organisation's own portfolio |
The link to human oversight
Article 4 is not a standalone compliance chore. It is the precondition for Article 14.
Human oversight for high-risk systems must be effective: the designated person has to be able to understand the system's capacities and limitations, remain aware of automation bias, correctly interpret output, and decide not to use the system or to override it. None of that is achievable by someone who has not been trained. In practice, a weak Article 4 programme converts directly into an Article 14 failure at the point where it matters most — and Article 14 does sit in the €15 million / 3% penalty tier.
Evidencing it
There is no certificate to obtain, so the evidence is your own record. A defensible file usually contains:
- An AI inventory — which systems are in use, by whom, in what role. This doubles as the starting point for high-risk classification.
- A role-to-competence mapping — the table above, adapted to your organisation.
- Delivered training records — dates, audiences, content, attendance.
- Internal usage rules — an acceptable-use policy covering what may be entered into which system, and what output may be relied on without review.
- A refresh cadence — the obligation is continuous, and the systems change.
- Contractor coverage — evidence that people acting on your behalf are included.
Common misreadings
"It only applies to high-risk systems." It does not. Article 4 sits in Chapter I, General Provisions, and is unqualified by risk category.
"We bought a tool, so it is the vendor's problem." The vendor is the provider and has its own Article 4 duty. Yours as deployer is separate and non-transferable.
"We will handle it with the 2027 high-risk work." The obligation has been enforceable since February 2025. Deferring it to the high-risk deadline leaves a gap of nearly three years on an obligation that is already live.
"One e-learning module for everyone is enough." Possibly, for a small organisation with a narrow AI footprint. But the statutory factors are role-, context- and impact-sensitive, so a single generic module is hard to defend where the footprint is broad.
Start from Article 4 itself, then work the compliance checklist to see how literacy connects to the rest of the obligation set.
Official AI Act Compliance Deadline Calendar
Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.
| Obligation | Applies to | Original date | New date | Status | Countdown | Legal basis |
|---|---|---|---|---|---|---|
| Prohibited Practices (Art. 5) | All providers and deployers | active | — | AI Act Art. 5 | ||
| GPAI Rules (Chapter 5) | GPAI model providers | active | — | AI Act Art. 51-56 | ||
| High-risk AI — Annex III (standalone) | Providers of standalone Annex III systems | deferred | — | AI Omnibus 2026 Art. 6(2) | ||
| High-risk AI — Annex I (embedded) | AI embedded in Annex I regulated products | deferred | — | AI Omnibus 2026 Art. 6(1) | ||
| AI-Generated Content Marking | Providers of generative GPAI systems | active | — | AI Act Art. 50(2) | ||
| Regulatory Sandboxes | National competent authorities | active | — | AI Act Art. 57 |
⬇ Download JSON · CC BY 4.0
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth — including what the AI Act adds on top of an existing DORA programme.
The AI Act for financial institutions ↗ Explore regulation-dora.eu ↗Frequently Asked Questions
Every provider and deployer of AI systems, regardless of risk category. Article 4 is not limited to high-risk AI. An organisation using a commercial chatbot is a deployer and is in scope.
2 February 2025, in the first wave of the AI Act alongside the Article 5 prohibitions. It is one of the few obligations already fully in force, and it was not deferred by the 2026 Digital Omnibus.
No. Article 4 sets an outcome, not a curriculum. There is no accredited certificate, no minimum number of hours, and no approved provider list. What matters is that the measures are appropriate to the roles, the context and the affected people.
There is no penalty tier attached specifically to Article 4 in the Article 99 list. But it is supervisable, it is evidence of the general standard of care, and human oversight under Article 14 is unachievable without it. Authorities can request evidence of the measures taken.
Stay ahead of AI Act changes
Get compliance alerts when deadlines or obligations change.
No spam. One-click unsubscribe.
Take compliance further with the AI Act Academy
Templates, training modules, and live Q&A — everything needed to implement AI Act compliance.