You Can't Train People on AI You Can't See

Today, 3 August 2026, national market surveillance authorities across the EU begin supervising and enforcing Article 4 of the AI Act, the AI literacy obligation. You'll see a lot of content about that this week. Most of it will quote a version of Article 4 that is no longer the law.

On 27 July 2026, Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force. It's the first amendment to the AI Act since 2024, and among other things it rewrote Article 4. The old version required providers and deployers to take measures to ensure a sufficient level of AI literacy among their staff and other people operating AI on their behalf. The amended version asks them to take measures supporting the development of that literacy, with the Commission and Member States picking up a bigger share of the promotional work and the AI Board set to publish common objectives.

Lawyers call that a shift from an obligation of result to an obligation of effort. It is softer. It is also still binding on every provider and deployer, and it is being supervised starting today.

I want to explain why the softening makes this more interesting for security teams rather than less, and why I think most organizations are about to answer the wrong question.

An obligation of effort is an obligation to show your work

If the law demands a result, you argue about whether you achieved it. If the law demands measures, you have to produce the measures. That is an evidence question, and evidence questions land on whoever holds the inventory.

So the sentence that matters most in Article 4 hasn't changed at all: the duty covers your staff and other persons dealing with the operation and use of AI systems on your behalf. That language reasonably reads to include contractors, service providers, resellers, and channel partners.

If you're a software vendor whose partners activate AI-enabled features in customer environments, those partners sit inside your Article 4 perimeter. If you use a managed service provider that runs AI tooling against your infrastructure, that relationship needs covering too. This is a supply chain obligation wearing an HR costume, and it will show up in contracts and partner onboarding long before it shows up in a training module.

The Commission's guidance is also unchanged on the point that matters operationally: literacy has to fit the role and the context. A salesperson using an assistant to draft customer commitments, an HR reviewer using AI to sift applications, and an engineer running a coding agent with commit access face completely different failure modes. One sixty-minute course for all three is a paper control, and it reads like one under scrutiny.

This still isn't a fine problem

I've already seen vendors staple the AI Act's biggest penalty numbers to Article 4. It doesn't hold up, and it's worth being precise about why.

The Omnibus left the penalty ceilings alone: €35 million or 7% of global turnover for prohibited practices, €15 million or 3% for a specified list of operator obligations. Article 4 is not on that list. Article 50, the transparency duty that went live the day before, is. So the €15 million figure being attached to AI literacy in a lot of commentary this week actually belongs to a different article. On Article 4, Member States retain wide latitude in how they supervise under national law. Anyone telling you an Article 4 gap means an automatic multi-million euro fine is selling you something. Confirm the position in your own markets with counsel.

The realistic exposure is more mundane and, I'd argue, more expensive:

Diligence friction. Enterprise buyers are already asking who uses a given AI feature, what those people were told, and how errors get escalated. A policy PDF is not a satisfying answer, and unsatisfying answers add weeks to deals.
Your position after an incident. If an AI-assisted decision causes harm and you can't show the operator had relevant, current guidance, you're negotiating with regulators, insurers, and customers from a much weaker footing. Not because of Article 4 specifically, but because "nobody told them" is indefensible under every framework at once.
Partner drag. Every partner who can't answer the question becomes your problem, because the customer asked you.

One more thing worth knowing, since it's the reason a lot of people think they got a reprieve. The Omnibus did defer the heavy high-risk obligations, standalone Annex III systems to December 2027 and embedded Annex I systems to August 2028. Article 4 was not deferred. Neither was 2 August 2026 for most other provisions. The headlines said delay; the literacy duty went live eighteen months ago and is supervised from today.

The dependency nobody planned for

Here's the part the compliance conversation keeps skipping.

Every credible Article 4 response starts with the same artifact: a list of the AI actually in use, who operates it, and what it can reach. You can't write role-specific guidance for a system you haven't discovered. You can't name a business owner for an agent nobody knows is running. You can't define an escalation path for a workflow that lives entirely inside someone's personal tooling.

And that inventory is exactly the thing most organizations don't have. Cisco's State of AI Security 2026 report found only 29% of organizations consider themselves ready to secure agentic AI deployments. My read of the field is that 29% is optimistic.

Article 50 makes the same point from the other direction, and it went live on 2 August, the day before Article 4 enforcement started. If an AI system interacts with people, you have to tell them it's an AI. Synthetic output has to carry machine-readable marking. And if you've put your own branding on a chatbot built over a foundation model, you're likely wearing the provider hat for it, which catches internal systems too: the IT help desk assistant, the incident reporting bot somebody in compliance stood up last quarter. You cannot disclose for a chatbot nobody registered. Worth noting that the marking duty has a transition to 2 December 2026, but only for generative systems already on the EU market before 2 August. Anything newer complies now.

Two obligations, one day apart, both assuming an inventory that in most organizations doesn't exist.

The AI moved to the workstation and the governance didn't follow

For a couple of years the industry's mental model of AI risk was cloud-shaped: model endpoints, APIs, data pipelines, people pasting things into a chat window. That was right at the time. It isn't where the interesting risk sits now.

Today it's on the employee's machine. Coding agents with shell access and the developer's own credentials sitting on disk. Desktop assistants reading local files and mailboxes. MCP servers wired into internal systems. Skills installed by individuals from public registries. Models called with personal API keys. None of it appears in the AI governance spreadsheet. All of it is in scope for Article 4.

Four things are worth inventorying, and most programs track none of them:

Agents. What's running, where, at what autonomy level, and with whose credentials.
Skills. The instructions those agents load, which are third-party code even though they look like configuration.
MCP servers. The tool connections that decide what an agent can actually touch.
Models. Which ones your people route work through, and whether you approved any of them.

That last one needs a caveat, because I keep hearing it stated wrongly. The AI Act does not publish a list of approved models, and nobody should imply otherwise. The constraints are yours to set: data residency, jurisdiction, whether prompts get used for training, sector rules. But if your staff are quietly routing customer data through a model you never sanctioned, your carefully written role guidance is decorative.

Guidance is not a control

Now the unpopular part. Telling people how to use AI responsibly is necessary and nowhere near sufficient, and an obligation of effort should not be read as permission to stop at the telling.

Look one layer down. Academic work published in January 2026 found more than a quarter of publicly available agent skills contained at least one security vulnerability, across fourteen distinct patterns: prompt injection, data exfiltration, privilege escalation, supply chain attacks. A follow-up study in February confirmed 157 malicious skills through behavioral testing and traced 54% of them to a single actor running templated brand impersonation at scale. In January a coordinated campaign called ClawHavoc pushed 341 malicious skills into one registry in three days, all reporting to the same command and control server. Some wrote instructions into the agent's memory files, so the backdoor survived removal of the skill itself.

None of that is a literacy problem. You cannot train a user to spot a hidden Unicode instruction inside a SKILL.md file. Manual review was the recommended control, and manual review demonstrably missed these.

So the honest version of "measures supporting the development of AI literacy" has two halves. Tell people what the system is for, where it breaks, when a human has to decide, and who to escalate to. Then make the bad outcome structurally hard: decide which AI tooling is permitted, scope what it can reach, and stop the rest before it runs. Malicious skills never execute. Banned agents don't start. Unapproved models never see company data.

That's the difference between reactive and preemptive. Runtime detection watches for the bullet. I'd rather take the gun off the table. Both have their place and they work well together, but only one of them hands you something to show a regulator or a buyer.

What I'd do in the next sixty days

Not a compliance program. Four things.

Name an executive owner for the Article 4 response and put it into board risk reporting. Ambiguous ownership is the single biggest reason this sits untouched.
Build the map. Which AI systems are in use, whether you're provider or deployer for each, who operates them, whether there's an EU nexus, who's affected, and who owns it. Include the workstations. Include the shadow estate, because that's where the surprises live.
Pick your five highest-consequence uses, meaning anything touching customers, employees, or regulated decisions, and write one page for each: what the system is for, where it's known to be unreliable, the point where a human has to decide, and who to escalate to. Short, specific, dated, reviewed after incidents.
Put the evidence somewhere buyers can find it. Trust center, RFP library, partner onboarding pack. Assume every strategic customer asks this year, because they will.

Then push the same expectation outward. Partners and service providers operating AI on your behalf should get applicable guidance before they turn on AI-enabled offerings, and that belongs in the contract rather than in a goodwill conversation.

The uncomfortable version

Most AI governance programs have inventoried models, suppliers, and data, then stopped. Article 4 exposes the layer underneath: people making consequential decisions with tools nobody cataloged, under guidance nobody wrote, with no obvious way to raise a hand when something looks wrong.

The Omnibus made that duty easier to satisfy on paper. It did nothing to make the underlying problem smaller, and starting today somebody can ask you to show your measures.

You can't govern what you can't see, and you certainly can't train for it.

Where to start

Last week we expanded Mondoo's platform to cover discovery, risk assessment, policy control, and remediation for enterprise AI agents. It inventories every agent, skill, MCP server, and model across your fleet, generates an AI Bill of Materials, and drives fixes through the tools your teams already run, so there's no new agent to deploy.

Want to check what your developers are already running before you talk to anyone? AI Skills Check is free and works across every registry.