ISO 42001 Annex A.4.5: Understand AI System and Computing Resources
ISO 42001 control A.4.5 concerns documenting information about system and computing resources used by an AI system. It helps the organisation understand whether the resources fit the activity and what constraints affect its decisions. Buying access to a service does not by itself establish that the intended use can operate under actual conditions.
What control A.4.5 requires in practice
Control A.4.5 asks the organisation to record details of the system and computing resources its AI system uses, as part of its wider identification of resources. These are the hardware, networking, storage and platform arrangements that let the system run and that hold its data and tools. The control statement leaves content to the organisation. Annex B, which is guidance, suggests considering the resource needs of the system, including running on constrained devices, where resources are located, such as on premises, in a cloud or at the edge, processing, network and storage resources, and the effects of the hardware on, for example, the environment or cost. It also reminds the organisation that development, deployment and operation can need different resources and that continual improvement can change needs. The record should let a reader judge whether the system can operate as intended under real conditions.
Connect capacity with the operating purpose
Annex B.4.5 considers resource requirements, location, processing and storage, and relevant hardware impacts. It also recognises that development, deployment and operation can have different needs. The guidance is required consideration under clause 6.1.3(e), with implementation tailored under B.1.
A practical resource description explains what the system needs to do and where a constraint could change the result. Capacity, connectivity or storage limitations may influence availability, performance or the ability to retain necessary evidence. The exact details depend on the organisation's role and the service.
Why documenting computing resources matters
A system that performs well in a controlled setting can disappoint on the shared hardware, slow connection or constrained device where it is actually used. Reviewers skip steps when responses lag, and service levels slip when capacity runs short. Understanding computing resources early helps the organisation make realistic promises to customers and avoid redesign after release. It also exposes cost and sustainability effects that management may want to weigh, since running AI workloads can consume significant energy and money. Where resources sit in a supplier's environment, the record shows what the organisation depends on and what it should ask for in contracts. For client audits and due diligence, a clear account of where a system runs and how it is supported answers questions quickly.
How to implement control A.4.5
Describe resources in terms of what the system must do, and then test the description against reality. Remember that a pilot, a production service and a later expansion may each need different capacity, so describe each stage rather than assuming the first setup will persist.
- State what the system must do in operation, including response expectations and the information it must retain.
- Record where the system runs and stores data, and who provides each environment, so that dependence on suppliers is visible.
- Note processing, network and storage requirements for development, deployment and operation separately.
- Compare the evaluation environment with the operating one and write down every material difference.
- Identify constraints that could change results or availability, such as shared devices or limited connectivity.
- Consider cost and environmental effects of the hardware, and record the ones management wants to monitor.
- Reassess the record when the system grows, moves to another environment or a supplier changes its service.
Illustrative manufacturing example: the pilot environment is different
A manufacturer evaluates an AI inspection aid on a dedicated workstation. It later deploys the aid on a shared device at the production line. Other workloads cause delays, and staff begin skipping the intended review sequence to maintain throughput.
The computing-resource description should make the deployment conditions visible. The organisation examines whether the operating environment supports the process criteria and whether a change in resources or use is needed. A successful pilot does not establish performance under every later configuration.
Illustrative IT example: cloud capacity is a dependency
An IT provider uses a cloud AI service for customer-support suggestions. The service has usage limits that were not reached during testing. During a peak period, delays push employees toward an unapproved alternative tool.
The provider documents the relevant service dependency and examines capacity assumptions and fallback arrangements within its role. It does not need to own the infrastructure to recognise the constraint. A statement that the service is “in the cloud” explains neither its limits nor the organisation's response when those limits matter.
Recognise lifecycle differences
Development may require resources unlike those used for everyday inference or monitoring. Evaluation may temporarily need additional storage or specialist environments. Retirement may require preserving selected evidence while disposing of resources appropriately. Document the differences that influence decisions rather than assume one configuration covers every activity.
Where a needed resource is unavailable, make that fact part of design or deployment discussions. A control based on retaining particular records is not credible if the service arrangement cannot provide them. Coordinate with resource documentation and deployment controls.
Consider impacts in the relevant context
The guidance includes consideration of hardware-related impacts, such as resource use and cost. This does not create a universal requirement to calculate an identical environmental metric for every AI system. Determine which impacts matter to the organisation, its objectives and assessment context.
Be clear about the evidence available. Supplier estimates may have boundaries and assumptions that differ from the organisation's use. Avoid presenting a general service claim as a verified assessment of a specific workload.
Evidence and failure patterns
The control's documentation can draw on architecture information, service specifications and operating evidence. It should explain relevant resource needs, locations and constraints sufficiently for assessment and change decisions. Sensitive technical detail can be protected while authorised reviewers receive what they need.
Common weaknesses include assuming unlimited capacity, recording only equipment ownership and ignoring differences between test and production environments. Another is using a technical capacity figure without examining its effect on the business process. A response-time limitation matters because of what users do when the response is delayed.
Frequently asked questions
Do cloud resources need documentation?
Yes, where relevant to the AI system. External ownership does not remove the dependency or the need to understand material constraints.
Must development and operation use identical resources?
No. Their needs can differ. Identify differences that affect evaluation, deployment or operating assumptions.
Does this control prescribe a universal energy calculation?
No. Consider relevant guidance and impacts in context. Do not invent a fixed metric or claim beyond the supporting evidence.
Test the resource assumptions behind an AI use
Discuss an AI capacity or deployment constraint with Sterling. Scoped support can connect resource information, risk decisions and Effivity ISO & GRC automation software. AI Risk & Impact Assessment provides relevant learning. See the resource controls and the complete library.