](/blog-assets/ru_57.png)
Control A.10.2 – Allocating Responsibilities
In today's article by Kimova AI, we continue our walk through Annex A with Control A.10.2 – Allocating Responsibilities, the control that turns AI governance from a stated intention into something with a name attached to it.
In complex AI ecosystems, unclear responsibilities are the root cause of audit failures, incident chaos and compliance gaps — especially once third-party vendors, data suppliers and customers enter the picture. This control closes the most common governance hole of all: fuzzy boundaries.
Objective of Control A.10.2
The control requires that responsibilities for AI systems are explicitly allocated, so that:
- every AI activity has a named owner
- the split between internal and external roles is unambiguous
- accountability survives changes in staff, vendors and systems
The principle is simple: accountability cannot be implied. If no one is named, no one is responsible.
What has to be allocated
Responsibility must be assigned across the full lifecycle, not only at deployment:
- data handling — sourcing, labelling, retention and quality
- model training, tuning and evaluation
- deployment and change management
- monitoring in production, including drift and performance
- incident response and escalation
- decommissioning and retirement
How organizations demonstrate conformity
From an ISMS auditor's perspective, this control is evidenced through artefacts rather than assurances:
- RACI matrices covering each AI activity and system
- contracts and SLAs that carry accountability through to external parties
- org charts and role descriptions that reflect the AI systems actually in operation
- timestamped sign-offs showing that assignments were reviewed, not merely written once
Auditors look for records that are current. A responsibility matrix that has not been reviewed since the AI system changed is a finding waiting to happen.
Internal versus external roles
Where a supplier operates part of an AI system, the boundary must be documented on both sides. A responsibility that each party assumes the other holds is the classic failure mode — and it typically surfaces during an incident, at the worst possible moment.
Common pitfalls
- responsibilities defined for the organization but never mirrored in supplier agreements
- a RACI produced for the audit and never maintained afterwards
- ownership assigned to a team rather than a role, so it evaporates on reorganisation
- no named owner for model monitoring, which is where most AI risk actually materialises
Best practices
- assign responsibilities by role, not by individual
- review allocations whenever an AI system, supplier or team structure changes
- embed the accountability model into your wider AIMS rather than maintaining it separately
- keep a version history — being able to show who owned what, and when, is the point
Conclusion
Annex A Control A.10.2 makes accountability explicit and auditable. Clear allocation reduces incident response time, removes ambiguity with vendors, and gives auditors exactly what they ask for: evidence that someone, by name, is answerable for each part of the AI system.
At Kimova AI, we see this control as the backbone of a working AI management system — everything else in Annex A depends on someone owning it.
In the next article by Kimova.AI, we'll explore Annex A.10.3 – Suppliers, covering how to identify, assess and monitor the vendors that supply your datasets, models and infrastructure.