Two purposes, one program, if you design it right
Companies order AI training for two different reasons, and it helps to name them separately before designing anything:
- Productivity. People should be able to use the tools available to them competently, know where they fail, and not produce worse work with AI assistance than they would without it.
- A legal measure. Article 4 of the AI Act requires taking measures that support AI literacy among staff and other people who operate or use AI systems on an organisation’s behalf.
These overlap but are not identical. A program built only around productivity may skip the role-based and context-based structure Article 4 actually asks for. A program built only to generate a compliance record may check a box without making anyone meaningfully better at using the tools safely. A program that does both deliberately serves both purposes with the same sessions.
What Article 4 requires today, and what changed
Article 4 was replaced by Regulation (EU) 2026/1744, in force since 27 July 2026. The current text requires providers and deployers of AI systems to take measures supporting the development of AI literacy of their staff and other people dealing with the operation and use of AI systems on their behalf, taking into account those people’s technical knowledge, experience, education, training, the context of use, and the people the system is used on. It explicitly does not require guaranteeing a specific literacy level for any individual.
This is a real shift from the earlier wording, which spoke of ensuring “a sufficient level” of AI literacy, a phrasing some existing training materials and articles online still describe as current law. It is not current law as of August 2026. If a source you are reading frames Article 4 as a “sufficient level” test with compliance proven by evidence of a measured level, it is describing the pre-amendment version. The European Commission’s AI Literacy Q&A, aligned with the current text, confirms no certificate is required, no strict format is imposed, and there is no obligation to measure employees’ knowledge.
Structuring content by role
A single generic session is a weak fit for a requirement that explicitly ties the measure to knowledge, role, and context. A more useful structure:
| Role | What they actually need |
|---|---|
| Deploys or configures AI systems | Deepest coverage: model limits and failure modes, permission and access control, logging, incident response |
| Uses AI tool output for daily work | Known failure modes for the tools they use, input rules (what must never be entered, especially client or personal data), and a practical method for verifying output before relying on it |
| Decision-maker on AI deployment | Risk categories under the AI Act, the organisation’s legal obligations, and where liability sits when something goes wrong |
| Occasional user | What the tool is for, what it is not for, and who to ask when something looks wrong |
What a program should produce
Three things are reasonable evidence that a proportionate measure actually took place, without overstating what any of them legally prove on their own:
- A record of who attended, when, and what was covered.
- An approved, accessible policy on AI tool use that people can actually find.
- A list of processes where output verification is mandatory before the result is used or sent externally.
None of these documents is, by itself, the legal requirement; the requirement is the measure, not the paperwork describing it. Together they are a reasonable way to show the measure was real and proportionate to the roles involved, which is what an auditor or regulator would actually want to see if the question ever came up.
On shadow use of AI tools
It is common in CIAD’s training engagements to find that staff are already using AI tools, sometimes personal accounts, for work tasks before any formal program or policy exists. Surfacing that is often one of the more useful outcomes of a training engagement, because it shows concretely what a policy needs to cover. CIAD does not have a published figure for how widespread this is across companies generally, and does not present one; if this matters to your organisation, it is worth checking directly rather than assuming a rate from elsewhere.
Related reading
For what a training certificate does and does not prove, see AI training certificates: what the certificate actually means. For criteria to compare training providers, see how to choose an AI training provider for your company. More answers are in the answer hub; to scope a role-based program, use the inquiry form.
Sources and limitations
The description of Article 4 reflects Regulation (EU) 2026/1744 and the European Commission’s current published guidance, both verified 6 August 2026. This page is not legal advice on whether a specific training program satisfies your organisation’s Article 4 obligation; that depends on your systems, roles, and risk profile, and should be reviewed with a lawyer where the stakes justify it.
Frequently asked questions
What does Article 4 of the AI Act actually require today?
As replaced by Regulation (EU) 2026/1744, in force since 27 July 2026, Article 4 requires providers and deployers of AI systems to take measures supporting the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account those people's technical knowledge, experience, education, training, the context in which the AI system is used, and the persons or groups of persons on whom the system is to be used. It explicitly does not require guaranteeing a specific level of AI literacy for any individual. This is a shift from the obligation to 'ensure a sufficient level,' which was the wording before the amendment; do not rely on any source that still describes the pre-amendment 'sufficient level' test as current law.
Is a shared, generic training session enough?
It can satisfy 'a measure was taken' in a minimal sense, but the current Article 4 wording explicitly ties the measure to role, knowledge, and context, so a single generic session is a weak fit for that requirement, not a compliant default. Someone who configures or deploys an AI system needs materially different content from someone who only reads its output.
Do we need to check whether employees are already using AI tools informally?
It is a reasonable and common finding in CIAD engagements that staff use AI tools, including personal accounts, for work tasks before any formal program exists, and surfacing that is often one of the most useful things a training engagement does, because it shows what actually needs a policy. CIAD does not have a published figure for how common this is across companies generally, and does not claim one; treat it as something worth checking in your own organisation rather than an assumed statistic.
How should training content differ by role?
People who deploy or configure AI systems need the deepest coverage: model limits, permission and access control, logging, and incident response. People who use AI tool output for their work need a middle layer: known failure modes, input rules (especially what must never be entered), and how to verify output before relying on it. People who make decisions about deploying AI systems need risk categories, legal obligations, and liability exposure. Occasional users need the basics: what the tool is for, what it should not be used for, and who to ask when unsure.
What should a training program actually produce as evidence?
A record of who attended, when, and what was covered; an approved and accessible policy on AI tool use; and a list of processes where output verification is mandatory before use. None of these are, individually, legal proof of Article 4 compliance under the current wording, since the obligation is to take proportionate measures, not to produce a specific document. Together they are reasonable evidence that a real, role-differentiated measure took place, which is the practical goal.