Overview & purpose

Scoping translates ISO/IEC 42001 requirements into a precise boundary for your AI Management System (AIMS). The boundary lists AI services, processes, people, locations and legal overlays included, plus interfaces to everything outside it. Clear boundaries help auditors and teams understand which systems must follow AIMS controls, why, and how change is governed.

Scope concepts & definitions

• AIMS boundary: The set of AI-related activities, assets and personnel subject to AIMS controls.
• In-scope system: Any AI/ML model, dataset, pipeline, or platform that supports decisions affecting users, customers, staff, or compliance.
• Interface: A dependency between in-scope and out-of-scope elements (e.g., ERP, CRM, data lake, identity provider).
• Exclusion: An out-of-scope element with risk rationale and a named control/owner at the interface.
• Scope Register: Controlled record of in/out items, interfaces, owners, and change history.

Context analysis (internal/external)

• Internal issues: AI maturity, change capacity, operating model, data estate, incident history, supplier reliance.
• External issues: EU/UK regulatory trajectory, sector rules (finance/health), customer expectations, competitive/market pressure.
• Outcome: A documented context statement that justifies the chosen AIMS boundary.

Stakeholders & roles

• Authorising Officer: Approves scope and major scope changes; owns risk appetite.
• AIMS Manager: Maintains Scope Register; coordinates interfaces and evidence.
• System Owners: Accountable for their AI service’s inclusion/exclusion justification and interface controls.
• Legal/Privacy/Security: Validate jurisdictional overlays and data protection boundaries.

Systems inventory & classification

Create a single inventory of AI systems using consistent labels so reporting and audits are straightforward:

• Attributes: name, purpose, users, model type (classifier/RAG/agent), criticality, data categories (PII/SCD/IP), deployment (cloud/on-prem), vendor dependencies, jurisdictions.
• Risk flagging: high/medium/low based on harm potential, autonomy, and affected populations.
• Lifecycle link: connect each item to evaluation plans, release approvals, oversight mode, monitoring.

Inclusions, exclusions & rationale

State what is in-scope and why; equally, document exclusions with controls at the interface:

• In-scope examples: Customer-facing chat assistants (RAG), automated triage tools, HR screening models, agentic workflow tools with external actions.
• Exclusion examples: Offline analytics dashboards without automated decisions; sandboxes used only for research (no production data); external model playgrounds blocked from PII.
• Rationale: Impact on people/compliance; autonomy; exposure to PII/SCD; integration into production workflows.

Interfaces & dependencies mapping

• Data interfaces: data lake → feature store; retrieval index → RAG; logging → SIEM/DSPM.
• Control interfaces: identity & access (SSO/RBAC), secrets vault, egress controls, DLP.
• Operational interfaces: incident platform, monitoring/observability, CI/CD.
• Vendor interfaces: foundation models, vector DBs, evaluation services, annotators.

For each interface, capture owner, purpose, data sensitivity, failure modes, and compensating controls (e.g., allowlists, PII redaction, rate limits).

Jurisdictions & legal overlays

• EU/UK alignment: EU AI Act (high-risk obligations), UK AI principles/guidance, GDPR/UK GDPR for data processing.
• Sector overlays: e.g., FCA, MHRA, medical device rules; ensure scope reflects these obligations.
• Cross-border transfers: SCCs/IDTA, data residency, vendor sub-processor transparency.

Data scope (training vs inference)

• Training: datasets, licensing, provenance, lineage, minimisation, retention; segregation from inference logs.
• Inference: prompts, retrieved documents, outputs, telemetry; PII handling and masking.
• Records: link dataset versions to model versions and releases; maintain deletion/retention proofs.

Shared services & vendors

• Shared components: prompt/guardrail libraries, feature stores, model registry, monitoring stack.
• Vendor AIMS posture: due diligence, DPAs, sub-processor lists, audit rights, incident reporting SLAs.
• Boundary rule: if a shared service is essential to in-scope AI, treat it as in-scope or apply explicit interface controls with evidence.

Scope change control

• Change events: new model/use case, dataset change, jurisdiction expansion, vendor swap, tool with external actions.
• Process: raise Scope CR → risk assessment → decision (include/exclude) → update Scope Register → communicate.
• Cadence: monthly review of pending changes; emergency path for urgent de-scoping or immediate inclusion.

Evidence & sample artefacts

• Signed Scope Statement (versioned), context analysis, stakeholder register.
• System Inventory with classification and risk flags; interface map with owners and controls.
• Legal overlays summary (EU/UK, sector); data lineage and residency matrix.
• Scope Register with change history; approval minutes; communications to teams.

Templates & examples

Title: AIMS Scope Statement — v1.0
Owner: AIMS Manager        Approver: Authorising Officer
Effective: 2025-11-07      Review: Quarterly

1) Purpose & Context
   - We operate AI systems supporting {products/markets}. The AIMS ensures these are safe, lawful, and effective.

2) Boundary (In-scope)
   - Systems: {RAG Assistant v2, Triage Model v1, Agent Runner v0.9}
   - Processes: Design, Build, Test, Release, Monitor, Incident & CAPA, Decommission
   - People: AI product teams, data stewards, oversight operators, approvers
   - Locations: EU, UK (primary processing); cloud region {eu-west}
   - Vendors: {Model API A, Vector DB B} — under vendor DD and DPAs

3) Exclusions (with rationale)
   - Analytics dashboards (no automated actions; read-only)
   - Research notebooks (no production data; gated access)
   For each exclusion, interface controls: {egress allowlist, PII masking, read-only roles}

4) Interfaces
   - Identity/SSO, secrets vault, data lake (read-only to RAG), SIEM, incident platform
   - Controls: RBAC, audit logs, DLP, rate limiting, approval gates

5) Legal overlays
   - EU AI Act high-risk: {if applicable}, GDPR/UK GDPR, {sector rules}
   - Cross-border: SCCs/IDTA in place; residency in {EU/UK}

6) Evidence
   - System Inventory (link), Interface Map (link), Legal Summary (link), Scope Register (link)
  

Implementation checklist

• Context statement documented and approved.
• System Inventory complete; risk flags applied consistently.
• Scope Statement signed; inclusions/exclusions justified with interface controls.
• Jurisdiction and sector overlays captured; cross-border controls defined.
• Data scope split (training vs inference); lineage and retention rules recorded.
• Scope Register live with change control and review cadence.
• Links to evidence (inventory, maps, legal summary) included.

© Zen AI Governance UK Ltd • Regulatory Knowledge • v1 07 Nov 2025 • This page is general guidance, not legal advice.