AI Literacy and What the EU AI Act Actually Requires

AI literacy is used loosely to mean knowing how to write a prompt. In the EU AI Act it is a defined term with a specific scope, and the difference matters if you are building a program against it.

Article 3(56) defines AI literacy as the skills, knowledge and understanding that allow providers, deployers and affected persons, taking into account their respective rights and obligations under the Regulation, to make an informed deployment of AI systems, as well as to gain awareness about the opportunities and risks of AI and possible harm it can cause.

Read that carefully and three things stand out. It is aimed at informed deployment, meaning decisions about use, not tool proficiency. It explicitly covers risks and possible harm, not just benefits. And it names affected persons alongside providers and deployers, so the people a system is used on are inside the concept.

Recital 20 gives the purpose: equipping people with the notions needed to make informed decisions about AI systems, and to enable democratic control.

Article 4 entered into application on 2 February 2025, in the first wave of the AI Act alongside the prohibited-practices rules. As originally enacted it read:

Providers and deployers of AI systems 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.

That is one sentence carrying a lot of structure. The duty is to ensure, qualified by to their best extent. The standard is a sufficient level, undefined and therefore contextual. And the closing clauses list the factors that determine what sufficient means in a given case, which turns out to be the most useful part of the article for anyone actually designing a program.

That wording has since changed, which is the next step.

In 2026 the EU adopted a package amending several digital laws, known as the Digital Omnibus. The European Parliament endorsed the AI component on 16 June 2026 and the Council gave final approval on 29 June 2026, with entry into force that July.

Article 4 was one of the provisions it reopened. The Commission's original proposal went furthest, removing the duty from providers and deployers and turning it into an encouragement addressed to the Commission and Member States. The co-legislators did not go that far. The adopted text keeps a duty on providers and deployers, but changes what the duty is.

Providers and deployers must now take appropriate measures to support the development of AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf, and it is made explicit that this does not require them to guarantee any specific or measurable level of AI literacy for any individual.

The Commission and Member States are separately required to support and facilitate this, including by publishing practical compliance examples.

The shift from ensure a sufficient level to support the development of is the distinction lawyers call an obligation of means versus an obligation of result, and it changes what compliance looks like.

Under an obligation of result, the question is whether the outcome was achieved: is your staff's literacy in fact sufficient? That invites assessment, thresholds, and an argument about what sufficient means, none of which the Act ever defined.

Under an obligation of effort, the question is whether you took appropriate measures. The outcome for any individual is not the test. What you did, and whether it was appropriate to your context, is.

The practical consequence is that a program is now evaluated on design and delivery rather than on demonstrated competence. That is easier to satisfy and harder to fake convincingly, because appropriate is still judged against the same contextual factors: the technical knowledge of the people involved, the context of use, and who the systems are used on.

It also means anyone selling certification as the route to compliance is selling something the Regulation does not ask for.

Two roles carry the duty, and most organizations are surprised to find they hold one.

A provider develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark.

A deployer, under Article 3(4), is any natural or legal person, public authority, agency or other body using an AI system under its authority, except where the use is a personal non-professional activity.

That second definition is broad on purpose. A logistics firm whose planners use an AI routing tool is a deployer. A law firm using an AI research assistant is a deployer. A school using an AI grading aid is a deployer. There is no technology-sector qualifier and no size threshold.

The covered population is also wider than employees. The article says staff and other persons dealing with the operation and use of AI systems on their behalf, which the Commission's guidance reads as reaching contractors, service providers and others operating under the organization's remit. If an outsourced team runs a system on your behalf, their literacy is inside your duty.

Two scoping questions get asked constantly, and the answers run in opposite directions.

Which AI systems? All of them. Article 4 is not limited to high-risk systems. The risk-tier machinery that governs most of the AI Act, prohibited practices, high-risk obligations, transparency duties, does not gate this provision. A general-purpose chat assistant used by the marketing team is in scope.

Which people? Not everyone. The duty attaches to those dealing with the operation and use of AI systems on the organization's behalf. An employee who never touches an AI system is outside it, though in practice that population shrinks every year as AI features appear inside ordinary software.

The combination is what makes this awkward to scope: broad on systems, narrower on people, and the people boundary is one most organizations cannot currently draw because they do not know which of their tools contain AI.

The AI Office published a questions and answers document on AI literacy, and several of its positions settle debates that otherwise consume a lot of meeting time.

There is no obligation to measure employees' AI knowledge. Testing is permitted, not required.

No certificates are required. Internal records of training initiatives are an acceptable way to show what you did.

Relying on the AI system's instructions for use, or asking staff to read them, is described as likely ineffective and insufficient on its own. Documentation is not a program.

What is appropriate depends on the target group's level and type of knowledge, and on the context and purpose of the systems in use. This is the Regulation pointing directly at role-based design.

The AI Office also maintains a living repository of AI literacy practices, collecting examples from organizations of different sizes and sectors. Usefully, the guidance is explicit that copying a practice from the repository does not automatically confer a presumption of compliance, which is a caution against treating any published template as a safe harbour.

Article 4 is unusual among AI Act provisions in that it is not backed by a penalty aimed at it.

Article 99 sets the penalty architecture in tiers: the highest, up to 35 million euros or 7 percent of worldwide annual turnover, applies to breaches of the Article 5 prohibited practices; a middle tier of up to 15 million euros or 3 percent covers non-compliance with most other obligations on providers and deployers; and a lower tier of up to 7.5 million euros or 1.5 percent covers supplying incorrect or misleading information to authorities. Article 99 does not name Article 4 among the provisions carrying a dedicated fine.

Supervision sits with national market surveillance authorities rather than the AI Office, and Member States were required to lay down their own penalty rules.

The honest reading is that AI literacy is not a provision designed to generate standalone fines. Its practical weight comes from elsewhere: a literacy failure is evidence in a proceeding about something else, and it is exactly the kind of organizational shortcoming that aggravates an incident involving a high-risk system. Marketing that quotes the 35 million euro figure next to AI literacy is misattributing a penalty that belongs to prohibited practices.

Article 4 became lighter. Several neighbouring obligations did not, and they are where training becomes a hard requirement rather than a supported development.

Article 26 places obligations on deployers of high-risk AI systems, including assigning human oversight to natural persons who have the necessary competence, training and authority. That is not an effort standard. If you deploy a high-risk system, the people overseeing it must actually be competent to do so.

Article 14 requires that high-risk systems be designed so they can be effectively overseen by natural persons, including enabling those persons to understand the system's capacities and limitations and to remain aware of automation bias, the tendency to over-rely on an automated output.

Article 50 transparency duties, such as informing people they are interacting with an AI system or marking synthetic content, also continue on their own timetable.

So the picture is layered. A general literacy duty of effort across all systems, and specific competence and oversight duties of result wherever high-risk systems are in play. A program built only against Article 4 will be insufficient for an organization operating high-risk systems.

If the obligation softened and carries no dedicated fine, the compliance-driven case for an AI literacy program is weaker than it was in 2025. It is worth being straightforward about that rather than pretending otherwise.

The case that survives does not depend on the Regulation.

Staff are already using AI systems, with or without a program, and the risks are concrete: confidential data pasted into external tools, fabricated outputs accepted because they read fluently, decisions about people made with more deference to a model than it has earned.

The factors Article 4 lists are a genuinely good design brief, independent of their legal force. Tailoring to technical knowledge, context of use, and the people affected is what makes training work, not merely what makes it compliant.

And the neighbouring duties in the previous step are unchanged, so any organization heading toward a high-risk deployment needs the capability regardless.

The honest framing is that the Regulation gives you a well-drafted specification and a weak enforcement threat. Build the program because the specification is sound, not because the threat is.