Training your teams on AI is now an obligation

Yes, and for longer than most people realise. Article 4 of the AI Act has required, since 2 February 2025, a sufficient level of AI literacy among the people who use these systems on the company’s behalf.

That obligation has not moved since. The 2027 deferral concerns the rules on high-risk systems; Article 4 already applies, and it covers any employer putting an AI tool into a team’s hands, including a consumer assistant.

An obligation of result, with no imposed format

This is what unsettles people, and it is actually good news. The text imposes no duration, no syllabus, no certification. It asks for a level sufficient in view of the context and the risks.

Proportionality is therefore the governing rule here. Two well-aimed hours are enough for a team using a drafting assistant. More is needed for a team delegating tasks that touch candidates, because there an error has consequences for third parties.

What does matter is being able to evidence it. A session with no trace did not happen from an auditor’s point of view. Three things are enough to constitute proof: an attendance sheet or read receipt, the dated material used, and its inclusion in the onboarding path for new joiners: the point everybody forgets six months later.

Three documents not to conflate

This is the most common mistake, and it renders the documents inoperative.

The acceptable-use charter carries the principles: what is expected, encouraged, prohibited. It addresses people and reads in ten minutes.

The AI policy describes the procedures: approved tools, permitted data categories, approval routes, who to contact in case of doubt. It addresses the teams who operate the system and changes more often than the charter.

The internal rulebook is the only one of the three that can carry a scale of sanctions, and it follows its own procedure, consultation, filing, notification of the labour inspectorate. Writing “any breach of this charter may result in sanctions” into a charter creates no enforceable sanction.

The sequence that works: the charter says why, the policy says how, the rulebook says what happens if.

What a charter must say when the tool is an agent

Most templates available online were written for conversational assistants. They talk about checking outputs, keeping prompts confidential and labelling generated content. That is useful and insufficient when the tool acts instead of answering.

Four additional points become necessary in that case.

What may be delegated, and what may not. The list of actual tasks, not a list of principles. It is the most-read part and the only one that changes behaviour: it maps directly onto the order in which you delegate.

Who approves what. Every outbound action needs a named owner. A charter that stops at “human oversight” without saying who oversees produces no oversight.

What the agent may not do, even when asked. Settle a rejection, act on a personal account, bypass an approval. Saying so in the charter also protects the employee who refuses, and it maps onto what an agent should be structurally incapable of.

What is logged, and who can read it. It is the first question asked in the room, and avoiding it costs more than answering it.

The content that actually drives adoption

A charter read once and filed has no effect. The ones that work answer the three questions teams genuinely have and almost never ask out loud.

“Is this going to replace me?” Avoiding it is the worst option: silence reads as yes. A direct sentence on what the tool takes on and what it does not beats a reassuring paragraph.

“Will I be held responsible for its mistake?” The answer must be written down. An employee who approves a flawed output in good faith is not in the same position as one who switched off a check, and the charter is where that difference gets stated.

“Is this here to monitor me?” The log exists to reconstruct what the agent did, not to measure what people do. Write that down, and write who has access.

Those three answers explain much of the gap between projects that stick and those abandoned while they were working.

What two useful hours look like

The complaint about AI training is almost always the same: it explains what a language model is to people who want to know what to do with it on Monday morning. Here is a two-hour agenda that has the merit of producing actual usage.

Twenty minutes, what the tool does, by doing it. No slides. You open the tool and work a real case the team brought: a profile search, a write-up to file, a follow-up to prepare. A demonstration by a colleague is worth ten by the vendor.

Thirty minutes: the mistakes, live. This is the part nobody does and the most instructive. You deliberately provoke a wrong answer: a question about missing data, a profile whose availability dates from last year. A team that has seen the tool get it wrong once in real conditions develops the right checking reflex, whereas a team told “always verify” verifies nothing after three weeks.

Thirty minutes, what is not delegated. The list, with the reasons. This is where you explain the difference between preparing a rejection and deciding one, and where you answer the responsibility question.

Twenty minutes, data. What may go in, what may not, and above all what becomes of information once entered. Two concrete examples beat the entire GDPR vocabulary.

Twenty minutes, questions. Plan the time, and accept that the first three will be about jobs.

Two rules govern how you actually run it. Train by team, not by job family: a business manager’s questions have nothing in common with a recruiter’s. And run it again at three months, one hour, on the usage actually observed: that is the more profitable of the two sessions, because the questions are finally the right ones.

One caveat worth stating for firms operating across borders. Article 4 is European and applies wherever the AI system is used in the Union, including to a team based elsewhere serving EU clients. Conversely, national labour law layers on top of it: the works council obligations described below are French, and the equivalent bodies elsewhere have their own thresholds and timings. Check the second layer before assuming the first is the whole picture.

Governance and timing

Three things to plan, none of them heavy.

Presentation to the works council before adoption. Whenever the charter accompanies a deployment that changes working conditions, it belongs in the same file as the consultation on the tool. Handling them together saves a full cycle.

A named committee. Two or three people, management, an operational lead, the data referent, who arbitrate new cases. With no addressee, questions do not travel upward and practice settles on its own, in the wrong direction.

A review at least annually. Write the review date into the document itself. A 2025 charter still talking about checking a chatbot’s answers no longer describes the tools in use, and an out-of-date charter is worse than none: it creates the impression the subject is handled.

One last point, more honest than legal. The Article 4 obligation formalises what was already the only thing that works: a team that understands what the tool does uses it, a team that does not either distrusts it or over-trusts it. Both failures are expensive, and two hours of training prevents both.