AI literacy under Article 4 is an adoption problem

Since July 2026 the AI Act asks providers and deployers to take measures that support their staff's AI literacy, without requiring any specific level from any individual. I learned how that kind of duty plays out from analytics adoption at JD Sports Group, where getting people trained was the easy part and keeping the habit was the real work.

What changed in Article 4

Article 4 has applied since 2 February 2025. The original text asked providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026) rewrote it. Providers and deployers now have to take measures to support the development of AI literacy of their staff, the text adds that this does not require any specific level of AI literacy of any individual, and the Commission has to publish practical examples of how to comply (AI Act Explorer).

The Commission's AI literacy Q&A says there is no need for a certificate, that relying on the instructions for use is not sufficient, and that organisations can keep an internal record of their training and guidance.

Read quickly, the new wording sounds lighter. In practice it leaves each organisation to decide what support means for its people and how it will know whether the support is working. I had to answer the same question for analytics.

What analytics adoption taught me

At JD Sports Group I was product owner of a programme of 8 measurement projects. The result I value most from it is a measure of behaviour: adoption of analytics grew 70% year on year. Stakeholder satisfaction was 90%, which was good to hear, but adoption told us whether people used the data when they made decisions.

Two practices were part of the programme from the start. Each implementation came with an operational dashboard, so people learned on the tool they would use. When an implementation moved into business as usual, a short survey checked whether it met the need it was built for.

The checkout project taught me the other half. Customer Care logged the reason for each live chat in Salesforce, and the weekly report built on those reasons was still used in their meetings long after the project closed. As the team hired new people, the logging discipline dropped and the reasons became less reliable, while the report kept arriving every week. The plan had been a one-off handover, so I made periodic retraining of Customer Care part of how the report was maintained.

Why AI tools behave the same way

An AI tool launched with one training session is in the same position as that report. People who join after the session never had it, the tool changes with each model update, and the habits that make output safe to use fade quietly: checking a claim against its source, or knowing which customer data must never go into a prompt. Nothing breaks on the day the habit goes, which is why a course completion rate says little about it.

Day to day I use AI to automate repetitive tasks, and my own time goes on verifying the output before I sign it off. That verification step is the first thing I would teach.

What I would do today

1. Start with an inventory of who uses which AI tools and for what. The role decides what literacy means: someone drafting customer replies with an assistant needs different knowledge from an analyst building a feature on a large language model.
2. Put AI guidance into onboarding, and repeat it on a date in the calendar and whenever a tool or its use changes.
3. Measure what people do with the tools. Two useful signals are the share of AI-assisted outputs that someone reviewed before they went out, and the incidents and near misses that people report.
4. Keep a dated record of the support each group received. The Q&A asks for no certificate, and a record is the simplest way to show what was done and when.

Who should see the AI's advice first? Why we put nutritionists in the loop

In 2024 we started building Nutr(IA) Coach, an AI product for nutrition. The first big product decision had little to do with models or prompts. It was about who receives the output. As a team we decided that the AI would work for nutritionists, and that a nutritionist would review its suggestions before they reached anyone.

The decision

The obvious version of the product gave nutrition advice straight to the public. It has the most potential users and the shortest path to growth. We chose the other version: the nutritionist uses the AI to prepare and speed up their work, and the person who receives the advice deals with a professional, with the AI behind them.

We made that call as a team, and the reason was ethical. Advice about what someone eats touches their health, and a person reading a confident answer on a screen has no easy way to tell a good suggestion from a harmful one. A nutritionist can, and can also see what the screen does not: the person's history, their circumstances and the questions that never made it into the prompt.

What the frameworks say

The principle has a long history in AI ethics, and reading the frameworks helped us put words to what we already felt.

The World Health Organization's guidance on ethics and governance of AI for health (2021) sets out six principles. The first is protecting human autonomy: humans should remain in control of health-care systems and medical decisions. Its 2024 guidance on large multi-modal models applies the same principles to generative AI.

The EU's Ethics Guidelines for Trustworthy AI (2019) list human agency and oversight first among seven requirements, and describe human-in-the-loop as one way to achieve it.

The AI Act turns human oversight into a legal duty for high-risk systems (Article 14), and since 2 February 2025 its first obligations apply, AI literacy among them. I am not saying the Act classes our product as high-risk. The point is that regulators and health bodies reached the same conclusion we did: when the stakes are personal, a person stays in charge.

The hard part: a reviewer can still rubber-stamp

A human in the loop is only a safeguard if the human actually reviews. Automation bias is well documented: people tend to accept a system's suggestion, more so when it is usually right and they are busy. A 2012 systematic review in JAMIA found it in clinical decision support. A nutritionist who approves every draft with one click gives the same protection as no nutritionist at all.

So the design question moves from "is there a human?" to "does the human have the time, the information and a reason to disagree?" These are the checks I would apply to any human-in-the-loop design:

1. The professional can see why the AI made a suggestion and which data it used.
2. Editing a draft is as quick as accepting it, so changing it costs nothing.
3. The AI says what it cannot handle and passes those cases straight to the professional.
4. Responsibility is written down: the professional signs the advice, and the record shows it.

What an analyst brings to it

Human in the loop also creates a measurement point that a direct-to-consumer product lacks. Every suggestion is accepted, edited or rejected by an expert. Those rates say more about the quality of the AI than a satisfaction score, and a rise in one-click approvals is an early warning of automation bias. Before a feature goes live, I want to know how we will measure it, and this design gives us something worth measuring.