Why should AI training be role-based rather than one course for everyone?

Because a single generic course over-serves most people and under-serves the few who carry the real risk. A finance analyst using a chatbot, an engineer building an agent, and a director approving the AI policy need very different things, and training written for all of them lands properly for none. It is also what the rules expect: the EU AI Act's Article 4 asks for literacy that is proportionate to the person's role and context, and ISO 42001 ties competence to actual responsibilities. Role-based training is simply training that matches the knowledge to the job and the risk.

What AI training does leadership and the board need?

Not how to write prompts, but how to govern. Leadership needs enough to set direction, approve the AI policy, own the risk knowingly, and ask the right questions: what AI are we using, who owns it, what could go wrong, and how would we know. They need to understand the regulatory landscape at a high level (EU AI Act, ISO 42001, data protection) and what good governance looks like, so they can resource it and hold it to account. The goal is informed oversight, not technical depth.

What do product and engineering teams need to know about AI?

The deepest and most technical literacy in the organisation, because they build the systems everyone else relies on. That means evaluation (how to measure whether a model actually does the job), guardrails and monitoring, human-in-the-loop design, secure design against prompt injection and data leakage, and the specific obligations that attach to what they ship, especially if it is high-risk. They need to treat governance as part of the architecture, not paperwork added at the end.

How do you decide how much AI training each team needs?

By risk and responsibility, not by seniority. Start from what each team actually does with AI: the more a team builds, buys, oversees or makes consequential decisions with AI, the more depth it needs. Map roles to the AI they touch (your AI register makes this concrete), give everyone the baseline, and add proportionate depth on top. Then evidence it by role, because ISO 42001 expects competence to be demonstrated, not assumed, and the EU AI Act expects you to show you took measures proportionate to the context.

Role-based AI training: what each team needs

Q: What AI training does an HR or People team need?

HR sits in genuinely high-risk territory, because AI used in hiring, performance or people decisions is treated as high-risk under the EU AI Act and carries real fairness and legal exposure. People teams need to understand where AI may and may not be used in employment decisions, how bias arises and what to watch for, where a human decision must stay, and candidate and employee rights. In many organisations HR also helps run the literacy programme itself, so they need to understand the obligation they are helping meet.

Q: Does every employee need AI training?

Everyone who uses AI at work needs a baseline, but that baseline is light and practical, not a deep course. It covers what the tools can and cannot do, the core risks (inaccuracy, bias, data leakage, over-reliance), your acceptable-use rules, checking output before relying on it, and when to involve a human or escalate. That floor applies to all staff; the depth is then added role by role for the teams that build, buy, oversee or make decisions with AI.

If you roll out one AI training course to the whole organisation, it will fail in two directions at once. It will bore the majority, who need a light, practical grounding, and it will under-prepare the minority who carry the real risk: the people building AI, buying it, overseeing it, or making decisions with it. AI literacy has to fit the role.

Which raises the obvious question, and the one this post answers: what does each team actually need? It is also not just good practice. The EU AI Act’s Article 4 duty asks for literacy that is proportionate to the role and context, and ISO 42001 ties competence to actual responsibilities. Both point at the same thing: match the knowledge to the job. (For how to structure and run the programme itself, see how to build an AI literacy programme that sticks; this piece is about the content each team needs.)

Start from the floor: what everyone needs

There is a baseline that applies to anyone who uses AI at work, and every role builds on it. It is deliberately light: what the tools can and cannot do, the core risks (inaccuracy and hallucination, bias, data leakage, over-reliance), your acceptable-use rules, checking output before relying on it, and knowing when to involve a human or escalate a concern. Most people never need more than this. The depth below is added on top for the teams that carry more.

Leadership and the board

Leadership does not need to learn how to write prompts. It needs enough to govern: to set direction, approve the AI policy, own the risk knowingly, and ask the right questions. The useful ones are simple, which AI are we using, who owns each system, what could go wrong, and how would we know. They need a high-level grasp of the regulatory picture (EU AI Act, ISO 42001, data protection) and of what good governance looks like, so they can resource it and hold it to account rather than nod it through. This is informed oversight, and we cover what it involves in AI governance for the board.

Product and engineering: the people building with AI

Your builders need the deepest and most technical literacy in the organisation, because everyone else relies on what they ship. That means evaluation (how to measure whether a model actually does the job, not whether a demo once worked), guardrails and monitoring, human-in-the-loop design, and secure design against the failure modes that matter for agents: prompt injection, data leakage, unsafe tool use. Above all they need to treat governance as part of the architecture rather than documentation added at the end, which is what separates a governed agent from a demo that made it to production. The discipline that anchors this is building the evaluation harness before you ship.

HR and People

HR sits in genuinely high-risk territory, and often does not realise it. AI used in hiring, performance management or other people decisions is treated as high-risk under the EU AI Act, and carries real fairness and legal exposure regardless of the regulation. People teams need to understand where AI may and may not be used in employment decisions, how bias creeps into those systems and what to watch for, where a human decision must stay in place, and what rights candidates and employees have. And because HR frequently helps deliver the literacy programme across the organisation, they need to understand the obligation they are helping the business meet, not just administer the training.

Legal, risk and compliance

This team carries the map. They need working fluency in the obligations that apply: the EU AI Act and where your systems fall within it, data-protection duties, and the standards you are measuring against. In practice that means being able to classify an AI system by risk, run or commission an AI impact assessment, and work out whether you are a provider or a deployer for a given system, because the obligations differ sharply. Their literacy is less about the technology and more about turning a moving regulatory picture into decisions the rest of the business can act on.

Procurement and the people buying AI

Most AI risk now arrives through tools you buy rather than tools you build, which makes procurement a quietly critical team. They need to know the right questions to ask a vendor, what a credible answer looks like, and how to assess an AI product before it goes live rather than after. That is a specific skill: how to evaluate an AI vendor covers the questions that actually matter, from data handling and training use to security and the vendor’s own governance. Procurement that can hold that line keeps a lot of risk out of the building.

Customer-facing teams

Sales, support and marketing use AI constantly, often on customer data and in customer-visible ways, which creates two distinct needs. First, disclosure: there are specific transparency duties for things like chatbots and AI-generated content under the EU AI Act, covered in Article 50 transparency, and these teams are usually the ones on the hook for them. Second, judgement: not over-trusting AI output in front of a customer, not pasting customer data into tools that are not sanctioned, and knowing when an answer needs a human. The stakes are higher here because the mistakes are external and public.

People who operate high-risk AI systems

Anyone operating or overseeing a high-risk system, a model that makes or shapes consequential decisions about people, needs role-specific, system-specific competence. That is the deepest and narrowest training of all: the particular oversight the system requires, how to read its outputs and spot when something is wrong, logging and record-keeping, incident handling, and the specific obligations that attach to that system. This is not a general awareness session; it is training tied to the exact thing the person is responsible for, and it is where the EU AI Act’s human-oversight requirements bite hardest.

How much each team needs, and proving it

The organising principle is risk and responsibility, not seniority. Start from what each team actually does with AI: the more a team builds, buys, oversees or decides with AI, the more depth it needs. Give everyone the baseline, then add proportionate depth on top, team by team. Your AI system register makes this concrete, because it already tells you who touches which systems and how risky each one is.

And whatever you deliver, evidence it by role. ISO 42001 expects competence to be demonstrated rather than assumed, and the EU AI Act expects you to show you took measures proportionate to the context. “Everyone did the annual module” is weak evidence; “this team, in this role, received this training matched to the AI they handle” is strong.

The short version

AI literacy is not one course. A single generic module over-serves the many and under-serves the few who carry the risk. Give everyone a light, practical baseline, then add depth by team: governance and oversight for leadership, deep technical literacy for builders, fairness and employment-law awareness for HR, the regulatory map for legal and risk, vendor assessment for procurement, disclosure and judgement for customer-facing staff, and system-specific competence for anyone running high-risk AI. Decide the depth by risk and responsibility, not seniority, and evidence it by role.

When you want a role-based programme designed for your teams and built to stand up to an auditor, that is the work we do: see our AI literacy and training service, or check which EU AI Act obligations, including the Article 4 literacy duty, actually apply to you with the free EU AI Act readiness assessment.