EU AI Act AI Literacy Training in 2026: What CEE Employers Must Deliver

The deadline you already missed, and the one that just landed

Two dates matter here, and most compliance teams in Warsaw, Budapest and Sofia have only one of them written down. Article 4 of the EU AI Act, the AI literacy obligation, has applied since 2 February 2025. It has been binding law for a year and a half. What changed on 3 August 2026 is that the enforcement architecture came into force: national market surveillance authorities with real powers, and a penalty framework sitting behind them.

If your working assumption has been that AI literacy is a 2027 problem, that assumption expired this month.

Here is the part people find irritating. Article 4 carries no headline fine of its own. The large numbers in the Act (up to 35 million euros or 7% of global turnover for prohibited practices, up to 15 million or 3% for most other breaches) attach to other articles. Article 4 gets enforced through supervisory attention, through what you can document when a regulator opens a file on something adjacent, and through your customers' procurement questionnaires. That third channel is the one that will cost you revenue this financial year, and it is already happening: if you sell software or services into a German or Dutch enterprise from a Polish or Bulgarian delivery centre, the AI literacy question is now in the vendor security review.

Related reading: Poland's Capability Centres in 2026: Hiring After the GBS Growth Slowdown · Bulgaria IT Outsourcing in 2026: A Buyer's Guide to Sofia's Software Sector · Budapest as Hungary's AI R&D Hub in 2026 · CEE Corporate Training and AI Upskilling in 2026.

What Article 4 actually asks for

Stripped of legal phrasing, the obligation is this. If your organisation provides or deploys AI systems, you have to take measures to give the people operating those systems on your behalf a sufficient level of AI literacy, calibrated to their technical background, their role, and the context in which the system is used. That is the whole requirement.

Notice what is absent. No prescribed curriculum. No certification body. No mandatory exam, no minimum hours, no approved provider list. Regulators left the definition of "sufficient" to you.

Every compliance lead I have spoken to in the region reads this as good news for about a week, then realises it is the harder version. A prescribed curriculum would let you buy a course, tick a box, and file the certificate. Instead you have to decide what sufficient means for your workforce, in writing, and defend that reasoning later. The obligation is not really "train your people". It is "have a defensible position on what your people need to know, and evidence you acted on it".

Your org chart is wrong about who the deployer is

Most CEE organisations start this exercise by listing their data scientists. That list is almost never the risk.

A deployer, under the Act, is any organisation using an AI system under its own authority in a professional context. That covers the recruiter running CV screening through a vendor tool. The credit team using a scoring model. The customer support manager who put a large language model in front of tier-one tickets. The marketing coordinator who uses an image generator on client work. None of them think of themselves as operating an AI system, and every one of them is inside scope.

A compliance lead at a Kraków shared-services centre described their first gap analysis to me. The data science team scored fine, no surprises. The failure was in accounts payable, where somebody had wired an invoice-extraction model into the approvals workflow eleven months earlier, through a low-code platform, with no review, no documentation, and no idea that the tool was in scope for anything. It had processed roughly 40,000 invoices by the time anyone looked at it.

That is the shape of the typical CEE finding. The exposure sits in operations, not in the AI team.

Three tiers, and what evidence each one produces

The structure that survives contact with a regulator is tiered by role rather than uniform across headcount. Here is a workable model, with rough delivery time and the artefact each tier should leave behind.

The middle tier is where organisations underinvest and where the actual exposure lives. Baseline training is cheap and everybody does it. Builder training is expensive and the engineers usually want it. Operator training requires knowing which tools are deployed in which workflow, which means somebody has to do a real inventory first, and inventories are unglamorous work that nobody volunteers for.

Build, buy, or use the national route

Three ways to source this in Central and Eastern Europe, with real trade-offs.

Buying from an international compliance vendor gets you speed and a recognisable brand on the certificate, which matters if your buyer is a German or Nordic enterprise. It gets you generic content that references no tool you actually run, and prices that assume a Western European budget. The material is usually a policy briefing wearing a training badge.

Building in-house is the only way to get tier-two right, because tier two is inherently about your tools and your workflows. It costs you a subject-matter lead for six to ten weeks and it produces something your operators will actually use. Most companies underestimate the maintenance: your tool estate changes quarterly, and stale training is worse evidence than no training, because it documents that you knew and then stopped.

The national and EU-funded route is the underused option in the region. Poland's public workforce development funding, the Digital Europe Programme, and the European Digital Innovation Hubs network all carry AI-skills money that CEE employers routinely leave on the table because the application overhead looks worse than the subsidy. For a company of 200 to 500 people, that arithmetic is usually wrong. Do the sums before dismissing it.

My recommendation, having watched a dozen of these: buy tier one, build tier two, and send tier three to whichever technical training partner your engineers already respect. Splitting the tiers across sources is more procurement work and produces a much better programme than any single vendor will.

The complications specific to this region

Supervisory designation has been uneven. Some member states named their market surveillance authority early and published guidance; others ran late, with implementing legislation still moving through national parliaments deep into 2026. If your authority has not published sector guidance yet, that is not a reason to wait. Article 4 applies regardless of how organised your national regulator is, and "our supervisor was slow" is not a defence you want to test.

Then there is language. Delivering AI literacy in English to a Polish, Hungarian or Bulgarian workforce is the single most common shortcut, and it undermines the "sufficient, taking into account education and experience" test in exactly the population most likely to misuse a tool. Engineers will be fine in English. The warehouse supervisor using a demand-forecasting dashboard will not. Localise tier one at minimum.

The third complication is structural and specific to the region's business services sector. If you run a capability centre in Kraków, Brno or Bucharest operating AI systems on behalf of a parent entity in Munich or Zurich, the deployer question gets difficult. Who is deploying: the legal entity that owns the system, or the one whose staff operate it? Answer it in writing, in the intercompany agreement, before a regulator asks. Several large GBS operators in Poland spent the first half of 2026 doing exactly this and found their intercompany documentation said nothing useful about AI at all.

Where these programmes fail

Four failure modes come up repeatedly, and all four are avoidable.

• Training that lands before the inventory. If you do not know which AI systems are running in which workflow, your training is aimed at a guess. Inventory first, even a rough one.
• One session, no refresh, no record of who missed it. Enforcement looks at continuity, and a single 2025 completion log will read as a project rather than a control.
• Ownership parked in Legal with no operational partner. Legal can define sufficient. It cannot map tools to roles. Pair the compliance owner with someone from operations who knows what people actually use.
• No connection to procurement. New AI tools keep arriving through vendor contracts and low-code platforms. If procurement does not flag them, your training scope drifts out of date within a quarter.

What I would do with a quarter and a modest budget

Spend the first three weeks on inventory. Not a survey emailed to department heads, which returns nothing useful. Pull the SaaS spend report, pull the low-code platform's connector list, and interview eight people across operations who will tell you what they are actually using. You will find two or three systems nobody in Legal knew existed.

Then write the sufficiency memo. Two pages: who is in scope, what tier each population sits in, what standard you have set, and why. Date it and have someone senior sign it. That memo is the single most valuable artefact in the entire exercise, because it is the thing that demonstrates reasoning rather than activity.

Deliver tier one across the whole organisation in month two, tier two to the mapped operator roles in month three, and schedule tier three for the following quarter. Then put a recurring calendar item on the inventory refresh, because that is the part everyone drops.

The organisations that will come out of this well are not the ones with the thickest training deck. They are the ones who can produce, on request, a dated memo explaining what they decided sufficient meant and a log showing they did it. If you have those two things by December, you are in better shape than most of the region.