AI training by role, not one course for everyone

Update note. This article describes Regulation (EU) 2024/1689 as worded in November 2025. AI literacy obligations may have changed since then. Before applying them in your organization, check the consolidated version on EUR-Lex and confirm it with your Legal or Compliance team.

When an organization decides to train its people in AI, the usual answer is an online course for all staff: an hour of general concepts, a few usage examples and a quiz at the end. It is easy to launch and easy to report on. It is also not enough. The executive who approves a use case, the analyst who uses an assistant to draft reports and the engineer who integrates a model into a critical process do not need to know the same things, or at the same depth.

This article proposes a role-based training program: what each group needs to know, at what depth, in what format and how to check that they learned it. The goal is not to train more, but to train each profile better.

Why a single course does not work

A course designed for everyone ends up at the lowest common denominator. For someone who has never used an AI tool it may help; for someone who builds with models every day it is wasted time. Most importantly, it leaves gaps in the profiles that concentrate the most risk.

The costliest AI mistakes rarely come from not knowing what a language model is. They come from specific decisions made without the right judgment: a user who pastes customer data into an unauthorized tool, a development team that does not evaluate the system before releasing it, a risk team that does not know what to ask in a review, an executive team that approves a use case without understanding its limits. Each of those mistakes calls for different training.

There is also a credibility problem. A generic course completed with a click produces a compliance indicator (percentage of staff trained) that says little about the organization's actual capability. If an auditor or a regulator asks how you make sure your staff understand the risks of the AI systems they use, that percentage is not an answer.

AI literacy is already an obligation

In the European Union, Regulation (EU) 2024/1689 on artificial intelligence includes an AI literacy obligation in its Article 4. Providers and deployers of AI systems must take measures to ensure that their staff, and other persons operating or using those systems on their behalf, have a sufficient level of AI literacy. The article itself asks them to take into account people's technical knowledge, experience, education and training, the context in which the systems will be used and the persons on whom they will be used. This provision is part of Chapter I of the Regulation, which applies from February 2, 2025.

Two points in that wording matter for program design. First, "sufficient" is measured against context: it is not the same for everyone. Second, the obligation covers those who use the systems, not just those who build them. A role-based program is the natural way to address both.

For organizations in Spain, the obligation applies directly if they are providers or deployers of AI systems. For organizations in Latin America, it may apply if they operate in the European market, and in any case it is a useful reference while each country defines its own framework. Whether and how it affects you is a question for your legal team.

Management frameworks point in the same direction. ISO/IEC 42001 requires the organization to determine the necessary competence of the people working within the AI management system and to make those people aware of the AI policy and their own role. The NIST AI Risk Management Framework, within its Govern function, includes that personnel and partners receive AI risk management training consistent with their duties. If you already work with ISO/IEC 42001, the role-based training program is part of the evidence you will need; we cover it in ISO/IEC 42001 in practice.

Five profiles, five sets of needs

We propose five groups. Each organization can adjust the boundaries, but it is best not to have many more: a program with fifteen variants is hard to maintain.

The table below summarizes what each profile needs. Durations are illustrative and depend on each organization's starting point.

Role	What they need to know	Suggested format	How to measure it
Leadership	What AI can and cannot do, main risks, regulatory obligations, how a use case is approved and overseen	Short sessions built around decision cases, for example two hours per quarter	Decision quality: use cases approved with documented risks and metrics
Business users	Authorized tools, which data can and cannot be used, how to verify an output, when to escalate	Short, hands-on module with exercises in the actual tools they use at work	Practical exercises passed, misuse incidents, questions to the support channel
IT and operations	How AI systems are deployed and monitored, permissions, logs, responding to AI-related incidents	Technical workshops and exercises on operating procedures	Incident drills, updated runbooks, response times
Development and data	Design, evaluation and testing of AI systems, data quality, security of model-based applications, documentation	In-depth technical training, labs and peer review	Code and evaluation reviews, security findings, documentation quality
Risk, security and compliance	Reference frameworks, AI-specific risks, how to review and audit a system, what evidence to ask for	Specialized training and guided participation in real reviews	Review quality, relevant findings, documented criteria

A few notes on each group:

• Leadership does not need to understand how a model works inside, but does need to know what questions to ask before approving an investment and what responsibility the organization takes on when it deploys a system.
• Business users are the largest group and carry the most day-to-day risk. Their training must be specific: which tool, for what, with what data. General principles without application are quickly forgotten.
• IT and operations need to treat AI systems like any other production service, with their particularities: non-deterministic behavior, dependence on data and permissions that can widen what an agent is able to do. Security guardrails for AI agents are good material for this group.
• Development and data is the group that needs the most depth. Beyond the technical side, it must master data preparation; the criteria in AI-ready data are a starting point.
• Risk, security and compliance need enough technical knowledge not to depend entirely on what the building team tells them. We expand on this in the CISO in the face of AI.

Format: less classroom, more practice

Format matters as much as content. Some criteria we recommend:

• Use the real tools. An exercise on the assistant the organization has authorized teaches more than a demo on a generic tool.
• Work with your own cases. Examples should come from the organization's own processes, with fictitious data, not from cases in other industries.
• Break it into short pieces. Several short, spaced-out sessions work better than a full day once a year.
• Update often. Tools and risks change quickly. Content that has not been reviewed in a year is probably out of date.
• Train champions. In each department, one or two people with deeper training can answer day-to-day questions and spot uses that should be escalated.

How to measure whether it worked

The percentage of people who completed the course is an activity indicator, not an outcome. It shows coverage, not capability. We recommend combining it with three types of measure:

1. Practical assessment. Instead of a multiple-choice quiz, an exercise where the person has to do something: verify an output, decide whether a piece of data can be used, review a use case.
2. Operational indicators. Data that already exists in the organization and that training should move: misuse incidents involving AI tools, quality of requests for new use cases, findings in security reviews.
3. Periodic review. At least once a year, review the program with Risk and Compliance: what has changed in tools, risks and regulation, and which content needs updating.

Keep the evidence in order: who received what training, when, with what content and with what result. That evidence supports an ISO/IEC 42001 audit and lets you show, if asked, how you meet the AI literacy obligation.

Where to start

A reasonable plan for launching the program follows these steps:

1. Inventory the AI systems and tools in use and who uses them.
2. Assign each person a training role based on their relationship with those systems.
3. Start with the highest-risk groups: business users with access to generative tools and the teams that build systems.
4. Define the minimum content and the assessment method for each role before producing materials.
5. Record the evidence and review the program with Risk and Compliance at least once a year.

Role-based training takes somewhat more effort to design than a single course, but it delivers what a single course does not: people who make better decisions with AI in their actual work. Before settling on your reading of the regulatory obligations that apply to you, validate it with Legal and Compliance, and coordinate the program with Human Resources.