AI Literacy

Article 4 of the EU AI Act obliges AI providers and operators to take steps ensuring their personnel have sufficient AI literacy. The standard depends on technical background, experience, training and the context in which the AI is deployed. This requirement has been in force since 2 February 2025 — regardless of the risk category of the systems in use.

No specific training format is prescribed. What's required is an appropriate level: someone using an AI tool as an end-user needs different knowledge than someone reviewing AI outputs technically or configuring systems. A tiered approach works well — foundational training for everyone, deeper training for power users and decision-makers.

Beyond legal obligation, AI literacy is the most important lever for AI projects to deliver real impact. Staff who understand what a language model can do and where it hallucinates use these tools more productively and safely. Typical training content covers how AI works fundamentally, effective prompting, handling errors, data protection rules and the company's internal policies.

What works in practice: short, hands-on formats using the company's actual tools and use cases rather than abstract theory — and documentation of completed training as proof of compliance.

AI tools change faster than any other office software: new model versions, new features, new limitations. Training from last year may cover content that's simply no longer accurate — like what a model can reliably do. So the literacy requirement includes an update mechanism: brief refreshers when relevant tools change, training as a standard part of onboarding new hires, and a named contact for everyday questions.

What's proven effective is tying updates to tool changes rather than the calendar: when a new AI system launches or an existing one changes significantly, affected roles get a compact briefing — documented in the same register as the systems themselves. This keeps effort proportional to actual change, and the company can always demonstrate that literacy and system landscape align. There's a cultural bonus too: teams that regularly discuss AI tools report problems and ideas sooner.

Article 4's requirement applies to AI providers and operators, covering their personnel and anyone working on their behalf to operate or use AI systems. So it doesn't blanketly include every employee, but only those actually working with the systems. The scope varies widely by organisation: where AI tools run only in accounting, the requirement primarily affects that department; where a company-wide assistant is rolled out, it reaches further. The phrase "appropriate level" matters: the required competency standard is measured by role, prior knowledge and use context — an end-user needs less depth than someone who technically reviews AI outputs or configures systems.

In practice, this means consciously defining who falls under the requirement, rather than either treating everyone the same or underestimating the obligation. A practical approach is mapping roles to deployed systems: who uses what, with what responsibility? This almost automatically clarifies who needs which training depth. Also remember that external staff and service providers working on your behalf with these systems fall within scope. This clear mapping isn't bureaucracy for its own sake: it ensures training lands where it has impact and no security-critical user handles an AI system without basic understanding.

Article 4 of the AI Act doesn't mandate explicit documentation — yet in practice, documentation is essential. Without evidence, you can't prove you've met the requirement if a regulator asks. A simple overview is recommended, recording for each training activity: date, content, target audience and participants — ideally linked to the AI register that captures systems in use anyway.

The effort is manageable and scales with your company size. A spreadsheet or intranet entry suffices to start; sophisticated training management only makes sense with larger teams or frequent system changes. What matters is linking documentation to changes: every new AI system or significant update to an existing one triggers a documented briefing. This way, your literacy documentation grows organically alongside AI use, rather than becoming a one-off bureaucratic exercise that goes stale. It saves rework and, if needed, shows that the company took the requirement seriously.