AI literacy is not a one-off training session

An attendance record proves that someone was present. It does not prove that they can detect a false AI output, protect sensitive data, override a decision effectively or stop at the right moment.

Many organisations answer AI literacy with one general webinar: how language models work, prompt tips, risks and a short quiz. The topic is then marked complete. Yet participants use different systems, data and decision rights. A developer, service agent, executive and assurance reviewer do not need identical capability.

Article 4 of the EU AI Act follows this contextual logic. Providers and deployers should, to their best extent, ensure sufficient AI literacy for staff and others operating or using systems on their behalf, considering knowledge, experience, education, training, deployment context and affected people. It is not an off-the-shelf syllabus but a requirement for reasoned design.

AI literacy means ability to act

The AI Act definition combines skills, knowledge and understanding with informed deployment and awareness of opportunities, risks and possible harm. Literacy is therefore demonstrated in a situation, not exhausted by terminology.

Can a person recognise missing evidence, know which data must not enter an external service, distinguish a draft from a decision input, mark uncertainty, escalate an exception and stop an action? Do they understand consequences for people who never operate the system?

A learning objective becomes observable: not „understands hallucinations," but „checks source, currency and scope for externally used factual claims and blocks publication where evidence is missing."

One foundation, several role profiles

Everyone needs a common baseline: Which AI systems are used? For which purposes are they approved? What limitations, benefits and harms exist? Which data, security and transparency rules apply? Where are incidents reported?

Role profiles build on that baseline.

Users need safe input, source checks, output interpretation, disclosure and escalation. Process owners define purpose, acceptance, human control, metrics and stop rules. Developers and integrators need provenance, evaluation, security, logging, version and change management. Executives govern risk acceptance, resources, vendors, accountability and deployment boundaries. Assurance functions need access to system maps, tests, logs, complaints and decision evidence. Contractors need task-specific capability when operating the system on the organisation's behalf.

Profiles prevent generic instruction and the assumption that technical expertise equals complete deployment competence. An experienced developer may still not know internal data rules or impact on affected people.

Five layers of a defensible competence matrix

The matrix connects role and system across five layers:

1 · Orientation: principles, opportunities, limitations and systems in use.

2 · System practice: approved purpose, operation, sources, interfaces and known failures.

3 · Data and protection: confidentiality, personal data, permissions, logging and safe tools.

4 · Judgement and oversight: output review, automation bias, authority, challenge and stopping.

5 · Incident and learning: report, preserve evidence, escalate, correct and feed lessons back.

Depth varies. A drafting user need not build model pipelines. A person operating an agent with write access needs tool permissions, reversal and incident behaviour. Required capability follows task and consequence.

Reading is insufficient; scenarios expose capability

AI Office guidance notes that merely reading instructions may often be ineffective and insufficient. Learning should fit the target group and actual system.

A scenario combines a normal task with a controlled disturbance: outdated source, prompt injection inside a document, sensitive input, contradictory evidence, biased recommendation, unauthorised tool call or missing approval. The participant must detect the issue, select the safe path and record the decision.

Assessment looks beyond the final answer to checking, reasoning, data hygiene, use of controls, escalation and stopping. Safe simulation failures provide richer learning evidence than multiple-choice definitions.

Capability and permission belong together

Training without technical boundaries transfers responsibility to individuals. An inexperienced user should not receive a production deletion tool merely after seeing a warning slide. Conversely, a qualified reviewer needs evidence, logs and a stop control.

The profile is connected to permissions. Read-only access differs from publishing, selecting people, exporting data or autonomous tool execution. Greater impact brings stronger practice, narrower scope, another gate and a shorter review cycle.

Competence is not a permanent badge. It applies to a role, system version and scope. Passing a support scenario does not authorise employment decisions or administrative database access.

There is no general certificate requirement