AI literacy is about more than completing a course
AI literacy is the practical ability to understand an AI system and use it with sound judgement in the context of one’s work. For an organisation, that can mean knowing what task is being delegated to a system, what its limitations are, what information it may receive, how to review its output, and whom to contact when something does not look right. It does not mean mastering model engineering, nor does it in itself amount to a certification.
Article 4 of the European Union’s Artificial Intelligence Regulation, known as the AI Act, is the regulatory starting point for this obligation. The European Commission publishes specific questions and answers on AI literacy and Article 4. AESIA, the Spanish Agency for the Supervision of Artificial Intelligence, also provides an institutional Q&A page on the same article. These sources can help guide how the provision is read, but they do not replace checking the current legal text when determining which obligations apply to a particular organisation.
It helps to distinguish three layers. The first is what the law establishes: this must be checked in the official text and any applicable institutional clarifications. The second consists of the design choices an organisation makes, such as dividing training by role or using exercises. The third is the internal evidence retained to manage the programme. A good practice at the second or third layer should not be described as an express requirement of the Regulation unless the legal source consulted says so.
AI literacy should not be confused with other governance measures either. Training people does not replace technical controls, rules for use, any applicable human oversight, or risk assessment. It is one part of responsible management, not a standalone solution that guarantees a system is safe or that everyone will detect every error.
First, establish the scope of the obligation and its timeline
Before designing a course, confirm whether the organisation and the people concerned fall within the scope described by the law. The sources provided point to providers and deployers of AI systems, but they are not enough to determine the regulatory role of each entity or resolve every borderline case. An organisation may have different roles depending on the system, the process, and its relationship with third parties. Do not infer its classification from an internal label such as “user” or “customer”.
Verification should be based on the current version of the Regulation and the relevant institutional guidance. Check the exact provision, who it addresses, what relationship with the system is relevant, and what conditions it sets out. If there is uncertainty about an entity’s role, the type of activity, or when the provision applies, record the question and refer it for qualified legal advice. This guide does not determine that role or provide an individual legal conclusion.
The timeline should be checked separately. The materials available confirm that the European Commission and AESIA pages address Article 4, but the excerpts provided do not verify a specific application date. For the sake of accuracy, do not turn a date repeated in a secondary source into a conclusion supposedly established by this evidence. Check the timeline in the official text and record which version the organisation consulted and when.
It is also important to distinguish a general obligation to take measures from a detailed list of required content or formats. According to the available summary, AESIA says there is no one-size-fits-all approach to AI literacy and that the aim is not to impose strict requirements. This supports a context-sensitive design, but it does not remove the need to verify the precise legal scope or allow an organisation to assume that any training initiative will be sufficient.
Initial verification using official sources
- 01Locate the current official text of the AI Act and the provision relating to AI literacy.
- 02Check the scope and conditions that apply to the case; do not infer the organisation’s regulatory role from its commercial description.
- 03Verify the timeline in the current legal text and note the version consulted. Do not rely on a date that has not been confirmed by the official source.
- 04Compare your reading with the European Commission’s and AESIA’s institutional Q&As, distinguishing clarifications from the legislative text.
- 05Record unresolved questions and assign them to the person or function responsible for obtaining a qualified answer.
Map actual tasks before assigning training
A single programme for the whole workforce can miss the decisions that matter most in each role. Before preparing content, take stock of the systems and processes in which AI is used and describe what each person does in them. The aim is not to rank people by technical prestige, but to identify what they need to know to carry out their tasks in an informed way.
For each use, note the purpose, the people who interact with the system, the kinds of data they enter or consult, the system’s degree of autonomy, and the consequences of an incorrect output. Include tools acquired from third parties as well as internally developed systems, where they are among the uses that need to be reviewed. If the system’s operation or scope is not well understood, record that as an open question rather than concealing it with a generic session.
The matrix below is an internal planning tool, not a legal classification or a conformity assessment. Its columns help identify relevant content and where additional controls may be needed. The impact assessment should be tailored to the process and does not replace any formal assessments that may apply.
Operational matrix for identifying training needs
| Role and task | AI use | Data and autonomy | Practical risk | Training need |
|---|---|---|---|---|
| Customer service staff preparing drafts | Generates replies that a person reviews before sending | May involve customer information; autonomy is limited only if the review is meaningful | Inaccurate answer, inappropriate tone, or disclosure of data | Check facts, remove unauthorised data, and know when to draft without AI |
| Analyst summarising documents | Extracts key points to support a decision | Internal documents; the summary may omit context | An incomplete conclusion influences a later decision | Check against the original document and communicate uncertainty |
| Manager using an automated classification | Consults results that may affect people or resources | The degree of autonomy and impact depends on the process | Treating a score as a final decision | Understand permitted use, review routes, and escalation |
| Technical team configuring a tool | Sets parameters, permissions, or connections | Potential access to data and system controls | Information exposure or unauthorised changes | Permissions, change logs, and incident procedures |
Design modules around concrete decisions
Once you have mapped the uses, organise the content around capabilities people can demonstrate in their work. Each group does not need to study every aspect in equal depth. Someone using a tool to draft text needs to recognise plausible errors and protect information; someone configuring integrations may need technical controls and change procedures. Tailoring training to knowledge, experience, education, and the context of use is consistent with AESIA’s described context-sensitive approach, although the organisation should consult official sources to establish precisely what the legal text requires.
A module on capabilities and limitations should explain what task the system performs, what it cannot guarantee, and what warning signs call for caution. Avoid absolute claims such as “it is always right” or “it never retains data” unless they are supported by verified information from the provider and the actual configuration. Teach people to distinguish a well-written answer from a verified one.
Review of outputs should be proportionate to their consequences. A quick check may be enough for a low-impact internal draft; it is not appropriate when an output may influence a sensitive decision. People should know which sources to use for cross-checking, which parts to examine, and what to do when they cannot verify a claim. If the process requires a human decision, the reviewer must have enough time, information, and authority. Ticking a box without a real opportunity to challenge the output is not useful practice.
Handling information must be connected to internal rules and the authorised conditions for each tool. Staff need to know what data they may enter, what data they must exclude, how to identify sensitive information, and where to ask if they are unsure. Do not assume that all systems follow the same practices for retention, use of inputs, or privacy settings.
Finally, everyone should know how to escalate an issue. Specify which behaviours require a workflow to be paused, who receives the report, what information should be retained, and what alternative to use while the issue is investigated. Training loses its value if someone spots a problem but does not know whom to tell—or is afraid that reporting an error will be treated as an individual failure.
Practise with workplace scenarios
Training is easier to apply when it gives people practice making recognisable decisions. Examples do not have to reproduce real cases containing personal data: they can use synthetic information or approved materials. They should present a task, an imperfect output, and a choice that the participant must explain. This makes it possible to see whether they can apply the instructions, rather than merely recall terminology.
One exercise might ask participants to check an answer against an authorised source. Another might present a request containing data that should not be shared with the tool in use and ask them to reformulate the task or choose an alternative. A third might simulate an output that conflicts with an internal procedure. The expected response will not always be to correct the result: sometimes it will be to stop, request a review, or not use the system for that task.
Assess what the person does and the practical reasoning they communicate. An attendance record, a satisfaction survey, or a completion certificate may provide administrative information, but none by itself shows that the person can spot a questionable answer. As an operational recommendation, use a short list of observable behaviours: cross-check, protect data, recognise limitations, and escalate. Treat the results as signals for improving the programme, not as a universal guarantee of competence.
Document the programme without confusing record-keeping with compliance
The sources provided do not establish what documentation Article 4 expressly requires, or whether the Regulation prescribes a particular format, attendance record, or test. The list below should therefore be treated as a proposal for internal management, not as a legal documentation requirement. Check the official text and applicable guidance before describing any of these elements as mandatory.
A proportionate record can help an organisation see who received which content, what use it was designed for, when it was delivered, and what needs to change. Keep a version of the materials and note who approved the module, when it was updated, and which questions remain open. If participation or exercise results are recorded, limit the information to what is necessary, control access, and follow applicable privacy and retention policies.
Documentation should support learning and correction, not simply the accumulation of files. If an incident reveals that several people did not know how to check an output, update the content and review the process that allowed the problem to progress. Do not use an attendance record as automatic proof that a person understood the system’s limitations, or as evidence that the whole organisation is compliant. Training does not transfer the organisation’s responsibility to the person using a tool.
Suggested internal record: what to note and why
These fields are an operational proposal. They are not presented as a list expressly required by the AI Act.
| Item | Practical purpose |
|---|---|
| Target group or roles | Identify whom the content was designed for and find groups not yet covered. |
| System, task, and context | Link training to actual use without turning the record into a legal catalogue. |
| Objectives and materials | Show which capabilities were covered and which version was used. |
| Date, owner, and update | Track when the training took place and who reviewed the content. |
| Participation and exercise | Keep proportionate evidence of the activity and any need for further support. |
| Questions, incidents, and actions | Connect issues or problems identified with changes to training and processes. |
Update training when the system or work changes
A module can become outdated even if the tool’s commercial name stays the same. Review the programme when the system, its purpose, configuration, the data it processes, the user group, or its role in a decision changes. It is also worth reviewing when internal instructions change, repeated errors are identified, or people do not know how to escalate an incident.
Review does not mean repeating the whole course for the entire workforce every time. Identify what changed, which roles are affected, and which behaviour needs updating. A specific instruction for one group, a new exercise, or a change to the procedure may be enough. If the change substantially affects the use or its consequences, it may be necessary to reassess whether the previous content is still suitable.
Set practical signals for identifying outstanding training needs: recurring questions about data, outputs copied without checking, confusion between a suggestion and a decision, use outside the intended purpose, or difficulty finding the escalation channel. These signals are internal improvement tools; they are not legal criteria in themselves and do not replace any applicable risk assessment.
Programme review cycle
- 01Define which AI uses and work groups the current programme covers.
- 02Record changes to the system, purpose, data, configuration, users, or process impact.
- 03Determine which knowledge or behaviours may have become outdated.
- 04Update materials and exercises for the affected roles.
- 05Communicate the current advice and escalation route.
- 06Review questions and incidents to decide whether the process or its controls also need to change.
Checklist and limitations
Before launching the plan, check that you have identified actual AI uses and the roles that interact with them; that you have verified the scope and timeline against the current official text; and that every module teaches observable behaviours related to a task. Also check that people understand the limitations of the tools they use, the rules for handling information, and a clear route for pausing and escalating a doubtful case.
Make sure someone is responsible for the content, that there is a way to review the materials, and that a mechanism exists for collecting questions. Keep proportionate internal documentation and clearly distinguish it from any evidence the law may require, if any. If you cannot verify a legal point using the institutional sources available, flag it as unresolved instead of filling the gap with a claim from a secondary source.
Training does not fix inadequate technical controls, make an inappropriate use acceptable, or guarantee that a person will identify every incorrect output. Nor does it determine the organisation’s regulatory role or replace legal review. Its purpose is to strengthen people’s ability to understand the specific use, act cautiously, and ask for help. The sensible next step is to combine this work with existing security and governance processes, and review official guidance when the regulatory framework changes.
Open questions
- The excerpts provided do not contain the full current text of Article 4, so the exact legal scope must be checked in the official Regulation.
- The sources provided do not verify a specific application date; the timeline must be checked directly in the current official text.
- There is not enough evidence provided to state which documents or formats the law expressly requires.
- This guide does not determine whether a particular organisation is a provider, deployer, or another regulated actor, and does not resolve borderline cases.
- There is not enough evidence provided to confirm detailed guidance on knowledge, experience, education, and context beyond the available institutional summary.
Keep exploring
Sources consulted
Corrections and transparency
If you spot incorrect or outdated information, send us a correction with the page and source we should review.
Submit a correction