Article 4 AI literacy: what you actually need to do

Article 4 AI literacy requirements have applied since 2 February 2025. Providers and deployers of AI systems must take measures to ensure their staff and other persons dealing with the operation or use of AI systems on their behalf have a sufficient level of AI literacy. “Sufficient” is not a fixed score or certificate — it must take into account each person’s technical knowledge, experience, education, training, the specific context of use, and the people affected by the system.[1][2]

Official EU guidance is unambiguous on the most common myths: there is no mandatory certificate, no required AI officer or fixed governance structure, no single training format that fits every organisation, and no obligation to formally test or measure every employee’s knowledge. Internal records that show you mapped your uses, tailored content to roles and risks, and reviewed it periodically are generally accepted as reasonable evidence.[1]

What matters operationally is a pragmatic, documented approach that reduces real risks and supports related obligations such as human oversight and transparency.

Law status (May 2026) Current law: Article 4 has been in application since 2 February 2025 together with the general provisions and prohibitions. National market surveillance authorities supervise and enforce it. The AI Office provides supporting Q&A, a living repository of practices, and webinars but explicitly states that replicating listed practices does not create any presumption of compliance.[3][1]

Proposed changes: The Digital Omnibus package (November 2025) and subsequent Council and Parliament positions focus primarily on linking high-risk rules to the availability of harmonised standards and support tools, SME simplifications, and certain procedural adjustments. No amendments to Article 4 AI literacy obligations have been adopted. Any future changes would be clearly labeled as such.

The AI Office’s dedicated Q&A and supporting pages cut through the noise on Article 4. Here are the points that matter most for operational planning:

• No certificate requirement. There is no prescribed training certificate, accredited provider, or third-party validation needed. Compliance is demonstrated through the measures you take and the records you keep, not through external paperwork.[2]

• No mandatory AI officer or fixed governance structure. Article 4 does not require you to appoint a dedicated AI literacy lead, create a new committee, or follow any particular organisational template. You may integrate literacy work into existing risk, compliance, or people functions.

• No one-size-fits-all training format. The obligation is explicitly context-aware. Measures must reflect the technical knowledge, experience, education and training already present in the relevant people, the concrete use case, and the potential impact on affected persons. A 30-minute generic e-learning module is unlikely to be regarded as sufficient on its own for high-risk or customer-facing deployments.[1]

• Internal records can be sufficient evidence. Market surveillance authorities will look for evidence that you identified relevant roles and uses, provided appropriate information or training, and kept a record of what was done. Simple, consistent documentation (logs, notes, acknowledgements, review dates) is the practical route.

The AI Office maintains a living repository of real-world literacy practices from companies and public bodies. These are useful inspiration but come with an explicit disclaimer: inclusion does not imply endorsement or presumption of compliance. Use them to spark ideas, not as a compliance checklist.[1]

A workable Article 4 programme starts with mapping, not with slides. Begin by answering four questions:

1. Which AI systems (or uses of external models) do we actually have in the organisation?
2. Which roles interact with them (build, configure, review outputs, make decisions with them, maintain them)?
3. What are the realistic risks and opportunities in each use case?
4. Who are the affected persons (customers, employees, job applicants, citizens) and what do they need to know?

From there, tailor content and format by role. The goal is informed use, awareness of limitations and risks, and the ability to apply appropriate safeguards — exactly what the legal definition of AI literacy in Article 3(56) requires.[2]

Different roles need different depth and style. A developer needs to understand model limitations, bias sources, and testing methods. A business user needs to know when to trust or override output and how to document decisions. Support staff may need clear escalation paths when the system behaves unexpectedly. Contractors and third parties should receive relevant extracts or briefings before they touch your systems.

Role-based literacy matrix

This matrix is illustrative. Adapt columns and depth to your actual systems and risk profile. A marketing agency using ChatGPT for copywriting will have lighter but still real requirements focused on accuracy, disclosure, and brand risk. An HR team using screening software will need deeper understanding of bias, non-discrimination, and documentation because the use is closer to high-risk territory. A product team shipping a customer-facing chatbot must cover transparency (Article 50), human oversight, and what affected customers need to know.

Three concrete examples

• Marketing agency using ChatGPT: Staff receive a short internal guide covering prompt hygiene, fact-checking requirements, disclosure to clients when AI-generated content is delivered, and escalation for sensitive campaigns. The guide is reviewed quarterly. Completion is logged via a simple form. No formal test is run; the emphasis is on practical habits and record-keeping.

• HR team using screening software: Recruiters and hiring managers complete a targeted session on how the tool was trained, known limitations, required human review steps, and documentation of override decisions. The session links explicitly to non-discrimination rules. A tool-specific checklist is used for every campaign and retained for audits.

• Product team shipping a customer-facing chatbot: Developers, product managers, and support staff receive role-specific briefings. The product team focuses on testing for hallucinations and bias. Support learns exact phrasing for transparency (“This is an AI system…”) and escalation. Customer-facing transparency notices are reviewed as part of the literacy effort. Records tie the training to the specific chatbot version.

Official guidance and enforcement expectations make clear that certain common approaches fall short:

• Simply telling staff “read the instructions” or “use AI responsibly” with no context, examples, or role-specific application.
• A generic annual compliance deck that mentions AI once in passing and is not connected to the systems people actually use.
• Zero recordkeeping — no log of who received what information, no evidence of review cycles, no link between the literacy measures and particular AI uses.

These approaches do not demonstrate that you considered the context, the people involved, or the need for ongoing awareness. They are unlikely to satisfy a market surveillance authority if questions arise.

Documentation should be lightweight, consistent, and tied to real work. Aim for artifacts that a reasonable person would find credible evidence of effort.

Good enough evidence for Article 4

Keep artifacts in a central, searchable location (shared drive, wiki, or compliance tool). For high-risk or sensitive uses, add short system-specific addenda that reference the relevant risk assessment or human oversight measures. Periodic reviews (e.g. annual or after major model updates) should be dated and note any changes made to content or audience.

Many organisations integrate Article 4 work into existing processes: update onboarding checklists, add AI sections to role-specific training paths, include literacy prompts in code review or procurement templates, and reference the programme in broader risk or quality management documentation.

• Treating Article 4 as a pure HR or L&D exercise instead of a cross-functional effort owned by the people who actually select, build, and oversee AI systems.
• Focusing only on “training” while ignoring simpler formats (guidance notes, checklists, recorded briefings) that are often more effective and easier to keep current.
• Copying generic external courses or repository examples without adapting them to your specific AI inventory, roles, and risk profile.
• Creating beautiful documentation that is never reviewed or linked to actual use cases.
• Assuming that technical staff or leadership are “automatically literate” without any contextual briefing on your particular systems and obligations.
• Over-documenting with exams, scoring, and complex tracking systems when simple logs and acknowledgements would suffice for most uses.

• Inventory all current and planned AI uses (internal tools, external models, customer-facing systems).
• Map roles that interact with each system and the affected persons.
• Draft or update role-specific guidance or briefings that reflect actual risks and context.
• Decide on delivery formats and create a simple delivery and acknowledgement log.
• Set a review cadence (e.g. after major model changes or annually) and assign an owner.
• Link literacy measures to related obligations (transparency notices, human oversight procedures, procurement clauses for contractors).
• Test the approach on one high-visibility use case (e.g. your marketing team’s use of generative tools or an internal HR screening pilot) and refine.
• Keep records accessible and up to date.

Use the free **AI Literacy Planner** to generate a tailored starter matrix, guidance templates, and evidence log structure for your organisation.

For a concrete worked example, see the **marketing agency AI literacy sample report**. It shows how a typical SME can document a practical programme without heavy overhead.

Further reading:

• AI literacy repository and practices
• Sector guidance: Marketing agencies, publishers, and AI-generated public content and EU AI Act for HR software teams

Sources All material claims above are drawn from the European Commission’s official AI literacy Q&A, the AI talent/skills/literacy policy page, the AI Act Service Desk timeline, and the consolidated regulation text. These remain the primary authoritative references. This page does not constitute legal advice.