If your organization has never written down who needs AI training, who actually got it, or what "enough" training even means, you have two days left to decide whether that's a problem you fix now or one an inspector finds for you.
Here is the part almost every explainer gets backwards: nothing new is being created on 2 August 2026. The obligation in Article 4 of Regulation (EU) 2024/1689 has bound every provider and deployer of AI systems in the EU since 2 February 2025. What changes on 2 August is enforcement competence, not the rule itself, and unlike the high-risk system deadlines that the EU's Digital Omnibus pushed to December 2027, this one was not moved. It also just changed shape days before this deadline arrived: Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and rewrote Article 4's core duty from an obligation to "ensure a sufficient level" of AI literacy to an obligation to "take measures that support the development of" AI literacy — a shift lawyers describe as moving from an obligation of result to an obligation of effort (aiactblog.nl; Gibson Dunn). The deadline held. The bar for meeting it moved four days before enforcement authority arrives.
Key Takeaways
- Article 4 has been legally binding since 2 February 2025. On 2 August 2026, national market surveillance authorities (Spain's AESIA, Germany's BNetzA, Ireland's National AI Office, and their counterparts elsewhere) gain formal power to inspect and sanction it. The obligation itself did not just appear.
- The population in scope is wider than most HR rosters: providers and deployers of any AI system, any risk tier, must extend AI literacy measures to staff and to contractors, service providers, and clients who operate the system on the organization's behalf.
- The penalty tier for a standalone Article 4 breach is genuinely unresolved among practitioners and even among primary-adjacent commentary. This article states that uncertainty rather than inventing a number.
Why "sufficient" was always going to be the hard part
Article 4 was written without a prescribed curriculum, certification, or exam, and the European Commission's own AI literacy Q&A confirms there is deliberately no one-size-fits-all standard: literacy has to be proportionate to the technical complexity of the system, the context it's used in, and the role of the person using it (Commission AI literacy Q&A). That's a reasonable design choice for a regulation covering everything from a customer-service chatbot to a factory safety system. It also means the compliance burden of defining "sufficient" sits entirely with your organization, and a definition you can't produce on request is functionally the same as no definition at all once an inspector asks for one.
The Commission's guidance is explicit that generic effort doesn't clear the bar: handing someone an instruction manual is not enough, and if staff are using generative AI for tasks like translation or drafting, they need to understand system-specific risks such as hallucinated output, not AI risk in the abstract. The Digital Omnibus's rewording softens what you have to guarantee, not what you have to document. An effort-based obligation still requires evidence of the effort, arguably more of it, since "we made reasonable, proportionate efforts" is a claim that needs a paper trail to survive scrutiny, where "we ensured a specific outcome" at least implied a measurable one.
Secure Privacy's AI Governance module is built around exactly this problem: without a real inventory of the AI systems your organization actually uses, you cannot define who needs to be literate about them or to what depth.
Scope: who Article 4 AI literacy actually covers
The most common compliance-planning mistake on Article 4 is starting from the org chart instead of the system inventory. The obligation applies to providers and deployers, not just one side of the relationship, and it applies regardless of the system's risk tier: a minimal-risk internal chatbot triggers the same literacy duty as a high-risk hiring tool, because Article 4 sits outside the Act's risk-tiered structure entirely. Secure Privacy's own Article 26 deployer obligations guide covers the parallel duties that attach specifically to high-risk deployers; Article 4 layers on top of that regardless of tier.
The population also reaches further than payroll. The text covers staff and "other persons dealing with the operation and use of AI systems" on the organization's behalf — which in practice means contractors, agency staff, outsourced service providers, and in some deployment models, clients who operate the system themselves. An organization that trains its full-time employees and stops there has covered a subset of the people the law actually names.
The practical fix is to build the in-scope population from the system side, not the HR side: for every AI system in your inventory, list who touches it (internally and externally) and at what depth, before you design a single training module. That is a different exercise from "who's in the org chart," and it's the one regulators will expect to see evidence of.
If you don't yet have a single list of every AI system your organization uses and who operates each one, that gap is the actual starting point, not the training content. Secure Privacy's AI Governance module registers each system with its risk tier, use case, and responsible owner, which is the same list Article 4 requires you to train against.
Role-differentiated literacy: what each tier actually needs
A single all-staff slide deck does not satisfy a proportionality requirement, because proportionality means the content has to differ by what the role actually does with the system. A workable structure looks like this:
| Role tier | Who's in it | Core literacy content |
|---|---|---|
| Executive and board | Directors and senior leadership with oversight responsibility | Strategic risk exposure, regulatory obligations, incident escalation triggers, board-level accountability for AI decisions |
| System owners and operators | Employees or contractors who configure, monitor, or directly run an AI system | System-specific capabilities and limitations, known failure modes (e.g., hallucination in generative tools), escalation procedures, human-oversight duties |
| Procurement and vendor-facing staff | Anyone selecting or onboarding third-party AI tools | How to evaluate a vendor's own AI Act compliance posture, contractual AI-specific clauses, risk classification questions to ask before signing |
| Developers and technical staff | In-house teams building or customizing AI components | Technical risk sources, data governance obligations, documentation requirements for high-risk components where applicable |
| General workforce | Staff using AI tools incidentally (writing assistants, internal chatbots, analytics copilots) | What the tool is, what it can get wrong, when not to rely on its output unverified, how to report a concern |
Shadow AI is the practical reason this population mapping matters more than the training content itself. As Shannon Yavorsky, a partner at Orrick who co-leads the firm's Cyber, Privacy & Data Innovation practice, put it in a June 2026 UC Berkeley Law discussion of AI Act compliance, system mapping is "really step one" for any AI governance program, because employees routinely adopt unauthorized AI tools and end up "plugging company data into the tool" with no compliance review in sight. A literacy program that only covers sanctioned tools misses exactly the population creating the most exposure.
The evidence question no cited source answers well
This is the question that actually determines whether an inspection goes well: what does a records set proving "sufficient" AI literacy contain? Based on the Commission's own guidance and the structure of what other AI Act obligations require as evidence, a defensible file looks like this:
- Training content and version history. What was taught, when, and how it changed as systems or guidance evolved. A static slide deck from February 2025 that hasn't been touched since is itself a compliance gap.
- Enrollment records tied to the system inventory. Who was enrolled, which system(s) that ties to, and why: not just a headcount, but a traceable link from person to system to role tier.
- Completion and comprehension evidence. Attendance alone is weak; some demonstration of understanding (a short assessment, a signed acknowledgment of role-specific risks) is stronger and directly responsive to an effort-based standard.
- Refresh triggers. A defined set of events that reopen the training obligation for a given population: a new AI system introduced, a role change, new regulatory guidance (including this summer's Digital Omnibus wording change), an AI-related incident, or a scheduled annual review.
- A traceable link back to the system inventory. Every training record should point to the specific AI system entry it covers, so an auditor (or your own team) can answer "show me evidence this operator was trained on this system" in one lookup, not a cross-referencing exercise.
None of the vendor blogs or consultancy pages currently ranking for this topic answer the evidence question with this level of specificity; most restate the obligation and stop at "keep records." Keeping records without a structure that ties them to systems and roles is not the same as being able to produce them coherently when asked.
This is precisely the gap Secure Privacy's Assessments module and Policies & Documents module are built to close: Assessments to run the role-differentiated literacy review as a structured, repeatable process, and Policies & Documents to store the training content, version history, and completion evidence as a single audit-ready file linked back to each system in the inventory.
AI literacy enforcement: what actually changes on 2 August 2026, and what it doesn't
To be precise about the deadline itself: 2 August 2026 does not create the AI literacy obligation. It activates supervisory competence for national market surveillance authorities, who were required to be designated by 2 August 2025 and now gain the formal power to investigate, request evidence, and sanction non-compliance with Article 4 specifically. That is a meaningful shift in practical risk even though the underlying duty is unchanged — an obligation that existed on paper for eighteen months becomes one an inspector can actually act on.
On the penalty question, the honest answer is that it is not settled, and this article will not manufacture false precision where the sources genuinely disagree. Article 99 of the AI Act, which sets out the administrative fine tiers, does not list Article 4 among the specific obligations enumerated under either the €15 million/3%-of-turnover tier (which names Articles 16, 22, 23, 24, and 26) or the €7.5 million/1% tier (which covers supplying incorrect information to authorities). Some commentary treats Article 4 non-compliance as falling under the general €15 million/3% catch-all for operator obligations; other analysis frames it as a factor that aggravates penalties for other violations rather than a standalone fine trigger; and at least one governance-focused source states plainly that penalties for Article 4 specifically will be "determined under national law," since member states retain discretion in how they implement and calibrate enforcement of this particular obligation (WTL Governance). Given that split, the more useful planning assumption is not which number applies, but that an undocumented AI literacy program will worsen your position in any other AI Act investigation a regulator opens — it becomes evidence of a broader governance gap, not an isolated line item.
As of this writing, no individual EU member state has published detailed, concrete Article 4 enforcement guidance beyond confirming their surveillance authority's designation; the most substantive practical guidance available remains the European Commission's own AI literacy Q&A and the AI Office's living repository of literacy practices, both centralized EU-level resources rather than national enforcement rules.
A 30-day starting sequence if you have nothing documented
- Week 1: Build the system inventory. List every AI system in use, including shadow tools staff have adopted independently, with risk tier and business owner for each.
- Week 1–2: Map the population per system. For each system, identify every internal and external person who operates it, and assign a role tier (executive, system owner/operator, procurement, developer, general workforce).
- Week 2: Draft or update the literacy policy. State your organization's standard for "sufficient" per role tier, referencing the Digital Omnibus's effort-based wording rather than an outcome you can't guarantee.
- Week 3: Deliver role-differentiated training and capture completion evidence, including some form of comprehension check, not just attendance.
- Week 3–4: File everything against the system inventory so each system entry links to its training records, and set refresh triggers for new systems, role changes, and regulatory updates.
- Ongoing: Treat this as a live governance process, not a one-time project. Review it at the same cadence as your risk register.
An AI literacy program that lives in someone's inbox is not a program a regulator can verify, and after 2 August 2026 that distinction has real enforcement consequences. Secure Privacy's Privacy & AI Governance Platform connects the AI Governance module's system inventory, Assessments for role-differentiated reviews, and Policies & Documents as the single evidence store, so the population, the training, and the proof are linked in one place instead of scattered across departments.
Frequently Asked Questions
Does Article 4 apply to low-risk AI systems, or only high-risk ones?
It applies to every AI system regardless of risk tier. Article 4 sits outside the Act's risk classification structure entirely, so a minimal-risk internal tool triggers the same literacy obligation as a high-risk system under Annex III.
Who counts as "staff" for AI literacy purposes?
More than employees. The obligation extends to contractors, service providers, and in some cases clients who operate the AI system on the organization's behalf, so the in-scope population should be built from the system inventory rather than the HR roster.
What changed on 2 August 2026 if the obligation already existed?
National market surveillance authorities gained formal supervisory and enforcement power over Article 4 on that date. The underlying duty to support AI literacy has applied since 2 February 2025 and was not altered by this date; what changed is that regulators can now actively investigate and act on it.
Did the Digital Omnibus delay the AI literacy deadline?
No. Regulation (EU) 2026/1744 (the Digital Omnibus on AI), in force since 27 July 2026, reworded Article 4's core duty from an obligation to "ensure a sufficient level" of literacy to an obligation to "support the development of" it, but it did not move the 2 August 2026 supervisory activation date.
What fine applies if my organization fails to meet Article 4?
This is genuinely unresolved. Article 99 does not name Article 4 in either of its two lower fine tiers, and expert commentary is split between treating it as covered by the general €15 million/3%-of-turnover tier, as an aggravating factor for other violations, or as a matter left to national law. Treat the exposure as real rather than betting on a specific figure.
What documentation proves "sufficient" AI literacy to an inspector?
A defensible record set includes training content with version history, enrollment records tied to specific systems, completion and comprehension evidence, defined refresh triggers, and a direct link from each training record back to the relevant entry in your AI system inventory.
Does a written AI use policy satisfy Article 4 on its own?
No. The Commission's guidance is explicit that instruction manuals alone are insufficient; staff need role-specific understanding of a system's risks and limitations, not just a policy document confirming rules exist.
How often does an AI literacy program need to be refreshed?
There's no fixed statutory interval, but a defensible program refreshes training when a new AI system is introduced, when someone's role changes, following relevant regulatory updates (such as the July 2026 Digital Omnibus wording change), after any AI-related incident, and at a minimum on an annual review cycle.
