Roles and responsibilities in an AIMS: who does what under ISO 42001?

Ask an organization who is responsible for a specific AI system and you will often get three different answers, or none at all. The business points to IT, IT points to the vendor, and the security department has never seen the system. This is not an exception; it is the normal starting situation in virtually every ISO 42001 project we support. AI governance rarely fails on documents and almost always on ownership. In this article: which roles an AI management system (AIMS) needs, how to assign them and which mistakes to avoid.

What the standard requires

ISO 42001 follows the familiar structure of management system standards. Clause 5 places responsibility firmly with top management: they must demonstrate leadership, establish the AI policy and ensure that roles, responsibilities and authorities for the AIMS are assigned and communicated. The standard does not prescribe which positions you must have. There is no need for a Chief AI Officer or a ten-person AI ethics committee. What must exist: an identifiable person or role for every relevant task in the AIMS, and top management that demonstrably steers it.

That sounds obvious, but the auditor tests it very concretely. Who assesses new AI applications before they go into use? Who owns the AI risks of a specific system? Who decides when a test result is out of bounds? If the answer to these questions is a department instead of a role, or a person who knows nothing about it, there is work to do.

The core roles in a working AIMS

In practice, a workable role model consists of a limited number of building blocks, which can be combined into fewer people depending on the size of the organization.

Top management establishes the AI policy and risk tolerance, allocates resources and conducts the management review. This cannot be delegated. An AIMS in which top management only shows up at the certification audit falls apart at the first serious question.

The AIMS coordinator (often the same person as the ISMS coordinator or compliance officer) keeps the system running: the AI inventory up to date, the risk assessments scheduled, the internal audit organized and the evidence in order. This is an orchestrating role, not an ownership role. The coordinator does not own AI risks; those belong to the business.

The AI system owner is the line manager in whose process the AI system runs. HR owns the CV screening system, marketing owns the segmentation model, operations owns the planning algorithm. The owner is responsible for use within the agreed boundaries, for following up on risks and for the decision to switch a system on or off. This is the role that is most often missing, and without it governance remains a paper exercise.

The data owner is accountable for the quality, provenance and lawfulness of the data that feeds an AI system. For procured AI, vendor management is added: who monitors the agreements with the AI vendor on updates, log access and incidents?

Finally, independent review: the internal auditor who periodically examines the AIMS. This role must not coincide with the people who design and operate the system; independence is a requirement of the standard.

Security advises, the business decides

The most common design mistake is assigning AI risk ownership to the security or compliance department. It feels logical, because that is where the expertise sits. But the effect is predictable: every AI initiative must pass through a single bottleneck, the business does not feel responsible for outcomes, and security becomes the department that always says no. The model that works is the same as in information security: security and compliance advise, set boundaries and review, but the business decides within those boundaries and owns the outcomes. This also matches how ISO 42001 intends governance: embedded in the organization, not isolated in a staff department.

For organizations working with the three lines model: AI system owners and data owners sit in the first line, the AIMS coordinator and risk function in the second, and internal audit in the third. AI does not require a new governance model; it requires that AI systems get a place in the existing one.

Connecting to existing roles: CISO, DPO and ISMS

Most organizations starting with ISO 42001 already have an ISMS under ISO 27001 and often a data protection officer (DPO). Use that. Role descriptions, the management review cycle and the internal audit planning can largely be extended rather than rebuilt. Two caveats. First: the CISO is not automatically the right owner of AI risks, because these go beyond security: bias, transparency and impact on affected persons are not classic security topics. Second: the DPO has a legally anchored, independent advisory role under the GDPR. Do not make the DPO an executive owner of AI systems, because they would end up reviewing their own work.

Competences and AI literacy

Assigning roles is step one; making sure the people in those roles can do their job is step two. ISO 42001 requires the organization to determine which competences are needed and to demonstrate they are present. The EU AI Act adds an obligation with Article 4: everyone working with AI systems on behalf of the organization must have an appropriate level of AI literacy. For an AI system owner that means something different than for a developer or an end user. Differentiate training by role and record who completed what; that is exactly the evidence an auditor asks for.

Common mistakes

Assigning ownership to departments instead of roles, so that nobody is accountable. Parking all AI responsibility with security or the DPO. Setting up an AI committee that advises but holds no mandate, so decisions land nowhere. Assigning roles on paper to people who do not know it themselves (the auditor interviews them, and the system falls apart). And forgetting that procured AI also needs an internal owner: the vendor manages the model, but the responsibility for its use lies with you.

What the auditor tests

At a certification audit you can expect three types of questions on this topic. Documentation: are roles, responsibilities and authorities recorded and up to date? Interviews: do the people in those roles know what is expected of them, and can they name decisions they have made? Operation: does the evidence show the role model works, for example a risk acceptance signed by the right owner, or a new AI system that went through the assessment process before going live? Consistency between these three is what matters.

Conclusion

An AIMS stands or falls with ownership. The standard does not require new positions but does require sharp choices: top management that steers, a coordinator who orchestrates, system owners in the business who decide and account for outcomes, and an independent internal audit. Assign the roles this way and the rest of the AIMS (risk assessment, policy, evidence) suddenly runs much more smoothly, because every question has an accountable owner.

Secure Audit helps organizations set up a workable AIMS under ISO 42001, including the role model and governance. Get in touch for a no-obligation conversation.