Article 4 of the EU AI Act requires providers and deployers of AI systems to take measures to support the development of AI literacy among their staff and other people who operate or use AI systems on their behalf. Since the Digital Omnibus amended it in July 2026, the article says expressly that this does not require any specific level of literacy for any individual. Matching the measures to people's technical knowledge, experience and the context in which the system is used is still the sensible way to scope them. In practice that means role-based training, matched to what each person does with AI, plus a record that you did it. For teams running AI agents, the people who most need it are the ones who approve agent actions, configure guardrails and handle incidents.

This post covers what the article says, the status of its application date, what a proportionate programme looks like, and how to produce evidence without building a training bureaucracy. For the wider regulation, start with the EU AI Act explained for engineering teams.

What Article 4 actually says

The original text in Regulation (EU) 2024/1689 required providers and deployers to "take measures to ensure, to their best extent, a sufficient level of AI literacy". The Digital Omnibus, Regulation (EU) 2026/1744, replaced it. Providers and deployers now "shall take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf", and the new text adds that this "does not require providers or deployers to guarantee any specific level of AI literacy of any individual". Article 3(56) defines AI literacy as the skills, knowledge and understanding that let people make an informed deployment of AI systems and gain awareness of the opportunities, risks and possible harm AI can cause.

Three features of the wording shape the work:

  • It applies to every AI system, not only high-risk ones. A customer-support agent, an internal coding assistant and a high-risk hiring tool all fall in scope.
  • It binds deployers as well as providers. A company that uses a third-party agent platform still owes literacy measures to its own staff.
  • It is an obligation of effort. The amended text asks for measures that support literacy, not a guaranteed level, so the work scales with the risk and context of the systems people actually use.

When it applies, and what the Omnibus changed

Article 4 sits in Chapter I and has applied from 2 February 2025, together with the prohibited practices. The Omnibus did not postpone it. It was not part of the high-risk obligations that the Omnibus deferred to 2 December 2027 (Annex III) and 2 August 2028 (Annex I); our post on what the Digital Omnibus changed covers those dates.

The Commission's November 2025 Omnibus proposal had suggested moving the emphasis from a duty on providers and deployers towards the Commission and Member States promoting AI literacy. The adopted text did not go that far. The duty stays on providers and deployers in a softer form, and new paragraphs add Commission and Member State support, published practical examples and AI Board recommendations. Either way, staff who approve agent actions without understanding what the agent can do are an operational risk, and training them is cheap insurance.

What a proportionate programme looks like

The Commission's AI literacy questions and answers give the clearest working guidance. In summary:

  • No certificate or exam is required. The amended Article 4(1) also says the duty does not require any specific level of literacy for any individual.
  • Relying only on the system's instructions for use, or asking staff to read them, might be ineffective. The approach should be adapted to role and risk, reflecting the organisation's role (provider or deployer), the systems in use and their risks.
  • Keeping an internal record of training and other guidance measures is a reasonable way to show compliance.
  • People "dealing with the operation and use of AI systems on their behalf" can include contractors and service providers, not only employees.

Read the FAQ itself before you design a programme; it is guidance, not law, and it may be updated.

A role matrix for teams running AI agents

Agents raise the stakes because they act. A staff member who approves a refund an agent proposed, or who widens an agent's tool scope, is making a decision with real effect. Training should follow those decision rights.

Role What they do with agents Literacy they need Evidence to keep
All staff using AI tools Prompt assistants, read AI output What AI can get wrong, what data not to paste, how to report a problem Completion record of a short baseline module
Agent approvers Approve or reject actions an agent proposes The agent's purpose and limits, common failure modes, when to escalate Role-specific module, named list of approvers, date trained
Policy and guardrail authors Write rules that allow, block or redact Prompt injection, data leakage, how rules are evaluated Module record plus review of a first policy change
Agent owners and engineers Build, register and scope agents Least-privilege tool access, logging, testing, the regulation's risk tiers Module record, design review sign-off
Incident responders Contain and investigate agent incidents How to stop an agent, preserve logs, and assess harm Tabletop participation record
Executives and risk owners Accept residual risk Business impact, accountability, regulatory exposure Briefing attendance, decision log

The approver row is where most programmes fall short. Human oversight only works if the human understands what they are approving. A rubber-stamp approval is weak evidence of oversight and weak evidence of literacy.

The most useful single control is to make training a precondition for decision rights:

  1. Name the roles. Define who may approve agent actions, publish policies and onboard new agents. Your AI agent onboarding process is the natural place to record agent owners and approvers.
  2. Gate the role on the training. Grant approval rights only after the role module is complete, and review the list when training lapses or people move.
  3. Put the rules in writing. An AI agent acceptable use policy states what staff may and may not delegate to agents. Training should teach that policy, not a generic slide deck.
  4. Refresh on change. When an agent gains a new tool, data source or autonomy level, its approvers need a short update, and the record should show it.

This turns Article 4 from a box-ticking exercise into something that strengthens oversight. It also gives you an answer when someone asks why a particular person was allowed to approve a particular action.

Article 4 readiness checklist

Where Praesidia fits

Training is a people process; no platform completes it for you. Praesidia helps with the parts around it. It builds an inventory of the agents and MCP servers in use, which tells you which systems your literacy programme must cover. It routes high-impact agent actions to human-in-the-loop approvals, so you can see who actually approves what and compare that list with your training records. And it records those decisions in a signed, tamper-evident audit trail, so when a reviewer asks who approved an action, the answer is on record. Matching approvers to completed training stays in your HR or learning system.

FAQ

Is there a fine for not meeting Article 4?

Article 99 leaves penalties to Member States within the regulation's framework, and Article 4 is not among the infringements with a specific fine cap listed there. Enforcement sits with national authorities. A gap in literacy is also likely to surface in an investigation of another failure, such as poor human oversight.

Do we need external certification?

No. The Commission's FAQ says no certificate is required. Internal training, documented, is the expected baseline.

Does Article 4 apply if we only use third-party AI tools?

Yes, if you are a deployer of those systems. The duty covers the people who use them on your behalf, whoever built the tool.