Cloud AI and ISO/IEC 42001: allocating responsibility before your audit

If your AI runs on someone else’s cloud, ISO/IEC 42001 expects you to be able to say who is responsible for what. Most organisations we audit can describe responsibilities inside their own business. Far fewer can show how those responsibilities are agreed with the parties either side of them. This guide sets out what the standard asks for, where we most often see gaps, and what to have ready before an audit.

Three parties, not two

Almost no organisation builds and runs an AI system alone. A typical deployment involves three distinct parties:

• the deploying organisation, which configures the system, supplies the input data and decides what it is used for
• the AI provider, which designs and trains the model, tests it and documents what it can and cannot do
• the cloud infrastructure provider, which supplies the compute, guarantees availability and enforces the security controls underneath

The familiar cloud shared responsibility model splits duties between a cloud provider and its customer. That split was written for infrastructure, not for a learning system whose behaviour emerges from training data the customer never saw. It gives you no way to answer the question that matters after something goes wrong: which of the three should have prevented it?

ISO/IEC 42001 is the first international management system standard written specifically for artificial intelligence, and it does not leave this to chance.

What A.10.2 actually asks of you

Annex A control A.10.2 requires that responsibilities within the AI system life cycle are allocated between the organisation, its partners, suppliers, customers and third parties.

That sentence is more demanding than it first appears, and it is worth reading slowly. It is not satisfied by an internal responsibility matrix. The allocation has to be between organisations, and it has to cover the life cycle, not just the point of purchase.

In practice, an auditor will want to see that you have agreed, with the parties on either side of you, who is answerable for each of these:

• Model design and development governance (A.6.1.2, A.6.1.3, A.6.2.2)
• Impact assessment on individuals and society (A.5.2, A.5.4, A.5.5)
• Security architecture and testing (A.4.5, A.6.2.4)
• Deployment configuration and service levels (A.6.2.5, A.9.4, A.10.2, A.10.3)
• Runtime monitoring and anomaly detection (A.6.2.6, A.6.2.8, Clause 9.1)
• Data governance and privacy (A.4.3, A.7.2, A.7.3)
• Incident response and remediation (A.8.3, A.8.4, Clause 10.2)
• Model update and version control (A.6.2.6, A.6.2.7, A.6.2.8)
• User redress and appeal (A.8.2, A.8.3, A.9.2, A.9.3)
• Regulatory compliance and reporting (A.2.2, A.2.4, A.3.3, A.8.5, Clause 4.2)

If you can produce that list with a named organisation against each line, and a contract behind it, you are in good shape. If the answer to several lines is “the vendor, we assume”, there is work to do.

Where we most often see gaps

Impact assessment treated as evidence, not as a gate

A.5.4 and A.5.5 require you to assess and document the potential impact of an AI system on individuals and on society before deployment. We frequently see this completed after a system is already live, as evidence gathered for the audit rather than a decision point that could have stopped the deployment.

The well documented failure of a widely used US healthcare risk-scoring algorithm makes the point. It used historical healthcare spending as a proxy for health need. Because less had historically been spent on Black patients, the model scored them as lower risk despite being measurably sicker. Nothing failed technically. The system did exactly what it was built to do. What was missing was a documented assessment of whether the chosen proxy was fair.

Treat A.5.4 as a gate before any deployment involving protected-group data. If the assessment cannot change the decision, it is not doing its job.

Intended use never verified by the deploying organisation

A.9.4 places the obligation to ensure a system is used according to its intended use, and its accompanying documentation, on the organisation deploying it. This one cannot be delegated to the vendor, and it is the control we expect clients to find least comfortable.

Public examples are easy to find: facial recognition adopted for suspect identification without documented guidance on accuracy limits by demographic group, and clinical decision tools adopted without validating them against local patient populations first. In each case a third-party model was taken into a high-stakes decision without anyone establishing where its documented limits were.

Before an audit, ask a simple question of each AI system in scope: what did the provider say this was for, and can we show we checked our use against that?

Monitoring that falls between the parties

A.6.2.6 requires monitoring of an AI system in operation. In a multi-party deployment this is the obligation most easily lost, because each party can reasonably assume another is doing it.

It has to be allocated explicitly, and the split we would expect to see is:

• infrastructure availability and security to the cloud infrastructure provider
• application-level performance and outcomes to the deploying organisation
• model drift and known failure mode notification to the AI provider

Incident response obligations under A.8.3 and A.8.4 cannot be triggered by information nobody holds. If no party has agreed to watch for a class of failure, that failure will be found by whoever it harms.

Vertical integration, where the controls have nothing to attach to

This one deserves particular attention because it is easy to miss.

ISO/IEC 42001’s supplier and third-party controls assume the developer, the platform and the infrastructure are separate organisations, because that separation is what gives the controls something to bite on. When a single company holds all three tiers, there is no external supplier to manage under A.10.3 and no arms-length relationship for the accountability provisions to govern.

The oversight mechanism does not fail. It has nothing to attach to.

If you procure AI from a vendor that also hosts it on its own infrastructure and audits its own model, you have one organisation marking its own homework at three levels. That is not a reason to avoid such vendors, but it is a reason to require independent assurance contractually, because the standard’s structural checks will not supply it for you.

Four steps to take before your audit

1. Map the parties honestly. For each AI system in scope, write down which organisation occupies each of the three tiers, and mark where one party occupies more than one. Vertical integration is not a fault, but it removes a check, and your management system has to compensate for that deliberately.

2. Allocate area by area. Work down the list above and name the accountable organisation for each, not just the accountable person inside yours. Where nobody has agreed, record it as a gap rather than leaving it blank. Visible gaps are far easier to defend in an audit than silent ones.

3. Put the allocation into contracts. A responsibility matrix that lives only in your management system documentation is not an allocation between parties. A.10.2 is met when the obligation sits in service level agreements, data processing agreements and terms of use, where it is enforceable. This is the single most common place we find the control satisfied on paper and not in substance.

4. Make monitoring shared and observable. Agree notification paths and, where possible, shared dashboards. Each party should be able to see enough to discharge the obligations it has accepted.

What we look for in an audit

When we audit an AI management system, the question we keep returning to is straightforward: can you show us who outside your organisation has agreed to be responsible for what, and what happens when they do not deliver?

An organisation that can answer that has understood the standard. An organisation that shows us an internal chart has documented an intention.

ISO/IEC 42001 is a strong standard and it is ahead of most regulation in requiring this allocation explicitly. Our observation, from auditing against it, is simply that A.10.2 is doing more work than most implementations acknowledge, and it is easiest to satisfy superficially in exactly the deployments where it matters most.

Written by Asma Khan, Quality Assurance and Compliance Manager, and Mehar un Nisa, Head of Middle East, at Cianaa Technologies.

Cianaa conducts ISO/IEC 42001 audits across New Zealand, Australia and the wider Asia Pacific region as an independent certification body. If you are scoping an AI management system and want to know where your responsibility allocation currently stands, a pre-audit is the sensible first step.