Why Competence Matters More in AI Than Almost Anywhere Else
When an organisation deploys an AI system, the stakes are different from deploying a new piece of machinery or a revised quality procedure. AI systems can make decisions at scale, influence outcomes for thousands of people, and behave in ways that are genuinely difficult to predict. That is precisely why ISO 42001 treats competence as a foundational requirement, not an afterthought.
On this page
Clause 7.2 of ISO 42001 sits within the Support section of the standard, alongside resources, awareness, communication, and documented information. But do not let that placement mislead you. In an AI management system, competence is arguably the most critical support requirement of all. Without people who genuinely understand what they are doing, every other control in the system is weakened.
This article walks through what Clause 7.2 actually requires, how it differs from competence requirements in standards like ISO 9001 or ISO 45001, and what auditors will look for when they assess whether your organisation has got it right.
What Clause 7.2 of ISO 42001 Actually Says
The language of Clause 7.2 follows the familiar pattern from the harmonised structure used across modern ISO management system standards. The organisation must determine the competence needed by people doing work that affects AI system performance and AI related impacts. It must ensure those people are competent on the basis of appropriate education, training, or experience. Where gaps exist, the organisation must take action to acquire the necessary competence and evaluate the effectiveness of those actions. And it must retain documented information as evidence of competence.
If you have worked with ISO 9001 Clause 7.2 or its equivalents in ISO 14001 and ISO 45001, that structure will feel familiar. The specific challenge with ISO 42001 is in the detail behind those words. What counts as appropriate competence for AI work? Who needs it? How do you evaluate whether training has been effective? These are harder questions to answer than they might first appear.
Exemplar Global Recognised Training ProviderRTP No. 310970
Who Needs to Be Competent Under Clause 7.2?
The clause applies to people whose work affects AI system performance or AI related impacts. That scope is broader than many organisations initially assume. It is not just the data scientists and machine learning engineers. It includes anyone whose decisions or actions touch the AI system or its outputs in a meaningful way.
Think about who that covers in practice:
- AI developers and engineers who design, build, and maintain the models
- Data teams who prepare, label, and manage the training and operational data
- Product managers and project leads who define requirements and make deployment decisions
- Risk and compliance staff who assess and treat AI related risks
- Procurement teams who select and manage third party AI providers
- Business process owners whose operations rely on AI system outputs
- Internal auditors who audit the AI management system itself
- Senior managers and top management who make strategic decisions about AI use
Each of these groups needs a different type and depth of competence. A data engineer needs technical knowledge of model behaviour, bias, and data quality. A procurement officer needs to understand what questions to ask a vendor and what contractual protections matter. A senior manager needs enough understanding to make informed decisions about risk appetite and resource allocation. A one size fits all training programme will not satisfy Clause 7.2.
What Does Competence Actually Mean in an AI Context?
This is where ISO 42001 becomes genuinely demanding. Competence in AI is not just about technical skills. It has at least four distinct dimensions that organisations need to address.
Technical Understanding of AI Systems
People working directly with AI systems need to understand how those systems work at a level appropriate to their role. For developers, that means understanding model architectures, training processes, validation methods, and the conditions under which a model might fail or produce biased outputs. For others, it means understanding enough about AI behaviour to recognise when something looks wrong.
This is not a trivial requirement. AI systems can fail in subtle ways that are not immediately obvious. A model might perform well on average while producing systematically poor results for a particular demographic group. Without technical understanding, that kind of failure can go undetected for a long time.
Understanding of AI Risks and Impacts
ISO 42001 is built around the concept of responsible AI. That means people need to understand the specific risks associated with the AI systems they work with, including risks to individuals, communities, and society more broadly. This connects directly to the impact assessment requirements in Clause 6.1.2 and Annex A.5.
Competent people need to understand concepts like algorithmic bias, privacy risks from AI processing of personal data, the potential for AI outputs to cause harm if acted upon without appropriate human oversight, and the legal and ethical dimensions of AI use in their specific context.
Knowledge of the Relevant Legal and Regulatory Landscape
AI regulation is developing rapidly in Australia and globally. The Australian Government has published its voluntary AI Ethics Framework, and mandatory guardrails for high risk AI use cases are being actively considered. Internationally, the EU AI Act is reshaping expectations for organisations that operate across borders.
People responsible for AI governance need to stay current with this landscape. That is not a one time training exercise. It requires ongoing professional development and a mechanism for updating organisational knowledge as the regulatory environment changes. You can read more about how the Australian AI ethics framework connects to ISO 42001 in our article on mapping the Australian AI Ethics Framework to ISO 42001.
Practical Application Skills
Knowing about AI risks in theory is not the same as being able to identify and manage them in practice. Clause 7.2 requires competence, not just awareness. That means people need to be able to apply their knowledge to real situations. An AI risk assessor needs to be able to conduct a credible risk assessment, not just describe what one looks like. An internal auditor needs to be able to gather meaningful evidence about AI system performance, not just tick boxes on a checklist.
Determining Competence Needs: A Practical Approach
The first step in meeting Clause 7.2 is determining what competence is actually needed. This sounds straightforward but requires real thought.
Start with your AI system inventory. For each AI system in scope, identify the roles that interact with it or are affected by its outputs. Then, for each role, define what competence is required. Be specific. Vague statements like “understanding of AI” will not satisfy an auditor and will not help your people do their jobs well.
A useful approach is to build a competence matrix that maps roles to required knowledge, skills, and experience. This does not need to be complicated. A simple table with roles down one side and competence requirements across the top, with ratings for required versus current levels, gives you a clear picture of where gaps exist.
Consider using a tiered structure. You might define three levels of AI competence: foundational awareness for all staff who interact with AI outputs, operational competence for those who work directly with AI systems, and specialist competence for those who design, develop, or govern AI systems. Each tier has different requirements and different training pathways.
Addressing Competence Gaps
Once you have identified gaps, Clause 7.2 requires you to take action to address them. The standard is deliberately non-prescriptive about what form that action takes. Training is the most obvious option, but it is not the only one.
Options include formal training courses, on the job learning under supervision, mentoring from more experienced colleagues, secondments or project assignments that build practical experience, hiring people with the required competence, and engaging external consultants or technical experts for specific tasks.
The important thing is that the action is proportionate to the gap and the risk. If someone is making decisions about deploying a high risk AI system and lacks the competence to do so safely, sending them to a half day awareness session is not an adequate response. The action needs to match the significance of the gap.
Evaluating the Effectiveness of Actions Taken
This is where many organisations fall short, and it is where auditors tend to focus their attention. Clause 7.2 requires you to evaluate whether the actions you took actually worked. Completing a training course is not evidence of competence. It is evidence that training was delivered.
Effective evaluation of competence might include post training assessments, practical demonstrations of skill, observation of work performance, review of outputs produced by the person, feedback from colleagues or supervisors, and performance review records.
The evaluation method should be appropriate to the competence being assessed. For technical AI skills, a written assessment might be appropriate. For practical skills like conducting an AI risk assessment, observation of the actual activity or review of the assessment produced is more meaningful.
Keep in mind that competence needs to be maintained over time. AI technology evolves quickly. A person who was competent two years ago may not be competent today if they have not kept pace with developments. Your competence evaluation process should be ongoing, not a one time event.
Documented Information Requirements
Clause 7.2 requires documented information as evidence of competence. This is one of the few explicit documented information requirements in the standard, which tells you how important it is.
What does that documentation look like in practice? It typically includes records of qualifications, training completed, assessments passed, experience, and competence evaluations. It should be sufficient to demonstrate, to an auditor or other interested party, that the people doing AI related work have the competence needed to do it safely and effectively.
Do not confuse training records with competence records. A training attendance sheet tells you someone attended. A competence record tells you they can actually do the job. You need both, and you need to be clear about which is which.
For practical guidance on what auditors look for when reviewing competence records across management systems, the article on how to audit competence records under Clause 7.2 provides a useful reference point.
How Auditors Will Assess Clause 7.2 Compliance
When an auditor sits down to assess your compliance with Clause 7.2, they are looking for a coherent story that connects your AI activities to the competence of the people performing them.
Expect auditors to ask questions like:
- How did you determine what competence was needed for each role?
- Can you show me the competence requirements for someone in this position?
- What gaps did you identify, and what did you do about them?
- How do you know the training or other action you took was effective?
- When was this person's competence last evaluated?
- What happens when the AI system changes significantly? Do you reassess competence needs?
Auditors will also sample records. They will pick specific individuals and trace through from role definition to competence requirements to evidence of competence. Gaps in that chain will result in findings.
A common weakness is that organisations have good training records but no evidence of competence evaluation. Another common weakness is that competence requirements are defined at a generic level rather than being specific to the AI systems and risks involved. Both are likely to attract nonconformities or at minimum observations from a thorough auditor.
The Connection to Awareness and the Broader Clause 7 Requirements
Clause 7.2 does not operate in isolation. It sits alongside Clause 7.3 on awareness, which requires that people understand the AI policy, their contribution to the effectiveness of the AI management system, and the implications of not conforming with requirements. Awareness and competence are related but distinct. Awareness is about understanding. Competence is about capability.
The two requirements work together. You cannot be truly competent in AI work without awareness of why the controls exist. And awareness without the underlying competence to act on it is not sufficient for roles with significant AI responsibilities.
The broader Clause 7 of ISO 42001 also covers resources, communication, and documented information. Understanding how these elements fit together helps you build a support framework that actually works, rather than one that exists on paper but fails in practice. Our overview of Clause 7 of ISO 42001 covers the full picture of these support requirements.
Exemplar Global Recognised Training ProviderRTP No. 310970Practical Steps to Get Clause 7.2 Right
If you are building or improving your AI management system, here is a practical sequence to follow for Clause 7.2:
- Map your AI activities to roles. Start with your AI system scope and identify every role that touches those systems or their outputs in a meaningful way.
- Define competence requirements by role. Be specific. Include technical knowledge, risk awareness, regulatory knowledge, and practical skills.
- Assess current competence against requirements. Use a structured method. Self assessment alone is not sufficient for high risk roles.
- Plan and implement actions to close gaps. Match the action to the significance of the gap. Document the rationale for your choices.
- Evaluate effectiveness. Use methods appropriate to the competence being assessed. Do not rely solely on training attendance records.
- Maintain and update. Revisit competence requirements when AI systems change, when the regulatory environment changes, or when roles change. Set a regular review cycle.
- Keep records. Ensure your documented information tells a complete story that an auditor can follow.
Building AI Competence as a Long Term Capability
The organisations that handle Clause 7.2 well are not those that tick boxes. They are the ones that treat AI competence as a genuine organisational capability that needs to be built, maintained, and developed over time.
That means investing in ongoing learning, not just initial training. It means creating pathways for people to develop deeper AI expertise as their roles evolve. It means building a culture where people feel confident raising concerns about AI system behaviour because they have the knowledge to recognise when something is wrong.
In the current environment, where AI capabilities are advancing faster than most organisations can track, that kind of genuine competence is not just a compliance requirement. It is a competitive and ethical necessity.
If you are working toward ISO 42001 certification or want to develop your ability to audit AI management systems, Audit Workshop offers practical training grounded in real audit experience. Our courses cover the full ISO 42001 standard, including how to assess Clause 7 requirements in a way that goes beyond surface level compliance. You can also explore our guidance on how to become an ISO 42001 AI management system auditor to understand the pathway to auditing AI systems professionally.
