EU AI Act Article 4: putting AI literacy into practice

What Article 4 actually uses as its benchmark

The provision addresses providers and deployers of AI systems. They are to take measures to ensure that their staff and other people dealing with operation or use on their behalf have a sufficient level of AI literacy. The text refers to technical knowledge, experience, education and training as well as context of use and affected persons or groups.

This does not produce one mandatory course length for every organization. A team using an AI system for internal text drafts needs different content from people selecting, configuring or approving a system, or using its outputs for consequential decisions. This is operational guidance, not legal advice for an individual case.

Distinguish roles and contexts of use first

A useful skills model starts by asking who works with an AI system and in what way. Job titles alone are not enough. What matters is which decisions a person makes based on AI outputs and which errors or risks can arise in their role.

An initial role map can remain simple. It connects groups of people with actual use cases and shows where shared foundations are enough and where deeper content is required.

• Users: assess outputs critically, shape appropriate inputs and recognize limitations.
• Business owners: own the use case, workflow and quality benchmark.
• Technology and operations: manage integrations, access, changes, monitoring and incidents.
• Procurement and vendor management: assess vendor claims, contracts and dependencies.
• Approvers and management: understand risks, responsibilities and decision criteria.

Base training on real work rather than tool features

A general introduction can establish shared language: What can the system do, what can it not do, which data may be used and how are outputs reviewed? Exercises should then connect to actual work. AI in customer service, product development or test automation requires different examples and quality criteria.

Context also determines which errors need particular attention. These include plausible but false outputs, inappropriate or confidential inputs, unchecked adoption of results and changes introduced by new models or features. The aim is not to make everyone a technical expert, but to enable safe and responsible decisions in each role.

• Start with a real, approved work example.
• Assess one good and several problematic outputs together.
• Apply the role's specific review and escalation rule.
• Finish with a real work task including documentation.

Keep records without creating bureaucracy

Operational records should show which groups received which training and how content relates to their context of use. Attendance, content, date, target audience and, where appropriate, a practical skills assessment can be documented. Specific legal and evidentiary requirements should be clarified with the responsible legal and data protection functions.

Documentation should work with existing HR, learning or knowledge infrastructure. The goal is not the number of signed lists, but the organization's ability to show that skills are built deliberately and that content relates to the systems actually used.

Embed AI literacy as a recurring process

AI systems, use cases and workflows change. One-off training therefore becomes outdated. New features, a different vendor or a broader user group can create additional training or information needs. Governance intake should include this question for every relevant change.

A regular AI forum with team leads can consolidate practical questions and reveal new training needs. In Luca's engagements, this format was connected to concrete use cases and clear ownership. AI literacy then becomes part of product and work quality rather than an isolated compliance topic.

• Assess training needs in the intake for new use cases.
• Update content after significant system or role changes.
• Use practical questions and anonymized errors as learning material.
• Assign ownership for content, audiences and updates.