ISO 42001 Annex A.4.4: Identify the Tools That Shape an AI System
ISO 42001 control A.4.4 concerns documenting tooling resources used by an AI system as part of resource identification. The main model is only part of the picture. Tools used to prepare data, evaluate results or deploy a service can materially influence the evidence and operating behaviour.
What control A.4.4 requires in practice
Control A.4.4 asks the organisation to document information about the tooling resources its AI system uses, again as part of resource identification. Tooling here goes beyond the model that users see. Annex B, offered as guidance, mentions algorithm types and machine learning models, tools or processes that condition data, optimisation and evaluation methods, tools that provision resources, tools that support model development and the software and hardware used for design, development and deployment. The organisation decides which of these influence its system and what facts about them are worth recording. The record should allow a reviewer to understand which tools shaped the system, for what purpose and in what condition. The control does not specify a format, and it does not ask the organisation to document tools unrelated to the system.
Follow what shapes the result
Annex B.4.4 considers tooling across model development, data conditioning, optimisation, evaluation and provisioning, including relevant software and hardware. Organisations must consider this guidance under clause 6.1.3(e), with tailored implementation permitted by B.1.
As an original discovery method, follow one output and one evaluation result backward through the tools involved. Identify which tool transformed an input, applied a rule or produced a score. A product inventory that lists only the user-facing application may miss these dependencies.
Why documenting AI tooling resources matters
The tools used to prepare data, train, test and release an AI system can change results as much as the model itself. If a testing tool is reconfigured, a library is upgraded or a pipeline step is swapped, performance figures can move without anyone deciding that the system should behave differently. Without a record of tooling, such changes go unnoticed, and an organisation may present evidence to a client or auditor that no longer describes the system in use. Documented tooling also supports recovery and continuity: a team can rebuild or investigate a system when a key engineer is absent. It gives purchasing and risk colleagues a view of tool dependence, which matters when a supplier changes its product or terms.
How to implement control A.4.4
Work backwards from results, because the tools that matter are the ones that touched the evidence. A modest record of the handful of tools that truly affect outputs is worth more than a long list nobody maintains, so decide early what level of detail is sensible.
- Pick one output and one evaluation result and trace backwards through every tool that handled the inputs or produced the score.
- List each tool with its purpose, version or configuration basis and who maintains it.
- Separate tools you control from those supplied by others, and note the terms under which suppliers may change them.
- Include data preparation, optimisation, evaluation and release tooling, not only the user-facing application.
- Decide which configuration settings affect results enough to be recorded, and keep those.
- Link tool changes to your change process so a revised configuration prompts a check of earlier evidence.
- Review the list when the system is updated, and remove entries that no longer apply.
Illustrative software example: the evaluation helper changes
A software team uses an automated evaluation tool to classify AI answers as acceptable or unacceptable. After a configuration change, the evaluation becomes more permissive. The model's reported performance improves even though the model itself has not changed.
Documenting the evaluation tool's relevant version, purpose and configuration basis helps the team interpret the result. The tool is a resource supporting evaluation; its output is not unquestionable truth. Appropriate review examines whether the method still supports valid conclusions for the intended question.
Illustrative construction example: a preprocessing tool removes context
A construction consultancy converts project correspondence into a format used by an AI summariser. A conversion tool removes tables that contain important qualifications. Staff initially attribute the incomplete summaries solely to the AI model.
The tooling description reveals the preprocessing dependency and its role. Investigation can then examine where information was lost and what changes are needed. Replacing the main model without understanding the conversion step might leave the same problem unchanged.
Document the level needed for decisions
Relevant information can include the tool's role, supplier or owner, version and important dependencies. These are suggested details, not a prescribed universal inventory schema. A user organisation may have limited visibility into a supplier's internal tooling, while a developer may control much more of the chain.
Make limited visibility explicit and assess its consequence. Avoid pretending to possess a complete technical inventory when the supplier has provided only a marketing description. The organisation can still identify its own tools and the external interfaces relevant to its decisions.
Link tools with evidence and change
A tool can be installed without being suitable for the task. Connect important tooling with evidence of its intended use and relevant limitations. For evaluation tools, this may include the method and population they are intended to assess. For deployment tools, the concern may be which configuration reaches operation.
When a tool changes, examine whether prior evidence remains comparable or relevant. A change in data preparation can affect outputs without a new model release. Connect the resource description with operational change control and verification and validation.
Evidence and common mistakes
The control calls for documentation of relevant tooling resources. A useful record helps a competent reviewer understand the tool's place in the system and locate associated evidence. It should be maintainable by the people who know when the tool changes.
Common weaknesses include listing a platform name without its role, treating evaluation software as inherently authoritative, and overlooking preprocessing or configuration tools. Another is maintaining an elaborate inventory that no one uses when assessing a change. Test the record against a real incident or performance shift.
Frequently asked questions
Does tooling mean only the AI model?
No. Relevant tools can shape preparation, evaluation, development, deployment and operation, depending on the organisation's activities.
Must we document every internal tool used by a supplier?
Consider relevant information within your role and access. Identify visibility limits and their significance rather than claim knowledge you do not have.
Can a tool change invalidate a comparison?
It can affect the meaning of results. Examine whether the changed method or configuration alters what the evidence supports.
Find the tooling dependency behind an uncertain result
Ask Sterling to help scope an AI tooling and evidence review. Agreed implementation support can include resource documentation and Effivity ISO & GRC automation software. AI Risk & Impact Assessment helps connect dependencies with consequences. Return to the resource theme and the library hub.