AI literacy under the AI Act: is one annual training session enough?

The company runs an hour-long webinar on generative AI. Staff learn that models can invent facts, confidential data needs protection and answers should be checked. Everyone receives a certificate.

That can be a useful introduction. It does not tell a developer how to review an agent’s actions, a recruiter how to question a candidate ranking or support staff which customer information may enter an approved tool.

AI literacy should follow the systems, roles and risks in the organisation. Article 4 does not prescribe one annual course or an identical programme for everyone. A certificate records attendance; it cannot by itself show that someone knows how to use a particular system appropriately.

This EU-wide analysis reflects the legislation and official guidance checked on 1 October 2026, including the adopted Digital Omnibus on AI.

What you will learn

In brief

• Amended Article 4 requires measures supporting AI literacy, fitted to people and use context.
• An annual webinar can contribute, but neither a yearly course nor a certificate is prescribed.
• Keep legal duties separate from guidance and proportionate internal evidence.

Current law: Article 4 after the Digital Omnibus

The original AI literacy provision began applying on 2 February 2025. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published on 24 July 2026 and entered into force on 27 July 2026. It is adopted and published law, rather than the November 2025 proposal or an intermediate political agreement.

Amended Article 4 requires providers and deployers to take measures supporting the development of AI literacy among staff and other people operating or using AI systems on their behalf. The measures must take account of technical knowledge, experience, education, training, the use context and the people or groups affected.

The revised wording does not require a guaranteed, fixed level of individual competence. It retains an organisational obligation to take measures. It also provides for Commission and Member State support, particularly for SMEs.

Use the enacted provision for the legal duty. Some official explanatory material retains references to earlier wording or the original proposal. Those passages should not displace the amendment now in force.

Keep three layers separate

The legal requirement: take context-sensitive measures supporting the literacy of people operating or using systems on the organisation’s behalf. Article 4 does not establish a universal training schedule, prescribed certificate or standalone AI Officer position.

Commission guidance: the AI literacy Q&A discusses understanding the systems, organisational roles, risk and differences between users. It says a certificate and specific governance structure are not required. This is interpretative guidance, not another regulation.

Prudent practice: keep a tool inventory, assign an owner, retain useful records and review instructions after changes. These help the programme work and explain the decisions taken. They are not presented here as a mandatory Article 4 documentation template.

Separate system-specific requirements too. High-risk AI can bring additional obligations concerning human oversight and the people assigned to it. General literacy training does not substitute for those requirements when applicable.

Start with the systems people actually use

Map approved tools, embedded AI features, API integrations and informal use. For each, identify the task, users, data, output, affected people and the point at which somebody relies on the result.

The organisation may be a deployer using someone else’s system or a provider developing and supplying its own. An integration, changed purpose or substantial modification can require closer role analysis. Our provider and deployer guide explains that distinction.

Include people acting on the company’s behalf beyond employees where relevant: contractors, administrators, moderators, support agents and those approving AI-assisted decisions. Identify customer personnel separately where they operate the delivered system; their organisation’s role and responsibilities also need to be clear.

If half the tools are missing from the inventory, training based only on approved tools will leave gaps. Start with our Shadow AI governance approach to understand what is being used.

What should a basic user understand?

A marketing employee improving a draft does not need to study model architecture. They need instructions they can apply while doing the task:

• Which tool and account are approved for the purpose.
• Which data may be entered and which must stay out.
• Why fluent output can be incorrect or misleading.
• How to verify facts, sources and customer-facing claims.
• Who reviews a result before publication or another consequential use.
• Where to ask questions or report a problem.

Use examples from the actual workflow. Ask the employee to check an invented product claim or identify personal data in a proposed prompt. That gives more useful feedback than asking whether they remember an abstract definition of AI.

Where disclosure or other legal obligations apply to particular content, include the relevant instruction. Do not teach that every AI-assisted email automatically needs a legal label.

Technical teams need a different module

Developers connecting a model or building an agent need to understand data flows, logging, vendor terms, model changes and permissions. A prompting course will not explain why a tool can access a production system or how to roll back a faulty action.

A practical workshop can cover:

• Input and output handling, secrets and API keys.
• Allowed tools, scopes and approval boundaries.
• Model limitations, prompt injection and relevant testing.
• Logging, retention and supplier changes.
• Evaluation of quality, bias and failure cases for the intended use.
• Monitoring, escalation, rollback and provider exit.

Have the team walk through one real integration. Ask what happens if the model confuses two customer accounts, if a retrieved document contains hostile instructions, or if the provider changes retention settings.

Link the instructions to the AI vendor and GDPR review. Literacy and supplier assessment should give consistent answers about data and permitted uses.

Human oversight needs more than an approve button

A person reviewing an AI recommendation needs to know what the system assesses, what information it lacks and which errors testing has revealed. They also need authority and a workable route to question, override or stop the process.

For a candidate-ranking workflow, discuss the consequences of a mistaken result, the limitations of the underlying data and when the reviewer must seek additional information. If the reviewer accepts every recommendation because they believe the model sees the complete picture, their presence does not establish meaningful control.

For high-risk systems, assess the applicable oversight and deployer requirements separately under the AI Act. A general literacy programme cannot be used to declare those additional duties completed.

Does the company need an AI Officer?

Article 4 does not require that title or a special committee. Still, assign somebody to maintain the tool map, coordinate role-specific instructions and notice when the programme needs updating.

A small team might use a product owner or security manager with legal and HR support. In a larger organisation, several teams may share the work. If a data protection officer is involved, assess responsibilities and potential conflicts rather than combine roles automatically.

The useful question is who notices that the training describes a tool removed six months ago, or that a formerly read-only assistant now writes to customer accounts. Governance should answer that without requiring an elaborate new department.

Keep evidence that helps explain the programme

An attendance list can show who attended. It cannot explain why a developer and recruiter received identical instructions despite different risks.

As a proportionate practice, retain the tool and role map, the reasons for the selected measures, material versions, dates, intended audiences and questions or incidents that led to changes. Record instructions provided to external collaborators where relevant.

Do not turn that recommendation into an invented legal requirement for a certificate, yearly exam or standard compliance binder. Choose records that let the company explain what it did and improve the next iteration.

Model case: one course for a 45-person SaaS company

A hypothetical SaaS company has 45 staff. Marketing uses text generation, support uses suggested replies and developers deploy an agent analysing customer tickets. Everyone attends the same safe-prompting webinar.

Two months later, marketing publishes an unchecked factual claim, support pastes personal data into the wrong tool, a developer misses a change to vendor log retention and a reviewer approves a faulty agent action because they assume it has the full customer history.

The certificates do not address those failures. A better programme would combine a shared introduction with short marketing and support instructions, a technical workshop, an agent escalation procedure and a trigger to review materials when a supplier changes.

That does not necessarily require much more training time. It requires distributing the right content and responsibilities to the people doing the work.

A workable first programme for an SME

Identify the systems and uses, assess the organisation’s roles, group users by what they do and prioritise risks. Prepare a shared foundation, then add instructions and exercises for the higher-impact workflows. Assign an owner and a place for questions.

Review when the model, provider, permitted action, data category or process changes. A yearly session may be one useful measure, but neither its frequency nor the certificate answers whether the programme fits the actual use.

For help assessing roles, supplier agreements and practical governance under EU rules, see our technology legal services or contact us.

Sources and further reading

• Regulation (EU) 2024/1689, the AI Act, especially Article 4 and the separate human-oversight provisions where applicable.
• Regulation (EU) 2026/1744, Digital Omnibus on AI, enacted amendment replacing Article 4; published 24 July 2026, effective 27 July 2026.
• European Commission: AI Literacy Questions & Answers, interpretative guidance; distinguish current answers from retained historical proposal passages.
• European Commission: AI talent, skills and literacy, official policy and implementation context.