What EU AI Act Article 4 Requires of Lithuanian Public Sector Bodies (and What Counts as Evidence)
Most guides to EU AI Act Article 4 are already out of date. The Digital Omnibus amendment entered into force in July 2026 and changed the core obligation. That change matters for how Lithuanian public sector institutions should structure their compliance evidence.
Article 4 of the EU AI Act has been legally in force since 2 February 2025. Formal enforcement by national market surveillance authorities began 2 August 2026. If your institution uses AI systems, you are subject to it now.
This post explains what Article 4 requires after the Digital Omnibus amendment, why generic training does not satisfy it, and what documentation a Lithuanian regulator will ask for.
Key Takeaways
- Article 4 has been legally in force since 2 February 2025. Formal enforcement by national market surveillance authorities began 2 August 2026.
- The Digital Omnibus amendment (July 2026) changed Article 4 from an obligation of result to an obligation of effort. Institutions must demonstrate ongoing, documented, role-appropriate measures.
- Generic training does not satisfy Article 4. Compliance is demonstrated through documentation that shows why the measures chosen were appropriate for the people and AI systems involved.
- In Lithuania, DigComp 3.0 is the measurement framework named in the National AI Strategy 2026-2035 for public sector AI literacy. Competence reports structured around DigComp 3.0 are the right format for compliance evidence.
What Article 4 says after the Digital Omnibus amendment
Article 4, as amended by the Digital Omnibus in July 2026, requires providers and deployers of AI systems to:
"take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of AI systems on their behalf, taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in, and considering the persons or groups of persons on whom the AI systems are to be used. This obligation does not require providers or deployers to guarantee any specific level of AI literacy of any individual." (Regulation (EU) 2024/1689, Article 4 para 1, consolidated text as of 27 July 2026 — eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)
The original text required deployers to "ensure a sufficient level of AI literacy." The Digital Omnibus replaced that with "support the development of AI literacy." This is a deliberate shift from an obligation of result to an obligation of effort.
Your institution does not need to guarantee that every staff member reaches a specific literacy threshold. It must take real, documented, ongoing measures that are appropriate for the people and AI systems involved. The measures must be defensible. That is what enforcement will assess.
The second part of the text carries equal weight; "taking into account their technical knowledge, experience, education and training and the context the AI systems are to be used in." The obligation is not uniform. It is contextual and role-differentiated by design.
Why Lithuanian public sector institutions are deployers
A deployer under the EU AI Act is any organisation that uses an AI system under its own authority in a professional context. This definition covers every Lithuanian ministry, agency, municipality, and public body that uses AI systems in any operational capacity.
You do not need to have built the AI system. You do not need to use a system classified as high-risk. Using any AI system for any professional purpose makes your institution a deployer. So Article 4 applies.
This includes third-party tools. If your institution uses AI-assisted tools for document classification, procurement evaluation, benefits processing, citizen communication, or case management, it is a deployer. Staff who use those tools on behalf of your institution are within Article 4's scope.
Article 4 also covers contractors and service providers. Any person operating an AI system on your institution's behalf, not just direct employees, is within the scope of the obligation.
Public sector deployers carry an additional obligation under Article 27. Before deploying high-risk AI systems, public sector deployers must complete a fundamental rights impact assessment and register the deployment in the EU AI systems database established under Article 71. AI used in social benefit processing, citizen-facing decision support, or law enforcement contexts may fall within Annex III's high-risk categories.
Why the obligation is role-differentiated
The most predictable compliance gap is applying the same training to everyone and treating that as sufficient. Article 4 explicitly requires the opposite.
The measures must take into account "their technical knowledge, experience, education and training and the context the AI systems are to be used in." Every element of that phrase points away from generic content and toward context-specific design.
A procurement officer evaluating AI vendors needs to assess risk classification, audit rights, and conformity documentation. A front-line case officer using an AI benefits tool needs to understand how the system produces recommendations and when to override it. A digital transformation lead needs to understand institution-wide governance obligations and how to structure a compliance programme. These are not the same competences.
Generic organisation-wide e-learning that delivers the same content to all three roles does not satisfy Article 4 for any of them.
Why the obligation is ongoing
One training session in August 2026 does not satisfy a continuous legal obligation.
AI systems change. New systems are adopted. Existing systems are updated or deployed in new contexts. The people using them change. The competences required to use AI systems safely in a public sector context evolve with all of these factors.
Article 4 requires measures that support the development of AI literacy over time. A programme that stops after an initial session produces evidence of a one-time event, not of ongoing effort. A regulator assessing your institution's compliance position will ask not only what training was done, but whether the programme is maintained as AI use changes.
Build a review cycle into your programme from the start. Review it at minimum annually, or whenever your institution adopts a new AI system or changes how an existing one is deployed.
What documentation satisfies Article 4
Article 4 does not prescribe a documentation format. It does not require a competence report, a certificate, or any specific output. What it requires is that proportionate, role-differentiated measures were taken, and that you can demonstrate this if asked.
That is the practical problem. "We ran a training day" is not a defensible answer. Five components form a defensible record:
1. A written AI literacy policy with governance ownership. This establishes that your institution has formally committed to the obligation and named who is responsible for it.
2. A needs assessment mapping roles to AI systems. Document which roles in your institution use which AI systems, and what competences those roles need to use those systems safely and appropriately. This is the analytical foundation of a defensible programme.
3. Training records tied to the needs assessment. Records must show who received what training, when, and what the content covered. They must also explain why the content was appropriate for those specific people using those AI systems. Attendance logs alone do not answer the last question.
4. Assessment results demonstrating comprehension. Evidence that training was delivered is weaker than evidence that it produced the competences the role required. Where possible, include assessment outcomes against a recognised competence framework.
5. An update log. A log showing how the programme has evolved as AI systems and staff have changed demonstrates that your institution treats the obligation as continuous, not a one-time event.
Evidence that a course was completed is not the same as explaining why the measures chosen were appropriate for the people and AI use involved. Documentation must make that case explicitly. In Lithuania, DigComp 3.0 competence reports are the right structure for meeting that standard.
Why DigComp 3.0 is the right measurement framework for Lithuania
DigComp 3.0 is the EU's current digital competence framework, published by the Joint Research Centre in November 2025 (JRC144121). It maps competences to specific areas and proficiency levels, from Foundation (Levels 1 to 2) through to Highly Specialised (Levels 7 to 8).
Lithuania's National AI Strategy 2026-2035 names DigComp 3.0 as the recommended framework for national AI literacy programmes. When a Lithuanian regulator assesses whether your institution's training measures were appropriate and role-differentiated, DigComp 3.0 is the framework they will use as a reference.
Article 4 does not require a competence report. But if a regulator asks whether your measures were proportionate and role-appropriate, a DigComp 3.0 competence report is the most defensible answer available. It shows what was measured, against a recognised framework, at what level, for which role. A generic completion certificate cannot make that case.
A competence report also makes the role-differentiation argument explicit. If your needs assessment determined that a case officer needs DigComp 3.0 Area 5.1 (Identifying digital security threats) at Intermediate Level 3, and the learner's report confirms they reached that level, you have documented exactly the link between the role's requirements and the individual's development.
What AI literacy looks like by role
The obligation does not define a fixed literacy threshold. It requires literacy appropriate to what each person does with AI systems, accounting for their background and the people affected by those systems. Three examples illustrate the practical difference.
Procurement officers evaluating AI vendors need to assess risk classification, audit rights, and conformity assessments. They need to know how to read an AI system's technical documentation and what questions to ask before a procurement decision. Without this literacy, your institution cannot evaluate AI systems safely.
Front-line case officers using AI support tools need to understand how the system generates its outputs and what its limitations are. They need to know when to override or escalate, and what documentation is required when AI output informs a decision affecting a citizen.
Digital transformation leads need the broadest view. This includes governance obligations across AI risk categories, how to design a role-differentiated programme, and how to structure institution-wide compliance evidence.
None of these roles needs the same training. A programme that addresses all three with identical content demonstrates that role-differentiation was not built in. That is a compliance gap, not a training achievement.
What to do if your institution has not started
Article 4 enforcement is already in effect. If your institution has no documented, role-differentiated AI literacy programme, the compliance position is not defensible.
Start with these steps.
Map your AI systems to the roles that use them. Identify every AI system currently in operational use and which staff roles interact with it. Include third-party tools your institution has deployed for staff use.
Assess what each role actually needs. This is not a self-assessment exercise. It requires someone with knowledge of the AI systems and the relevant legal and operational context to determine what competences each role needs, at what proficiency level, to use those systems safely.
Choose training that produces competence documentation, not just attendance records. The training content must be mapped to the specific competences each role requires. The outcome records must show what competences were developed and to what level. Generic course completion records do not produce that evidence.
Build a review cycle in from the start. Schedule a programme review at least annually, or whenever your institution adopts a new AI system or changes how an existing one is used.
Institutions that want a structured starting point can reach out at joseph@kelias.tech. Kelias is pre-commercial and piloting with a small number of Lithuanian public sector institutions before launch. The pilot provides access to the full curriculum, individual DigComp 3.0 competence reports, and compliance tracking, with no commitment.
Summary
Article 4 requires Lithuanian public sector institutions to take documented, role-differentiated, ongoing measures to support the development of AI literacy among their staff. The Digital Omnibus amendment confirmed this is an obligation of effort, not guaranteed outcome. Enforcement started 2 August 2026.
Article 4 does not prescribe a documentation format. What it requires is evidence that proportionate, role-differentiated measures were taken and maintained. A DigComp 3.0 competence report is not mandated — it is the most defensible form of that evidence. It maps what each person learned to a recognised framework, at a level appropriate to their role, with a timestamp. That is what closes the gap between "we did something" and "we can demonstrate what we did and why it was appropriate."
Generic training, applied uniformly, cannot make that case. A regulator does not need to find a violation. They only need to find that your documentation does not answer the question.
Ikpong Joseph Alexander holds an MSc in Artificial Intelligence and is the founder of Kelias, a pre-commercial AI literacy platform for Lithuanian public sector professionals. This post reflects the state of Article 4 as amended by the Digital Omnibus (July 2026). It is not legal advice. For the authoritative text, see Regulation (EU) 2024/1689 on EUR-Lex and the EU AI Office AI talent and skills page.