# EU AI Act AI Literacy: A Practical Training Plan for Professional Teams
> Article 4 has applied since 2 February 2025. A practical AI literacy programme for professional teams: role based tiers, content, evidence, and how to keep it current.
- Author: [Maximilian Betz](https://www.offgen.ai/en/authors/maximilian-betz)
- Published: 2026-08-26
- Updated: 2026-08-26
- Category: Security & EU Regulation
- Labels: Security & EU Regulation, Regulated Industries
- Canonical URL: https://www.offgen.ai/en/blog/eu-ai-act-ai-literacy-training-plan
> This article is for information only and does not constitute legal advice.
## Evidence for this article

This article supports its claims with 4 sources. Key sources include:

1. [Regulation (EU) 2024/1689 (Artificial Intelligence Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) (EUR-Lex)
2. [Regulation (EU) 2026/1744 (Digital Omnibus on AI)](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) (EUR-Lex)
3. [AI Act regulatory framework and implementation timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (European Commission)

[Full source list](#sources)
Article 4 of the EU AI Act requires providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among staff and other persons operating or using AI systems on their behalf, taking into account their technical knowledge, experience, education and training, the context of use, and the persons on whom the systems are used.

It has applied since 2 February 2025. It applies to deployers of any AI system, not only high risk ones.

That last sentence is where most internal guidance is still wrong. Organisations built their AI Act programme around the high risk timeline, then treated everything else as future work. Article 4 was already in force while that planning was happening.

<Callout title="Scope and legal review">
  This is operational guidance, not legal advice. Obligations depend on your role, the systems you deploy and your national context. AI Act counsel should review your programme and your documented reasoning.
</Callout>

## What the obligation actually says [#what-the-obligation-actually-says]

Three things are worth reading carefully in the text.

**"To their best extent."** This is a proportionality standard, not an absolute one. What is sufficient depends on your organisation, your systems and your risk. That is helpful, and it means your documented reasoning about proportionality matters as much as your completion rate.

**"Staff and other persons dealing with the operation and use of AI systems on their behalf."** Broader than employees. Contractors, temporary staff and, depending on the arrangement, some third parties operating systems for you.

**The listed factors.** Technical knowledge, experience, education and training, the context of use, and the persons on whom the systems are used. That last factor is the one people skip, and it matters: a system used on customers or employees deserves more literacy than one used on public market data.

The regulation names no specific measure. Training is one measure. Most organisations combine several, and the combination is what makes the programme proportionate rather than performative.

## Why this matters beyond compliance [#why-this-matters-beyond-compliance]

I want to make the practical case, because compliance driven training produces compliance driven attendance.

A reviewer who does not understand how a generative system fails cannot exercise meaningful oversight. They see a fluent, well formatted output and their instinct is to trust it, because everything in their professional experience says that polished work has been checked.

The characteristic failure of these systems is a statement that is plausible, consistent with the surrounding material, confidently expressed and unsupported. That is precisely the failure that human review exists to catch and precisely the failure that untrained review will miss.

So AI literacy is not primarily a compliance exercise. It is the thing that makes your human review gate function. If you were designing the control from scratch with no regulation at all, you would still need it.

## A four tier programme [#a-four-tier-programme]

Depth should scale with what a person actually does. Four tiers cover most organisations.

### Tier 1: baseline, for everyone who touches AI at work [#tier-1-baseline-for-everyone-who-touches-ai-at-work]

Two things to convey and no more, because a baseline that tries to teach everything teaches nothing.

**What these systems do and where they fail.** They generate plausible text. Plausible is not the same as true. They fill gaps confidently. They can be wrong in ways that read as correct.

**What our rules are.** Which tools are approved, for what data, what is never permitted, who to ask, and how to report a problem without it going badly for you.

Thirty to forty five minutes, refreshed annually and whenever the rules change. Everyone.

### Tier 2: users of approved systems [#tier-2-users-of-approved-systems]

For people using AI in their actual work, per system.

* What this specific system can and cannot do.
* What data may go in, in concrete terms rather than as a classification abstraction.
* How the system indicates uncertainty, and what gap markers mean.
* How to check output, with worked examples from your own domain.
* The failure modes you have actually seen in your organisation.
* Escalation and reporting.

Make this system specific, not generic. Generic AI training does not tell a proposal manager what to check in a generated credentials page.

### Tier 3: reviewers and approvers [#tier-3-reviewers-and-approvers]

The tier that matters most and gets the least attention.

* How this system produces output, in enough detail to reason about it.
* The specific failure modes and how they present, with real examples.
* Automation bias, named and explained, with the evidence that it affects competent professionals.
* What their review is responsible for, and what it is not.
* How to use provenance, change reports and gap markers.
* When to reject, and the reassurance that rejecting is a normal outcome.
* Their personal accountability for what they approve.

This should be substantial, involve real material, and include an exercise where the reviewer is given output containing a planted unsupported claim. People remember catching one far better than they remember being told to look.

### Tier 4: owners and governance [#tier-4-owners-and-governance]

For those who deploy, configure and govern systems.

* The regulatory framework and the current timeline, including what changed.
* Classification assessment: how to determine whether a system is high risk.
* Your obligations as a deployer in detail.
* The interaction with GDPR, and with sector rules where relevant.
* Vendor assessment and the documentation to obtain.
* Incident handling and reporting duties.
* How to keep the assessment current when systems evolve.

## The current timeline, stated precisely [#the-current-timeline-stated-precisely]

Your training content has to be current, and a lot of material written in 2025 is now wrong. As of 2026:

| Date            | What applies                                                                           |
| --------------- | -------------------------------------------------------------------------------------- |
| 2 February 2025 | Prohibited practices under Article 5, and the AI literacy obligation under Article 4   |
| 2 August 2025   | General purpose AI model obligations and governance rules                              |
| 2 August 2026   | General application of the AI Act, including transparency obligations under Article 50 |
| December 2026   | The additional prohibition introduced by the Digital Omnibus                           |
| 2 December 2027 | Obligations for Annex III high risk systems, deferred from 2 August 2026               |
| 2 August 2028   | Obligations for high risk systems embedded in products under Annex I                   |

The deferral came through Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July 2026.

Two points worth making explicitly in tier 4 training. First, the deferral moved a date and not a direction. Second, and more relevant day to day, nothing about the deferral touched Article 4 or Article 50, both of which are live now.

## Building the programme [#building-the-programme]

**Step 1: inventory your AI systems.** You cannot size literacy without knowing what is deployed. Include the systems people are using without approval, because those users need the baseline most urgently.

**Step 2: map people to systems and roles.** Who uses what, who reviews what, who owns what. This produces your tier assignment.

**Step 3: assess proportionality and write down the reasoning.** What is sufficient for a team using an approved drafting assistant on internal material differs from what is sufficient for a team using AI on customer decisions. Document the assessment. The reasoning is part of your compliance position.

**Step 4: build tier 1 first and ship it.** Wide coverage of the basics beats deep coverage of nothing. Get everyone to a common baseline quickly.

**Step 5: build tier 3 next, not tier 2.** This is counterintuitive and it is correct. Reviewers are your control. An untrained reviewer approving generated material is a bigger exposure than an untrained user producing it, because the user's work is supposed to be checked.

**Step 6: make tier 2 system specific.** Roll it out with each system rather than as a separate programme.

**Step 7: set the refresh triggers.** New system deployed. Existing system materially changed. Regulatory position moved. Periodic cycle otherwise.

## Evidence to keep [#evidence-to-keep]

<Checklist>
  * The inventory of AI systems in use, with owners.
  * The assessment of what is sufficient, and the reasoning behind it.
  * Tier definitions and the mapping of people to tiers.
  * Content delivered, with version and date.
  * Completion records by person and tier.
  * System specific instruction provided at deployment.
  * Refresh triggers and evidence they were acted on.
  * Review cycle for content currency, with dates.
  * Incidents and near misses, and what training changed as a result.
</Checklist>

That last item is the one that turns a programme from paperwork into something useful. When something goes wrong, the training should change. A programme that never changes is not learning from your organisation.

## Common failure modes [#common-failure-modes]

**Treating it as future work.** Article 4 has applied since February 2025. If your programme is scheduled around the December 2027 high risk date, you are two years late on the obligation that actually applies to you.

**One generic module for everyone.** A single course sized for the least technical audience gives reviewers nothing they can use, and reviewers are the control.

**Content that is already out of date.** Material describing the August 2026 high risk deadline is wrong. This area moves, and a programme without a currency review will drift within a year.

**Measuring completion rather than capability.** Ninety eight percent completion on a module nobody remembers is not literacy. Test whether reviewers can actually catch a planted unsupported claim.

**Ignoring shadow usage.** People using unapproved tools are outside your programme and at the highest risk. Bring them in rather than assuming a prohibition solved it.

## Where offgen fits [#where-offgen-fits]

Vendors have a role in supporting deployer literacy, and it is fair to ask what we provide. Our [trust center](/en/security/trust-center) and documentation describe how the system behaves, what it does when evidence is missing, how permissions are enforced and where the boundaries are. That is the raw material for tier 2 and tier 3 content about our system specifically.

Product behaviour also supports literacy directly. When a system marks gaps rather than filling them, keeps source references in the file and reports what it changed, reviewers learn the right habits by using it. A tool that hides its uncertainty teaches the opposite lesson.

The point I would leave you with: build tier 3 properly. Your reviewers are the control that everything else depends on, and a reviewer who does not know how the system fails is a control in name only.
## Frequently asked questions

### What does the EU AI Act require on AI literacy?

Article 4 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 persons operating or using AI systems on their behalf, taking into account technical knowledge, experience, education and training, the context of use, and the persons on whom the systems are used.

### Since when has the AI literacy obligation applied?

Since 2 February 2025, together with the prohibitions in Article 5. It applies to deployers of any AI system, not only to those using high risk systems, which is the point most internal guidance still gets wrong.

### Does AI literacy mean a mandatory training course?

The regulation names no specific measure. Training is one measure. Most organisations combine several, sized to their own assessment of staff, systems and affected persons: a general baseline, role specific depth, system specific instruction, and refreshers when systems or rules change.

### Who needs AI literacy training in a professional services firm?

Everyone who operates or uses an AI system on the organisation's behalf, which in practice means anyone using an approved AI tool at work. Depth should scale with role: users need enough to work safely, reviewers need to know how the system fails, and owners need to govern it.

### What evidence should you keep?

The assessment behind your approach, what was delivered to whom and when, the content covered, completion records, the system specific instruction provided, and the review cycle. Documented reasoning about proportionality matters as much as completion percentages.

### How often should AI literacy training be refreshed?

Whenever a new system is deployed, when an existing system's capability or configuration changes materially, when the regulatory position moves, and on a periodic cycle otherwise. This is a fast moving area, and content written in 2025 about high risk deadlines is already out of date after the Digital Omnibus.
## Sources

1. [Regulation (EU) 2024/1689 (Artificial Intelligence Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) — EUR-Lex, 2024-07-12; accessed 2026-08-26.
2. [Regulation (EU) 2026/1744 (Digital Omnibus on AI)](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) — EUR-Lex, 2026-07-24; accessed 2026-08-26.
3. [AI Act regulatory framework and implementation timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — European Commission; accessed 2026-08-26.
4. [Trust Center](https://www.offgen.ai/en/security/trust-center) — offgen; accessed 2026-08-26.
## Related articles

- [EU AI Act for Deployers: What Applies in 2026 and What Comes Later](https://www.offgen.ai/en/blog/eu-ai-act-deployer-checklist)
- [Human in the Loop Review for AI Generated Presentations](https://www.offgen.ai/en/blog/human-in-the-loop-ai-presentations)
- [AI Presentation Governance: A Practical Framework for Enterprise Teams](https://www.offgen.ai/en/blog/ai-presentation-governance-framework)