AI literacy and staff training

AI literacy training gives staff enough understanding of AI to use it safely in their own role, with a short baseline for everyone and deeper modules for the people who build, buy, oversee or decide with AI. In the EU, Article 4 of the AI Act requires organisations to take measures to support it. AI literacy used to be a nice-to-have on the learning calendar. It is now part of the governance record. Regulators expect it, auditors test it and incident reviews keep finding that the person overseeing a system did not understand what it could get wrong. This guide covers what the EU AI Act requires, what a role-based programme looks like and how to evidence it.

What Article 4 of the EU AI Act requires

Article 4 of the EU AI Act has applied since 2 February 2025. It was amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026.

As amended, Article 4 requires providers and deployers of AI systems (organisations that develop or supply AI, and organisations that use it) to take measures to support the development of AI literacy of their staff and of other persons dealing with the operation and use of AI systems on their behalf. The measures take into account people’s technical knowledge, experience, education and training, the context the AI systems are used in and the persons or groups the systems are used on. The amended text states that the obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual.

The original wording asked organisations to ensure, to their best extent, a sufficient level of AI literacy. The change moves the duty from something close to an outcome towards a duty to take proportionate measures. It does not remove it. The amendment also gives the Commission and Member States a role in supporting providers and deployers, with particular attention to small and medium-sized enterprises.

A few points from the text and the Commission’s guidance shape a practical response.

• AI literacy is defined. Article 3(56) defines it as the skills, knowledge and understanding that allow providers, deployers and affected persons to make an informed deployment of AI systems and to gain awareness of the opportunities and risks of AI and the harm it can cause.
• It reaches beyond employees. “Other persons” acting on the organisation’s behalf can include contractors and service providers operating or using AI for you.
• It applies to all AI systems in scope, not only high-risk ones. A deployer of a general-purpose chat assistant has the duty as much as one running a credit model.
• Records, not certificates. The Commission’s guidance says external certification is not required and that organisations should keep internal records of the measures taken.
• Enforcement is national. Supervision sits with national market surveillance authorities, with penalties under Member State rules.

Article 4 sits beside a more specific duty. Under Article 26(2), deployers of high-risk AI systems must assign human oversight to people who have the necessary competence, training and authority, and give them the support they need. Literacy is the floor. Oversight competence for high-risk systems is a higher bar for a smaller group.

Beyond the EU

Other frameworks expect the same thing in different words. ISO/IEC 42001 requires the organisation to determine the competence needed by people doing work that affects AI performance and ensure they are competent (clause 7.2), and to make people aware of the AI policy and their contribution to it (clause 7.3). The NIST AI RMF expects personnel and partners to receive AI risk management training so they can perform their duties (GOVERN 2.2). National guidance in the UK, Singapore, Japan and Australia treats staff capability as part of responsible adoption. An organisation that builds one programme to the strongest of these will usually satisfy the rest.

Step 1: Map who uses AI and how

Start from the AI register and the acceptable use policy. For each system, note who uses it, who built or bought it, who oversees it and who is affected by its output. You will usually find six groups.

1. Everyone. All staff and contractors who might use a general AI tool.
2. Builders. Engineers, data scientists and product teams who build or integrate AI.
3. Buyers. Procurement, vendor managers and business owners who select AI products.
4. Overseers. People named to approve, check or monitor the output of a system or agent.
5. Decision-makers. People who act on AI output that affects customers, staff or the public.
6. Leaders. Executives, the governance committee and the board.

Step 2: Define role-based learning outcomes

Write outcomes as things people can do. “Understands AI risk” cannot be tested. “Can explain why a confident answer from a chat assistant might be wrong and check it” can.

Group	They should be able to
Everyone	Explain in plain terms what generative and predictive AI do and how they fail. Apply the data rules in the acceptable use policy. Recognise a phishing or manipulation attempt that uses AI. Report a problem.
Builders	Apply secure design for AI, including prompt injection, data leakage and excessive agency. Document a system for the register. Run and interpret evaluations and security tests.
Buyers	Ask the vendor due-diligence questions that matter. Read model and data terms in a contract. Spot an AI feature added to an existing product.
Overseers	Explain how the system works, its known limits and its failure modes. Recognise automation bias. Know when and how to intervene, override or stop it.
Decision-makers	Weigh AI output as one input rather than the answer. Explain a decision to the person affected. Know the review and appeal routes.
Leaders	Ask the board-level questions about AI risk. Understand the organisation’s risk appetite and obligations. Read the quarterly AI governance report.

Step 3: Build or buy the content

Keep the baseline short, twenty to thirty minutes, and specific to your organisation. Generic AI awareness courses are a reasonable foundation, but the parts that change behaviour are local. Use your approved-tools list, your data rules, two or three real examples of things going wrong and the actual reporting route.

Role modules can be longer and more technical. For builders, point to recognised material such as the OWASP Top 10 for LLM Applications. For overseers, train on the specific system they oversee, including its documented limits and what a failure looks like in practice. For leaders, a short briefing tied to the board report works better than a course.

Step 4: Assign, track and expire

Assign courses by role through your learning system, with a due date and a validity period. A completion that expires after a year forces the refresh that literacy needs as tools change. For each course, track how many people were assigned, how many hold a completion that has not expired and how many are overdue. Watch those numbers the way you watch any other control.

Step 5: Link training to access and oversight

Training is easiest to enforce when it is a condition of something people want. Make the relevant module a precondition for access to a higher-risk system, for being named as a system’s human overseer and for approval of an AI use request. When someone’s training expires, the system owner should know.

Step 6: Refresh on change

Annual refresh is the backstop. Reassign training when a new class of tool is approved, when a system changes in a way that changes what overseers need to watch for, when the acceptable use policy changes and when an incident review finds that someone misunderstood what the AI could do.

Step 7: Keep the evidence

When a regulator, auditor or customer asks about AI literacy, they will want to see the measures, not just a statement. Keep the content and its version, the role mapping, assignments, completions with dates and expiry, and any assessment results. Keep the decisions too, for example the decision that a contractor group was in scope and how they were trained. The records guide covers how to keep these so they stand up later.

Where Aicura fits

Step 4 is where most programmes lose track, and it is the part Aicura carries. Its Training area holds each course with who is assigned, who has completed, who is overdue and whose completion has expired, whether the course is entered by hand or, at Enterprise, reported by your learning system. The share of people who have completed, and how recently they trained, are tracked as figures you can set a KPI or an alert limit on. Guardian, the part of Aicura that acts when monitoring spots a problem, raises an item when someone is past due or holds an expired completion.

Each completion is captured as a snapshot, a sealed copy kept in the Evidence Vault, so you can show the measures you took. Designing the training, and deciding what is enough, stays with you.

Sources

• Regulation (EU) 2024/1689 (the AI Act), Articles 3(56), 4 and 26, as amended by Regulation (EU) 2026/1744, eur-lex.europa.eu
• European Commission, AI Literacy Questions and Answers, digital-strategy.ec.europa.eu
• ISO/IEC 42001:2023, clauses 7.2 and 7.3, iso.org
• NIST AI Risk Management Framework 1.0, nist.gov/itl/ai-risk-management-framework

A note on this page

This guide is general information, not legal advice. Whether and how Article 4 applies to your organisation depends on your role under the AI Act and the systems you provide or deploy. Read the primary sources and take your own professional advice.