In brief
- An introductory module creates a shared foundation; role- and application-specific learning paths make it practical.
- Real work cases and observable tasks demonstrate more than a certificate of attendance.
- Onboarding, new systems, model or policy changes and incidents trigger learning or refreshers.
- Usage, error patterns, escalations and competence evidence show whether the programme works.
Article 4 calls for appropriate measures, not one standard course
Legal position on 17 July 2026: Article 4 of Regulation (EU) 2024/1689 has applied in its original form since 2 February 2025. Providers and deployers must take measures, to their best extent, to ensure a sufficient level of AI literacy among staff and other persons dealing with operation or use on their behalf. Technical knowledge, experience, education and training, the use context, and the people or groups affected must be taken into account.
The Digital Omnibus on AI was adopted by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, and was signed on 8 July 2026. On 17 July 2026, publication in the Official Journal and entry into force were still pending. The new wording requires providers and deployers to take measures to support the development of AI literacy and expressly states that no specific level of literacy must be guaranteed for any individual. It will enter into force on the third day following publication.
Neither the Commission FAQ on the currently applicable wording nor the adopted new text prescribes one standard course, a particular certificate or a uniform knowledge test. Internal records of training and other guidance or learning initiatives can document implementation. The practical assessments and effectiveness measures below are risk-based governance recommendations, not general statutory format requirements.
A Swiss company should separately assess whether the particular use falls within the territorial and personal scope and whether it acts as a provider or deployer. Relevant connections can include placing or putting a system into service in the EU, an EU establishment, or use of system output in the EU. Regardless of legal scope, a risk-based literacy programme reduces misuse, data risks and unclear accountability.
- Shared foundation
- Everyone in scope understands which AI systems are used, what they can generally do, where their limits lie and which internal rules apply.
- Role-specific depth
- Someone who drafts text needs different knowledge from a person reviewing employment decisions, approving an agent or operating the platform.
- Context and affected people
- Learning becomes deeper when sensitive data, external communication, decisions about people or actions that are hard to reverse are involved.
Five role profiles make learning needs concrete
Profiles should follow actual tasks rather than the organisation chart. One person may have more than one profile. A domain reviewer in a critical process therefore needs greater use-case depth than an occasional user of the same tool.
| Role profile | What the person must be able to do reliably | Suitable evidence of competence |
|---|---|---|
| Ordinary users | Apply approved-tool and purpose rules, follow data requirements, understand limitations and hallucinations, verify sources, recognise prompt injection and avoid forwarding unchecked output. | Complete a typical task with permitted data, flag a problematic output and choose the correct reporting route. |
| Domain reviewers and approvers | Apply domain quality criteria, assess reliable sources and evidence, handle exceptions, understand possible impacts and recognise the limits of human oversight. | Assess several realistic cases, explain errors and make a traceable release, correction or escalation decision. |
| Product and process owners | Define purpose and non-goals, risk tier, roles, acceptance criteria, monitoring, change control, incident handling and retirement. | Present a use case for approval with its data flow, controls, measurable criteria and named owners. |
| Development, platform and operations teams | Understand model limits, permissions, prompt injection and tool risks, evaluation, logging, privacy, incident response and safe change management. | Demonstrate controls in a test environment, investigate a failure and execute a rollback or access block. |
| Leadership, risk, legal and compliance | Understand the portfolio and risk appetite, organisational roles, material legal issues, required evidence, residual risks and escalation decisions. | Use a decision package to set justified conditions, accountable owners, a review date or a rejection. |
Learning objectives describe observable behaviour
Knowing AI is neither practicable nor reliably testable as an objective. Good objectives describe what a person can decide or execute in a concrete situation. Selection and depth follow role and risk.
- Capabilities and limits
- Explain what the system is suitable for, what it cannot do reliably and when another method is required.
- Handle data correctly
- Distinguish permitted data, tools and features, minimise inputs and choose a safe alternative for restricted content.
- Recognise manipulation
- Detect prompt injection, suspicious instructions in documents and unexpected tool actions, then stop and report them.
- Verify sources and evidence
- Check claims against approved sources, assess currency and scope, and make uncertainty visible.
- Exercise human review
- Go beyond confirmation by applying clear criteria to correct, reject, escalate or approve an action.
- Handle incidents correctly
- Stop data exposure, harmful output, erroneous actions or suspicious behaviour, preserve evidence and use the accountable reporting route.
From role profile to an evidenced learning path
A literacy programme is an operating process, not a one-off campaign. A short shared introduction can be provided centrally; the important exercises are developed with domain and system owners.
- Step 1
Map systems, tasks and roles
The AI inventory shows who uses, reviews, develops, approves or operates each system for which tasks and which people may be affected.
- Step 2
Set the baseline and learning objectives
Technical knowledge, experience, existing education and use-case risk determine which foundations and specialist modules are needed.
- Step 3
Practise with real work cases
Approved or synthetic cases include typical errors, unsafe data, weak sources, manipulation attempts and a decision about review or escalation.
- Step 4
Demonstrate competence in practice
The person completes a task, explains a decision or performs a technical control and incident procedure against criteria defined in advance.
- Step 5
Embed support in the workflow
Quick guidance, approval points, accountable contacts and reporting options are available where the system is actually used.
- Step 6
Refresh and retrain selectively
Onboarding, broader rollout, new models or features, policy changes, weak metrics and incidents trigger the appropriate learning action.
Measure attendance, competence and outcomes separately
An attendance list demonstrates reach but not correct workplace behaviour. The programme needs a small set of measures on three levels: Are the relevant people covered, can they perform their task and is safe use improving? Targets should be set by role profile and risk tier.
| Level | Measurable evidence | What a gap should trigger |
|---|---|---|
| Coverage | Share of people with the correct role profile, completed onboarding and an on-time refresher. | Correct missing assignments, restrict access until qualification or provide a catch-up learning window. |
| Applied competence | Result of a practical task covering data selection, source verification, human review, manipulation and escalation. | Targeted practice for the weak objective rather than repeating the entire course. |
| Quality of use | Correction and rejection rate, recurring error patterns, unnecessary manual rework and achievement of domain quality criteria. | Improve learning material, system boundaries, interface or process controls together. |
| Security behaviour | Detected test cases, timely stops, useful reports and correct handling of prompt injection or prohibited data. | Investigate the cause and adjust permission, control or approval routes where risk is high. |
| Adoption with value | Active use in the approved process combined with time saved, quality and user feedback. | If use is low, examine relevance, access and workflow; do not force adoption by bypassing controls. |
Lean evidence stays current with the system
Each role profile should show why particular objectives were selected, which measures were delivered and how competence and outcomes were assessed. Versioned role profiles, learning materials, exercises, scoring criteria, completion records and agreed improvements are often sufficient.
Connect the records to the AI inventory and change process. A new model, additional data source, new user group, broader action, revised policy, weak metric or incident triggers a short reassessment. Only affected roles receive the necessary refresher.
- Accountable owner and affected systems for each role profile
- Versioned objectives, content, exercises and scoring criteria
- Date, result and necessary follow-up for each competence assessment
- Trigger, decision and date of the next review
- Aggregate metrics and documented improvement actions
Example: Literacy programme for an SME with 85 employees
The company introduces an approved writing assistant for 60 employees and a knowledge assistant for customer service. Everyone completes a 25-minute foundation module and works through one case on data rules, hallucinations and reporting. Twelve service employees additionally review three answers containing an outdated, conflicting and manipulated source. Two product owners document acceptance criteria and a change check; the IT team practises a blocked tool action and an incident. Access for each role is enabled only after the practical assessment. After six weeks, assessment and error data show that source citations are often missed, so the company retrains only this objective and makes the evidence more prominent in the interface.
What to remember
First map systems, tasks and roles. Then define a small set of observable learning objectives, practise with real work cases and measure competence and outcomes separately from attendance. This creates a programme that helps in daily work and remains traceable.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.
- EUR-Lex: Regulation (EU) 2024/1689, Article 4
- Council of the EU: Signed Digital Omnibus on AI (PE-CONS 30/1/26 REV 1)
- Council of the EU: Adoption and publication status, 29 June 2026
- European Commission: Questions and answers on AI literacy
- EU AI Office: Repository of AI literacy practices
- NIST: AI Risk Management Framework Core
- NIST: AI RMF Playbook – Govern