Article 4 of the EU AI Act requires the people who operate and use AI systems on your behalf to have a sufficient level of AI literacy. It is a standing obligation rather than a one-off webinar, and it is evidenced with records, not with a statement that training happened.
dfzoo AI Institute delivers the AI literacy training required by Article 4 of Regulation (EU) 2024/1689 for organizations operating in the European Union, including companies based outside Poland with EU customers or staff. The obligation has applied since 2 February 2025 and was not covered by the omnibus package that postponed high-risk compliance deadlines. We build the programme per role: one thing for the board and procurement, another for the people operating a system and exercising human oversight, another for engineering. What stays with the client is the evidence pack: a register of trained people, the per-role programme with dates, a validation record of learning outcomes and named certificates. DFZOO.COM Sp. z o.o. holds ISO 9001:2015 issued by DNV Business Assurance, certificate no. 10000439701-MSC-RvA-POL.
Article 4 of Regulation (EU) 2024/1689 puts an obligation on providers and deployers of AI systems to ensure a sufficient level of AI literacy among their staff and other people dealing with the operation and use of those systems on their behalf. The article names what has to be taken into account: technical knowledge, experience, education and training, the context the systems are used in, and the people or groups the systems are used on.
There is no hour count in the text, no named course and no requirement for an external certificate. The test is fit to role, so an auditor or a customer looks at two things: whether the programme matched what that person actually does with the AI system, and whether you can show it.
The personal scope is the widest in the whole Regulation. It reaches people who are not your employees but act on your behalf: contractors, agencies and subcontractors operating your systems.
The obligation has applied since 2 February 2025. The 2026 omnibus package moved high-risk compliance deadlines, and left Article 4 where it was.
This is where paper compliance is manufactured. One course for everyone ticks the box and changes nothing about how people work with the system. Below is the starting layout we bring in, then adapt to your systems and roles.
The evidence column is the one that matters later. It answers the question that arrives months after the training: what will you show to prove that this person received a programme matched to their role.
| Role | What this person has to understand | Scope of training | Evidence that stays |
|---|---|---|---|
| Board and buyers | What the company takes on when it buys an AI system, and which duties follow the provider role rather than the deployer role | Orientation in the Regulation, roles, risk classes, contractual and procurement consequences | Dated programme and a named certificate |
| Process owner, that is the deployer | What the system is for, where its reliability ends, and when to stop or escalate | Limits of use, input data, monitoring, deployer obligations | Per-role programme and a validation record of learning outcomes |
| Operator carrying human oversight | How to recognise an output that must not be accepted unchecked, and what to do next | Hands-on work on your system, edge cases, escalation path, decision logging | Practical exercise completed in your own environment |
| Engineering team | Where model errors come from, how to measure them, and what to record so they can be reproduced | Evaluation, testing, event logging, traceability, application-layer security | Knowledge test result and workshop artifacts |
| Marketing, support and anyone publishing content | What may be published, what has to be labelled, and where the tool's responsibility ends | Transparency obligations, content marking, verification before publishing | Publishing checklist and a named certificate |
| Procurement, legal and compliance | What to require from a vendor and what has to end up in the contract and in the system register | Provider versus deployer duties, documentation, vendor questions | Reusable vendor question set and a register entry |
Article 4 is one obligation among many and on its own it makes no system compliant. We say so plainly, because the usual problem after training is not missing knowledge, it is overestimating what the training covered.
Article 4 comes from the Regulation, so it applies across the Union in the same wording. What differs country by country is the national supervision layer and the funding attached to training.
In Poland, market surveillance sits with the Commission for the Development and Security of Artificial Intelligence, established by the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003). The Act entered into force on 11 August 2026, except for Articles 8-18 and Chapters 3-5, 8 and 9, which apply from 28 October 2026 and carry the inspection regime and the penalties.
Public training money in Poland also runs on its own rules: since 1 January 2026 it flows through the Baza Usług Rozwojowych register, and the 2026 National Training Fund priorities name AI explicitly. If your Polish entity intends to co-fund the training, that path has to be settled before dates are fixed, and we settle it with you.
For a group operating in several member states, the practical answer is one role map and one evidence format, with local annexes where a national regulator or a funding body asks for something extra.
One webinar goes out to everyone, the attendee list stays inside the meeting tool, the recording lands on a shared drive. Six months later a customer security questionnaire asks who was trained, on what programme and when. Nobody can reconstruct a named list or show that the scope matched the role, so the answer becomes "we run training", which in a questionnaire counts for nothing.
We start from the list of people who touch AI systems and diff it against the list of people trained, so you see the gaps as named individuals before the first session. After each group we issue a dated register, the per-role programme and named certificates, and we confirm outcomes with a test and a practical exercise rather than with attendance. Register completeness is checked again when the project closes.
A generic "AI for business" course is bought once and pushed through the whole organization, because that is cheaper and easier to account for. Engineers get an hour on what a language model is, and the person who approves or rejects cases on that system never sees a single example from their own screen. The box is ticked, daily practice does not move, and the first questionable output finds nobody who knows what to do with it.
We map roles to the level of understanding each one needs and build a separate programme per group, on material taken from your systems rather than from slides. The starting level is checked with a short test before the session, the result with a practical exercise in your environment. A group that lands below the threshold repeats the module, not the course.
Scope is set around the tool the company adopted deliberately, a coding assistant or an internal chat. Left outside are the AI features built into software bought years ago: summaries in the ticketing system, candidate ranking in the recruitment platform, drafted replies in support. Those are exactly where deployer duties sit, and people use them daily without ever calling them AI.
Before the programme is fixed we run a short inventory of actual use: the application list from SSO sign-ins, a direct question to vendors about features added in updates, and a survey inside teams. What we find enters the training scope, and what falls outside training goes onto a list of systems to classify, handed over as a separate result.
A funding body's calendar sets the date, so the scope bends towards whatever can be accounted for inside that window rather than towards who needs what. The paperwork is then assembled after the fact, from memory, and that is when a missing signature, a missing outcome record or a mismatch between the declared and delivered programme shows up.
We build the programme around roles first and only then look for a window, not the other way round. Documentation is produced alongside the sessions: attendance, the validation record of learning outcomes and the certificates are finished on the day the training runs. Before anything is submitted we check the pack against the funder's requirements.
After the training somebody writes, in good faith, that the company is AI Act compliant, in a customer questionnaire or a tender response. A training certificate says nothing about system classification, technical documentation or oversight, so the mismatch surfaces during the first serious due diligence, which is the worst possible moment: mid transaction or mid procurement.
The materials and the register state plainly what the training covers and what it does not. On top of that we issue a one-page scope note written in the language of a customer questionnaire, so the person filling in the form has a true sentence ready instead of improvising one. The note is reviewed with your legal team before it is issued.
We establish who touches AI systems and in what role, and which tools people actually use, including AI features built into software bought earlier.
We build a separate programme per group on material from your systems. In parallel we settle whether and how the training is to be co-funded, and what that means for dates and paperwork.
Sessions run per group, each on its own programme. Operational and engineering groups work in your environment, not on slide examples.
Outcomes are confirmed with a test and a practical exercise; we issue the register, the validation record and the certificates, and close the funding documentation.
We return after a systems change or after a year: the role map is updated, new people and new tools are added, and the programme is refreshed where scope moved.
Poland's AI act (Journal of Laws 2026 item 1003) entered into force on 11 August 2026; the inspection and penalty provisions on 28 October 2026. How to build a register that holds up.
High-risk deadlines moved, the Article 50 transparency duties did not. What has to be disclosed, where in the interface, and how to verify the marking survived publication.
Role-specific training for engineering, design, ops and leadership - workshop or cohort format.
AI system inventory, risk classification and the technical documentation the Act requires.
Usage policies, evaluation cadence and risk register - the procurement-ready baseline.
We are an engineering and training team, not a law firm. This page describes how to perform the obligation and how to evidence it, not how the article should be read for your situation. The legal reading and any assessment of liability are signed by counsel: yours, or our legal partner. Dates and instrument numbers are published together with their sources so you can verify them without asking us for an opinion.
Tell us where you are with the Article 4 AI literacy obligation. We respond within one business day.