Everyone in your company can already get a useful answer out of a chat window. Almost none of them can tell you which data classes are prohibited, what the approved-use list says, when an output must be verified before it travels, who to tell when something looks wrong, or who carries the consequence when it is. Those are the things an AI management system means by competence, and none of them are acquired by using the product.
Where the obligation actually sits. ISO/IEC 42001:2023 handles this in two separate clauses for a reason. Clause 7.2 asks you to determine the competence your work requires, ensure people have it, act where they do not, evaluate whether the action worked, and keep the evidence. Clause 7.3 asks something different and universal — that people are aware of the AI policy, of their contribution to the system, and of what happens if they ignore it.
Plain-English explainer · ISO/IEC 42001:2023 · EU AI Act as amended by Regulation (EU) 2026/1744 · Last reviewed August 2026
No. Daily use of a chat assistant produces operational fluency, and an AI management system asks for something else entirely. Competence under ISO/IEC 42001 clause 7.2 is role-specific and determined by the organisation: you decide what knowledge each role needs for the work it does, ensure the people in it have that knowledge through education, training or experience, act on the gaps, evaluate whether the action worked, and retain the evidence. A fluent operator who does not know your data classification, your approved-use list or your escalation route is not competent in that sense, however good their prompts are. The distinction is not academic. It is the difference between a person who can make a tool produce something impressive and a person who knows when not to use it, what may be put into it, what must be checked before the output leaves the building, and who answers for it afterwards. This page sets out what the obligation actually says, why it differs by role, the six topics that carry the weight, a verification-threshold model you can publish, and the evidence an accredited certification body asks for — which is where most well-intentioned programmes come apart.
Key Takeaways
- Prompting fluency and governance competence are different things. ISO/IEC 42001 clause 7.2 asks you to determine what competence each role needs, ensure it, evaluate whether your actions worked, and keep the evidence — none of which daily tool use supplies.
- Competence is role-appropriate by design. A developer running a coding agent, an HR user screening candidates and an executive deciding on AI-assisted analysis need materially different knowledge, and a single blanket module serves none of them well.
- Six topics carry most of the weight: hallucination and verification, confidential data handling, permitted and prohibited uses, the specific limitations of the tool in front of them, when to escalate, and who remains accountable for the output.
- Not every output needs fact-checking, and pretending otherwise gets the policy ignored. Publish a threshold: verification scales with consequence, and anything used for a consequential decision or external communication is checked against a primary source by a named person.
- Accountability for AI-assisted work stays with the organisation and the individual who used it. Vendor terms allocate commercial liability between companies, but they do not transfer your answerability to a customer or a regulator.
- The evidence limb that fails audits is evaluating effectiveness. Completion rates measure delivery. Clause 7.2 also asks whether the action taken actually produced the competence, and that is where minor nonconformities land.
Two different things wearing one word
A skilled operator can decompose a task, iterate on phrasing, supply the right context, and get materially better output than a colleague who cannot. That skill is real, it is worth having, and it is not what an auditor is asking about. Governance competence is a different set: knowing which categories of information may never leave your boundary, which uses are approved and which are prohibited, what this particular system is unreliable at, when a piece of output must be verified before it travels, how to raise a concern, and who answers for the result.
The two can vary independently, which is the uncomfortable part. In readiness work the most fluent users are frequently the ones who have moved furthest ahead of the guardrails — connecting a personal account to a work repository, wiring an assistant into a data source nobody assessed, or building an automation that quietly acquired the ability to act rather than merely draft. High skill with no organisational knowledge does not produce caution. It produces reach. That pattern is the whole subject of shadow AI, and it is why competence is treated as a resource the system depends on rather than a nice-to-have.
There is a second reason the standard separates awareness from competence. Awareness is universal and shallow: everyone should know the AI policy exists, roughly what it forbids, and where to ask. Competence is narrow and deep, and it attaches to the work rather than the person — which means it changes when the work changes, when the tool changes, and when a capability arrives that nobody asked for.
Not a nice-to-have, in four instruments
Read the third column rather than the second. The requirement wording is easy to satisfy on paper. What separates a programme that passes from one that does not is what the assessor asks for when they arrive. Annex A of ISO/IEC 42001 is a reference control set you select from and justify in the Statement of Applicability, not a mandatory checklist.
| Source | What it requires | What is actually asked for |
|---|---|---|
| ISO/IEC 42001:2023, clause 7.2 (Competence) | Determine the competence needed by people whose work affects AI performance, ensure they have it through education, training or experience, act where there is a gap, evaluate whether the action worked, and retain documented evidence. | Show me how you decided what each role needs, and show me how you know the training changed anything. The evaluation limb is the one most programmes cannot answer. |
| ISO/IEC 42001:2023, clause 7.3 (Awareness) | People working under your control are aware of the AI policy, of how their work contributes to the management system, and of what happens if they do not follow it. | A short interview with someone outside the AI team. Not a document request — a question to a person in finance about what the AI policy says. |
| Annex A.4.6 — human resources | Competence of the people responsible for the AI system across its life cycle, treated as a resource the system depends on in the same way it depends on data and compute. | The Statement of Applicability entry, the justification, and the mapping from named system to named competent people. |
| Annex A.9.2, A.9.3, A.9.4 — responsible and intended use | Defined processes and objectives for responsible use, and use of AI systems in line with their documented intended purpose. | How users know what the intended purpose is, and what stops the tool being used for something else — which is a training question before it is a technical one. |
| Annex A.3.2 and A.3.3 — roles and reporting of concerns | Allocated AI roles and responsibilities, and a route for people to raise concerns about AI systems. | Who is accountable for each system, and whether people can name the escalation route without looking it up. |
| EU AI Act, Article 4 (AI literacy), as amended | Providers and deployers take measures to support the development of AI literacy among staff and those operating systems on their behalf. Regulation (EU) 2026/1744 replaced the earlier duty to ensure a sufficient level, and states that no specific level need be guaranteed for any individual. | Rarely audited directly today. It matters because customers now write literacy and training clauses into contracts, and a contract does not soften when a regulation does. |
| EU AI Act, Articles 14 and 26 — human oversight | For high-risk systems: oversight assigned to natural persons with the necessary competence, training and authority, able to interpret output, remain aware of automation bias, and disregard, override or interrupt the system. | Named individuals, their training, and the written authority. Unamended by the 2026 Omnibus — only the application dates for high-risk classification moved. |
| NIST AI RMF 1.0, GOVERN 2.2 | That personnel and partners receive AI risk management training enabling them to perform their duties consistent with related policies, procedures and agreements. Note the word partners. | Voluntary framework, so nobody audits it — but it is the vocabulary US enterprise buyers use in questionnaires, and partners is the word that catches contractors. |
| SOC 2 — CC1.4, CC1.5, CC2.2 | Commitment to attract, develop and retain competent individuals. Individuals held accountable for their internal control responsibilities. Internal communication of the information needed to carry them out. | Completion evidence for the full population including mid-period joiners and contractors, tested by a licensed CPA firm as an operating-effectiveness matter. |
Two notes on the regulatory row, because the position moved recently. The EU AI Act is Regulation (EU) 2024/1689. It was amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026 — which, among other changes, deferred the application of obligations for stand-alone high-risk systems under Annex III to 2 December 2027, and for AI embedded in products already covered by EU product-safety law to 2 August 2028. The same instrument rewrote Article 4: providers and deployers now take measures to support the development of AI literacy rather than ensure a sufficient level of it, and the amended text states that no specific level need be guaranteed for any individual. Verify the consolidated text before relying on either point.
What did not move is the human-oversight architecture. Article 26(2) still provides that deployers “shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support”, and Article 14(4) still requires that the oversight person be enabled to understand the system’s capacities and limitations, to remain aware of the tendency of over-relying on its output — the Act names this automation bias — and to decide not to use it or to disregard, override or reverse its output. If you take one sentence from the legal side of this page, take the three words competence, training and authority, because programmes routinely deliver the first two and forget the third. The framework comparison sits in ISO 42001 versus the EU AI Act.
Nine roles, nine different answers
This is the table clause 7.2 is really asking you to produce, and the one most organisations do not have. Build it from your AI system register outward — roles first, then the systems each role touches, then the knowledge those systems demand. A competence matrix written from a course catalogue instead of a register describes a training programme rather than a requirement.
| Role | Competence it actually requires | The failure it prevents | Evidence |
|---|---|---|---|
| Software engineer using a coding agent | Recognise plausible-but-wrong code, know which repositories and secrets the agent can reach, understand that suggested dependencies may not exist or may carry incompatible licences, and know that review obligations do not weaken because a machine wrote the diff. | An unreviewed dependency, a licence obligation nobody noticed, a secret pasted into a prompt, or an agent given standing production credentials because the workflow was faster that way. | Role module completion plus a code-review record showing AI-assisted changes went through the same non-author approval as any other change. |
| HR or talent screening with AI assistance | Know that candidate data is personal data with a lawful basis attached, that ranking or filtering people is a materially different act from summarising a document, and that the screening use case may be classified differently from the drafting one. | A shortlist produced by a system nobody assessed, candidate CVs entering an unapproved tool, and a decision the organisation cannot explain to the person it affected. | Role module plus the impact assessment for the screening use case and a record that the named reviewer can override the ranking. |
| Executive deciding on AI-assisted analysis | Ask what the analysis was built from, what was verified and by whom, and where the numbers came from — and be visibly willing to send work back when the answer is that nobody checked. | Automation bias at the point where it costs the most: a board paper, a pricing decision or a market claim resting on a figure the model produced and nobody traced. | Attendance at the leadership briefing, and decision records that name the verification performed rather than the tool used. |
| Customer support drafting replies with AI | Know which commitments they are not authorised to make, that a drafted reply becomes a statement by the company the moment it is sent, and which customer data classes may be pasted into the assistant. | An invented policy, an invented SLA, or one customer’s data appearing in another customer’s thread. | Role module plus quality-assurance sampling of sent replies against the permitted-commitments list. |
| Marketing and communications publishing AI-assisted content | Verify every factual claim, statistic, quotation and citation to a primary source. Know the disclosure expectations that apply. And understand that a fabricated citation is the organisation’s error, not the tool’s. | A confidently cited source that does not exist, a competitor claim you cannot substantiate, and a regulatory statement made without review. | Role module plus the publication checklist showing source-verification sign-off before release. |
| Finance and procurement using AI on contracts and invoices | Understand that extraction accuracy degrades on unusual documents, that a summarised clause is not the clause, and that payment or commitment thresholds require a human reading the underlying text. | A payment approved against a summary, a renewal auto-accepted, or a liability cap misread by a model that saw a scanned page badly. | Role module plus evidence that amounts above the stated threshold were traced to the source document. |
| Legal, privacy and risk reviewing AI use cases | Distinguish approving a vendor from approving a use case, know which data classes and which populations change the classification, and know when an impact assessment is triggered rather than optional. | A tool approved once and then used for something materially different a quarter later, with no reassessment. | Role module plus the use-case register showing assessments performed at the point of new use, not only at procurement. |
| Named human overseer of a high-impact system | Understand the system’s capacities and limitations, interpret its output correctly, remain aware of the tendency to over-rely on it, and hold the standing authority to disregard, override or stop it — with the time and access to do so. | Oversight that exists on paper: a person nominated in a document who cannot in practice halt the process they are said to oversee. | System-specific training record, the delegation of authority in writing, and logged instances of intervention or of a decision not to intervene. |
| Everyone else — baseline awareness | Know the AI policy exists and roughly what it says, which tools are approved, what must never be pasted anywhere, who to ask, and how to raise a concern without going through their own manager. | The single largest category of incident: a well-meaning person using an unapproved tool on data they did not realise was restricted. | Baseline awareness completion across the full roster, including contractors with accounts. |
Four modules plus a baseline covers most organisations under a thousand people: engineering, customer-facing, people and hiring, and leadership. The register is what tells you whether you need a fifth. If your engineers run agents that hold credentials and take actions rather than assistants that suggest text, the engineering module is a different animal — start with coding agent governance and when a tool becomes an agent, because the competence requirement changes the moment the system can act.
Six topics that carry the weight
Everything else in an AI training curriculum is context for these six. The right-hand column matters more than the middle one: if you cannot describe how you would check whether someone has the competence, you have written a topic list rather than a requirement, and clause 7.2 will ask you to evaluate effectiveness against it.
| Topic | What competence looks like | How you check it |
|---|---|---|
| Hallucination and verification | The user understands that fluent, confident, well-formatted output carries no signal about accuracy, and that fabricated citations, invented case law, plausible statistics and non-existent software packages are ordinary failure modes rather than rare glitches. | Give them a short AI-drafted brief containing one fabricated citation and one plausible-but-wrong figure. Ask what they would check before sending it. You are testing the instinct, not the recall. |
| Confidential data handling | They can name the data classes that must never be pasted anywhere, know the difference between an approved enterprise tenancy and a personal account, and understand that pasting a document into a chat window is a transfer of information out of one boundary and into another. | Ask what happens to a customer contract pasted into a personal account. A correct answer names the loss of enterprise identity, logging and contractual protection — not just “it might train the model”. |
| Permitted and prohibited uses | They can state, without looking, the two or three things that are always prohibited and know where to find the approved-use list. They also know that a tool approved for one purpose is not thereby approved for another. | Present three borderline scenarios drawn from your own use-case register and ask which are permitted. Disagreement between competent people is a finding about the policy, not the person. |
| Limitations of the tool | They know what this specific system is bad at — knowledge cut-offs, arithmetic, long-document recall, non-English material, unusual formats, its behaviour when it lacks an answer — rather than what AI in general is bad at. | Ask them to describe a task they would not give the tool and why. A user who cannot name one has not used it seriously enough to be trusted with consequential work. |
| When to escalate | They recognise the triggers — output they cannot verify, an apparent instruction embedded in a document, an agent asking for a permission it did not previously need, personal or regulated data appearing unexpectedly — and know the route without asking their manager first. | Ask for the escalation path. If the answer is “I’d tell my manager”, the route is not designed. A.3.3 contemplates a mechanism to raise concerns, and a single hop through the person who set the deadline is not it. |
| Who remains accountable | They understand that accountability for AI-assisted output sits with the person who used it and the organisation that employed them, that the vendor’s terms do not transfer it, and that “the model produced it” is a description of a method rather than a defence. | Ask who signs the work. If any part of the answer points at the tool, the awareness training has not landed, whatever the completion record says. |
Two of these have external vocabulary worth adopting, because it makes the risk legible to a security team that has never read your training. The OWASP Top 10 for LLM Applications, whose 2026 edition was published on 4 August 2026, lists Prompt Injection at LLM01 and moved Excessive Agency to LLM03 — up from LLM06 in the 2025 edition, the largest upward move in the list and a direct consequence of production incidents in agentic systems. The same edition carries Misinformation and Sensitive Information Disclosure as categories in their own right, which are the technical names for the verification topic and the data-handling topic above. Prompt injection is the one users most need a plain-language version of: content the system reads can contain instructions it follows, so a document, a web page or a ticket can be an attack surface. That is covered in detail in prompt injection and tool calls.
Does every output need fact-checking
No — and a policy that says yes will be ignored within a fortnight, which is worse than having no policy, because you will then believe a control exists that does not. Verification scales with consequence. Publish the thresholds so the judgement belongs to the organisation rather than to whoever is closest to the deadline.
| Tier | What it covers | Verification standard | Who | What is recorded |
|---|---|---|---|---|
| Tier 0 — Disposable | Output with no audience and no consequence: brainstorming, rephrasing your own note, explaining an error message, drafting something you will rewrite entirely. | None beyond ordinary judgement. Requiring verification here is what makes people stop reading the policy. | The user. | Nothing. |
| Tier 1 — Internal working material | Shared internally, informs thinking but decides nothing: meeting summaries, first drafts, research scans, code that has not left a branch. | The user reads it end to end and corrects what they can see. Any factual claim that would survive into a decision is promoted to Tier 2 before it travels. | The user. | Nothing formal. Convention is to mark the artefact as AI-assisted and unverified. |
| Tier 2 — Consequential internal decision | Budget cases, architecture choices, hiring shortlists, risk ratings, incident analysis, anything that will be cited in a later decision. | Every load-bearing figure, citation and quotation traced to a primary source by someone competent to evaluate it. Reasoning is checked, not just the answer. | The user, plus a second competent reader where the decision is irreversible. | The decision record names what was verified and against what source. |
| Tier 3 — External communication or production | Customer replies, proposals, published content, regulatory or investor material, and code merged to a production branch. | Source-checked and reviewed by a named person other than the requester. The organisation is making the statement in its own name, and the drafting method is irrelevant to that. | A named reviewer with authority to refuse release. | Reviewer, date and version — the same record any other external artefact carries. |
| Tier 4 — Rights-affecting or regulated | Decisions about people or safety: credit, employment, education, health, insurance, security access, law enforcement, and anything your impact assessment flags as affecting individuals or groups. | Human oversight in the Article 14 sense: the overseer understands the system’s capacities and limitations, interprets the output correctly, remains aware of automation bias, and can disregard, override or interrupt it. | A named overseer with competence, training and authority — and the time to use it. | The decision, the human contribution, the override option and the reasons. Where a legal regime requires two-person confirmation, both names. |
Three design rules make this model survive contact with real work. Put the tier boundaries where an existing checklist already lives — the publication approval, the pull-request template, the payment threshold — so that Tier 3 verification is a line in a process people already follow rather than a new ritual. Write the promotion rule explicitly, because most failures happen when Tier 1 material is quietly reused in a Tier 3 artefact and nobody re-checked it. And accept that Tier 0 exists: a policy that refuses to name the harmless case has no credibility when it describes the harmful one.
On accountability, the position is simpler than the debate around it suggests. Responsibility for AI-assisted output sits with the organisation and with the individual who used it. ISO/IEC 42001 requires AI roles and responsibilities to be defined and allocated (A.3.2) and responsibilities to be allocated across the value chain (A.10.2). The AI Act assigns duties to providers and deployers, which are legal and natural persons, not systems. And a SOC 2 examination tests, under CC1.5, whether individuals were held accountable for their internal control responsibilities. A vendor’s terms allocate commercial liability between two companies. They do not move your answerability to your customer, and no regulator has yet accepted a system as a respondent.
Seven ways a programme produces records only
Each of these generates a completion percentage and no competence. They are also, collectively, the most common shape of AI training we encounter in readiness work — not because anyone was careless, but because the security-awareness model was the nearest thing to copy.
| One annual module for everyone | A single course pitched at the whole organisation is necessarily pitched at the person with the least exposure, which makes it useless to the engineer running a coding agent against a production repository and patronising to everyone else. It also fails clause 7.2 on its own terms, because 7.2 asks what competence each role needs — a question a single module has not asked. |
| Training written before the tools were deployed | Generic AI-awareness content bought in 2025 does not mention the connector your team enabled in July, the agent framework your engineers adopted, or the assistant now embedded in the CRM. Users notice within four minutes that the training describes a world they do not work in, and the credibility loss carries across to the parts that were accurate. |
| A quiz that tests recall rather than judgement | Multiple-choice questions about what a large language model is produce a completion record and no behaviour change. The decisions that go wrong are judgement calls under time pressure: is this document confidential, is this claim checkable, is this the tool for this job. Scenario questions with defensible wrong answers test that, but definitions do not. |
| Policy acknowledgement standing in for competence | A signature confirming somebody received a document evidences communication, which is a different requirement. Awareness and competence are separate clauses for a reason: one is about knowing the rules exist, the other is about being able to apply them to work you have never seen before. |
| No refresh when the tool changes | Capability changes are the trigger that matters, and they arrive on the vendor’s schedule rather than yours. An assistant that gains file access, a coding agent that gains terminal execution, a connector that gains write scope — each is a new competence requirement for the same people, and a calendar-driven annual cycle will not notice for eleven months. |
| The executive exemption | Leadership is routinely excused from training on grounds of time, and is simultaneously where automation bias is most expensive, because senior decisions travel furthest and are questioned least. A thirty-minute briefing built around three real decisions — with the verification each would have required — does more than the ninety-minute course they will not attend. |
| Training with no route back | A programme that tells people what not to do without telling them what to use instead produces shadow AI rather than caution. Every prohibition needs an approved path beside it, and the training is where users find out that path exists. |
What works instead: four layers, one of which is not training
A short universal baseline satisfying clause 7.3, running to twenty or thirty minutes rather than an hour, built around the systems in your register by name. It covers the policy, the prohibited data classes, the approved-tool list, the escalation route, and the single fact that accountability does not transfer. Everyone takes it, including contractors with accounts and including the people who believe they do not use AI.
Role modules satisfying clause 7.2, built from the competence matrix and delivered to the roles that need them. These are worth making specific to the point of naming products and showing real output, including a real mistake your organisation made. Scenario assessment beats a definitions quiz, because the thing you are trying to install is a judgement rather than a fact.
In-flow guardrails, which are not training at all and do more than training does. A warning in the tool at the moment of use, an approved-tool list where people actually look, a verification line in the publication checklist, data-loss controls on the paths that matter, and permission scoping so the consequence of a mistake is bounded. Competence reduces the rate of error. Configuration reduces the blast radius, and only one of those two is affected by how busy someone is. The permission side is covered in connectors and permissions.
Change-triggered refresh, wired to the AI system register rather than the calendar. A new tool, a new capability on an existing tool, a new use case, or an incident raises a competence action with an owner and a date. Keep an annual cycle underneath it for the baseline, but the change trigger is what tracks reality. Both belong in the same register that drives your AI inventory and use-case approval.
240 people, eight months, one minor
An illustrative composite, not a client. Read the middle column first: everything that mattered was in place months before the certification body arrived, and the one finding they raised is the finding almost everybody gets.
| Baseline | September 2026 | A 240-person B2B analytics company, ISO/IEC 42001 certification targeted for the following year. One AI policy, acknowledged by 236 people. One annual sixty-minute AI-awareness module, 94 per cent complete. No role differentiation, no competence matrix, four contractors with accounts and no training record. |
| Move 1 | 5–23 October | The AI system register is reconciled against expense and identity data. Eleven systems in real use against six on the register. Each is given an accountable owner, and the competence matrix is written from the register outward: nine roles, each with the knowledge its systems demand. |
| Move 2 | 3–28 November | Baseline awareness is cut to twenty-two minutes and rebuilt around the eleven real systems. Four role modules follow: engineering with coding agents, customer-facing staff, people and hiring, and leadership. The leadership session is thirty minutes and built from three decisions the company actually took. |
| Move 3 | From 1 December | The verification-threshold model is published as a one-page annex to the AI policy and, more usefully, pinned in the two channels where the work happens. Tier 3 review is wired into the existing publication and pull-request checklists rather than created as a new step. |
| The event | 19 February 2027 | A contract summariser misreads a liability cap in a scanned renewal. Finance catches it because the threshold rule requires the source clause to be read above a stated value. The near miss is logged, and the finance module gains a scanned-document example within nine days. |
| Stage 2 audit | 11–13 May 2027 | The auditor interviews four people at random, two outside the AI team. Completion evidence covers 244 people including contractors. One minor nonconformity is raised: the effectiveness evaluation for two role modules was a completion report rather than a measure of behaviour. |
The number that did the work is eleven against six. Until the register was reconciled, the training addressed six systems and the organisation used eleven, so five systems had no competence requirement attached to them at all — including, in this composite, the contract summariser that later misread the liability cap. A competence matrix is only as complete as the inventory beneath it, which is why the register work precedes the training work rather than following it.
The February near miss is the most useful artefact the programme produced. It demonstrated the threshold model operating rather than merely existing, it fed a real example into the finance module within nine days, and at the May audit it answered the effectiveness question for that module without anyone having to construct an argument. Near misses are worth logging precisely because they are the cheapest evidence of a control working that you will ever collect.
The minor nonconformity is instructive because it is so common. Completion reports were offered as evidence of effectiveness for two role modules, and completion is delivery rather than effect. The corrective action was small — a short scenario assessment at the end of each module, with results reviewed at the next management review — but it had to be raised because clause 7.2 asks for the evaluation as a separate step from the action.
A completion rate tells you the training was delivered. It tells you nothing about whether anybody can now make the decision the training existed to inform.
What the assessor actually requests
For ISO/IEC 42001 this is an accredited certification body at Stage 1 and Stage 2. For a SOC 2 examination it is a licensed CPA firm testing the people controls as an operating-effectiveness matter. The requests are close enough to prepare once. Note how many of them are about the population and the requirement rather than about the training itself.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of people in scope | A system-generated roster reconciled to an independent source — the identity provider against payroll and the contractor register — covering employees, contractors, and anyone operating a system on your behalf, with counts stated. | A completion percentage with no denominator. A roster that excludes contractors who hold accounts. A list assembled by hand by the person who runs the training. |
| Show how you determined what each role needs | A competence matrix mapping roles to required knowledge, tied to the AI systems in your register and to the risk and impact assessments that justified them, with a date and an owner. | A course catalogue. A statement that all staff receive AI training. Any answer that describes delivery without first describing the requirement it was designed to meet. |
| Show completion for that population | A platform export listing individual, module, date and result for the full roster, including mid-period joiners, with exceptions listed and their closure evidenced. | A screenshot of a dashboard. One certificate offered as representative. A completion figure that does not reconcile to the roster count. |
| Show the content matched the role | The materials themselves, dated, with the version history showing when they were updated and why — ideally referencing the specific tools in your inventory. | A vendor course title with no content. Material whose examples predate the systems in your register, which tells the auditor the content was never mapped to the environment. |
| Evaluate the effectiveness of the actions taken | Something that measures behaviour rather than attendance: scenario assessment results, a fall in unapproved-tool detections, sampled Tier 3 output showing verification recorded, or a documented management review of the programme with actions raised. | Completion rate offered as effectiveness. Satisfaction scores. This is the limb of clause 7.2 most programmes cannot evidence, and it is a routine minor nonconformity. |
| Show awareness reached beyond the AI team | An interview, not a document. The certification body will ask a person in finance or sales what the AI policy says and where they would raise a concern. | A policy published on the intranet with a read receipt. Awareness is tested in the room, and that is the whole difference between clause 7.3 and clause 7.5. |
| Show the named overseer holds real authority | A written delegation naming the person, the system, and their power to override or stop it — plus logged instances where they intervened, or a record of the review where nothing needed intervening. | A role title in an organisation chart. An overseer whose calendar makes intervention impossible, which surfaces the moment the auditor asks how long they have to review each case. |
| Show re-training after a material change | A change record for the AI system linked to the competence update it triggered, with the delivery date and the population it reached. | An annual cycle offered as the answer to a capability change that landed in month two. The gap between the change date and the training date is the finding. |
The mechanic that distinguishes an AIMS certification audit from a documentation review is the interview. A certification body auditor will select people, not files, and the selection deliberately includes staff outside the AI function — that is how clause 7.3 awareness is tested, and no amount of published policy substitutes for a person in accounts payable being able to say what the rules are and who to tell. Prepare people by making the baseline short enough to be remembered, not by rehearsing answers, which auditors recognise immediately.
On the SOC 2 side, the arithmetic is the familiar one: the population is your full roster for the period including mid-period joiners and contractors with accounts, and the firm tests completion against it. Training and policy acknowledgement travel together and are usually evidenced from the same export. A joiner with a training record and no acknowledgement is still a deviation. The competence criterion is CC1.4, communication of responsibilities sits at CC2.2, and accountability at CC1.5 — and a SOC 2 report is an attestation under AT-C 205 issued by a licensed CPA firm, never a certificate.
The edge cases that generate the questions
The matrix above covers the ordinary eighty per cent. These are the situations that produce genuine disagreement between an organisation and an assessor, and where settling the answer before the audit is worth several days.
Contractors, agencies and people operating systems on your behalf
The scope language in both the standard and the regulation reaches beyond your payroll. Clause 7.2 covers persons doing work under the organisation’s control. The AI Act’s literacy duty extends to those operating AI systems on a provider’s or deployer’s behalf. And NIST AI RMF GOVERN 2.2 says personnel and partners. In practice this means the contract development shop, the outsourced support desk and the marketing agency drafting your content. Two workable routes: bring them into your own training and count them in your roster, or place a competence obligation in the contract and collect their evidence annually. What does not survive an audit is a roster that quietly stops at employees while contractors hold accounts in the same systems.
The specialist who knows more than the trainer
Your senior ML engineer does not need a module explaining what a language model is, and making them sit through one damages the programme more than skipping it. Clause 7.2 permits competence to rest on education, training or experience — three routes, not one. Record the basis you relied on, keep the artefact that supports it, and be specific: a named qualification, a publication record, or a documented assessment against your own matrix. The exemption that fails is the undocumented one, where the only evidence is that everyone agrees they are good.
The person who says they do not use AI
They almost certainly do. Assistants are embedded in the mail client, the meeting recorder, the CRM, the helpdesk and the document editor, usually enabled by an administrator rather than chosen by the user. Awareness under clause 7.3 is universal for exactly this reason, and the baseline module should name the embedded features by product so that people recognise what they are already using. A programme that only addresses staff who deliberately open a chat window misses the largest population you have.
Competent but not authorised
The most common oversight defect we see is not a training gap. It is a well-trained reviewer with no standing authority to stop the process, or with a review window so short that overriding is theoretically possible and practically not. Article 26(2) puts competence, training and authority in one sentence, and Article 14(4)(d) speaks of deciding not to use the system or to disregard, override or reverse its output. Both halves have to be real. Test it by asking what happens to the release schedule when the overseer says no: if nobody can answer, the authority does not exist.
A model or capability changed mid-cycle
A vendor updates a model, a connector gains write scope, an assistant gains file access, or a coding agent gains the ability to execute commands. Each of these changes what a competent user needs to know, and none of them appears on your training calendar. The mechanism that works is a link from your change and vendor-monitoring process into the competence matrix, so a capability change raises a training action with an owner and a date. The audit question is simple arithmetic: the change date, the training date, and the distance between them.
Every output verified, or the model is useless
This is the genuine tension, and answering it with “always verify” is what causes the policy to be ignored. Nobody re-derives a rephrased sentence. The defensible position is a published threshold: verification scales with consequence, and the tiers are written down so the judgement is the organisation’s rather than each individual’s. An auditor will accept a risk-based verification standard readily. What they will not accept is an unwritten one, because then the control is a habit rather than a process, and habits cannot be sampled.
A multilingual or distributed workforce
Competence is demonstrated in the language people work in. Training delivered only in English to a workforce that operates in three languages produces completion records and no competence, and the gap shows the moment an auditor interviews someone in their second language about a nuanced data-classification rule. Where the AI Act applies, the literacy provision expressly directs attention to the technical knowledge, experience, education and training of the people concerned — which is a proportionality instruction, not a licence to standardise downward.
The literacy obligation softened, but your contract did not
Regulation (EU) 2026/1744 rewrote Article 4 from a duty to ensure a sufficient level of AI literacy into a duty to take measures to support its development, and stated that no specific level need be guaranteed for any individual. That reduces regulatory exposure, but it changes nothing in the customer agreement you signed last year promising role-appropriate AI training and annual evidence. Check which instrument actually binds you before relaxing a programme. Contracts do not track amendments to regulations.
Where the question is which certificate is worth anything in the first place, start with accreditation and ISO/IEC 42006. Where you need a named competent overseer on an ongoing basis and do not have one internally, that is what a fractional CISO or DPO engagement is for.
What buyers push back on and the answer
These seven arrive in almost every enterprise AI questionnaire and every board discussion that follows one. The difference between a good answer and a defensive one is, as usual, specificity.
“Our people already use ChatGPT every day. Why do they need training?”
Because those are two different competences that happen to involve the same interface. Daily use produces operational fluency — better prompts, faster iteration, a feel for what the tool does well. It produces no knowledge at all of your data classification, your approved-use list, your escalation route, your verification thresholds, or who carries the consequence when the output is wrong. Clause 7.2 asks what competence the work requires, and none of the answers to that question are acquired by using the product. The engineers who worry us least are usually the most fluent ones. The fluency is exactly why they move faster than the guardrails.
“Show us your AI training completion rate.”
A fair question with a misleading answer, and it is worth reframing rather than simply satisfying. Completion measures delivery, not competence, and a 100 per cent rate on a module nobody remembers evidences nothing. The stronger response gives the denominator first — the full population including contractors — then the role breakdown, then how effectiveness was evaluated, which is the limb of clause 7.2 that most programmes cannot answer. Buyers who ask this question are usually working from a checklist, but the ones who matter will recognise a better answer when they see one.
“We require certified AI professionals on the account.”
That is a procurement policy rather than a requirement of any standard, and it is worth naming the difference politely. Neither ISO/IEC 42001 nor the AI Act names a course or a credential. Both point at demonstrable competence, and 42001 accepts education, training or experience as the basis. Where the buyer holds the line, find out whether it is a hard gate or a scoring factor before spending the budget. Where it is negotiable, offer the competence matrix and the named overseer with their written authority — which is more information than a certificate conveys.
“AI literacy is optional now — the Omnibus removed it.”
It softened it. It did not remove it. Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July, replaced the Article 4 duty to ensure a sufficient level of AI literacy with a duty to take measures to support its development, and added that no specific level need be guaranteed for any individual. The obligation survives as one of means rather than result. Separately, the human-oversight provisions at Articles 14 and 26 were not amended, and those are where competence, training and authority are named together.
“How do you know your engineers are not shipping AI-generated code you cannot licence?”
The control is not a training slide, though the training is what makes people care about it. The mechanism is that AI-assisted changes go through the same non-author review as any other change, that dependency additions are checked against a policy, and that the review record shows author and approver as different accounts. The competence element is narrower and specific: engineers need to know that suggested packages may not exist, that suggested code may reproduce licensed material, and that neither risk is transferred by the vendor’s terms.
“Who is accountable when the model gets it wrong?”
The organisation, and within it the person who used the output. That is not a rhetorical position — it is how every instrument here allocates it. ISO/IEC 42001 requires roles and responsibilities to be defined and allocated. The AI Act assigns duties by role, to providers and deployers, not to systems. And a SOC 2 examination tests whether individuals were held accountable for their control responsibilities. Vendor terms allocate commercial liability between two companies and do not touch your accountability to your customer or to a regulator. The useful internal phrasing is that the tool is a method, and methods do not sign anything.
“Annual training satisfies our other frameworks. Why is AI different?”
Because the thing being trained on changes faster than the calendar. A security-awareness cycle works annually because phishing in November resembles phishing in March. An AI estate does not hold still: capabilities arrive on vendor schedules, new tools enter through ordinary procurement, and a connector that gains write scope changes what a competent user must know that week. Keep the annual baseline — it is efficient and it satisfies awareness. Add change-triggered role updates on top, which is the part that actually tracks the risk.
What this costs to build properly
The variable is not headcount. It is how many distinct AI systems are genuinely in use and how many roles touch them in materially different ways. An organisation of 200 people with four systems and three role groups is a lighter build than one of 60 people running eleven systems including agents that hold credentials.
For the ordinary case, expect the register reconciliation and competence matrix to take two to three weeks of part-time work, content build another three to four, and the first full delivery cycle a further month. The recurring load afterwards is small — a few hours a month — provided the change trigger is wired into a process that already exists. Most of the effort is in the matrix rather than the slides, which is the opposite of what people budget for.
Tranquility Cybersecurity has trained 500+ professionals and works across 20+ frameworks in the USA, UK, Australia, UAE & India. On this work we build the competence matrix from your AI register, write the role modules against your actual systems, design the verification thresholds so they land in checklists you already run, and prepare the evidence pack an assessor will ask for. TCSA advises, implements and coordinates. ISO/IEC 42001 certificates are issued by accredited certification bodies and SOC reports by licensed CPA firms. We do neither, and the separation is what makes the readiness work useful.
The most common sequencing error is building the training first. Content written before the register is reconciled describes the systems you thought you had, and the gap between that list and the real one is where every incident in this page’s worked example came from.
Frequently Asked Questions
Does ISO 42001 require AI training?
Is prompting skill the same as AI competence?
Does every AI output need to be fact-checked?
Who is accountable for AI-generated content?
What should role-based AI training actually cover?
How often should AI training be refreshed?
Do contractors and agencies need AI training too?
Did the Digital Omnibus remove the EU AI Act AI literacy obligation?
What evidence of AI competence does a certification body ask for?
Is a completion rate enough to show competence?
Related reading: the AI system register, use-case versus vendor approval, shadow AI, reviewing AI-generated code, AI incident classification, integrating ISO 42001 with ISO 27001, and the ISO 42001 hub. For delivery, see training services.
Related Reading
AI Supplier Due Diligence and Ongoing Review
The artefacts to obtain, why plan tier changes the answer, and what triggers re-review.
Read moreWhen a Model Changes, What Do You Reassess?
The material-change test, the detection problem, and regression testing at scale.
Read moreMonitoring Agents That Work Unattended
Tool-call history is the load-bearing record. What must be captured for an action to be investigable.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more