Who needs training and on what: a roles-competence matrix for AI

In short. An AI training plan built by department trains some people twice and leaves others uncovered. Clause 7 of ISO/IEC 42001 asks for competence tied to roles, and for most organizations three levels are enough: those who govern and approve, those who own the risk of a specific system, and those who use the tools in daily work. A roles-competence matrix links each role to what it must be able to do, the training format, the evidence to keep for audit, and how often it is refreshed.

Once they realize clause 7 asks for more than one course for everyone, many companies move to different tracks but keep deciding content by department. A process owner and a clerk in the same office then end up in the same course, even though one decides and the other executes, while people in other departments who sign risk assessments miss the track they need.

The criterion that works looks at what the person must decide or do with respect to a specific system, and the org chart becomes a starting point to cross-check against the inventory.

The competence levels

The board and senior management approve system adoption, accept residual risks, and answer for those choices to shareholders and authorities. Risk owners are the people assigned the risk of a given system; they keep the assessment current and escalate when something changes. Operational users work with the tools every day, and they are where a system error becomes a process error.

Each level needs a different depth, and a single course bores the first group and leaves the third unprepared, with neither problem surfacing until an auditor starts asking questions.

The matrix

Role	What they must be able to do	Format	Audit evidence	Refresh
Board and senior management	Read an AI rating, ask why a risk was accepted, understand the accountability attached to approval	A few hours on company cases	Minutes with questions asked and decisions taken	Yearly and for every new high-risk system
Risk owners	Run and update the risk assessment, recognize a substantial change, trigger escalation	Hands-on workshop on inventoried systems	Signed, current assessments and logged escalations	At every system change and at least yearly
Operational users	Recognize when an output needs checking, know whom to report an anomaly to	Short modules in the context of the tool	Attendance record linked to role, practical check	At adoption and at every version change
Control functions	Check consistency between inventory, risks, and controls	Technical and regulatory track	Internal audit plan and reports	Yearly
Contractors with system access	Follow defined procedures and usage limits	Contract clauses and briefings	Documented acceptance	At every contract renewal

The board

Board members don't need to read a model; they need to read an AI rating report and ask why a given risk was accepted rather than mitigated, knowing what it means to sign an approval without asking that question. Training at this level takes hours, and it is measured by the quality of the questions the board asks in later meetings more than by course minutes completed.

Risk owners

A risk owner cannot just sign an assessment prepared by an outside consultant. They must recognize when the system they own has changed enough to need a fresh analysis, for example after a model update or an extension to a new category of users, and know how to escalate before the problem surfaces on its own. Training here works on the systems in the company's inventory, because generic examples do not prepare people to spot the signals of their own context.

Operational users

An operator using an AI-assisted tool needs to know when an output requires human verification before moving on and whom to report odd behavior to, with examples taken from their own work. This is the largest group and often the most neglected, even though it is the one in daily contact with real errors.

A hypothetical example

An insurer with four AI systems in its inventory, including one that supports claims assessment, builds the matrix by cross-checking the org chart with the list of systems. The claims manager, who under a department-based plan would have taken the users' course, turns out to be the risk owner of the claims system and joins the risk assessment workshop, while the adjusters on the team get short modules on verifying outputs and reporting anomalies. The example is illustrative and does not describe a real case.

Mistakes to avoid

• Assigning content by department without looking at the role relative to the system.
• Treating the board as a secondary audience because its training is short.
• Forgetting contractors who work on the systems.
• Recording attendance without linking it to the role held.
• Building the matrix once and not updating it when people or systems change.

Next step

The matrix starts from the list of systems and the roles that touch them, and the method for building it is in our guide to the AI system inventory. The full requirements of clause 7 are described in ISO/IEC 42001 clause 7, explained without jargon.

Our approach to role-based training is described on the AI Training page. To build the matrix for your organization, book an assessment meeting.