The AI literacy obligation: who it covers and how you prove it

Almost everything written about the EU AI Act sorts obligations by the risk of the use: the more the system decides about a person, the more it demands of you. There is one exception, and it is the one boards discuss least. AI literacy obligations do not scale with risk. They reach you because you use AI at all, and they have been live longer than most of the regulation: according to the Commission’s regulatory framework, they entered into application from 2 February 2025, alongside the prohibited practices.

A note on method, related to the one I use in the EU AI Act and AI agents. I give this date because it is published in the Commission’s framework and I can show you where. I do not cite article numbers, because the detail moves and the text itself is the place for it. What follows is the operating criterion I would apply in a company that already has agents doing work.

Why this one slips under the radar

The rest of the regulation reads like a matrix. You classify each use, see which band it falls into, and know what applies. I describe that work in the EU AI Act and AI agents and will not repeat it here. The practical effect is that a board that has classified its uses well, and placed most of them in bounded back office, leaves the meeting relaxed, because the matrix has told them the requirements are light.

AI literacy does not sit in that matrix. This duty looks somewhere else. It asks whether the people who work with the system understand what it does. An agent reconciling invoices sits in the mildest band of the regulation, and the person reviewing its exceptions still has to know what they are reviewing. That is why the duty survives the conclusion that “ours is low risk”. The conclusion does not switch it off.

The perimeter: who is inside

The first question is how many people it reaches, before what training to give them. This is where every headcount I have seen falls short, because it counts users of a tool rather than people who work with the system.

I draw the perimeter with four questions, and anyone who falls into any of them is inside:

• Who operates the system? Whoever launches the agent, works its exception queue, or configures its permissions.
• Who acts on its output? The controller signing off an entry an agent proposed works with AI even if they never open the tool. This is the most forgotten group, and the one that does most damage when it trusts too readily.
• Who works with the system on your behalf without being on your payroll? Contractors, seconded staff, the provider’s team running your process.
• Who is putting AI into a process without telling anyone? No list survives this one. Until you surface the usage you cannot draw the perimeter, and that groundwork is in shadow AI.

Putting the third group inside is not a judgement call of mine. The duty is written over staff and over other persons dealing, on the company’s behalf, with the operation and use of the systems, and that wording reaches past who signs the payroll. It is the uncomfortable part of the perimeter, because it means outsourcing the operation does not shrink it. It splits it.

What counts as sufficient competence

The short answer is that it depends on the role, and that dependency is the useful part. A generic two-hour course for the whole company is cheap to buy and easy to evidence, which is why it is the answer most often sold. As proof of competence it is thin, because it does not distinguish the person configuring permissions from the person reading a report.

The test I use is three questions, per person and per role. What does the system you work with do. Where does it fail, with a concrete example from your own process. What do you do when you suspect it got something wrong, including who you tell and what authority you have to stop it. Anyone who cannot answer all three about their own work is not trained, whatever certificate they hold.

The content of that training, especially the hard part of teaching people to supervise automated decisions, is already covered in change management for AI agents, and that is where I send you. One possible confusion is worth clearing. In prepare your company for agents I argue that general training does not prepare a process, and that still holds. These are two different things: preparing a process is work on maps, rules and data, while this is a duty about people that exists even when the process is already clean.

When a provider operates the agents

Here comes the question finance directors ask me most. If the provider runs the capability, is the training their problem?

Partly, and the split is worth writing down. The provider answers for its own people, and you can require that in the contract: what training whoever touches your process receives, how often it is refreshed, and what they hand you as evidence when you ask. It is one more clause among those I list in AI managed services, and it costs little to add before signing and a lot afterwards. This duty splits the way it does because the two of you hold different roles under the regulation, and which one is yours is what I work through in provider or deployer.

You answer for your own people, and you still have people inside the perimeter even if you never touch the system. The controller who validates, the process owner who decides on exceptions and the executive who approves the agent’s mandate are yours. The split resembles the one that governs personal data, where the provider acts on your behalf and you remain answerable, which I cover from that angle in AI agents and data privacy. With one difference worth keeping straight: that is data protection law, and this is a duty of the AI regulation about the competence of people.

The evidence: what you show when asked

A duty without evidence is an intention. The evidence here is documentary and it is about people, and that distinction is the one I have seen confused most often.

The agent’s trace, which takes up almost the whole technical conversation and which I develop in auditing AI agent decisions, does not serve here. It demonstrates what the system did, not that the person supervising it knows how to supervise it. What I would keep is duller and shorter:

• Who is inside the perimeter, with their role, reviewed when someone changes job or a new system arrives.
• What each of them received and when, with content matched to their role rather than one deck for everyone.
• What was refreshed and why, when the system, the process or the model underneath it changes.
• What the provider certifies about its own staff, in whatever format you agreed.

With that you can answer an audit question in an afternoon. Without it you will have to say you do not know, and that answer lands worse the tidier the rest of your compliance looks. This work sits inside the framework I describe in AI agent governance, and the entry point to the whole set is AI agents for business.

Frequently Asked Questions

Is AI literacy mandatory for every company?

The European regulation’s AI literacy obligations do not depend on the risk level of the system but on the company using AI at all. According to the framework published by the Commission, they entered into application from 2 February 2025. Classifying your uses as low risk does not switch the duty off, because it looks at the people who work with the system.

Who does it cover inside the company?

Whoever operates the agent, whoever supervises its exceptions, and also whoever acts on its output without ever opening the tool, which is the group almost no headcount captures. It also reaches contractors and the provider’s staff, because the duty is written over those dealing with the operation and use of the systems on the company’s behalf, whether or not they are on its payroll.

If I contract the operation out, is training the provider’s job?

They answer for their own people, and you require it in the contract with a clause on what training they receive, how often it is refreshed, and what evidence they hand over. You answer for yours, and you still have people inside the perimeter: whoever validates, whoever decides on exceptions and whoever approves the agent’s mandate.

Does a general AI course for the whole company do the job?

It is convenient to buy and weak as proof, because it does not distinguish roles. Competence is measured per role: knowing what the system you work with does, where it fails in your own process, and what you do when you suspect it got something wrong. An identical certificate for the person setting permissions and the person reading a report evidences neither.