Article 4 of the EU AI Act asks providers and deployers of AI systems to ensure, to their best extent, a sufficient level of AI literacy among the people who operate and use those systems on their behalf. It has applied since 2 February 2025, and national authorities supervise and enforce it from 2 August 2026. For most organizations, a credible AI literacy program should include how AI assistants can be manipulated and how they leak data.

This post is for security, HR, and compliance leads in the EU who are deciding what AI literacy should actually mean in their organization. It is not legal advice. It summarizes the official sources, explains why AI security belongs in the picture, and sketches a practical, role-based program.

What the law actually says

The AI Act is Regulation (EU) 2024/1689. Two provisions matter here.

Article 3(56) defines AI literacy as the skills, knowledge, and understanding that let providers, deployers, and affected persons make informed use of AI systems, and gain awareness of the opportunities and risks of AI and the possible harm it can cause.

Article 4 puts the duty on providers and deployers. They must take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other persons dealing with the operation and use of AI systems on their behalf. The article asks you to take into account people’s technical knowledge, experience, education and training, the context the AI systems are used in, and the people or groups the systems are used on.

A few points from the European Commission’s AI literacy Q&A are worth knowing:

  • “Deployer” is broad. An organization using an AI system in a professional capacity is typically a deployer. If your staff use a general-purpose assistant for work, Article 4 is likely relevant to you.
  • There is no one-size-fits-all format. The Commission does not prescribe a specific course, number of hours, or certificate. What is “sufficient” depends on the systems, the roles, and the risks.
  • Records help. The Commission indicates that a certificate is not required, and that organizations can keep internal records of the measures they take.
  • Timing. The obligation has applied since 2 February 2025. The Q&A explains that supervision and enforcement by national market surveillance authorities starts from 2 August 2026.

The text may change

EU rules on AI are still moving. The Commission’s Digital Omnibus proposals, published in late 2025, include changes affecting the AI Act, and some of them touch how the AI literacy duty is framed. Proposals are not law until adopted. Before you build a program around specific wording, check the current consolidated text on EUR-Lex and the latest Commission guidance, and confirm your interpretation with your legal advisers.

What no training can promise

No course, workshop, or platform makes an organization “compliant” with the AI Act. Article 4 asks for measures suited to your context, taken to your best extent. Training is one such measure. Anyone selling a certificate as a compliance guarantee is overselling, and that includes us.

Why security belongs in AI literacy

Many AI literacy programs focus on what AI is, how to write a good prompt, bias, and responsible use. All useful. But the definition in Article 3(56) explicitly includes awareness of the risks of AI and the harm it can cause. For an organization that has rolled out assistants and agents, the most practical risks are often security ones.

Here are two that staff meet every day, whether they know it or not.

Prompt injection

An AI assistant reads text and follows instructions. It cannot reliably tell your instructions apart from instructions hidden in the content it reads. A supplier’s PDF, a web page, an email, or a shared document can carry text that steers the assistant: summarize this and also forward the attachment, approve this request, ignore the policy. The OWASP GenAI Security Project ranks prompt injection as the top risk for LLM applications.

Picture Aldermoor Logistics, a fictional EU freight company. A procurement officer asks the company’s assistant to summarize incoming supplier offers. One offer contains hidden text telling the assistant to describe it as “pre-approved by finance.” The summary says exactly that. Nobody was hacked in the traditional sense. The assistant was simply persuaded.

The Indirect Prompt Injection lesson explains the mechanics. The point for literacy is simpler: AI output can be manipulated by content the user never wrote, so treat it as a draft, not a verdict.

Nobody was hacked; the assistant was persuaded
Supplier
Offer PDF
Company assistant
Procurement officer

Procurement officer to Company assistant: "Summarize incoming offers"

Company assistant to Offer PDF: read

Company assistant to Procurement officer: Leaked"Pre-approved by finance"

treat AI output as a draft, not a verdict

Data leakage through assistants

Staff paste contracts, customer records, and source code into AI tools to get work done. Two things can go wrong. The data may go somewhere it should not, such as an unapproved consumer tool. And an assistant connected to company systems may surface data to someone who should not see it, because a user claimed a role or because the assistant was given broader access than any single person needs.

People who understand these failure modes make better decisions: which tool to use, what to paste, when to double-check, and when to report something odd.

Where this meets other AI Act duties

For high-risk systems the AI Act goes further. Article 15 requires appropriate accuracy, robustness, and cybersecurity, including resilience against attempts to alter a system’s use or outputs by exploiting vulnerabilities. Article 26 asks deployers to assign human oversight to people with the necessary competence, training, and authority. Human oversight means little if the overseer does not know an AI system can be manipulated by its inputs. Even outside high-risk use cases, security awareness is where literacy turns into fewer incidents.

What a practical program looks like, by role

The Commission’s guidance points toward a risk-based, role-based approach. Here is one way to apply that to AI security. Adjust it to the systems you actually run.

Everyone who uses AI at work

  • What the approved AI tools are, and what data may go into each.
  • That AI output can be wrong, confidently.
  • That content the assistant reads can contain hidden instructions, so summaries of external documents deserve a second look before acting.
  • How to report a suspicious AI behavior, and that reporting is welcome.

Time needed: one short session plus a one-page reminder. A hands-on exercise works far better than slides for this group.

Managers and approvers

Everything above, plus:

  • Never treat an AI-generated summary or recommendation as authorization. Approvals still go through the normal process.
  • Know which decisions in your area use AI, and who oversees them.

These teams handle sensitive data and often use assistants connected to it. Add:

  • Why “the assistant will refuse” is not a control. A confident request can talk a model into sharing what it should not.
  • What realistic attacks look like in your own workflows: a fake auditor, a planted instruction in a CV or invoice, a request that escalates slowly. Narrative-Based and Crescendo attacks are good examples.

Developers, product owners, and IT

The people who build and configure AI systems need depth:

  • Prompt injection, direct and indirect, and why it cannot be fully fixed in the prompt.
  • Least-privilege tools, authorization outside the model, output handling, and human approval for risky actions. Our defense checklist covers these.
  • Agent and tool risks, including tool poisoning in MCP.
  • Testing: building an attack regression suite and red-teaming before release.

Security and compliance leads

  • Map which AI systems you provide or deploy, and who uses them.
  • Decide what “sufficient” means for each group, write it down, and review it as systems change.
  • Keep records of what was delivered, to whom, and why that level was chosen.
  • Track changes in the AI Act text and Commission guidance.

Where a hands-on session fits

Most security awareness fails because it is abstract. A slide that says “AI can be manipulated” does not change behavior. Watching a colleague talk a realistic HR assistant into revealing an executive’s salary in three messages does.

A live, hands-on session is a strong fit for the “everyone” and “sensitive teams” tiers above. People try to trick fictional AI apps, see which tricks work, and then discuss which control would have stopped them. The debrief is where literacy happens: what did the model treat as authority, what data could it reach, and what should the process have checked? Our guide to running an AI security awareness session covers the format.

Hands-on sessions are a complement, not a whole program. They work best alongside clear tool policies, role-specific guidance, and records of what was delivered.

Getting started

  1. Read Article 4 and the Commission’s Q&A yourself. They are short.
  2. List the AI systems your organization provides or deploys, and the roles that use them.
  3. Decide what each role needs to know, with AI security included, and record your reasoning.
  4. Give people an experience, not just a policy: one session where they see an AI system manipulated.
  5. Revisit the program when your tools change or the law does.

For a self-paced starting point, the free prompt injection course covers the core attacks in six short lessons. To run a live exercise for your teams, see how to host a session.