A.6.1.2 AI development objectives: evidence and requirements

What A.6.1.2 asks for and why auditors start with the objectives

A.6.1.2 Objectives for responsible development of AI system asks the organization to identify and document the objectives that guide responsible development of its AI systems, such as fairness, security or transparency, and to take those objectives into account and build measures to meet them into the development life cycle. The control sits under objective A.6.1, Management guidance for AI system development, alongside A.6.1.3. The organization owns these objectives. An independent auditor does not write them, but will test whether they exist, whether they are approved, and whether the development process visibly carries them forward. The risk this control addresses is an organization that says it builds AI responsibly while the commitment lives only in a slide deck, a values statement or an engineer's memory. Objectives that are never written down cannot be tested, and objectives that are written but never linked to a design review, a test gate or a release decision give the appearance of governance without changing how systems are built. Auditors usually start here because every later life cycle control, from requirements to verification and monitoring, is judged against whatever objectives the organization declared.

Objectives are hard to make useful because they tend to be vague ("be fair"), unowned (no one is accountable for measuring them) and disconnected from delivery. A practical starting point is Annex C of ISO/IEC 42001, which lists potential AI-related organizational objectives and risk sources that an organization can draw on when setting its own. Each objective should name an owner, a measurable indicator where one is feasible, the life cycle stage where it is checked, and the record that proves the check happened. Confirm with your certification body or consultant how much measurement detail they expect for your context, since that depends on your risk profile and scope, and document the reasoning for any objective you choose not to adopt.

Which AI systems, teams and suppliers fall under A.6.1.2

A.6.1.2 applies wherever the organization develops AI systems, so the first work is deciding which systems, teams and suppliers the objectives must cover. The answers determine whether one objective set serves the whole organization or several sets differ by system risk and by how each system is built.

In-house systems versus adapted third-party models

Systems the organization trains or designs itself carry the full set of development objectives, including data choices and model architecture. Systems built on a third-party model through prompting, API calls or configuration still need objectives, but the supplier's documentation becomes an input to them. Record which category each system falls into, because the depth of evidence the auditor expects differs between the two. Confirm the category with the engineering lead before the objectives are written.

Teams that write and own objectives

Objectives written only by data science often omit security, privacy and accessibility goals that product and platform teams are better placed to set. Name the product owner, the ML engineering lead, the security lead and the privacy officer for each system, and state who approves changes to the objective set. Check that every team building or changing an AI system can point to the objectives it must meet. Unowned objectives tend to be reviewed late or not at all.

Objectives that vary by system risk

A customer-facing assistant that makes eligibility decisions and an internal summarization tool do not need identical objectives. Tie the objective depth to the impact assessment outcome under A.5 so high-impact systems carry stricter fairness, transparency and security objectives. Document the criteria that place a system in each tier. Auditors usually ask how the tiers were set and whether the rules were applied consistently to every system in scope.

Fine-tuning and retrieval pipelines

Fine-tuning changes model behavior, so objectives for training data, evaluation and rollback apply to the tuned model. Retrieval-augmented pipelines introduce document sources, access rules and ranking logic that can leak restricted content or surface stale information. Write objectives for each pipeline component, including the index, the retrieval step and the prompt templates, and link them to the controls that enforce access. Treat each change to a source corpus as a development event that the objectives cover.

Agent features with tools and autonomy

Agent features that call tools, write to systems or chain actions widen the failure modes an objective set must address. Objectives should state the permitted actions, the approval steps for consequential actions and the security goals for tool credentials. Security testing of agent behavior, including prompt injection and tool misuse, provides evidence that these objectives were met. Confirm that each tool integration appears in the system's scope before release.

How an assessor tests the AI development objectives

This table sets out how a certification body's assessor typically examines A.6.1.2, what evidence they ask for, and where organizations most often fall short. Read each row as one test step, with the evidence to prepare before the audit and the findings that signal a weak control.

Test approach	Evidence requested	Common findings
Review the documented development objectives for scope and approval	Objectives document with version history, scope statement naming the AI systems covered, and records showing approval by accountable management	Objectives exist only as general principles such as fairness or transparency, with no measurable intent and no approval record
Trace each objective to a development stage and a measure	Traceability matrix linking each objective to the life cycle stage where it applies, the design or test measure used, and the owner of that measure	Objectives are never linked to a stage or test, so there is no evidence they shape development work
Sample recent AI system projects to confirm objectives were considered	Project records such as design reviews, requirement documents and test plans that reference the applicable objectives (sample selection is agreed with the assessor)	Project files show no reference to objectives, or the references are copied text that does not reflect the project's actual risks
Confirm each objective has a named owner	Role assignments or RACI entries naming who maintains each objective and who checks the related measures	No owner is named, or the owner has no authority or time to act on the objective
Check that objectives link to working tests and gates	Test results, release checklists or gate criteria that show the objective was measured before approval to proceed	Measures exist on paper but no test results are recorded, or gates are waived without documented reasons
Check that objectives were revisited after a material change	Change records showing when a model, data source, use case or deployment context changed, and the objective review that followed	Objectives were written at project start and never updated after retraining, a new use case or a change in users
Review how Annex C was used when setting objectives	Notes showing which potential objectives and risk sources in Annex C were considered and which were excluded, with reasons	No record of how objectives were chosen, so the assessor cannot tell whether the list was considered at all
Confirm the objectives are reflected in the AI policy and management review	Links from the AI policy to the objectives, and management review minutes that discuss objective performance	Objectives sit in a project folder and do not appear in governance reporting to leadership

Implementing A.6.1.2 objectives in the development life cycle

This sequence turns the A.6.1.2 objectives into owned, testable criteria that run through design reviews, release gates and later change reviews, so each objective leaves evidence at every stage of development.

Select candidate objectives from Annex C and risk sources
Start with the AI-related organizational objectives and risk sources listed in Annex C of ISO/IEC 42001, then filter them against the organization's own risk register, intended use cases and the affected populations for each system. Product, risk and legal stakeholders should agree on a short list such as fairness, security, transparency or human oversight, with a one-line rationale for each entry. The output is a versioned objectives register for the AI system or product family, approved by the accountable governance body. The step is complete when every objective traces to a named source, either an Annex C item or a documented risk.
Assign an accountable owner to each objective
Name one accountable person for each objective, usually a role in product, engineering or risk rather than a committee, and record who answers for it when a design or release is questioned. The owner decides how the objective is interpreted for the system, approves exceptions and signs off on evidence. Confirm that the owner has the authority to stop a release, since an objective without that authority is a statement of intent. The output is an ownership table in the objectives register, linked to the roles and responsibilities defined under the organization's AI governance structure.
Define a measurable criterion and test for each objective
Translate each objective into a criterion that a tester can check, such as a stated fairness metric with a threshold, a security test scope for prompt injection or data leakage, or a documentation standard for transparency. Specify the test method, the dataset or scenario, the pass condition and the reviewer. Where a criterion cannot yet be measured, record that gap and the interim control, rather than leaving the objective untestable. The output is a criteria and test catalog that A.6.2.4 verification and validation can reference. The step is complete when each objective has at least one criterion and one test that produces a recorded result.
Write objectives into the development process and design reviews
Add the objectives, owners and criteria to the development process and to the design review template, so each design review asks how the proposed architecture, model choice and training approach serve each objective. Reviewers should record decisions and open risks, and the design record should show which trade-offs were accepted and by whom. Engineering teams should be able to find the objectives from the same tools they use for design work. The output is an updated design review checklist and a sample completed review, which feeds the design documentation expected under A.6.2.3.
Integrate objective tests into release gates
Connect the criteria catalog to the test pipeline and the release approval process, so each objective has an automated or manual check that must pass before a release proceeds. Where a test is automated, such as static analysis in CI or model evaluation runs, store the outputs in a location the auditor can reach. Where a test is manual, define who performs it and what record they produce. Owners should be able to block a release on their objective. The output is a gate definition per release stage and retained test results for each release candidate.
Review objectives when systems or risks change
Set triggers for revisiting the objectives register, such as a new model, a change in training data, a new deployment context, a material incident or a shift in the regulatory position. Each review checks whether the objectives still fit, whether the criteria still measure what matters and whether owners are still in post. Record the outcome, including any objective that was retired or added, and the reason. The output is a dated change log for the objectives register and a link from each change to the impact assessment and risk records. The step is complete when the register reflects the current system, not the version approved at launch.

Evidence that passes A.6.1.2 and how to keep it current

An assessor testing A.6.1.2 looks for a documented set of objectives, proof that they guide real development decisions, and a record of how they changed over time. The cards below name the artifacts that show this, with a routine that keeps each one current between audits.

Documented objectives with owners

A dated objectives register that names each objective, such as fairness for a credit model, security for a support chatbot or transparency for a recommender, with a named owner and an approver. Each entry should state the measure that shows the objective is met and the Annex C risk source it addresses. Keep the register in version control so every edit has an author and a timestamp. Review it at each planned governance cycle and whenever a new AI system enters development.

Traceability from objectives to design

A matrix linking each objective to the requirements, design decisions, model choices and test items that implement it. An assessor uses it to confirm that objectives influenced the life cycle rather than sitting in a policy document. Build the matrix as part of the design record, so each row points to a ticket or document identifier. Check for objectives with no linked test item, since those are the first gap an audit finds.

Review records showing objectives were revisited

Minutes or sign-offs from scheduled reviews where owners confirmed each objective still applied, recorded any changes and noted open risks. Set the review interval in the register itself and assign it to a named role, so reviews do not depend on memory. Record who attended, what was decided and which objectives were carried forward unchanged. Keep these records even when nothing changed, because an unchanged objective still needs proof that someone checked it.

Test results for objective-linked measures

Results from the tests that measure each objective, such as bias evaluations across demographic groups, prompt injection and jailbreak runs, or hallucination checks on a language model. Open-source tools such as garak can produce a JSONL report of every attempt and a hit log of successful attacks, which gives the assessor raw evidence. Store each run with the model version, dataset and date it covers. Results that cannot be tied to a specific model version carry little weight.

Change records for material updates

Records showing that objectives were updated when a material change occurred, such as a new training data source, a new user population or a new regulatory obligation. Link each change to the merge request or release ticket that introduced it, and note which objectives were reassessed. Protected branches in GitLab can require approval before a merge, so the approval itself becomes part of the change record. Confirm with your auditor how they define a material change before writing the procedure.

What meeting A.6.1.2 costs in money and effort

This table breaks the cost of meeting A.6.1.2 into its components, showing who is paid, whether each cost is one-time or recurring, what pushes it up or down, and how to keep it contained. Read it before requesting a quote, because the drivers listed are the items a written scope should state explicitly. No price or duration is implied, since none is supplied for this control.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Internal engineering and governance time	Both: one-time to define objectives, recurring to review and update them	Number of AI systems in scope, number of teams building them, and how many objectives each system must trace	Use one objective set across teams and reference Annex C for the objective list rather than drafting from scratch for each product
Tooling and licenses	Recurring	Commercial observability, testing and code scanning licenses priced per seat, host or usage	Evaluate self-hosted open-source options such as Langfuse (MIT), garak (Apache-2.0) and Semgrep Community Edition, and confirm each license terms with the vendor
Test and red team work	Recurring, repeated at each material release	Number of AI systems, risk level, and how often models or prompts change	Automate probe runs in CI/CD so each release produces the same records, and scope deeper manual red teaming to high-risk systems
Evidence upkeep	Recurring	Volume of traces, test reports and change records, and whether evidence is collected by hand	Keep objectives, test results and approvals in version-controlled repositories with protected branches, so records are generated during normal work
External review	Recurring, usually at planning and before certification	Whether a partner prepares the objective set and gap review, and how much of the work the organization already owns	Ask the partner to state which deliverables are documents, which are configured systems, and which the organization must approve itself
Auditor sampling	Recurring, tied to surveillance and recertification cycles	Number of AI systems and objective records an auditor samples, and quality of traceability between objectives and tests	Maintain a single traceable register linking each objective to its design decision, test and release approval so samples are quick to pull
Written quote items to request	One-time at contract signing	Scope in AI systems, teams, objectives, environments and deliverables	Require the quote to list each component above separately, with the owner of each task and the evidence each deliverable produces

Open-source tools that produce A.6.1.2 evidence

A.6.1.2 is satisfied by documented objectives, not by tools alone. The four tools below produce records that show whether objectives such as safety, security and transparency were tested, operated and changed under control. Each one only becomes useful evidence once the organization has defined its objectives and linked each test, trace or approval back to them.

garak for objective-linked model probing

garak is an Apache-2.0 scanner that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. Its JSONL report records every attempt and evaluation, and its hit log lists the attempts that found a weakness. Map each probe family to a stated objective, such as data protection or safe output, so the report shows that the objective was tested. Confirm which probes your model type supports before you cite results.

Langfuse traces as operating evidence

Langfuse (MIT) records each trace of a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For A.6.1.2, traces show whether objectives such as response quality or cost limits hold in real use, not only in test. Tag traces with the objective they measure and set a review cadence. Confirm the retention and access settings in your own deployment, since they determine how far back evidence goes.

GitLab protected branches for approvals

GitLab Community Edition (MIT) protected branches restrict which roles can push or merge to a branch, can block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Use them to ensure that changes affecting an objective, such as a safety filter or a fairness threshold, pass through a named reviewer. The branch history then shows who approved each change. Check that approval rules are enforced in your version and that the reviewer roles match your documented responsibilities.

Semgrep rules in CI/CD pipelines

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including Python, JavaScript, TypeScript, Go, Java and Terraform, using community or custom rules. Running it in CI/CD scans repositories on each change. Write custom rules for objectives that code can enforce, such as blocking logging of personal data or requiring a human approval step before a model is promoted. Review the license terms with counsel before distribution, since LGPL obligations depend on how the software is used and modified.

Who owns A.6.1.2 and what is worth outsourcing

Your organization owns the objectives themselves. A.6.1.2 asks you to identify and document the objectives that guide responsible AI development, such as fairness, security or transparency, and to build measures for them into the development life cycle. Choosing which objectives apply to your AI systems, weighing them against your business purpose and risk appetite, and approving them is a management decision that no outside party can make on your behalf. Annex C of ISO/IEC 42001 lists potential AI-related organizational objectives and risk sources you can draw on, but selecting from that list is still your call.

Objective selection: Decide which objectives apply to each AI system or class of system, and record why others were excluded.
Approval: Have a named executive or governance body approve the objectives and any later changes, with dates and versions.
Accountable owners: Assign a specific person to each objective, such as a product owner for fairness metrics or a security lead for adversarial testing.
Integration decisions: Define which development gates, reviews and release criteria each objective feeds into.
Review cadence: Set when objectives are revisited, such as after a material model change or a new regulatory requirement.

Check that every objective has an owner, an approver and a link to at least one measure in your development process before any outside party starts work.

Common gaps in AI development objectives and how to close them

Most objectives for responsible AI development fail in predictable ways: they are written once and never connected to the system, the work or the decisions that follow. The cards below name six common shortfalls against A.6.1.2 and the concrete action that closes each one.

Template objectives with no system link

Objectives copied from a policy template often name fairness, security or transparency in general terms that could apply to any AI system. An assessor reviewing A.6.1.2 will look for objectives that reflect this system's purpose, users, data and failure modes. Close the gap by rewriting each objective around the specific system, then recording which design decisions it drives, such as the choice of training data or the human review step for high-impact outputs.

Objectives without measurable criteria

An objective like "the system will be secure" cannot be tested, so no one can show it was met. Each objective needs a criterion, a measure and a threshold or review condition that a reviewer can check. For example, a prompt injection objective can point to the test cases run, the attack categories covered and the pass condition agreed before release. Ask the owner to state how the team will know the objective is met and what evidence it will keep.

Objectives with no named owner

When an objective belongs to everyone, nobody updates it when the model, data source or deployment context changes. Record one accountable owner for each objective, separate from the people who implement it, and state what that person must approve or accept. The owner should be identifiable in the roles documentation that supports the A.3 controls, so an auditor can trace who decided that an objective was met.

Objectives that never reach a gate

An objective that appears only in a policy document has no effect on delivery. Connect each objective to a specific design review, testing gate or release approval where it is checked and where the outcome can block progress. Confirm with the engineering team which gate applies to each objective, and keep the gate record as evidence that the objective was taken into account during development.

Objectives not revisited after change

A model retraining, a new data source or a new use case can make an existing objective irrelevant or incomplete without anyone noticing. Set explicit review triggers, such as a material change to the model, the training data or the intended use, and require the objective list to be reviewed before the change proceeds. Keep dated versions of the objectives so the record shows what was in force at each release.

Conflicting product and risk objectives

Product teams may target speed or accuracy while risk teams target caution or explainability, and both objectives sit in the same document without a stated resolution. Record each conflict, the decision taken, who made it and the rationale. Escalate unresolved conflicts to the management level that owns AI governance, so the trade-off is an accountable decision rather than a silent default.

A.6.1.2 cost, timeline and in-house or partner questions

What does meeting A.6.1.2 cost, and what drives the price up?

No supplied fact gives a price for A.6.1.2, so the cost depends on the work in your environment. The main cost is staff time: leaders who set the objectives, engineers who build the measures into the life cycle, and a reviewer who checks the records. Costs rise with the number of AI systems in scope, how many regulated markets you sell into, how many objectives you must justify, and how much of the evidence already exists. Recurring cost comes from reviewing objectives when systems change. Ask any partner for a fixed-scope written quote that lists the systems covered, the deliverables and who signs off each one. DeployOpen does not publish a price list, and a quote follows from that written scope.

How long does it take to put A.6.1.2 objectives in place?

The time depends on how many AI systems you develop, whether objectives already exist in policy, and how quickly leaders agree on priorities such as fairness, security and transparency. Teams that already keep a documented AI policy usually need less time to turn it into system-level objectives. Teams starting from nothing spend most of their time on agreeing trade-offs between objectives and deciding how each one will be measured. Ask for a timeline in the written scope that ties each milestone to a named deliverable, and confirm with your certification body when it expects to see the objectives in operation.

What does the internal team need to supply?

The internal team owns the objectives and the decisions behind them. You need an accountable owner for AI development, product and engineering leads who can translate each objective into a design or test measure, and someone from risk or compliance who can check that the objectives are documented and traceable. Engineers must be able to show where an objective affects code, data, model choices or release gates. An implementation partner can prepare the templates, records and tooling, but it cannot decide your organization's priorities or accept residual risk on your behalf.

Can a small team meet A.6.1.2 without outside help?

A small team can meet A.6.1.2 alone if it has a named owner, a short list of AI systems and time for review. Annex C of ISO/IEC 42001 lists potential AI-related organizational objectives and risk sources that a small team can use as a starting list, so it does not need to invent every objective. The harder part is consistency: each objective needs a measure, an owner and a record that shows it shaped the work. Outside help is most useful for a readiness review, for building the evidence trail, or for testing whether the measures hold up. Confirm the scope of any outside help in writing before work starts.

What should a partner put in a written scope for A.6.1.2?

A written scope should state which AI systems and life cycle stages are covered, which objectives are in scope, and which deliverables you will receive. It should name the records produced, such as the documented objectives, the mapping from each objective to design, test and release measures, and the review schedule. It should also say who performs each task, what the organization owns, what the partner prepares, and how changes to scope are handled. Ask for the acceptance criteria and the dates for each deliverable. Be cautious of any scope that promises a certificate or an auditor's opinion, because only an independent certification body can issue those.

Can one set of objectives cover several AI systems?

Yes, an organization can set common objectives for several AI systems, but each system still needs its own measures. A shared objective such as security or transparency gives consistent direction across products, while the design, testing and monitoring steps differ by system. Be specific about where a shared objective applies and where a system adds its own objectives, for example a higher-risk use case that needs stricter human oversight. Keep one record that maps each system to the objectives it must meet, so an assessor can trace the link from policy to a specific system.

Will an auditor accept A.6.1.2 objectives that are not certified?

An auditor does not certify objectives, and ISO does not certify organizations either. Certification is issued by an external certification body, and only that body can decide whether your AI management system conforms. Your documented objectives are evidence that the organization set its direction, and the auditor will test whether those objectives are used in practice. Ask your certification body early which records it expects and how it samples AI systems. ISO/IEC 42006:2025 sets additional requirements for bodies that certify AI management systems, so confirm the body's accreditation status before you contract with it.

How DeployOpen scopes and evidences A.6.1.2

DeployOpen helps organizations set up the systems, records and evidence behind their A.6.1.2 objectives, inside their own infrastructure. The organization decides its objectives and owns the control; DeployOpen prepares the tooling and documentation, and only an independent auditor or certification body can issue a report or certificate.

How we scope

Engagements are fixed-scope, with the A.6.1.2 objectives, systems and development projects in scope agreed in writing before work starts.
The written scope lists which AI systems and development life cycles the documented objectives must cover, such as fairness, security or transparency.
Scope also confirms which Annex C risk sources the organization uses as input when setting its objectives and who approves them.

How we build

We configure protected branches in GitLab Community Edition so objective-linked changes to AI code and configuration need approved review.
We set up Semgrep Community Edition scans in CI/CD pipelines with custom rules that check for objective-related coding issues.
We instrument AI applications with Langfuse traces and run garak probes to produce recorded evidence that stated objectives are being measured.

How we hand over

Deliverables include the written objectives register, a mapping of each objective to its development life cycle measures, and the test and trace records behind them.
Documentation is written so the organization's own owners can maintain objectives, review them and update them as systems change.
Handover includes walkthroughs with the internal owners so the organization can explain its objectives and evidence to an auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover periodic refresh of the objectives register and of the scanning and probe results as AI systems change.
Before engaging any party, confirm with the certification body which evidence it expects for A.6.1.2 and how it will be sampled.