Most organizations approaching ISO 42001 for the first time assume the scope question is straightforward: list the AI we built and call it done. In practice, the scope declaration is where the first audit findings appear, not because organizations are careless, but because the standard’s definition of “AI system” is broader than intuition suggests, and because most organizations are using AI they haven’t formally classified as such.
The scope statement is the first output of the AI management system. It determines what the AIMS is actually governing. An auditor reviewing it is asking one question: does this reflect honest organizational reality, or was it written to minimize the work?
What ISO 42001 means by “AI system”
Clause 3 of the standard defines an AI system as an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, decisions, or content that influence real or virtual environments. This is broader than most organizations expect.
The definition covers:
- ML-based models: classification, regression, generative
- Optimization systems
- Computer vision and NLP components
- Rule-based decision systems, where those systems are deployed as part of an AI system boundary
What the definition does not require: internal development, novel architecture, or explicit AI labeling by the vendor. An LLM accessed via API is an AI system. An ML-driven anomaly detection feature in a SIEM is an AI system. A SaaS “smart routing” feature built on a trained model is an AI system if the organization is using it in a consequential process. Whether the vendor calls it AI is not the test. Whether it meets the Clause 3 definition is.
ISO 42001 applies to organizations that develop, provide, or use AI systems. The “use” category is the one that catches most organizations off guard. You do not need to be building AI to be in scope for the standard.
The inventory problem
You cannot scope what you haven’t found. The scope statement is only as accurate as the inventory that underlies it, and the inventory step consistently surfaces more AI systems than organizations expected to find. A structured discovery pass typically covers five areas:
- Vendor and procurement register. Flag any vendor whose contract or service description includes AI, ML, machine learning, intelligent automation, or predictive features. This catches third-party SaaS AI before anyone has to inspect each product individually.
- SaaS subscriptions. Check which products have AI add-ons enabled or in active use: copilot features, AI-assisted search, automated summarization, smart categorization. Many of these are on by default and go unnoticed.
- API consumption logs. Identify calls to OpenAI, Anthropic, Google Vertex, Hugging Face, Azure OpenAI, or similar endpoints. If engineering is consuming a model API in a product or internal tool, that is an AI system in use.
- SDLC and infrastructure review. Flag ML model training pipelines, inference endpoints, A/B tested decision systems, and any automated scoring or ranking processes deployed in production.
- Process walk-throughs. Interview team leads for automated decision points: hiring screening, credit or risk scoring, content moderation, fraud detection, pricing optimization. These surfaces are often managed by business teams who do not think of what they are doing as “AI.”
The output is a list of candidate AI systems with: name or identifier, vendor or internal origin, purpose, data processed (especially personal data), and a preliminary assessment of the consequentiality of its outputs. This list is the raw material for the scope decision.
Three scope mistakes we see consistently
“We don’t build AI”
The most common first-audit scope failure: the scope statement says “not applicable: no AI systems in scope,” while the organization is actively consuming an LLM API in a customer-facing product, has AI-assisted HR screening enabled in their ATS, and is running an ML-based fraud detection model from their payment processor. None of those are internally built. All of them are AI systems in use.
The “we don’t build AI” position is sometimes defensible, but only after a genuine inventory confirms it. An organization that has run a documented discovery process and found nothing in scope has evidence. An organization that assumed it before looking does not.
Scoping by product instead of by system
Common in product companies: the ML recommendation engine is in scope; the AI-assisted support triage tool, the automated anomaly detection in the data pipeline, the internal document summarization tool, and the fraud model embedded in the checkout flow are not. Each exclusion may have been a deliberate decision, or each may simply not have come up during the scope discussion.
Exclusions are valid when justified; the standard does not require unlimited scope. But silence is not justification. When an auditor finds an AI system that is not in scope and not documented as excluded, the question is not “why wasn’t this included” but “how many others are missing.” One undocumented exclusion undermines confidence in the entire scope statement.
Scope that doesn’t survive a Clause 4 cross-check
Clause 4.3 requires that scope be determined considering the organizational context from Clause 4.1 (internal and external factors) and the interested parties from Clause 4.2. A scope statement written before the context analysis is complete, or written without reference to it, is an easy finding: the two documents say different things, or the scope excludes systems that the context analysis identifies as relevant to AI risk.
Order matters. Context analysis first. Interested parties second. Scope third. Organizations that draft scope on day one, then do context analysis later as a separate compliance exercise, arrive at contradictions that are visible to an auditor within the first hour of document review.
What a defensible scope statement looks like
A defensible scope statement is one that is specific enough to be auditable. That means it contains:
- Named AI systems or well-defined categories, with enough specificity that an auditor can determine whether a given system is in scope or out
- Justified exclusions, with documented rationale for each AI system found in the inventory but excluded from scope
- Explicit linkage to Clause 4 outputs (what organizational factors shaped the boundary decisions)
- Any physical or organizational limits that apply (specific geographies, business units, product lines)
Auditors check the scope statement against several reference points: Clause 4.1 and 4.2 outputs, Clause 6.1 risk assessments (is there one for every in-scope system?), Annex A controls (do they reference the right systems?), and management review records (is scope reviewed periodically, not just at initial certification?).
A scope statement vague enough to avoid contradictions is also vague enough to be a finding. “AI systems used by the organization where applicable” is not testable. When scope cannot be tested, it cannot be audited. When it cannot be audited, the AIMS has no boundaries that can be verified.
How scope gaps cascade
A system missing from scope does not generate one finding. It generates a chain of them. When an auditor identifies an AI system that should have been in scope:
- No risk assessment (Clause 6.1). The standard requires AI-specific risk assessment for in-scope systems. An unscoped system has none.
- No impact assessment (Annex B). ISO 42001’s impact assessment framework applies to in-scope systems. A missing system has no documented evaluation of potential harms.
- No supplier controls (Annex A.6). Third-party AI systems trigger supplier management obligations. If the system isn’t in scope, those obligations were never applied.
- No lifecycle controls (Annex A.6.1–A.6.2). Data management, model documentation, testing, and deployment controls attach to in-scope systems. Missing from scope means missing from the control evidence.
A single unscoped system found during fieldwork typically generates five to eight linked findings. The scope gap is the root cause; the clause findings are the visible surface. In audit reports, this pattern concentrates findings in a way that looks worse than it is, but it is still a significant gap that requires remediation before surveillance or recertification.
The organizations that arrive at ISO 42001 fieldwork with the fewest scope-related findings are the ones that ran a genuine inventory first, documented their exclusion decisions, and resolved any conflicts between context analysis and scope before fieldwork began. Scope is the foundation. What gets built on it is only as solid as what it rests on.