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

According to the AI Office Q&A, Article 4 does not require a specific certificate. Internal records of training and other guidance initiatives can be kept, and no particular governance structure is mandated solely for Article 4.

Evidence still matters. An organisation should show how it identified target groups, systems, risks and prior knowledge, which measures followed, when they occurred and how effectiveness was considered. Attendance is one data point, not the complete case.

A competence record can contain role, system, objective, method, scenario, outcome, open gap, approval status and next review. It stores only necessary personal information under clear access and deletion rules.

Knowledge must age with the system

Models, tools, sources, autonomy, interfaces and policies change. Yesterday's course can create today's false confidence.

Refresh triggers include a new version, use case or role; a critical incident; repeated error; new legal or security requirements; or a long pause. Updates focus on what changed rather than forcing everyone through the entire programme.

Operational evidence closes the loop. Protected analysis of error reports, overrides, complaints, risky inputs and near misses produces new scenarios, guidance, technical controls or process changes.

Shadow AI is also a literacy problem

Bans do not prevent staff from using public tools. Shadow AI often grows when approved alternatives are absent, rules are unclear or data flows are misunderstood.

Effective literacy explains not only what is prohibited, but why, which safe alternative exists and how legitimate needs are raised. The organisation studies patterns without creating blanket surveillance and improves tools and approvals.

An open reporting culture matters. Early disclosure of risky input enables containment. People who expect punishment without a learning path conceal incidents.

Affected people belong in the perspective

Organisational measures mainly target those providing or using systems on behalf of providers and deployers. The definition and recitals also consider affected people and informed decisions. Depending on risk, customers or other groups may benefit from appropriate literacy.

This goes beyond a transparency notice. People may need to understand that AI is involved, what an output means, which limits exist and how to request questions, correction or human review. Hidden notices and jargon do not produce agency.

Turn training into an operating system

A sustainable capability system follows a loop:

1. Map systems, roles, affected people and risks.

2. Define observable competence objectives.

3. Provide foundation and role-specific modules.

4. Simulate normal and disturbed scenarios.

5. Link capability to scope and permission.

6. Observe use, incidents and control behaviour.

7. Close gaps through learning, process or technology.

8. Refresh content and approval when triggers occur.

AI literacy becomes part of governance and operations. It prevents failures and improves value: people frame better tasks, recognise limitations earlier and know when automation helps — and when responsibility cannot be delegated.

Worksheet: Build a role-based competence matrix

Choose one concrete AI use case.

1. List roles, tasks, systems and affected groups.

2. Define three observable actions for each role.

3. Assign the five competence layers and required depth.

4. Create one normal and two disturbed scenarios.

5. Define assessment, stop criteria and escalation.

6. Link competence status to permissions and scope.

7. Define minimised internal evidence records.

8. Set refresh triggers and accountable owners.

All materials to download — the topic overview and the worksheet:

Scope: This article presents an organisational implementation pattern, not a mandatory universal solution. Article 4 does not prescribe one certificate, governance structure or training format. The appropriate level depends on role, prior knowledge, system, deployment context, risk and affected people. Editorial review date: 17 July 2026.