Control · C-103 · Skills, Capability & Culture
Role-based AI training
Reviewers, developers, risk and assurance staff, approvers and front-line teams receive training specific to their AI responsibilities, with competence assessed and completion tracked.
- Control type
- Directive
- Risks addressed
- 12
- Audience
- Heads-of · Practitioner
- Frameworks
- Article 4 · Article 26 · Clause 7 · AML.M0018
- Responsible AI domain
- Lifecycle stage
- Reviewed
- 2026-11-11
What it does
It prepares people for the particular job they do in relation to AI. Beyond general literacy, each role with AI responsibilities has defined training: reviewers learn how the system fails and how to resist deferring to it, developers learn secure and responsible practice, validators and auditors learn how to test, approvers learn what to ask, incident responders learn the playbooks, and front-line staff learn to recognise problems such as impersonation. Heads of function are accountable for their teams; learning and development coordinates. Training precedes taking up the role and is refreshed on change.
How to implement it
- Identify the roles with AI responsibilities and what each must be able to do.
- Design training for each, using the organisation's own systems and cases.
- For reviewers, practise on realistic cases that include system errors.
- Assess competence, not attendance, before the person acts in the role.
- Track completion, and block access or sign-off rights until it is done.
- Update after incidents, system changes and new guidance.
Evidence it operates
Design: a role and training matrix. Operation: completion and assessment records by role; evidence that role permissions depend on training; content updates traced to incidents or changes; exercise results.
Where it fits
Before a person takes on an AI responsibility, and through their time in it. With reviewer effectiveness testing it is a primary control for automation bias and over-reliance, and it supports ineffective human review, inadequate AI resourcing and competence and AI incident response gap. It builds on the AI literacy programme.
Limits
Training gives knowledge and not time, tools or authority. Its effect on automation bias fades unless the work itself is designed to support scrutiny. People change roles faster than training is delivered. The specialist skills needed to validate and audit AI are not acquired from a course.
Risks this mitigates
Primary mappings
- Automation bias and over-reliance High
- Teaches reviewers when and how to challenge outputs. People accept AI outputs without the scrutiny they would give another source, and the system's errors pass into decisions unchallenged.
Supporting mappings
- AI incident response gap High
- Responders are trained on AI-specific failures. AI-specific failures are not covered by the incident process: they have no classification, no playbook and no trained responders.
- AI literacy gap in the deploying organisation Medium
- Adds role-specific depth. Staff who use, rely on or make decisions about AI systems do not understand what those systems can and cannot do, so they misuse or over-trust them.
- AI-enabled social engineering of staff High
- Staff learn to expect convincing synthetic impersonation. Attackers use generated voice, video and text to impersonate executives, customers or suppliers convincingly enough to defeat staff verification.
- Deepfake impersonation and synthetic identity fraud Critical
- Front-line staff learn the signs. Generated voice, image, video or documents are used to impersonate customers or to create false identities, defeating verification and authentication.
- Human-agent trust exploitation Medium
- Approvers learn how agents can mislead. People approve an agent's request or accept its account of events because it is fluent and familiar, so the human check that was meant to stop a harmful action passes it instead.
- Inadequate AI resourcing and competence Medium
- Builds the role-specific skills. AI systems are adopted without the people, skills, tooling and budget needed to build, oversee and operate them safely.
- Inadequate board oversight of AI High
- Board members receive training suited to their role. The board and senior management lack the information, expertise or forum to challenge AI risk, and approve what they cannot evaluate.
- Ineffective human review High
- Reviewers are trained for the task. A human review step exists and operates, but reviewers do not in practice detect or correct the system's errors.
- Insecure AI-generated code High
- Developers learn what assistants typically get wrong. Code suggested by an AI assistant is accepted with vulnerabilities, invented dependencies or licence problems that review would have caught in code a person wrote.
- Missing information for deployers and users Medium
- Operators are trained on them. The people who operate or use a system have not been told its intended purpose, how well it performs, where it fails and what oversight it needs.
- Personal data in prompts and context High
- Staff understand why the restriction exists. Users or integrations put personal data into prompts, uploads or retrieved context without a lawful basis or appropriate safeguards.
Framework and clause references
| Framework | Clause | Title |
|---|---|---|
| EU AI Act | Article 4 | AI literacy AI literacy. |
| EU AI Act | Article 26 | Obligations of deployers of high-risk AI systems Competence of those assigned oversight. |
| ISO/IEC 42001:2023 | Clause 7 | Support Competence. |
| MITRE ATLAS | AML.M0018 | User Training User training. |
Related terms
How to cite
Axiom Verity (2026). Role-based AI training. Reference Library, C-103. https://axiom-verity.com/controls/role-based-ai-training. Reviewed 2026-11-11.
Found an error or a better source? Report a correction.