EU AI Act Article 4: AI Literacy Obligations for Providers and Deployers

Article 4 of Regulation (EU) 2024/1689 has been in force since 2 February 2025. It is not a future obligation. If your organisation provides or deploys AI systems — any AI systems, not only high-risk ones — you are already subject to it.

The duty is deliberately open-textured: providers and deployers must take measures to ensure, to the best of their 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. The regulation ties that obligation to the technical knowledge, experience, education, and training of the people involved, the context in which the systems are used, and the persons and groups on whom those systems are used. In plain terms: proportionate, role-appropriate competence — not a fixed syllabus, not a certification, and not something that only bites once you deploy a high-risk system.

Before going further: Article 4 is not Article 10. Article 10 governs data and data governance for high-risk systems. Article 4 governs the competence of the people who operate and deploy AI. Old compliance guides conflate the two; that confusion is why so many organisations have the wrong obligation on their radar.

---

Who Is in Scope Under Article 4

The scope is broader than most organisations initially assume. Both providers (those who develop and place AI systems on the market or into service under their own name) and deployers (those who use AI systems under their authority in a professional context) carry the Article 4 duty. Competent authorities — the national enforcement bodies — carry it too, though that dimension is primarily a public-sector concern.

For most companies, the question is: do you provide AI systems, deploy them, or both? A software house shipping an AI-assisted contract analysis tool is a provider. A law firm that subscribes to that tool and uses it in client work is a deployer. A company that builds an internal CV-screening tool for its own HR team is both provider and deployer simultaneously. All three are in scope.

The phrase "other persons dealing with the operation and use of AI systems on their behalf" extends the duty beyond direct employees. Contractors, external operators, and third-party processors who have hands on the system need adequate literacy too. The obligation attaches to the function, not the employment contract.

---

What "Sufficient" Means in Practice

Article 4 sets no prescribed format, no mandatory certification, and no minimum training hours. That flexibility is intentional — a 10-person accounting firm deploying a basic invoice-processing tool faces a different proportionality analysis than a 500-person insurer deploying a credit-scoring model under Annex III.

The proportionality factors the regulation names are:

• Technical knowledge, experience, education, and training of the individual. A data scientist on the development team needs different literacy than a customer-service agent who receives the system's outputs.
• The context of use. A system used to generate customer newsletter copy sits in a different risk context than a system used to prioritise emergency-services dispatch.
• The persons and groups on whom the system is used. Where the system affects vulnerable populations — children, people with disabilities, people in financially precarious situations — the duty to ensure competence is correspondingly higher.

"Sufficient" does not mean "perfect" or "certified." It means the people operating or using the system on your behalf understand what the system does, what it cannot do reliably, when to question its outputs, and how to escalate concerns. A deployer who rolls out Microsoft Copilot across sixty employees without any preparation cannot satisfy Article 4. A deployer who runs a two-hour role-differentiated onboarding, documents it, and refreshes it annually almost certainly can.

A useful self-check before designing any programme is to ask three questions per system: who are the people who act on this system's outputs or decisions? What could go wrong if they misread or blindly trust those outputs? What would a reasonable senior compliance officer expect them to know before they sit at that console?

If you can answer those three questions with specifics — not generalities — you are in a position to design training that is genuinely proportionate rather than nominally compliant.

---

Article 4 Is Not a Certification Requirement

This is worth stating plainly because the market has filled the vacuum with certification schemes. There is no EU AI Act certification for AI literacy. Article 4 does not reference any specific qualification, credential, or audit standard. Paying a third party to issue a badge does not, by itself, constitute compliance — nor does completing a generic e-learning module that covers "AI ethics" in the abstract.

What the obligation actually requires is that organisations can demonstrate, concretely, that their people have the competence appropriate to their roles and the systems they are working with. That demonstration lives in records: training logs, session agendas, competency checks, refresh dates. The form is yours to choose; the substance is not.

One practical consequence: if a regulator or auditor asks you to demonstrate Article 4 compliance, the answer is not "we use a certified training provider." The answer is the records, the role mapping, and the documented judgment you made about what proportionate literacy looked like for your specific systems and people. The certification, if you chose to use one, is supporting evidence — not the substance of compliance itself.

---

What Article 4 Means for Providers Specifically

Much of the compliance conversation around Article 4 focuses on deployers, partly because deployer-side failures are the most visible — an employee acting blindly on a flawed output, a manager with no idea what the system they oversee actually does. But providers carry an equally important Article 4 obligation that runs in a different direction.

Providers must ensure that the people who build, train, evaluate, and maintain AI systems have the technical literacy appropriate to that role. This is not the same as deployer literacy. A developer at a company building a recruitment-screening tool needs to understand how training data biases propagate through model outputs, what the Article 9 risk management process requires of her specifically, and what Article 10's data governance standards mean for the datasets she works with. A product manager at the same company needs to understand the Article 6 classification logic well enough to flag when a new feature pushes the system toward a higher-risk classification.

This internal provider-side literacy is also the precondition for producing the Article 11 / Annex IV technical documentation that deployers rely on. If the development team does not understand what information a deployer needs to exercise oversight under Article 26, the documentation they produce will be incomplete — and the deployers downstream will be unable to train their own staff adequately. Article 4 failure at the provider level therefore propagates into Article 26 failures at the deployer level.

Providers who are also deployers — companies that build AI tools and use them internally — carry both dimensions simultaneously. The internal deployment team needs deployer-side literacy; the development team needs provider-side technical depth. These are distinct training tracks and should be designed separately.

---

The Relationship to Article 26 and Article 14

Article 4 is general — it applies to all AI systems regardless of risk tier. Two related provisions sharpen the obligation for high-risk systems.

Article 26 requires deployers of high-risk AI systems to ensure that the natural persons assigned to human-oversight tasks have the necessary competence, training, and authority to exercise that oversight. This is the deployer-specific operationalisation of Article 4 for the high-risk context: it is not enough to have documentation about the system; the people responsible for oversight must actually be capable of exercising it.

Article 14 — the human oversight requirement for high-risk systems — sets out what that oversight means in practice: the ability to understand the system's capacities and limitations, to interpret its output, and to decide not to use or override it. You cannot satisfy Article 14 with untrained staff. Article 4 is therefore the precondition for Article 14 to function.

The logical chain: Article 4 creates the baseline literacy duty for all systems; Article 26 focuses that duty on high-risk deployers; Article 14 sets the competence standard the assigned persons must meet.

---

Article 4 Versus Article 13: Two Distinct Obligations

Article 13 of the EU AI Act requires providers of high-risk AI systems to design their systems to be sufficiently transparent that deployers can understand how to use them appropriately, and to provide deployers with certain information — instructions for use, capabilities and limitations, performance metrics, human oversight measures, and expected lifespan.

The two articles address different problems. Article 13 is an information-supply obligation: the provider must produce and hand over specific documentation so that the deployer has what she needs. Article 4 is a competence obligation: the provider and the deployer must each ensure that the right people in their own organisations have actually absorbed enough understanding to do their jobs responsibly.

You can satisfy Article 13 perfectly — produce complete, accurate, well-structured documentation — and still breach Article 4 if your deployer staff never read it, or were never given the time or context to understand what it means for how they work. Conversely, you can have thoroughly trained staff who fail Article 13 because the documentation itself is inadequate.

This distinction matters for scoping compliance effort. Article 13 is a high-risk-system obligation; it does not apply to limited-risk or minimal-risk systems. Article 4 applies across all risk tiers. A company that deploys only minimal-risk tools — a text-autocomplete feature, a basic recommendation engine — still has an Article 4 obligation, and cannot satisfy it by pointing to Article 13 documentation that does not exist for those tools.

A useful way to frame the division: Article 13 governs what information flows between provider and deployer; Article 4 governs whether the people on each side have the competence to use that information. Both are necessary. Neither substitutes for the other.

---

Building a Proportionate AI Literacy Programme

There is no mandatory template. Below is a practical structure that maps well to how regulators will likely assess compliance.

Map your AI inventory to staff roles

You cannot design literacy training without knowing which systems you use and who touches them. Start with an inventory: what AI tools are in use, which teams operate them, and what decisions or outputs do those teams act on? This mapping exercise also feeds your Article 5/6 classification work — it is not duplicated effort.

Once you have the map, segment staff into three broad competence bands:

• Developers and technical staff who build, configure, or modify AI systems. They need depth: model behaviour, failure modes, data quality, and the technical Article 4/10/11 obligations.
• Operational users who receive and act on AI outputs (the HR manager who sees a CV-shortlist, the claims handler who sees a risk score). They need to understand what the output means, what it cannot tell them, and when to override.
• Decision-makers and governance staff responsible for approving AI deployment or monitoring compliance. They need enough to exercise meaningful oversight and ask the right questions of technical colleagues.

Design role-appropriate training content

Each band needs different content. Forcing the claims handler through a module on training-data governance wastes time and does not address her actual risk exposure. Giving the data scientist only a basic "what is AI" overview leaves him without the technical literacy the Act expects.

For operational users, the most important content is:

• What the specific system does and what it was trained to predict
• Known limitations and documented failure modes
• The organisation's escalation procedure if an output looks wrong
• Their legal right — and obligation — to question and override

For developers, add:

• How the EU AI Act's risk classification works (Articles 5, 6, Annex III)
• The data governance requirements of Article 10
• How the Article 9 risk management system works
• Their role in maintaining Annex IV technical documentation

Keep records

Article 4 creates a duty that, in any enforcement context, will be assessed against evidence. At minimum, keep:

• Training session date, attendees, and the material covered
• Who designed or delivered the content
• Any competency check conducted (a short scenario-based quiz, for instance)
• The date of the next scheduled refresh

Records do not need to be elaborate. A shared spreadsheet tied to HR onboarding records is workable for most companies. The point is to have something that shows the training was systematic, not ad hoc.

Build in refresh cycles

AI literacy is not static. The systems change, new use cases emerge, and regulatory guidance accumulates. A sensible refresh cadence is:

• Annual baseline refresh for all staff in scope.
• Triggered refresh whenever a new AI system is deployed, an existing system is substantially modified, or a material incident occurs.
• Ongoing awareness — a short update whenever relevant regulatory guidance or enforcement decisions are published.

Triggering a refresh after a substantial modification is especially important because substantial modification under Article 3(23) can change a system's risk classification, which in turn changes what competence is needed.

---

Worked Example: A 60-Person Company Rolling Out Copilot

Apex Advisory is a 60-person management consultancy. In March 2025 it rolled out Microsoft 365 Copilot across the firm for drafting, summarising client documents, and generating presentation slides. Apex is a deployer, not a provider. The underlying model is Microsoft's; Apex neither develops it nor puts its name on it.

Article 4 applies from the moment Apex gives staff access to the tool. Here is how a proportionate programme looks.

Apex divides its 60 employees into three groups. Senior partners (8 people) use Copilot to draft client-facing deliverables and need to understand the risk of factual errors, hallucination, and confidentiality exposure when feeding client data into the tool. Junior analysts (24 people) are heavy users for desk research and presentation drafts — they need the same risk basics plus Apex's specific policy on what data can be processed. Operations staff (28 people) use it lightly for scheduling and internal email — lighter coverage is proportionate.

Apex runs two sessions: a 90-minute role-differentiated online workshop (senior staff and analysts together, operations separately), followed by a short scenario quiz. The quiz is not a formal examination; it checks that staff can identify a situation requiring them to verify a Copilot output before client delivery. All completions are logged in the HR system with date and session ID.

Apex schedules an annual refresh. When Microsoft updates Copilot with new capabilities in late 2025, Apex pushes a 20-minute update module covering the changes and reminds staff of the escalation procedure.

Total investment: roughly four hours of staff time per person in year one, two hours per year thereafter. The output is a documented, auditable record that Apex took Article 4 seriously — which, in practice, is what a regulator would want to see.

---

Enforcement Posture and Practical Risk

Article 4 breaches do not carry a specific penalty tier of their own. Enforcement exposure comes primarily from two directions.

First, if an investigation into a high-risk system deployment reveals that staff had no adequate literacy, the Article 4 failure compounds the primary breach. A deployer that ran a biometric-attendance system without any training for the HR staff who relied on its outputs has a heavier compliance profile than one that ran the same system with documented training in place.

Second, Article 4 failures can surface in audits and market surveillance activities even for non-high-risk systems. The national competent authority does not need to find a high-risk system to examine whether you have taken your AI literacy obligations seriously.

The absence of a fixed fine for Article 4 alone is not an invitation to treat it as optional. It is a baseline obligation that regulators will read as a proxy for how seriously an organisation takes AI governance overall.

There is also a less obvious enforcement channel: employee complaints. Under Article 85 of the Act, Member States must ensure that workers and their representatives can raise concerns about AI systems without disadvantage. An employee who was given no training on a system and then suffered adverse consequences — a performance review driven by an output she was never taught to question — has a credible factual basis for a complaint to the national competent authority. Article 4 compliance, in that scenario, is also employment-risk management.

The current enforcement posture across EU Member States is still in its early phase. National competent authorities are building capacity, and the European AI Office is still establishing the governance apparatus around GPAI models. But Article 4 entered force sixteen months ago. When enforcement activity picks up — likely from 2026 onward as the general application date passes and more obligations come into scope — regulators will ask for records going back to February 2025. Documenting your literacy programme from the start is the only way to demonstrate a sustained obligation, not a last-minute one.

---

How Confir Supports Article 4 Compliance

Confir's compliance workflow includes a competence and training record alongside the system assessment. For each AI system in your inventory, you can log the staff roles in scope, the training provided, completion dates, and scheduled refresh cycles — creating the documented audit trail that Article 4 requires. The record sits alongside the Article 26 human-oversight assessment and the Article 27 Fundamental Rights Impact Assessment, so your literacy documentation connects directly to the oversight obligations that depend on it.

The engine is rule-based and deterministic: same intake, same finding, fully explainable. Starting from zero, the AI inventory step — registering each system with its risk tier and actor role — is also the natural foundation for mapping which staff need what level of training. Classification first, then training design: the workflow follows the logic the regulation intended.

---

The Three Things Article 4 Actually Asks Of You

Strip away the commentary, and Article 4 reduces to three requirements.

Know which of your staff and contractors deal with AI systems. Ensure they have competence appropriate to their role and the system's risk level. Keep evidence that you did it.

The Act does not tell you the format, the hours, or the syllabus. It trusts you — as provider or deployer — to make a proportionate judgment. That judgment, documented, is your compliance.

One watch item for 2026 and beyond: the European AI Office is expected to publish guidance and possibly common specifications on AI literacy as the Act matures. Track those publications. Where common specifications are adopted under Article 40, they create a presumption of conformity that simplifies your compliance position considerably.

---

Related guides

• EU AI Act compliance fundamentals
• SMB compliance requirements guide
• AI governance tools for Article 4
• AI system inventory documentation tools