ISO 42001 AI Resources: Data, Tools, Computing and People

Describe the system that must actually operate

Begin with a specific system and intended use. Identify what is supplied internally, what comes from customers or third parties and what changes across development, evaluation and operation. This establishes the boundary for useful resource information. An inventory of every technology in the company is unlikely to explain the dependencies of one important AI service.

A.4.2 provides the connecting view. A simple diagram or structured record can show how components, information and responsibilities fit together. These are suggested methods, not compulsory document formats. The record should help a decision-maker recognise a missing dependency, understand the consequences and identify who can resolve it. A visually impressive architecture diagram with no owner or current status is less helpful than a modest record people maintain.

Annex B requires consideration as part of control implementation, and its guidance can be tailored under B.1. It discusses resources through the life cycle and the implications when required resources are unavailable. The practical question is not simply whether a resource exists today, but whether the proposed system can be developed, operated and changed on a supportable basis.

Connect four resource views without collapsing their differences

The data view describes relevant data resources and their characteristics: where they originate, their intended roles, update arrangements and associated responsibilities. It helps reveal whether the information needed for a proposed use is available and suitable to assess. Detailed quality and provenance controls belong in the data theme; listing a dataset in a resource record does not prove it is appropriate or authorised for use.

The tooling view covers the models, algorithms and relevant software or hardware tools used across the system's life cycle. Record enough to understand significant dependencies and their purposes. A toolchain can include preparation, development, evaluation and provisioning activities, not merely the final model. The degree of detail should support decisions and traceability rather than becoming an indiscriminate list of every installed utility.

The computing view considers requirements for processing, storage, networks, location and related infrastructure. Different stages may have different needs. A development experiment can run successfully in an environment that does not support reliable operational use. Cost and environmental implications can also matter in context; neither a universal computing specification nor a standard carbon threshold is created by this theme.

The people view identifies the resources and competence needed to develop, deploy, operate, maintain and change the system. Consider business and domain understanding alongside technical expertise. A system that depends on knowledgeable review needs people who can actually perform that review when required. Merely naming a human oversight role does not supply its time, competence or authority.

Illustrative IT service example: an assistant with hidden dependencies

An IT service provider proposes an AI assistant that helps support analysts find relevant troubleshooting information. The demonstration works well with a small curated knowledge base. The production proposal assumes access to several client knowledge repositories, a third-party model service and analysts who can judge whether a suggested response fits the customer's environment.

A resource review exposes three separate dependencies. Some repositories lack clear update ownership; the model service has operating constraints that affect the proposed workflow; and experienced analysts have not been allocated time to evaluate questionable suggestions. Buying additional processing capacity would not resolve any of those issues. The team records each dependency against the intended use and decides what must be established before operational approval.

The provider then distinguishes resources needed for evaluation from those needed in service. Evaluation requires representative cases and competent reviewers; operation requires maintained information, support arrangements and a usable escalation route. The resulting resource record supports decisions about rollout scope. It does not claim that documenting these items alone establishes acceptable risk or proves the assistant's performance.

Illustrative construction example: project analytics in changing environments

A construction organisation wants AI-assisted analysis of project progress photographs. The same application may be used across sites with different connectivity, camera practices, project stages and information restrictions. A central team initially describes the resource requirement as “access to the platform,” overlooking the conditions under which usable information is captured and reviewed.

The project and technical teams map the complete path: image collection, authorised transfer, preparation, processing and review by people who understand site conditions. They assess what happens when connectivity is limited or the available images do not represent the relevant work. They also identify who can distinguish a useful progress indication from an unreliable inference. These are governance and resource decisions, not instructions for construction safety or acceptance of completed work.

When the organisation considers a new site, it checks the resource assumptions rather than copying the original approval. Differences may require an adjusted workflow, additional evaluation or a narrower use. The record makes the decision explainable: a delay may arise from missing representative data or review capacity, rather than from resistance to technology.

Make resource changes visible to risk and operation

Resources change after implementation. A dataset stops being updated, a supplier changes a component, a specialist leaves or a computing arrangement moves. Determine which changes can affect the system's requirements, performance, impacts or permitted use. Connect those changes to the appropriate assessment and operational processes instead of treating the inventory as a passive catalogue.

A useful review follows a dependency from resource information to the decision it supports. If an external component becomes unavailable, can the owner identify the affected service and the required response? If competent review capacity falls, does anyone reconsider the operating arrangement? These tests reveal whether the documentation is useful without imposing a specific technical monitoring solution.

Be proportionate about detail. Highly consequential or fragile dependencies may deserve closer control than interchangeable low-impact tools. Explain why the selected level of information is enough. The aim is to reduce avoidable surprises, not to make staff update a record whose detail has no connection with decisions.

Evidence, ownership and common failures

Evidence can include maintained resource records, component relationships, competence information, ownership allocations and the decisions made when a resource is missing or changes. Distinguish the control's documented-information needs from optional supporting methods such as dependency maps or capacity reviews. A reviewer should be able to understand the relevant resource picture without requiring a particular spreadsheet or software screen.

Common failures include documenting only purchased components, overlooking customer-supplied data, assuming supplier support covers internal responsibilities and treating people as an unlimited resource. Another is recording planned resources as if already available. Use clear status and ownership so that a design assumption cannot quietly become an unsupported operational fact.

Connect the resource picture with AI life-cycle controls and external relationships. The Annex A overview explains how those themes support risk treatment together. Resource documentation is most valuable when it informs a decision to proceed, change the approach, reduce scope or obtain what is missing.

Individual controls in this theme

Why knowing your AI resources matters

An AI system is only as dependable as the things it relies on: the data it learned from, the tools that shaped it, the infrastructure it runs on and the people who can support it. When any of these is poorly understood, the organisation cannot judge risk, estimate impact or promise service with confidence. Typical business consequences are an output nobody can explain, a system that works in a pilot but not in daily use, and a key supplier or specialist whose absence stops the service. Gaps are also found before a commitment is made to a client. For auditors, this theme shows whether the organisation's risk and impact work rests on facts about its real systems.