Lead
On 2 February 2025, Article 4 of the EU AI Act entered into application. Supervision and enforcement rules apply from August 2026. It is short. It is vague. It applies to almost everyone. And it has put a quiet obligation on the desk of every European employer who lets staff use an AI tool at work.
The clause says that providers and deployers of AI systems must take measures to ensure a sufficient level of AI literacy of their staff and other people dealing with the operation and use of AI systems on their behalf. That is the whole sentence. It does not define “sufficient.” It does not specify hours of training. It does not list approved programmes. What it does do is create a standard that a regulator, a works council, or a plaintiff’s lawyer can measure you against after something goes wrong.
This article is the practitioner’s guide we wished existed when clients first started asking us about Article 4 in late 2024. It covers what the clause actually requires - not what conference speakers say it requires - and what documentation organisations should be ready to evidence. It is opinionated in places. Where the law is vague, we tell you how we read it and why. Where the law is clear, we say so plainly.
If you are responsible for AI literacy at your organisation and you need a defensible programme before an incident forces the question, this is for you.
What Article 4 actually says, in plain English
- The text of the clause, unpacked phrase by phrase
- “Providers” vs “deployers” - which one are you
- “Staff and other people dealing with the operation” - the scope is wider than you think
- What “sufficient” has to mean, by the standards of adjacent EU law
The clause is one sentence. Read slowly:
Providers and deployers of AI systems shall take measures to ensure, to their best extent, a sufficient level of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training, and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used.
Three phrases do the heavy lifting.
“Providers and deployers.” A provider is the organisation that builds, brands, or substantially modifies an AI system and puts it on the market. A deployer is anyone using an AI system in a professional capacity - which is the box almost every European employer sits in the moment a member of staff opens ChatGPT, Copilot, Gemini, Claude, or any embedded AI feature inside a SaaS tool to do their job. If your team uses AI at work, you are a deployer. If you also build or rebrand AI features, you are both.
“Staff and other persons dealing with the operation and use … on their behalf.” The scope is wider than full-time employees. It reaches contractors, agency staff, freelancers, and partners who operate the system on your behalf. The test is not the contract. The test is whether the person is using AI to do work for you.
“Sufficient level.” This is the part that worries people, and it should. The Act does not define sufficient. There is no hours-of-training threshold. There is no approved curriculum. The standard is calibrated to the role, the risk, the context of use, and the people affected by the output. That means “sufficient” for a junior marketer using AI to draft social posts is not “sufficient” for an HR specialist using AI to filter CVs, and neither matches what is “sufficient” for an engineer training a model on customer data.
The closest reference points in adjacent EU law are GDPR’s “appropriate” safeguards and the Working Time Directive’s “adequate” rest. In both, regulators read the standard against what a competent organisation in your sector should reasonably be doing. Article 4 will be read the same way. “Sufficient” means defensible against a reasonable expectation - not perfect, not a completion record, but documented, role-appropriate, and refreshed.
Who Article 4 applies to
- Every employer whose staff use a third-party AI tool
- Every organisation building or integrating an AI feature into its own product
- Contractors, freelancers, and agency staff - why they are in scope
- The small-employer question - is there a carve-out (no, but read the nuance)
If your organisation does any of the following, Article 4 applies to you:
Your staff use a third-party AI tool at work. This is the broadest and most common case. The moment an employee uses ChatGPT, Copilot, Gemini, Claude, Perplexity, an AI summariser inside Notion or Slack, an AI feature inside your CRM, or any other AI-powered function to produce work output, you are a deployer under Article 4. Free-tier, paid-tier, sanctioned, or shadow - it does not matter. Use creates the obligation.
You build or integrate an AI feature into your own product. If your product calls a model API, fine-tunes a model, or wraps third-party AI in your own interface, you are a provider for that feature. Provider obligations stack on top of deployer obligations - so you carry both.
You use contractors, freelancers, or agency staff who handle AI on your behalf. A common gap. Article 4 explicitly extends to “other persons dealing with the operation and use of AI systems on their behalf.” If a freelance designer uses Midjourney to produce assets you ship, if an agency uses ChatGPT to draft your campaigns, or if a contracted analyst uses an AI tool to prepare your reports, the obligation reaches them through you. Their literacy is your responsibility to evidence.
You are small. There is no carve-out by headcount. The Act applies to the smallest sole-proprietor consultancy and to the largest multinational. What changes with size is what “sufficient” looks like in practice - a 6-person team is not expected to run the same programme as a 6,000-person enterprise. But the obligation itself is the same. Smaller organisations often default to lighter, more pragmatic evidence: a written policy, a short induction, a refresh schedule, and a simple log of who completed what. That is enough, when it is real.
The practical takeaway: if anyone connected to your work uses AI to produce output, plan for Article 4 as if it applies to you, because it does.
The timeline - what is enforceable when
- 2 February 2025 - Article 4 and prohibited-practice clauses in application
- 2 August 2025 - general-purpose AI model rules in application
- 2 August 2026 - high-risk system obligations and supervision and penalty framework apply
- What the staged timeline means for your training programme planning
The AI Act came into force on 1 August 2024 and switches on in stages. The dates that matter for AI literacy planning:
2 February 2025 - Article 4 entered into application. Together with the prohibited-practice clauses, this is the first wave of obligations to attach. The clause is in application now. What is not yet in force is the formal supervision and penalty regime around it - that arrives in 2026.
2 August 2025 - rules for general-purpose AI models in application. Mainly affects providers of frontier and foundation models, plus organisations that fine-tune or substantially modify them. Most deployers are not directly hit by this date, but the upstream tooling your team uses will change in response - which is one reason a refresh cycle matters.
2 August 2026 - high-risk system obligations and the supervision and penalty framework apply. This is the date many teams are mentally anchoring on, because it brings the enforcement architecture: market surveillance authorities, conformity assessment for high-risk systems, and the financial penalties associated with breach. From August 2026, the Article 4 obligation that has been in application since February 2025 sits inside an active supervisory framework.
2 August 2027 - some provisions for high-risk systems already on the market continue to phase in. Mainly relevant to providers, not most deployers.
What this staged timeline means for your training programme: the obligation is live now. The penalty machinery activates from August 2026. The window between is the time to build a programme that is real, role-appropriate, refreshed, and documented - so that when the supervision regime arrives, you are not building from scratch. The organisations that will struggle in 2026 are the ones that treated 2025 as a deferral.
What “AI literacy” actually requires - the four competencies
- Understanding what the AI system is doing, at the level needed for the role
- Recognising the risks and limitations that apply to your use case
- Knowing when human judgment is required and how to exercise it
- Being able to document and explain AI-assisted decisions after the fact
Here is what the four competencies look like in practice, role by role. The point is not to be exhaustive - it is to show how “sufficient” shifts with the work.
Legal and compliance. Understanding extends to how the model handles confidentiality, retention, and source attribution. Risk awareness includes hallucinated citations, jurisdictional drift in legal reasoning, and confidentiality leakage through prompts. Human judgment is the heart of the role: every AI-assisted output is reviewed against primary sources and the lawyer’s own analysis before it leaves the firm. Documentation: which matters were AI-assisted, which models, what review was performed, and what the lawyer changed.
HR and people operations. Understanding includes how recruitment, screening, and performance tools score and rank people, what features they use, and where bias enters. Risk awareness covers protected-characteristic proxies, scoring drift over time, and the line between supportive automation and a decision that legally must be made by a human. Human judgment: every shortlist, performance flag, or recommendation reviewed before action. Documentation: training records for the team, AI-tool use logs for hiring decisions, and a clear record of where the human decision sits.
Marketing and content. Understanding extends to how generative tools produce text and images, what training data they were built on, and the limits of factual reliability. Risk awareness covers brand voice drift, plagiarism risk, fabricated statistics, and disclosure obligations to the audience. Human judgment is editorial: every AI-drafted asset reviewed for accuracy, voice, claims, and rights. Documentation: which assets were AI-assisted, what review was done, what the marketer changed.
Engineering and product. Understanding includes how code-generation models work, what data they were trained on, the risks of suggested code, and the distinction between code-completion and autonomous generation. Risk awareness covers licence contamination, security vulnerabilities in suggested code, leaked secrets in prompts, and over-reliance. Human judgment: review of every accepted suggestion, and a deliberate practice of writing the test before accepting the implementation. Documentation: which features used AI assistance, any model fine-tuned on internal code, and the review record.
Customer support and sales. Understanding covers how AI summaries, draft replies, and recommendation tools generate output and where they fail. Risk awareness covers misstatement of policy, made-up commitments, hallucinated product features, and tone mismatch with the brand. Human judgment: agent reviews every AI-generated reply before sending, especially where the customer is in a vulnerable state, dispute, or regulated context. Documentation: which interactions used AI assistance, escalation pathways, and the agent’s edits.
The shape repeats: the four competencies are constant. The content and depth scale with the role’s risk and the consequence of getting it wrong.
What documentation organisations should be ready to evidence
- A written AI literacy policy - what sections it has to contain
- Training records - who was trained, on what, by whom, with what materials
- Assessment evidence - how you know the training worked
- Incident logs - when AI use went wrong and what was learned
- A retention schedule - how long to keep the above, and in what form
There is no official Article 4 file format. There is no submission portal. The European Commission has confirmed no certificate is required. What is required is internal records that, taken together, show a competent organisation took measures appropriate to the role and the risk. In practice, when a compliance lead, regulator, customer, works council, or board asks “show us your Article 4 evidence,” they are looking for these artefacts:
A written AI literacy policy. Short is fine, real is essential. It should name who the policy covers (including contractors and agency staff), what tools are sanctioned, what is prohibited, where to ask, what training is required for which roles, and how often the policy itself is reviewed. One to three pages, owned by a named person, dated, version-controlled.
Training records. Who was trained, on what, by whom, with what materials, on what date. The record should be retrievable per person and per role. Materials should be archived in the form they were delivered - if you ran a workshop, keep the deck and the attendance list; if you used an e-learning module, keep the version and the completion log. Vendor-supplied training is fine as part of the programme, not as the whole of it.
Assessment evidence. How you know the training worked. This does not have to be a multiple-choice test. The strongest evidence is work-product review: a marketer’s first AI-assisted asset reviewed by a senior; an engineer’s first AI-assisted pull request reviewed against the literacy criteria; an HR specialist’s first shortlist review documented. The principle: assessment built into the work, not bolted onto it.
Incident logs. When AI use went wrong, what happened, what was learned, what changed. “Wrong” is broad: a confidentiality leak, a hallucinated fact that reached a customer, a near-miss caught in review, a policy breach. The log shows the organisation responds, learns, and updates the programme - which is the core of “sufficient measures, taking into account experience.”
A retention schedule. How long records are kept and in what form. Five years for training records is a reasonable default in most EU contexts; align with your wider retention policy. Keep the policy itself, the training materials, the completion records, the assessment evidence, and the incident log together so a reviewer can read the story end to end.
This is what an evidence pack looks like. None of it requires a third-party completion record. All of it is producible by a competent organisation that takes the obligation seriously.
Common mistakes we see employers making
- Treating Article 4 as an IT problem
- Relying on vendor-supplied training as the whole programme
- Training once and never refreshing
- Leaving contractors and agency staff out of scope
- Not documenting - the hardest one to fix after the fact
The five patterns we see most often when employers come to us mid-programme:
Treating Article 4 as an IT problem. It is not. It is an organisational obligation that touches policy, people, training, and records. IT can sanction tools and lock down secrets. It cannot, on its own, evidence that staff understand what the tools do, where they fail, and when human judgment is required. Article 4 needs HR, legal, line management, and IT pulling together. Where it sits as an IT-only initiative, the policy and training layers are usually missing.
Relying on vendor-supplied training as the whole programme. Microsoft’s Copilot training is good. OpenAI’s ChatGPT for Work module is fine. Neither is a programme. Vendor training teaches a tool. Article 4 asks for role-specific competence around the use of AI in your context, with your data, against your risks. Vendor material can be one component. It cannot be the answer.
Training once and never refreshing. The text of the clause says measures must take “experience” into account - and the tools change every quarter. A programme with no refresh cadence ages out fast. Set a refresh interval that matches how fast your tooling changes; for most teams that is six to twelve months, not annually.
Leaving contractors and agency staff out of scope. Article 4 explicitly reaches “other persons dealing with the operation and use of AI systems on their behalf.” If your agency drafts your campaigns with AI and you have not extended your literacy policy to them, that is a gap. The fix is contractual: training requirement, policy attestation, and a record retained on your side.
Not documenting. The hardest mistake to fix after the fact, because the events you needed to document have already happened. The pattern is familiar: a team runs solid training, builds real capability, and produces no records. Eighteen months later a customer asks for evidence and the organisation cannot produce it. Documentation does not need to be heavy. It does need to be habitual, and it needs to start now, not when the question is asked.
If you recognise more than one of these in your own organisation, you are not behind - you are normal. The work is in closing the gaps before someone external asks you to.
Building a programme that holds up to scrutiny
- Map where AI is used across roles (most employers underestimate this by 3-5x)
- Write the AI literacy policy before designing the training
- Tier the training by role-risk, not by seniority
- Build assessment in - not as a test, but as a work-product review
- Set a refresh cadence that matches how fast the tooling changes
- Keep records in a format your compliance lead can review and a regulator can understand
This is the Map -> Train -> Evidence pattern we use with every client. It is opinionated. It works.
1. Map where AI is used across roles. Most employers underestimate this by three to five times. Run a structured discovery: every team, every tool, every workflow that touches AI - sanctioned, unsanctioned, embedded inside SaaS, or quietly used on personal accounts. The output is a usage map by role, with risk ratings against the four competencies. The map is the foundation. Get it wrong and the rest of the programme trains the wrong people on the wrong things.
2. Write the AI literacy policy before designing the training. The policy is the constitution; the training is the curriculum. Write the policy first so the training is built to deliver against it - not the other way around. The policy is short, role-aware, and signed off by a named owner. It is also the document that makes “sufficient” defensible: it states what the organisation has decided is appropriate, given role and risk.
3. Tier the training by role-risk, not by seniority. The senior partner who uses AI for one weekly summary needs less depth than the junior associate who uses it daily on client work. Tiering by seniority is a habit. Tiering by role-risk is the discipline. Build a baseline tier for everyone, a deeper tier for AI-intensive roles, and a specialist tier for roles where AI touches regulated decisions.
4. Build assessment in, not as a test, but as a work-product review. The strongest evidence that training worked is the first piece of AI-assisted work each person produces, reviewed by a senior against the literacy criteria. It is more credible than a quiz score, and it doubles as on-the-job coaching. Capture the review in the record.
5. Set a refresh cadence that matches how fast the tooling changes. Annual refresh is too slow for most teams. Six to nine months is closer to right. Trigger an out-of-cycle refresh when a major tool changes, a new model is rolled out, or an incident surfaces a gap. The refresh is short - it is not a re-do, it is an update.
6. Keep records in a format your compliance lead can review and a regulator can understand. Plain language. Dated. Version-controlled. One folder, one structure, one owner. The test is whether someone unfamiliar with the programme can read the records front to back and understand what was taught, to whom, when, and what evidence shows it stuck. If they can, you have an evidence pack. If they cannot, you have a stack of files.
A programme built this way - mapped, policy-anchored, role-tiered, assessed in the work, refreshed on cadence, and documented in a readable form - is what “sufficient measures” looks like in practice. It is not a completion record. It is not a guarantee. It is a defensible position, which is the standard the clause actually asks for.
How AISO Learn helps with Article 4
- Team Engagement with the Article 4 literacy package
- What is included (training + policy + records)
- What is not included (legal sign-off - get your counsel on the policy)
- Discovery call as the next step
If you are responsible for Article 4 readiness at your organisation and you want a defensible programme before the question is forced by an incident, customer review, works council, or regulator inquiry, a discovery call is the next step.
Or, if you want to see where your team stands first, the AI Readiness Scorecard includes an Article 4 competency band and tells you the shortest path to close the gap.
AISO Learn provides AI literacy training and documentation to support organisations with AI Act Article 4 readiness. We are not a law firm or certification body and do not provide legal advice, formal compliance certification, conformity assessment, or a guarantee of regulatory compliance.