Allocating Responsibilities
Decide and write down which party (your organisation, your partners, suppliers, customers or other third parties) is responsible for each task across the life of an AI system, so no duty is left unowned.
Plain language
When you build or run an artificial intelligence (AI) system, the work rarely sits with one organisation alone. A supplier might provide the model, a partner might host it, your own staff might operate it, a customer might feed in their own data, and other third parties might handle support or reviews. This control says you must agree, in writing, who is responsible for what at every stage of the AI system's life, from design and build through to running it, changing it and shutting it down. The point is that when responsibilities are split across several parties but never written down, the gaps between them are where things fail: each party assumes someone else is handling a problem, and no one acts.
Framework
ISO/IEC 42001:2023
Control effect
Preventative
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
19 June 2026
Official control statement
The organisation shall ensure that responsibilities within their AI system life cycle are allocated between the organisation, its partners, suppliers, customers and third parties.
Why it matters
If a shared AI system produces a harmful or unlawful result and no party was named as responsible, each side points at the other while the affected people (customers wrongly refused a service, for example) get no fix and no answer. An OAIC complaint or a regulator's enquiry then lands on your organisation, because under the Privacy Act 1988 and your contracts the accountability does not transfer to a supplier just because they built the tool. Unallocated duties also stall incident response: a model fault can sit live for weeks while the organisation and its suppliers argue over whose job it was to monitor it.
Operational notes
Treat the responsibility allocation as a living record, not a one-off contract annex. Re-confirm who owns each duty whenever a partner or supplier is added or dropped, a customer's role in feeding or operating the system changes, or the system moves to a new life-cycle stage such as a major change or decommissioning. Pay attention to the seams between parties, such as handover points at deployment, where a duty can quietly fall between two organisations and end up owned by neither.
Implementation tips
- The person who owns the AI management system should map the AI system's full life cycle (design, build, deployment, operation, change and decommissioning) and, for each stage, write the name of the single party responsible, whether that is your own organisation, a partner, a supplier, a customer or another third party. A one-page responsibility matrix or RACI chart is usually enough to make the split visible.
- When procurement or the contract owner sets up a supplier or partner agreement, they should write into it which party is responsible for each ongoing duty (monitoring the model, maintaining it, responding to incidents and decommissioning it) so accountability does not stop at the moment of delivery.
- The product owner should agree with each partner and supplier, in writing, who handles customer-facing failures, so that when an AI gives a customer a wrong or harmful result there is no doubt about which party investigates and which party communicates with the affected person.
- The AI or data owner should, for each external data source the AI uses, record which party is responsible for that source being accurate and lawful to rely on (the customer who supplies it, a supplier who licenses it, or your own organisation) so the duty to keep each source fit for use has a named owner rather than being assumed.
- The risk or compliance owner should re-confirm the whole allocation whenever a supplier, partner or customer role changes, or the system enters a new life-cycle stage, and record who signed off the updated split so unowned gaps are caught before they cause harm.
Audit / evidence tips
- AskAsk for the document or matrix that allocates AI responsibilities across the life cycle.GoodEach life-cycle stage has a single named responsible party, and the split between the organisation and its partners, suppliers, customers and third parties is explicit.
- AskRequest a supplier or partner agreement for an AI system.GoodThe agreement assigns named ongoing responsibilities to each party across the system's life, not just who builds or sells it.
- AskAsk to see what customers are told they are responsible for.GoodA signed or published statement sets out the customer's responsibilities and distinguishes them from those your organisation retains.
- AskAsk the AI owner to name which party is responsible for each external data source the AI relies on.GoodEvery external data source has a named party accountable for it, and that party is recorded alongside the source.
- AskAsk for evidence the allocation was reviewed after a recent change in suppliers, partners or life-cycle stage.GoodA dated review record shows responsibilities were re-allocated after the change and signed off by a named owner.
Cross-framework mappings
How Annex A 10.2 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
handshakeSupports(2)expand_less | ||
| Annex A 5.19 | Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle among internal and external parties | |
| Annex A 5.20 | Annex A 10.2 requires clear allocation of responsibilities across the AI system life cycle, including with suppliers and other third parties | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| ISM-1569 | Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle between the organisation and external... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ISO 42001 controls in A.10 Third-party and customer relationships
See all A.10 Third-party and customer relationships controls, or browse the full ISO 42001 library.
Want to implement this AI control?
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.