AI literacy under Article 4 should follow the work people perform

The Skybridge EU AI Act tracker converts “AI-native” familiarity into documented ability to operate one system within its purpose, limits, and authority. That distinction makes literacy evidence specific to the work each person performs.

Article 4 of the EU AI Act requires providers and deployers to take measures supporting AI literacy for staff and other people operating or using AI systems on their behalf. The Commission's post-Omnibus Q&A says the amended duty does not prescribe one specific level every individual must reach.

The practical response is role-based support tied to real systems. This is an operational framework, not legal or employment advice.

The amended duty prescribes measures, not one exam

Article 4 began applying in February 2025 and was amended in 2026. Current Commission material emphasizes measures that consider technical knowledge, experience, education, training, use context, and the people affected by the system.

That wording resists a universal two-hour course. A person drafting internal copy needs different preparation from an approver authorizing supplier communication. An engineer who can change model routes or connector credentials needs another level again.

The Commission maintains a repository of literacy practices. It also states that copying an example does not create a presumption of compliance. The organization must still choose measures suitable for its systems and people.

Start with the system and the person's authority

For each role, record five facts:

1. which AI systems the person touches.
2. what data and people those systems affect.
3. which outputs the person can accept, change, or send.
4. which failures the person needs to recognize.
5. where the person can stop or escalate the work.

This creates a literacy requirement that can be observed. “Understands hallucinations” is vague. “Checks the cited project record before approving an external date change” describes work.

Build four learning paths

Add specialist modules where a system affects employment, education, safety, public services, or other sensitive contexts. The role map should include contractors and other people operating the system on the organization's behalf where Article 4 applies.

Teach through failure cases

People remember an operating decision better than a glossary.

For a project-brief system, give the user two source records with conflicting dates. The expected behavior is to preserve the conflict and request a decision. Put an instruction inside a retrieved email asking the agent to ignore its task. Show that retrieved content is evidence and carries no authority by itself. Give the approver a correct draft with the wrong recipient and require rejection.

Skybridge implementation history provides real classes of failure. One approval tool refused an incomplete request while the model's prose implied that approval had been created. Logging later made the refusal visible. Another incident came from a script resolving the wrong environment before a model even ran. These cases teach people to verify execution state and target identity rather than trusting conversational text.

Record evidence without creating attendance theatre

Keep a short literacy record for each role and system:

• assigned material and date.
• scenario or demonstration completed.
• support and escalation route.
• changes that require a refresh.
• owner responsible for keeping the material current.

Attendance shows exposure to the material. It does not show that the person can perform the task. Add one practical exercise for roles with meaningful authority.

Measure operational signals as well. Repeated wrong-source approvals, unsafe data entry, ignored conflicts, or misuse outside the intended purpose may indicate that instructions, interface, or training need correction. Blaming the user hides a design problem.

What Skybridge implementation history taught us

Skybridge engineering documentation covers system behavior, provider routes, approval states, incident response, releases, and operating boundaries. The literacy record translates that evidence into role-specific operating capability, support, and accountability.

The fix begins by connecting existing artifacts to roles. Users need the relevant system guide. Approvers need action and evidence training. Operators need incident and fallback procedures. Engineers need environment, access, and change controls. The same release record can point each person to the part they own.

Compsia makes this role map part of every managed production-system launch and refreshes it after material changes. The AI governance guide provides the surrounding ownership model.

Refresh does not need to mean repeating the full programme. A new interface may require a five-minute demonstration. A model change that alters output behavior may require new failure exercises. A new action tool may change approver and administrator material. Record which change triggered the update, who received it, and which scenario proves the new behavior was understood. That keeps the literacy record attached to the living system.

AI literacy questions

Does Article 4 require an AI certification?

The Commission's current guidance does not prescribe one universal certification or individual proficiency level. Organizations should select measures suitable for the people, systems, context, and affected groups.

Does every employee need the same AI training?

No operational reason supports identical content. Training should reflect actual system access, decision authority, technical knowledge, and consequence.

Is a policy acknowledgement enough?

A policy can form part of the evidence. Practical instruction, support, and scenario-based learning provide stronger evidence that people can operate the system as intended.