Resources for AI systems: what Annex A.4 of ISO 42001 requires and how to document it

Ask an organization which AI systems it uses and you will usually get a list. Then ask which datasets one of those systems was trained on, which version of which framework sits underneath it and who can retrain the model if the current data scientist leaves, and the room goes quiet. That is exactly the gap Annex A.4 of ISO 42001 addresses. The controls in this domain require documentation of the resources an AI system needs, across its entire life cycle. In this article we walk through the five controls, in our own words and with the nonconformities we encounter most often in audit practice.

Why the standard dedicates a separate domain to resources

An AI system is more than a piece of software. Its behavior is determined by the data it was trained on, the tooling it was built with, the infrastructure it runs on and the people who maintain it. If one of those four disappears or changes unnoticed, the system changes with it. A vendor quietly updating a pretrained model, a data source drying up, a GPU budget exhausted halfway through the year: all of these affect how AI behaves without a single line of your own code changing.

Documenting resources is therefore the foundation under almost everything else the AI management system does. A risk assessment of an AI system whose data sources you do not know is guesswork. An impact assessment without visibility of the training data cannot take bias seriously. And an incident analysis without version control of tooling and models never gets past treating symptoms.

A.4.2: the overview per life cycle stage

The first control, A.4.2, asks you to identify and document the resources required at each stage of an AI system's life cycle, and for the organization's other AI activities. Think of a resource overview per system that covers the four categories: data, tooling, computing and storage capacity, and people. That overview starts at design, grows during development and deployment, and stays current during operation, up to and including decommissioning.

The format is free. An organization with three AI systems can perfectly well keep this in the system documentation per system; an organization with thirty systems is better served by a central register linked to the AI inventory. The pitfall sits in the coverage: we regularly see documentation that only describes computing capacity and skips data, tooling and people, or that stops at go-live and ignores the operational phase.

A.4.3: data as a resource

For data, the standard asks you to record the data sources the AI system uses: training data, validation data, test data and operational data. Documenting here means more than listing. An auditor wants to see that the suitability of the data has been assessed: is the dataset representative of the target population, complete, relevant for the intended use and checked for bias? Quality and availability belong here too. Quality with concrete criteria, such as accuracy, completeness, consistency and timeliness. Availability with the question of what happens if a data source disappears or access is revoked.

A common nonconformity: data selection happened informally and can no longer be reconstructed. The team roughly remembers which data went into the model, but an assessment of representativeness or bias was never recorded. For a system that supports decisions about people, such a finding carries real weight.

A.4.4: tooling

The tooling control asks for documentation of the tools used to develop, deploy and operate AI systems: ML frameworks, development environments, MLOps platforms, CI/CD pipelines and monitoring tools. For each tool, the version, purpose, licensing terms and known limitations should be in view. Selection deserves attention as well: does the organization choose tooling based on criteria such as security, support and maturity, or based on what an individual developer happens to know?

Open source needs extra care here. Many AI stacks lean heavily on open-source libraries, and that is fine, as long as someone watches vulnerabilities and licenses. The nonconformity we see most often: different teams use different versions of the same frameworks, without a central picture and without a process for updates and tool deprecation.

A.4.5: system and computing resources

AI workloads make different demands on infrastructure than classic applications. Training needs peak GPU or TPU capacity, inference needs predictable latency, and both devour storage for datasets, model artifacts and logging. A.4.5 asks for documentation of those needs per system: processing capacity for training and inference, storage and network requirements.

In practice, more belongs around it: monitoring of utilization and availability, capacity planning that grows with the workload, and availability and recovery measures for production systems. Plus cost control, because cloud costs for AI can climb fast. An organization that does not track its GPU spending usually discovers the problem on the invoice.

A.4.6: people

The last control in the domain concerns human resources: document which people and competencies are needed for development, deployment, operation, change management, maintenance, transfer and decommissioning of the AI system, and for verification and integration. That sounds like a duplicate of clause 7.2, but the angle differs. Clause 7.2 assures that people are competent; A.4.6 ties the required roles and competencies to the system itself.

The most sensitive point here is key person dependency. In many organizations, knowledge of a model rests with one or two people. If that one data scientist leaves, nobody can retrain the model or fix the pipeline. A.4.6 forces you to make that dependency visible, so you can address it with knowledge sharing, documentation or succession planning.

The nonconformities in a row

The common thread in the findings we see in audits on this domain: resources are arranged ad hoc and the documentation is missing or outdated. Concretely: there is no resource overview per AI system. The documentation covers only computing capacity. Data suitability was never assessed for representativeness or bias. There is no tooling inventory and no version control across teams. Open-source components have not been assessed for vulnerabilities and licenses. Capacity planning is absent, costs are not tracked. And key person risks are known to everyone except on paper.

Which documents an auditor expects

Count on the following: a resource register or resource overview per AI system, a data inventory with suitability and quality assessments, a tooling inventory with versions and limitations, infrastructure specifications and capacity plans, and an overview of required roles and competencies per system, including measures against key person dependency. Existing documents count: a DPIA that describes data sources or a CMDB that records infrastructure does not need to be redone, as long as the link to the AI system is made.

A practical approach

Start from your AI inventory and work through the four categories per system. For most organizations this means recording existing knowledge rather than doing new research: the teams know which data, tooling and infrastructure they use, it just is not written down in one place. Then plan for upkeep: tie updates of the resource overview to change management, so a new data source or framework upgrade automatically means an update of the documentation.

In the Secure Audit platform, the guidance for A.4.2 through A.4.6 is attached directly to the standard elements, with interview questions, expected documents and common nonconformities per control. Anyone preparing an internal audit of their AIMS sees in advance what an auditor will look for.