Regulation (EU) 2024/1689, known as the AI Act, set 2 August 2026 as its general date of application. That date has now passed, and much of the coverage summarised it by saying the European Union had just delayed the law. That summary is misleading for anyone who has to answer for their staff training.
The delay is real, but it has a specific perimeter. The Digital Omnibus on AI moved the obligations for high-risk systems, the ones requiring risk management, technical documentation, conformity assessment and human oversight. What it did not move is the obligation that deals with people.
This piece does not walk through the whole regulation or get into risk classification. It focuses on Article 4, on what it requires regarding training, on who it reaches inside an organisation that merely uses AI tools, and on what evidence supports that compliance.
What did the Digital Omnibus postpone, and what stayed on schedule?
The Digital Omnibus on AI reshuffled the regulation’s calendar during 2026. The shift affects high-risk systems rather than the regulation as a whole, and that distinction changes the headline considerably.
| Block of obligations | Current date |
|---|---|
| AI literacy (Article 4) | In application since 2 February 2025 |
| Prohibited practices | In application since 2 February 2025 |
| Transparency (Article 50) | 2 August 2026, unchanged |
| Annex III high-risk systems | 2 December 2027, postponed |
| Annex I high-risk systems | 2 August 2028, postponed |
Article 4 does not appear among the postponed items because it had already been in application since February 2025. What the Digital Omnibus did change is its wording. The obligation moved from ensuring a sufficient level of AI literacy to supporting the development of that literacy, a formulation that is less demanding on the outcome while leaving the duty to act intact.
That nuance should not be read as a downgrade, because the opposite happened in parallel. The European Commission explains in its questions and answers on AI literacy that the obligation already applied from 2 February 2025, and that national market surveillance authorities started supervising and enforcing it on 2 August 2026.
For a year and a half the obligation existed without an authority reviewing it. That period is over.
What does Article 4 require on AI literacy?
Article 4 requires providers and deployers of AI systems to take measures so that their staff, and other people dealing with the operation and use of those systems on their behalf, develop AI literacy.
AI literacy is a person’s ability to use artificial intelligence systems with informed judgement, understanding what the tool can do, where it fails and what consequences its output has for those on the receiving end. It is not technical training on how a model is built, but judgement about how it is used and when its output deserves scepticism.
The regulation sets no syllabus, no minimum hours and no certificate to close out. Instead it lists the factors that shape the measure, and they are what make two organisations with identical headcount train differently.
- Each person’s prior technical knowledge, experience, education and training.
- The context in which the AI systems will be used.
- The people or groups of people on whom those systems will be used.
That last factor is the one most often overlooked. The requirement depends not only on who operates the tool, but on who its output lands on. A system involved in decisions about candidates, customers or patients raises the bar for what its operator needs to understand, however simple the interface may be.
The absence of a fixed syllabus is not a gap worth celebrating. It means the organisation decides the scope and then has to justify it, much as happens with the proportionality principle in other European frameworks. It is the same logic of self-assessed responsibility already present in the awareness requirements of the NIS2 Directive.
Who does the obligation reach inside your organisation?
This is the point most often miscalculated. Article 4 does not only address whoever develops AI, it also addresses the deployer, meaning whoever uses an AI system under their own authority in a professional context.
With that definition, the obligation stops being a technology-sector matter. A consultancy using an assistant to draft documents, an HR department screening CVs with an off-the-shelf tool, or a support team running a chatbot all fall within scope without having written a line of code.
The usual confusion consists of looking at risk classification before looking at the role itself. A system not being high-risk, and its specific obligations having moved to December 2027, does not affect Article 4, which applies regardless of the risk level of the system in use. An organisation can sit entirely outside Annex III and still have to train whoever operates its tools.
Working out whether you are in scope is, again, the organisation’s own call rather than a notification arriving from outside. It is the same exercise DORA forces on its scope of application, where no official register of covered entities exists either.
The perimeter does not stop at payroll either. The article refers to staff and other people dealing with the operation and use of the systems on the organisation’s behalf, so a contractor operating the tool falls inside the same circle. It is the same shift towards the supply chain seen in other frameworks, and one worth resolving before it shows up in a customer’s security questionnaire.
There is a side effect worth noting. When an organisation does not train its people on AI use, the use does not disappear. It becomes invisible and migrates to personal tools beyond any control, a pattern examined in why blocking ChatGPT does not solve shadow AI. AI literacy and reducing that risk are the same job.
How is AI literacy demonstrated to the authority?
Through records, and records that explain decisions. Because Article 4 asks for measures calibrated to each person’s profile and to the context of use, an attendance list from a generic session answers the question an authority will actually ask rather poorly.
On the people layer, the evidence supporting compliance usually rests on these elements.
- An inventory of the AI systems in use and the areas operating them, which is what sets the scope of the training.
- Identification of each person’s role in relation to those systems, distinguishing who decides, who operates and who reviews the output.
- Content differentiated by that role, with a scope defensible against the Article 4 factors.
- A record of who received training, when and on what, covering external personnel operating systems on the organisation’s behalf.
- Sustained updating over time, because the tool catalogue changes faster than the annual training plan.
That demand for traceability by role is nothing new for anyone who has worked through other frameworks. The difference between evidencing training and evidencing behaviour is something I covered when breaking down control 6.3 of ISO 27001:2022, and the problem of rebuilding that trail by hand appears in the audit questions your spreadsheet cannot answer.
SMARTFENSE, as a security awareness platform operating across Europe and Latin America, offers a training programme dedicated to the AI Act with 10 modules organised into two tracks, one for all staff and one for management and C-Level. Every action is recorded and segmented by group and by role, which is the unit in which Article 4 frames the requirement. The detail is on the AI Act compliance page, and the full regulatory map on the compliance page.
The AI Act calendar moved for systems and stood still for people. That asymmetry says something about how the European legislator reads the risk of this technology, and it leaves organisations with an obligation that has been in force for over a year and now, on top of that, has someone reviewing it.
Leave a Reply