A common question since ISO 42001 landed: the team started using Copilot, so are we in scope now? The honest answer is that it depends on your scope statement, and there are two different ways in. Most writing on this picks one and ignores the other, which is how teams end up assembling the wrong evidence pack.
Which ISO 42001 AI pipeline controls your delivery pipeline can evidence depends entirely on which way in applies to you, and for one of the two the answer today is none. The general model for turning pipeline activity into control evidence is in the guide to CI/CD compliance; what follows is the ISO 42001 cut of it, including the large part the pipeline cannot help with.
What ISO 42001 actually governs
ISO/IEC 42001:2023 is an AI management system standard. It sits alongside ISO 27001 in structure and intent: 27001 asks whether you manage information security, 42001 asks whether you manage the AI systems you are responsible for. Its Annex A controls cover AI policies, internal roles, resources, impact assessment, the AI system lifecycle, data management, information for interested parties, responsible use, and third-party relationships.
Read that list and the shape of the problem appears. Most of it is governance and assessment work carried out by people, and recorded in documents. Only one family, the AI system lifecycle controls, describes activity a delivery pipeline performs.
Two ways into scope, and they are not the same
The first is the artefact. Does this pipeline build or deploy an AI system: does the thing it produces contain or serve a model whose behaviour the organisation is responsible for. A fraud scorer, a recommendation engine, a service wrapping a model. This is the route the standard's lifecycle controls are written for.
The second is the process. An organisation can declare its AI-assisted business processes inside the management system, and coding is one of those processes. Organisations going through certification are doing this, with scope statements covering both the products they build and the AI-assisted work of building them. Under that route the use of coding assistants is in scope even though the software shipped is conventional.
The two are independent. A team shipping a payments service written with a coding assistant is in the second and not the first: the service is not an AI system, and the practice of building it with assistance may still be inside the certified scope. You can be in neither, either, or both, and the pipeline evidence available differs completely between them.
What this rules out is answering the scope question with the artefact question. “Our product is not an AI system, so 42001 does not apply to us” is a non sequitur if the scope statement covers AI-assisted development. That mistake runs in the reassuring direction, which is what makes it worth naming.
Both routes are declarations rather than detections. Nothing in a pipeline's run history reliably indicates that the thing being built is an AI system, and nothing in it indicates what an organisation wrote in its scope statement. Any tool claiming to determine your 42001 scope automatically is guessing. The organisation declares scope; the pipeline then evidences what it can within it.
The ISO 42001 AI pipeline controls a pipeline can evidence
This section is the first route only: a declared AI system. There, four Annex A controls have a genuine pipeline signal, and all of them sit in the A.6.2 lifecycle family. If you are in scope by the process route instead, skip ahead: none of these attach to a conventional service, whatever wrote it.
A.6.2.4, verification and validation. Automated test gates, acceptance gates, and a required build gate are all V&V measures, and the pipeline records that each ran, on which commit, with which result. The honest caveat: 42001 expects AI-specific validation, meaning performance against stated criteria, robustness, and bias testing. Generic unit tests are necessary but not sufficient. They are partial evidence and should be presented as partial.
A.6.2.5, deployment. This control asks whether requirements were met before the system was deployed. The pipeline evidences it positively through validated migrations and required pre-deployment gates, and negatively through the things that route around them: a commit that skipped CI on the way to production, a hotfix that bypassed the standard path, a force push onto a protected branch, an approval step that is rubber-stamped every time rather than genuinely exercised.
A.6.2.6, operation and monitoring. Evidenced by the fact that the deployed system is monitored at all, which is a property of the platform rather than of any single pipeline run.
A.6.2.8, recording of event logs. Evidenced by the run history and the audit trail over it. The structure of that trail is covered in building an audit trail from CI/CD.
Four controls, out of roughly thirty-five in Annex A. That is the whole of it, and any vendor implying broader ISO 42001 coverage from pipeline data is overstating what pipeline data contains.
Why your security controls do not count here
The tempting move, once a team has SAST, secret scanning, and dependency scanning running as automated gates on every commit, is to point them at ISO 42001 and claim coverage. That is a category error. Those are information-security controls, ISO 42001 explicitly defers information security to ISO 27001, and an auditor working the 42001 checklist will not accept them.
The same gates map cleanly to ISO 27001, where they belong and where they carry real weight. That mapping is set out in the ISO 27001 CI/CD evidence checklist. Running both standards usually means running one set of gates and cutting the evidence two different ways, not building two pipelines.
What the pipeline cannot evidence
Being explicit about the gap is more useful than a coverage percentage. No pipeline signal exists for AI policies, internal organisation and roles, resource allocation, AI impact assessment, the data management and data quality controls, information provided to interested parties, responsible use, or third-party and customer relationships. Those are the substance of ISO 42001 software development governance, and they are produced by people and recorded in documents.
One gap deserves singling out because it is frequently misrepresented. Data provenance under A.7.5 concerns the lineage of data used by the AI system, meaning training and input data. Artefact signing and an SBOM evidence artefact integrity and component inventory, which is a different thing entirely. Signing your model container does not evidence where the training data came from, and presenting it that way will not survive scrutiny.
The honest summary for the first route: the pipeline executes part of the AI lifecycle. It does not run your AI management system.
If you are in scope by the process route
The control set is different, and so is the answer. Declaring AI-assisted development inside the management system engages the governance controls rather than the lifecycle ones: responsible use, AI impact assessment, third-party relationships with the assistant vendor, and the policy and role controls that say who decided what and on what basis.
Every one of those sits in the list above of controls no pipeline signal reaches. So the practical position is stark: if your scope covers AI-assisted coding, the pipeline evidences approximately nothing for it today. Not a small amount. None of the controls that route engages are things run history speaks to.
There is one plausible exception worth watching rather than claiming. Responsible use is substantially about human oversight of AI output, and coding assistants can record attribution on the commits they contribute to. A pipeline that read that attribution could evidence that AI-assisted changes went through review and the standard gates, dated per change. We do not read it today, and there is a ceiling on how good that evidence could ever be: attribution is opt-in, so its absence proves nothing. Partial evidence honestly labelled is the best available outcome there.
Until then, treat the process route as a documentation and governance exercise that the delivery pipeline supports indirectly, through the change-management and approval evidence it already produces for other standards.
Where CI/CD Watch fits
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, audits pipelines against a rule set and produces dated, structured findings, which is the raw material an evidence pack is assembled from across all five families of pipeline-relevant controls: access, change management, segregation of duties, audit trail, and secure development.
For ISO 42001 specifically, the coverage is the narrow lifecycle slice described above, conditional on you declaring which repositories build AI systems, and there is nothing yet for the process route. We would rather say that plainly than show a reassuring compliance percentage that falls apart under an auditor's first question.
Neither is something a tool can infer. Scope is a decision your organisation records and an auditor tests, so any product offering to work out your 42001 exposure from pipeline data is selling a guess. Separately from the standard, the question of whether AI assistance is helping your delivery at all is answerable from pipeline data, and that is the subject of AI-assisted software development.
Where to start
Read your scope statement first, and read it for both routes. Which repositories build or deploy an AI system, and separately, does the scope cover AI-assisted business processes. Teams tend to answer the first and assume it settles the second. It does not, and the gap is where evidence packs come apart.
For repositories in scope by the artefact route, confirm the lifecycle gates are enforced rather than optional, because a gate that can be skipped evidences nothing under A.6.2.5. For the process route, expect to evidence it through documentation and oversight records rather than through the pipeline, and resource that as the management system work it is.
If you want the pipeline half producing dated evidence before the first audit conversation, connect a provider and run an audit. The findings arrive structured and dated from the first run, which is the form an evidence pack needs and the form a screenshot taken the week before an audit does not have.
CI/CD Watch is built by 3CS Technologies Ltd, a UK consultancy that has run pipeline audits across regulated programmes and now runs the same engine inside the SaaS platform. Our mapping work on CI/CD compliance records where a control is only partially evidenced, because a partial mapping presented as a complete one is the failure mode that costs an audit.