The EU’s Quiet Training Mandate Now Faces Enforcement

主要收获

Article 4 of the EU AI Act made staff AI literacy a legal duty in February 2025, and enforcement began on August 3, 2026. The obligation is broader than most compliance teams assumed. It covers contractors and vendors operating AI systems on an organization’s behalf, alongside direct employees. A 2025 Pennsylvania settlement against a property management company already confirmed that logic: the company was held accountable for its AI vendor’s failures regardless of who built the tool. Article 4 carries no standalone fine, but regulators treat missing training as an aggravating factor that raises penalties for separate violations. The same competence-over-paperwork standard is showing up in unrelated regimes, including Australia’s CPS 230. What follows sets out what a defensible AI literacy program actually contains and the four steps compliance teams should take now that enforcement is live.

Article 4 of the EU AI Act became applicable on February 2, 2025, requiring every provider and deployer of AI systems to ensure their staff held a sufficient level of AI literacy. No penalty regime backed it, and no authority was checking. Most compliance teams shelved it for later and turned their attention to the deadlines that carried visible teeth.

National market surveillance authorities begin supervising Article 4 on August 3, 2026, the same window in which the Act’s higher-profile obligations also land. What read for a year and a half like background noise has just become one of the first things a regulator asks to see. And the request will not stop at your own payroll.

Who Does the EU AI Act Article 4 Cover?

Article 4 of the EU AI Act covers direct employees, but it also covers contractors and vendor staff operating an AI system on your organization’s behalf. That’s the part most compliance teams miss.

Article 4 is easy to underestimate because it reads like common sense rather than law. Providers and deployers must take measures to ensure their staff, and any other person dealing with AI systems on their behalf, hold a level of AI literacy proportionate to their role and the risk of the system involved. That final clause carries more weight than it first appears.

The standard is not flat or uniform. It scales with context, which sounds like flexibility until you notice what it actually requires: evidence that training was built around the specific systems in use, rather than purchased off a shelf and applied to everyone equally.

The obligation also extends further than many risk and compliance functions have accounted for. It covers contractors and service providers acting on the organization’s behalf, not only direct employees. A vendor’s staff operating an AI tool inside your processes can fall inside your compliance perimeter, even though they never appear on your own payroll.

That blind spot is common: in a recent cross-industry study on AI governance and third-party risk, most organizations rated their own confidence in managing third-party AI risk at just two or three out of five.

The same principle has already played out in the United States. In May 2025, the Pennsylvania Attorney General settled with a property management company whose AI-based platform contributed to maintenance delays and unsafe housing conditions for tenants. The property management company had sourced that platform from a vendor. Pennsylvania held the company accountable regardless.

Article 4 builds similar logic into EU law directly. Buying the tool from someone else does not transfer the obligation to understand how it is being used.

Regulators have also been specific about what will not satisfy the standard. A generic AI awareness session, delivered once and filed away, is unlikely to count as sufficient. What the guidance points to instead looks closer to a documented program: content tailored by role, a record of who completed it and when, and evidence that it reflects the systems actually deployed rather than AI as an abstract subject.

None of this carries a standalone fine under the EU AI Act. That absence is precisely why the obligation has been easy to deprioritize. Regulators have been equally clear, though, that a lack of training will be read as an aggravating factor when something else goes wrong: a biased output, an unsupervised high-risk decision, a data protection failure traced back to how a system was used by staff who were never properly prepared for it.

Article 4 rarely gets enforced in isolation. It tends to surface as the reason a separate penalty was set higher than it might otherwise have been. But there’s a wrinkle worth knowing before you relax: the same logic is already showing up in regulation that has nothing to do with AI.

Are Other Regulators Asking the Same Question?

Australia’s CPS 230 applies the same logic outside the EU, requiring institutions to prove the people managing critical operations and vendor relationships are actually competent, not just that a policy exists.

Step outside the EU and the same instinct appears in supervisory language that has nothing to do with AI specifically. Operational resilience regimes, including Australia’s CPS 230, have spent the past year pushing institutions to demonstrate that a governance framework exists, and that the people operating it are competent to do so.

A risk register with no documented competence behind it satisfies no inspection. A vendor contract with the right clauses but no evidence anyone was trained to enforce them is a paper exercise dressed up as a control.

The common thread across these regimes is a shift in what regulators accept as proof. A policy document was, for years, often sufficient to demonstrate a framework existed.

Supervisors increasingly want to see that the humans inside that framework understand what it requires of them, and that the understanding is current rather than inherited from an induction session several roles ago. Training has moved from something HR schedules on a calendar to something compliance and risk teams need to defend under direct scrutiny.

The result is a shift in who owns the problem. AI literacy in particular sits awkwardly between HR, legal, risk, and IT, and compliance teams that leave it with whichever function happens to notice the deadline first tend to produce exactly the generic, undocumented training that regulators have signaled will not hold up. Building it properly means treating training design as a compliance deliverable with its own evidence trail, owned deliberately, rather than a course booked once and left to age.

The practical consequence is that training now needs to be defensible in the same way a policy or a risk assessment is defensible. An auditor or supervisor asking who was trained on a given system, when, and to what standard, is asking a question that many enterprises currently cannot answer with more than a completion certificate from a generic e-learning module.

Under CPS 230, the equivalent question is asked of the people managing critical operations and material vendor relationships. Under Article 4, it is asked of anyone dealing with an AI system on the organization’s behalf. The wording differs; the expectation does not. The overlap is not an accident.

What Does a Defensible AI Literacy Program Contain?

A defensible AI literacy program differentiates training by role, covers the specific AI systems genuinely in use, produces a dated record of who was trained on what, and extends the same standard to contractors and vendors, not only direct employees.

A program built to survive scrutiny shares a few features, regardless of jurisdiction or framework. It differentiates by role, so a named human overseer working with a high-risk system receives materially different content from someone using a general-purpose assistant to draft correspondence.

It is specific to the systems genuinely in use, rather than a broad primer on artificial intelligence disconnected from what staff actually touch day to day. It produces a record, showing who was trained, on what, and when, refreshed as systems and guidance evolve rather than delivered once at onboarding. And it treats contractors and service providers as part of the same perimeter as employees, since regulators have made clear the obligation does not end at the payroll line.

None of this is conceptually difficult. What makes it hard in practice is coordination: bringing together the people who understand the regulatory requirement, the people who know which systems are genuinely deployed, and the people who can deliver training at the scale a large enterprise needs, all before an authority requests evidence rather than intentions. The coordination problem is exactly where most programs stall.

What Compliance Teams Should Do Now

Risk and compliance leaders who spent the months before August 3 treating this as a genuine compliance deadline can already produce a training record on request. Everyone else is now closing that gap with a regulator already watching. Four steps close it fastest:

– Map every AI system actually in use, and who touches it, staff, contractors, and vendor personnel included. You cannot build role-based training against a system inventory you do not have.

– Audit existing training against the role-and-risk standard, not the completion-certificate standard. A single e-learning module logged once at onboarding will not satisfy an auditor asking what a named individual understood about a specific system.

– Extend the obligation into vendor contracts. If a contractor’s staff operate an AI tool on your behalf, your evidence trail needs to cover them, not just your own payroll.

– Assign an owner. Article 4 sits between HR, legal, risk and IT by default, which means it belongs to whichever of those functions is prepared to defend it, not whichever one happens to notice the deadline first.

That distinction, a defensible record versus an assembled one, tends to matter more to a regulator deciding how much latitude to extend than the specific content of the training itself.

The Choice in Front of You Now

Now that August 3 has passed, a market surveillance authority can ask you to prove you met it: a name, a system, a date, and evidence that the training behind it was real.

If you spent the months before that date mapping your systems, auditing your training, extending your contracts, and naming an owner, the answer is a document you already have. If you did not, the answer is a scramble, built after the fact, in front of an audience with little reason to extend you patience.

Start on the answer now. The deadline is no longer a date on a calendar. It is the reason someone might already be asking.

Most AI risk in your compliance perimeter comes from vendors, not systems you built. Mitratech Prevalent, a TPRM platform, extends your third-party risk program to cover that exposure; Mitratech PolicyHub gives you an auditable record of who was trained on what and when; and Mitratech Syntrio delivers the training itself, tailored by role rather than issued as one generic module.
Learn more now.