What does AI Act Article 4 require now?

AI literacy under the EU AI Act is an operating obligation, not a demand that every employee earn a generic certificate. A company has to take measures that support the development of literacy among staff and other people who operate or use AI systems on its behalf. The useful work starts with identifying those people, the systems they touch, the decisions those systems influence, and the mistakes each role can realistically make.

That wording matters because Article 4 changed in July 2026. Regulation (EU) 2026/1744 removed the former duty to ensure a "sufficient level" of literacy and now says that providers and deployers do not have to guarantee any specific level for an individual. It did not delete the organisational duty to act. A slide deck sent to everyone may count as activity, but it is weak evidence of a sensible measure when recruiters, software engineers, customer support agents, and managers use different systems and expose different people to harm.

This is a practical compliance design, not legal advice. Employment rules, sector regulation, works council duties, data protection law, and national enforcement practice can add requirements that Article 4 alone does not answer.

Article 4 requires measures, not a certificate

The amended Article 4 requires providers and deployers to take measures that support AI literacy, with the measures shaped by knowledge, experience, education, training, use context, and the people affected by the system. It expressly says an organisation does not have to guarantee a particular level for every individual. That is a more realistic duty, but it still expects deliberate action.

The distinction between a learning result and an organisational measure is easy to miss. You cannot guarantee that every person remembers every lesson. You can decide who needs guidance, give them material suited to their work, let them practise the risky decisions, check whether the lesson landed, and correct gaps. Those are observable management actions.

The European Commission's AI Literacy Questions and Answers says there is no mandatory format and no one format that fits every company. It also says that merely asking staff to read system instructions may be ineffective. I agree with the first point and would state the second more firmly: vendor instructions explain a product, while your staff need to understand your approved uses, your data, your escalation path, and the consequences of a wrong output in your business.

No official Article 4 certificate exists, and the Commission says a certificate is not required. A completion certificate from a course provider can support an attendance record, but it cannot prove that the content matched a person's role or that the company addressed a known risk. Treat certificates as receipts, not as the compliance program.

The obligation has applied since 2 February 2025. The Commission says national market surveillance authorities supervise and enforce it under the enforcement framework that began in August 2026. A late company should build a defensible program now, document the date honestly, and avoid backdating attendance or policies. A clean record of correction is better than fictional history.

Providers, deployers, contractors, and leaders can be in scope

Article 4 reaches organisations that provide AI systems and organisations that deploy them, including many companies that simply use third party AI tools at work. A deployer is generally an organisation or person using an AI system under its authority, outside personal nonprofessional activity. A business does not escape the issue because it did not train the model or because an employee opened a public chatbot in a browser.

The people covered extend beyond payroll. Article 4 refers to staff and other persons who deal with operation and use on the organisation's behalf. Contractors who prepare marketing copy, outsourced support agents who use suggested replies, consultants who screen records, and temporary workers who label data may all need measures suited to their tasks. Put the obligation in the operational relationship instead of assuming the supplier handles it.

The company should first decide whether it is a provider, a deployer, or both for each system. A startup that builds an AI feature is a provider for that product. The same startup may be a deployer of a purchased recruiting assistant and an internal coding assistant. Roles drive the curriculum because a provider's engineers need to understand testing, limitations, documentation, and downstream use, while a deployer's staff need to understand approved inputs, output checks, and escalation.

Senior leaders belong in the scope analysis. A manager approving an AI purchase or changing a workflow can create more exposure than an employee writing a prompt. Give decision makers enough literacy to ask what the system does, whose interests it affects, which data enters it, where humans intervene, and what monitoring will reveal failure. Leadership training that stops at productivity tips misses the decisions Article 4 is meant to improve.

The AI Act can also apply to actors outside the EU when the statutory territorial conditions are met, such as placing an AI system on the Union market, using one in the Union, or producing output used in the Union under the Act's rules. Do not decide territorial scope from headquarters location alone. Counsel should resolve difficult cross-border cases, but the training owner can still map EU users and affected groups while that analysis proceeds.

Start with an AI use register and a role map

A defensible program starts with actual use, not with a catalog of fashionable AI risks. List the AI systems the organisation provides or deploys, including embedded functions that employees may not call AI. Search, ranking, fraud signals, transcription, recommendation, content generation, applicant scoring, code completion, and support suggestions can sit inside ordinary software.

Shadow use deserves its own discovery route. Ask teams what they use, review approved software inventories, inspect expense claims and single sign-on applications where lawful, and give people a safe way to disclose experiments. An amnesty period often produces better information than a threat. The goal is to move unknown use into a governed decision, not to punish the first person who admits that a public tool saved them an hour.

For each use, record who operates it, what they put in, what the output influences, who may be affected, and what a plausible failure looks like. Then group people by decisions rather than job titles. A recruiter and a sales manager may both need a lesson on automation bias if each receives ranked people. Two software engineers may need different material if one uses code completion on internal utilities and the other builds a model driven feature for customers.

Use a simple exposure test with four questions:

• Can an output affect employment, access to a service, safety, credit, education, or another consequential interest?
• Can users enter personal, confidential, copyrighted, regulated, or security sensitive information?
• Can the system act, publish, send, approve, reject, or change records without a meaningful review?
• Would a reasonable user overtrust the output because it sounds authoritative or arrives inside an established workflow?

A "yes" does not automatically make the system high risk under the AI Act. This is where teams routinely blur two different classifications. Operational risk means the use can hurt the business or a person. "High risk" is a legal classification under the Act with defined conditions. Confusing them can cause both underreaction and needless bureaucracy. Train for operational risks even when counsel concludes that the statutory high risk regime does not apply.

Finish the map with a named owner and a review trigger. New systems, material feature changes, new affected groups, incidents, and a change in legal classification should reopen the literacy decision. An annual calendar alone reacts too slowly when a vendor adds an autonomous action or a team moves a tool from drafting into decision making.

Useful training changes what a person does at work

Training counts when it gives a person the knowledge and habits needed for the AI use in front of them. It can include a live workshop, a short recorded module, written guidance, supervised practice, office hours, scenario exercises, or an approval gate. Article 4 does not force every company into a classroom, and the Commission's repository includes varied approaches. The repository also warns that copying an example does not create a presumption of compliance.

Every participant needs a common foundation: what the organisation calls an AI system, which systems it approves, how outputs can fail, what data may enter, when a human must review, and how to report trouble. General awareness should then give way to role practice. Someone who generates an internal meeting summary needs different depth from someone who uses a ranking to shortlist job applicants.

A good test asks the employee to make a work decision. Give a support agent a plausible but invented customer record and an AI drafted reply containing a fabricated refund term. Ask the agent to identify the problem, verify the policy, revise the answer, and record the issue. A multiple choice quiz can check vocabulary, but it rarely proves that a person will pause when fluent output looks right.

Training should also define prohibited behaviour in concrete language. "Use AI responsibly" tells an employee almost nothing. "Do not paste customer records into unapproved tools" and "Do not send a generated legal claim until the designated reviewer checks the cited source" can guide action. Pair each restriction with an approved route, or staff will work around the rule when a deadline arrives.

Experienced technical staff may already know model mechanics, but that does not settle their literacy needs. The Commission says experience can be enough depending on the tool and qualification, while pointing to legal and ethical gaps that technical employees may still have. I have seen excellent engineers miss retention rules and product limits because everyone assumed technical fluency covered governance. Verify the missing layer instead of making them repeat an introductory lesson.

Keep evidence of judgment, delivery, and correction

Article 4 does not prescribe a special certificate, so the best evidence shows how the organisation reached its decisions and carried them out. Keep enough material for a new compliance owner or an authority to reconstruct who was covered, why the content fit, when it was delivered, and what changed after feedback or an incident.

A compact evidence pack should contain the approved AI use register, the role and risk assessment, the training material with a version number, participation records, exercise or assessment results, exceptions, and follow up actions. Keep the source of each requirement clear. A privacy rule, an information security rule, a vendor restriction, and an AI Act measure may appear in the same lesson, but the underlying duties are not interchangeable.

This small record is enough for many low exposure uses:

program_version: 2026-08-01
owner: Head of Operations
scope_basis:
  systems: [internal meeting summarizer, approved writing assistant]
  roles: [operations, marketing, customer support]
  affected_groups: [employees, prospects, customers]
measures:
  common_briefing: 60 minutes
  role_exercises: 90 minutes
  guidance_acknowledgement: required
evidence:
  attendance_file: literacy-attendance-2026-q3.csv
  exercise_record: literacy-results-2026-q3.csv
review_triggers: [new system, material feature change, incident, role change]
next_review: 2027-02-01

The YAML is an index, not proof by itself. The referenced files need participant identifiers appropriate to local employment and privacy rules, dates, program version, assigned role track, completion status, and any remediation. Store the exact slides, scenarios, policy, and answer guide used for that version. If the policy changes later, preserve the old version so the record still explains what a participant received.

Do not collect more personal data than you need. A named attendance record may be justified; a recording of every discussion probably is not. Set access and retention rules with HR, privacy, and legal owners. Article 4 does not cancel GDPR duties, and a bloated evidence folder creates its own exposure.

Record nonattendance and correction rather than quietly marking everyone complete. If a contractor misses the session, restrict the AI task until they complete an equivalent measure. If an exercise exposes a common misunderstanding, revise the workflow or guidance and log that action. Evidence of learning from a gap often says more about the program than a page of perfect quiz scores.

Avoid screenshots as the main record. Screenshots lose versions, context, and searchability. Keep structured records and export stable copies when a learning system may later delete accounts or overwrite content. Test once a year that the evidence links still resolve and that the compliance owner can retrieve a complete sample without asking five departments.

A one day program can establish the baseline

One focused day can establish a credible baseline for an ordinary company using generative tools, provided the company completes the system inventory before the session and follows up on gaps afterward. The day cannot finish the work for every provider or every use classified as high risk. It can give a mixed group a common language, practise the main decisions, and produce evidence for the next iteration.

1. From 09:00 to 09:30, participants establish scope and identify approved systems, their role, and one current use.
2. From 09:30 to 10:20, teams examine hallucination, automation bias, uneven performance, privacy, confidentiality, and security examples tied to company uses.
3. From 10:30 to 11:20, each role marks what data may enter a system and which outputs need review.
4. From 11:20 to 12:00, participants trace who can benefit, lose an opportunity, receive a false statement, or struggle to challenge a result.

After lunch, the work moves from analysis into rehearsal and a recorded assessment.

1. From 13:00 to 14:15, groups detect and correct failures in realistic, invented cases.
2. From 14:15 to 15:00, each group practises stopping use, preserving facts, notifying the owner, and choosing a safe fallback.
3. From 15:15 to 16:00, builders and approvers review limits, human control, vendor claims, and change triggers.
4. From 16:00 to 17:00, participants complete a practical check while owners assign remediation and record unresolved questions.

Send a short baseline survey before the day. Ask which systems people use, what decisions the outputs influence, what data they enter, and where they verify results. Do not ask participants to rate their "AI maturity" on a vague scale. Concrete questions expose curriculum needs and create a useful before record.

Use company shaped examples without exposing live confidential or personal data. Rewrite a real failure pattern with invented names, figures, and records. Preserve the decision pressure that made the mistake tempting: a customer waiting, a release blocked, or a manager asking for a shortlist. Sanitised examples become useless when trainers remove the context along with the sensitive information.

End the day with an applied assessment. Participants might choose an approved tool, reject a forbidden input, find an unsupported claim, state the required reviewer, and file a sample incident. Score against a written answer guide. Anyone who misses a safety relevant item gets targeted remediation rather than another pass through the whole day.

The program owner should issue a brief completion note within five business days. It should state attendance, role tracks, assessment method, gaps, assigned actions, owners, and due dates. That note turns the event into a managed measure. Without it, the workshop can become a pleasant day that changes nothing.

Exercises should rehearse failure under pressure

The best literacy exercise recreates the moment when a reasonable person might trust or misuse the system. It should make the participant inspect evidence, apply a company rule, and choose a fallback. Abstract warnings about hallucination fade quickly because everyone already agrees that AI can be wrong.

Use four exercise patterns across roles:

• A fluent answer invents a policy, source, product fact, or citation, and the participant must verify it against an authoritative record.
• A user tries to paste personal or confidential information into an unapproved tool, and the participant must choose an approved route or remove the sensitive content.
• A ranking or recommendation disadvantages a person, and the participant must identify the affected interest, inspect relevant inputs, and route the decision to meaningful review.
• An AI function changes after a vendor update, and the owner must decide whether prior guidance, testing, and approval still apply.

Make the answer guide explicit. A trainer should be able to say which action is required, which action is acceptable, and which action creates risk. Open discussion still matters, especially when company policy has a gap, but ambiguity should produce an assigned policy decision rather than ten unofficial rules.

Do not teach prompt tricks as the main safeguard. Better prompting can improve an output, but it cannot make a model a source of truth, create permission to disclose data, or turn a nominal human check into meaningful oversight. Prompt technique belongs in productivity training after the participant understands boundaries and verification.

Include an incident drill even if the company has never recorded an AI incident. The participant should know where to report, what facts to preserve, who can pause the use, and what manual fallback keeps the work moving. If the reporting route is too slow or unclear during the drill, fix the process. Training has done its job when it reveals an operational defect before a real event.

Different roles need different depth

A shared foundation reduces confusion, but role tracks make the measure proportionate. Article 4 tells organisations to consider technical knowledge, experience, education, training, and use context. Sending the longest technical course to everyone ignores that instruction as surely as sending a five minute video to model developers.

• All users need to recognise approved uses, protect data, verify outputs, and report problems; retain attendance, a scenario result, and guidance acknowledgement.
• Managers and buyers need to describe purpose, affected people, human review, vendor limits, ownership, and change triggers; retain the completed approval case and decisions.
• Engineers and product staff need to test limitations, document intended use, control changes, communicate constraints, and support monitoring; retain a technical scenario, test artifact, and release gate record.
• HR, legal, security, and risk staff need to apply their own domain rules to AI use and resolve escalations; retain the case review and assigned policy actions.
• Contractors and service providers need to follow the approved route for the delegated task and use the agreed incident channel; retain contract linked guidance and completion records.

People who use systems classified as high risk may need further training tied to human oversight and the relevant deployer duties, including Article 26 where applicable. Do not assume the general Article 4 session satisfies those separate obligations. Map each duty to its own evidence, then reuse material where it genuinely covers both.

Executives need a short but demanding track. Ask them to approve or reject a proposed use with incomplete vendor information, a promised productivity gain, and a real affected group. They should identify what remains unknown and who owns the decision. An executive briefing made only of definitions allows the people with the largest authority to avoid practice.

Exemptions should be evidence based. A machine learning engineer may test out of the basic mechanics module, while still completing company rules and an affected people exercise. Record why the prior knowledge was accepted and which parts remained required. Seniority by itself proves nothing.

A failed rollout usually starts with a false inventory

A familiar failure begins when a company buys a generic course for every employee and records near perfect completion. Procurement believes the task is closed. Six weeks later, customer support quietly activates an AI reply function inside its existing help desk, recruiters use a separate writing assistant to summarise interview notes, and engineers paste error traces into personal accounts. None of those uses appeared in the course examples or the system register.

The support team then sends a generated answer that invents a contract term. A manager calls it a hallucination problem and schedules another generic module. That response misses the operating failure: nobody owned feature changes, the approved use list did not include embedded AI, the agent had no required source check, and the incident route did not capture AI involvement. More training on model definitions will not repair those controls.

A competent review updates the inventory, names the use owner, adds a source check before sending contractual claims, records the incident pattern, and gives support agents a ten minute corrective exercise. It also asks other teams where AI appeared inside software they already owned. The evidence pack then shows the original gap and the correction rather than pretending the first course prevented every mistake.

This is why annual completion is a weak operating metric. Track coverage of known roles and systems, overdue remediation, policy questions discovered, changes reviewed, and incidents that led to a control or lesson update. The numbers should help owners find gaps, not decorate a board slide.

Refresh training when work changes. New hires need the baseline before independent use. Existing users need a targeted update when a system gains a material function, when an affected group changes, when an incident reveals misunderstanding, or when law and guidance change. Regulation (EU) 2026/1744 itself is a good example: material written before late July 2026 may still quote the old "sufficient level" wording and should now be corrected.

Enforcement will examine whether the measures made sense

National market surveillance authorities enforce Article 4, and the Commission says penalties and other measures depend on national law and the individual case. The AI Act calls for proportionate enforcement, with factors such as the nature, gravity, and intentional or negligent character of an infringement considered. The Commission also notes that scrutiny may be more likely when an incident points to missing training or guidance.

Do not convert that into a made up EU fine table for Article 4. The Act does not give the literacy duty its own simple price tag. National penalty rules, sector duties, contractual claims, employment disputes, data protection exposure, and evidence after an incident can interact. Ask counsel about the jurisdictions and systems that matter to your company instead of repeating a maximum fine from an unrelated provision.

The Commission's living repository of literacy practices is useful for formats and ideas, not as a safe harbour. Its own notice says replication does not automatically create a presumption of compliance. Borrow a method only after you connect it to your systems, roles, and affected people.

A reviewer should be able to trace a straight line: the organisation identified a use, understood who operated it and who could be affected, chose measures suited to that context, delivered them, checked application, and corrected gaps. Perfection is not the standard written into the amended Article 4. Indifference is still hard to defend.

For founders, the sensible first action is a ninety minute working session with operations, product, HR, security, privacy, and legal owners. Leave with a list of systems, role groups, affected people, and owners. If the inventory cannot survive that meeting, buying a course is premature. A Team & AI Audit from oleg.is can examine the wider team and AI operating model when the literacy work exposes ownership or workflow problems, but the company should still retain legal counsel for its compliance conclusions.