1 Clause
Scope
The draft gives organisations a common set of descriptors for saying what an AI system does and how it does it. It is written for every kind of organisation that touches an AI system at any point in the system life cycle, and for every stakeholder role, not only the builder.
What this settles
The scope decides who can use the framework and for what. It is broad on purpose: a procurer, an assessor and a developer are all meant to describe the same system in the same terms, so the description can travel between them without being re-invented.
Who it binds
No one, in law. This is a voluntary descriptive standard. It binds an organisation only when a contract, a procurement schedule, a regulator or a management system adopts it by reference.
What to do in your practice
Write one sentence that says which systems you will describe with the framework and which you will not. Name the roles that will read the description. Without that sentence, every team invents its own boundary and the matrix stops being comparable across the estate.
Evidence an auditor or regulator asks for
| A scope note naming the AI systems and life cycle stages covered. | Shows the boundary was decided rather than assumed. |
|---|---|
| A list of the roles that read the characterization, with the decision each one makes from it. | Connects the descriptor set to a real reader. |
| The date the scope was agreed and the owner who agreed it. | Makes the boundary reviewable when the estate changes. |
Which AI systems would a colleague expect to see in this description, and which are deliberately outside it?
Common gaps this page catches
- The scope is copied from the standard and never adapted to the estate.
- Only the build team is named as a reader, so procurement and assurance describe the system differently.
- No date or owner is attached, so the boundary cannot be reviewed.
What to prepare before publication
Before the draft is published, agree the boundary in one meeting: the systems in scope, the stages covered, the roles that read the output and the person who owns the list.
How to test it here
Take one live system rather than a template, find the field or sentence where Scope is used, and put this page beside it. Record the answer, the artefact and the date. A glossary entry on its own is an intention; a dated record beside a live artefact is evidence.
What this page does not claim
The page does not reproduce the draft, does not know the descriptor wording that the public preview withholds, and does not certify the system or the organisation. It states the unit at the claim level "scope statement" and stops where the public record stops.
Common questions
- What does Scope mean in ISO/IEC DIS 42102?
- The draft gives organisations a common set of descriptors for saying what an AI system does and how it does it. It is written for every kind of organisation that touches an AI system at any point in the system life cycle, and for every stakeholder role, not only the builder.
- What evidence should we keep for 1?
- A scope note naming the AI systems and life cycle stages covered. A list of the roles that read the characterization, with the decision each one makes from it.
- Is Scope a requirement?
- No. The draft is a descriptive framework. It sets no management system requirement and no conformity test. It becomes binding only when a contract, a regulator or a management system adopts it.
Related units
Last updated: · Markdown version · Check your system