ISO 42001 Annex A.6.1.2: Build Responsible AI Objectives into Development

What control A.6.1.2 requires in practice

Control A.6.1.2 asks the organisation to identify and record objectives that steer how AI systems are developed responsibly, and to act on those objectives by building measures to achieve them into the development life cycle. There are two parts: setting objectives, and making them operational. Stating that a system should be fair or transparent without showing where that affects the work meets only the first part. Annex B, which is guidance, links these objectives to the wider objectives process in the management system, and gives the example of an organisation that sets fairness as an objective: the objective should then appear in requirements, data acquisition, data conditioning, training, verification and validation, with specific tools or methods provided where needed. It also points to examples of organisational objectives that can help choose them. The organisation decides what objectives suit its role and risks.

Make the objective affect the design

Annex B.6.1.2 explains that relevant objectives should influence design and development activities, including requirements, data and evaluation. The guidance must be considered under clause 6.1.3(e); B.1 permits suitable tailoring. It does not prescribe one universal set of ethical objectives or a single metric for all systems.

As an original design exercise, choose an objective and follow where it can be achieved or undermined. If the objective concerns useful human oversight, it should influence the information shown to reviewers and the decisions they can make, not only the wording of a final user guide.

Why responsible AI objectives matter in development

Principles that never reach engineering are easily forgotten when deadlines tighten. Turning an objective into concrete requirements and checks lets the organisation show clients that its stated approach actually shapes what it builds. It also reduces late-stage conflict: a concern about explanation or bias raised during requirements costs far less than the same concern raised at release. Where several teams build different systems, shared objectives give some consistency without forcing identical designs. They also make later audits and customer reviews straightforward, because the link from statement to practice is visible. For managers, the objectives become a way to judge whether a proposed shortcut would undermine something the organisation has said matters.

How to implement control A.6.1.2

Pick objectives the organisation can act on, then follow each one through the stages where it can be won or lost. Fewer objectives, clearly connected to engineering work, are easier to defend than a long list of aspirations that no team can trace into its tasks.

1. Draw objectives from your AI policy, risk and impact findings, customer expectations and legal obligations.
2. Express each in terms a developer can act on, instead of a slogan.
3. For each objective, trace the life-cycle stages it affects, such as requirements, data, training and evaluation.
4. Add the requirement, test or review that gives the objective effect at each stage, for example a specific testing method.
5. Tell teams which tools or guidance to use, and make sure they have the competence to apply them.
6. Check at release whether the objective was met, and record the result and any accepted shortfall.
7. Review objectives periodically against experience, and retire or sharpen those that changed nothing in practice.

Illustrative software example: understandable limitations

Illustrative manufacturing example: performance across relevant conditions

A manufacturer develops an AI inspection aid with an objective of reliable review across the product variants in scope. Data selection focuses only on the most common variant because it is easiest to collect.

The objective should influence acquisition, evaluation and release decisions before development is complete. The team identifies evidence needed for less common but consequential conditions and determines whether the proposed scope remains supportable. A high overall result should not erase a material limitation in an included variant.

Connect objectives across stages

An objective can influence requirements, data preparation, model choices, interface design and verification. Identify which measures contribute at each relevant stage and how evidence will be assessed. The organisation's clause 6.2 objectives provide the wider management-system connection.

Do not assign an objective to one specialist and assume all other teams will incorporate it automatically. Developers, domain experts and evaluators may each need different instructions. The development process should preserve those interactions.

Handle trade-offs and limits accurately

Objectives can interact. A design change that improves one performance characteristic may affect another. Make the trade-off and evidence visible to authorised decision-makers rather than quietly changing the meaning of success.

Where a goal cannot be achieved under the proposed conditions, reconsider the design, scope or intended use. Avoid declaring the objective met because a convenient proxy improved. A larger amount of explanatory text does not necessarily mean users understand the output better.

Evidence and common weaknesses