ISO 42001 Annex A.6.2.2: Specify AI Requirements Before Building or Extending a System
ISO 42001 control A.6.2.2 concerns specifying and documenting requirements for new AI systems or material enhancements. The specification should explain the intended result and relevant conditions, rather than merely name a model or feature. It gives design, evaluation and deployment a common basis for decisions.
What control A.6.2.2 requires in practice
Control A.6.2.2 asks the organisation to define and record the requirements for new AI systems and for material enhancements to existing ones. A requirement in this sense describes what the system must achieve and the conditions that matter, not simply which technology to use. Annex B, as guidance, asks the organisation to record the rationale and goals for developing the system, for example whether a business case, a customer request or government policy drives it, and how data needs can be met and how a model may be trained. It stresses that requirements should span the whole life cycle and be revisited if the system cannot operate as intended or new information arises, for instance if development becomes unaffordable. The outputs are a documented specification and a way of updating it as understanding changes.
Explain why the system is being developed
Annex B.6.2.2 connects requirements with the rationale and goals for development, including how relevant data needs can be met. It considers requirements across the lifecycle and revisiting them when the system cannot operate as intended or new information changes the picture. The guidance must be considered, with tailored implementation allowed by B.1.
A useful starting question is what business or user problem the AI system is intended to address. “Use the latest model” describes a technology preference, not the required outcome. Consider whether the proposed approach is feasible under the available data, resources and operating constraints.
Why AI requirements specification matters
Requirements decide whether later testing and deployment have anything to measure against. A vague specification leaves developers to guess, testers to invent criteria and customers to discover mismatches after delivery. For AI the risk is higher, because capability can look impressive in a demonstration while failing the actual task. Specifying the purpose, constraints and data needs early exposes feasibility problems while change is cheap, and helps management decide whether to proceed, redesign or stop. It also gives clients a reliable basis for agreeing what a service will and will not do, reducing disputes. Recording why a system is being built helps later teams judge whether a proposed change still serves the original purpose.
How to implement control A.6.2.2
Write requirements as outcomes and conditions, and treat the specification as something that is revisited. Where you configure or purchase a system rather than build it, the same discipline applies to deciding what you need and judging whether a supplier's offering meets it.
- State the problem the system addresses and who drives the need, whether a customer, the business or a regulation.
- Describe the intended outcome in terms a tester could check, instead of naming a preferred model.
- Record conditions of use, including users, environment, data available and constraints that matter.
- Identify how the data needs will be met and whether the plan is feasible with the resources you have.
- Cover the whole life cycle, including operation, support and eventual retirement.
- Agree the specification with those who will build, test, deploy and rely on the system.
- Set a trigger to revisit requirements when performance falls short, costs change or new information appears.
Illustrative BPO example: a summary requirement is incomplete
A BPO provider specifies that an AI tool should summarise customer calls quickly. The specification says little about the details staff need to preserve, the languages in scope or how uncertain statements should be handled.
The team clarifies the purpose of the summary and its role in the customer process. It identifies consequential information and the conditions under which employees may rely on the result. These decisions provide a more useful basis for evaluation than a target summary length alone.
Illustrative manufacturing example: the available data changes feasibility
A manufacturer proposes AI detection of a rare visual defect. Initial planning assumes that enough representative examples are available. Discovery shows that historical images lack the detail needed to distinguish the defect reliably.
The organisation revisits the requirements and development approach rather than quietly lower evaluation expectations after building the model. It may need better evidence, a different scope or a different method. The control supports a reasoned reconsideration; it does not require continuing an infeasible project because the initial business case was approved.
Include the lifecycle conditions that matter
Requirements should extend beyond the initial output. Consider relevant operating resources, user interaction, monitoring, change and support needs. These are practical prompts, not an instruction to include every possible feature in every specification.
If human review is essential, specify what makes it possible. If the service depends on a supplier, identify relevant information and constraints. Link the requirements with responsible-development objectives and assessment results so important conditions are not lost when translated into engineering work.
Keep requirements and evidence connected
Requirements should be understandable enough to support evaluation. Avoid vague terms such as “fully trustworthy” without an explanation of the intended result and its limits. Not every requirement needs a numerical threshold, but the team should know how to examine whether it is met.
Control material changes and preserve the reason for them. A requirement changed because new evidence shows a different need is not the same as a criterion relaxed only to make a failing test pass. The decision and implications should remain visible.
Evidence and common mistakes
The control calls for documented requirements. Supporting rationale, feasibility information and links to evaluation can make the record useful. A customer request can inform requirements, but may need clarification before it becomes a complete specification.
Common failures include copying a supplier feature list, ignoring the intended population and treating an enhancement as minor because it uses the same model. Follow the proposed output into its business action to judge whether the changed use needs new requirements and assessment.
Frequently asked questions
Does every enhancement require a new system specification?
The control addresses material enhancements. Update the relevant requirements and evidence in a controlled way rather than automatically create an entirely separate document.
Can requirements change during development?
Yes. New information can justify revision. Preserve the reasoning and examine the effect on design, assessment and evaluation.
Is a supplier's capability statement a specification?
It can provide input, but it does not necessarily describe your intended use, conditions or required result.
Clarify the requirement before committing to a solution
Discuss an AI specification or material enhancement with Sterling. Scoped support can connect objectives, assessment and Effivity ISO & GRC automation software arrangements. AI Risk & Impact Assessment helps teams examine consequential requirements. See lifecycle controls and the complete library.