ISO 42001 Annex A.4.6: Document Human Resources and Competence Across AI Activities
ISO 42001 control A.4.6 concerns documenting human resources and their competence for relevant AI lifecycle activities, including development, operation, change, transfer and retirement. It makes the people behind the system visible. An organisational chart may identify reporting lines without showing who can perform the specialist work on which an AI control depends.
What control A.4.6 requires in practice
Control A.4.6 asks the organisation to document information about the people involved with its AI system and their competences. The control names the activities covered: development, then deployment and operation, then change management and maintenance, and finally transfer and decommissioning, plus verification and integration. It therefore reaches beyond the engineers who build a system to everyone whose knowledge the system relies on. Annex B, which is guidance, suggests considering diverse expertise and the types of roles a system needs, and mentions data scientists, people who provide human oversight, experts on topics such as safety, security and privacy, and AI and domain specialists. It adds that needs differ between life-cycle stages. This control sits alongside, and does not replace, the general competence requirements of the management system. Its purpose is to make sure the organisation can see whether the capability a system needs exists.
Identify expertise by activity
Annex B.4.6 discusses diverse expertise and different resource needs across lifecycle stages. Technical knowledge, human oversight and relevant domain or trustworthiness expertise can contribute. The guidance must be considered under clause 6.1.3(e), while B.1 permits an implementation suited to the organisation's role and treatment needs.
As an original resource test, identify a difficult decision at each relevant stage and ask who can provide the necessary knowledge. Avoid starting with a list of fashionable job titles. The useful question is whether the organisation has access to the capability the activity requires.
Why documenting AI competence matters
AI systems often depend on a small number of specialists, and on domain knowledge that the technical team does not have. If the organisation has never written down who can evaluate results, oversee decisions or maintain the pipeline, a resignation, a reorganisation or a new use case can leave a system without anyone able to support it. Documenting human resources by activity makes those dependencies visible to management before they become incidents. It supports realistic planning of training and hiring, and helps the organisation show customers that the people behind a service are competent for the task. It also prompts a useful question about oversight: whether reviewers really have the knowledge and time to challenge what the system produces.
How to implement control A.4.6
Organise the record by the work to be done, since an organisation chart does not show who can do what. Competence evidence can include experience, training and external support, and the record should say which, so that gaps are accurate and plans to close them can be tracked.
- List the life-cycle activities your organisation performs for a given system, from development through retirement.
- For each, identify the hardest decision and ask who has the knowledge to make it well.
- Record the competences needed, including domain, oversight and trustworthiness expertise, not only technical skills.
- Map named people or teams, internal or external, to those competences and note where only one person holds a skill.
- Compare needs with what exists, and plan training, hiring or outside support for any gap.
- Make sure human reviewers have the knowledge, authority and time their role assumes.
- Update the record when staff, suppliers or system scope change.
Illustrative construction example: technology expertise is not domain expertise
A construction consultancy develops an AI tool to extract progress information from project images. The technical team can evaluate recognition performance, but it may not understand how site sequencing, access constraints or temporary works affect interpretation.
The resource description identifies relevant project and domain expertise and explains where it contributes to assessment and review. It also makes limits clear: a technical evaluation does not authorise an engineering decision. The organisation uses appropriate specialists instead of assuming that one model developer can answer every question.
Illustrative software example: capability disappears after handover
A software provider's development team builds an AI assistant and transfers it to a service team. The developer who understands important evaluation limitations moves to another project. The service team can operate the platform but cannot interpret a new pattern of incorrect outputs.
The organisation identifies the competence needed after deployment and arranges a meaningful handover or continuing access to expertise. Documentation of the human resource dependency helps management see the gap before relying on an unsupported service. A contact name alone is insufficient if the person is unavailable or no longer assigned.
Connect people, duties and evidence
Role allocation explains responsibilities, while A.4.6 makes relevant human resources and competence visible. Clause 7.2 independently requires suitable competence and documented evidence. Keep these perspectives connected without assuming that a role title proves capability.
Evidence may include relevant experience, demonstrated work, qualifications and evaluated development. The record should show why it relates to the task. A general awareness certificate can support understanding but does not establish specialist model evaluation or domain judgement.
Consider representation and perspective appropriately
The guidance recognises that particular perspectives may be needed for the system's design and data context. This does not mean assigning someone responsibility solely because of a demographic characteristic. Determine the relevant knowledge, contribution and method for obtaining it respectfully and competently.
Affected-party understanding can complement technical expertise, especially when consequences are not visible from aggregate performance. Relevant consultation or specialist input may help, but no single participant should be treated as representing every person in a group.
Evidence and common weaknesses
Useful documentation identifies the activity, needed capability and the available resource or dependency. It can connect with workforce planning and supplier arrangements rather than create a separate personnel database. Protect personal information appropriately.
Common failures include overlooking maintenance and retirement tasks, relying on one person with no continuity arrangement, and treating external specialists as permanently available without an agreement. Test a staff absence or changed use to see whether the documented resource plan still works.
Frequently asked questions
Does the control require every organisation to employ data scientists?
No. Human-resource needs depend on the organisation's activities and role. Obtain appropriate capability without copying another organisation's staffing model.
Can external experts provide needed competence?
They can contribute where the arrangement gives suitable access and continuity. The organisation still needs to understand responsibilities and limits.
Does documenting a person's training prove they can perform the role?
Not automatically. Link learning and experience with evidence appropriate to the actual task and operating conditions.
Identify the capability needed for a critical AI task
Discuss an AI expertise or handover gap with Sterling. Scoped implementation can connect competence planning, documentation and Effivity ISO & GRC automation software. AI Risk & Impact Assessment supports assessment contributors before supervised application. Return to the resource theme or the library hub.