Scoping an AIMS Across In-House, Embedded and Third-Party AI
Meridian Group is a 2,400-person financial services firm seeking ISO/IEC 42001 certification within nine months. It uses AI in four areas: an in-house credit-scoring model in the lending division, an AI screening feature inside a purchased HR SaaS platform used by three recruiters, a generative-AI writing pilot used by 12 marketing staff, and a third-party fraud-detection service whose vendor does not disclose model details. The credit model is heavily documented for regulators. The marketing pilot has no inventory entry, no owner and no usage rules. The CISO proposes excluding the HR SaaS and fraud service because they are 'vendor products', and excluding the marketing pilot because it is 'only a trial'. A draft scope statement says 'all AI systems across Meridian Group'. The steering committee asks you to settle scope before the risk assessment begins.
1. Recommend the AIMS scope and boundary. Explain how you would treat each of the four AI uses and whether the CISO's proposed exclusions are defensible under ISO/IEC 42001 clause 4.3.
Read the worked answer
Start from clause 4.3, which requires the scope to be documented and to consider the issues in 4.1 and the requirements of interested parties in 4.2. A vendor-hosted or embedded AI system is not automatically outside the AIMS: what matters is whether Meridian determines its purpose and use and relies on it in its own processes. The HR screening feature influences employment decisions; the fraud service affects customers and regulatory obligations. Excluding them because they are 'vendor products' would leave significant AI risk outside the management system and weaken the credibility of the scope. The marketing pilot is also an AI system in use. If it is excluded, Meridian must either terminate it or show that it is a genuinely separate activity with its own governance and not used for in-scope processes. A defensible scope would list the organizational units, processes, locations and AI systems included, and would state interfaces and dependencies. It should be backed by an AI inventory, not by the phrase 'all AI'. If shadow AI cannot be found, 'all' is an overclaim. Recommend including lending, HR and fraud, and either including the pilot or shutting it down before certification. Record the rationale and approve it.
2. The draft scope says 'all AI systems'. What documented information and governance decisions are needed to make this scope auditable and to avoid overclaiming?
Read the worked answer
Documented information should include the scope statement, context analysis, interested-party register, AI system inventory with owners and lifecycle status, process and interface maps, roles and authorities, the Statement of Applicability with inclusion and exclusion justifications, and the risk assessment and treatment plan. Governance decisions include one accountable owner per AI system, a new-AI intake and approval gate, criteria for adding or removing systems from scope, a review cycle, and communication to staff and suppliers. To avoid overclaiming, do not say 'all AI' unless the inventory has been built from procurement, IT, HR, marketing and shadow-AI discovery. Use a scope statement such as 'AI systems listed in Inventory A, used in processes X, Y and Z at the named sites', and define how new systems enter scope. Auditors will test whether the scope is real by sampling systems and asking for evidence of controls. If a system is in scope but has no owner or records, the scope is not implemented. If a system is excluded, the justification must be consistent with 4.1 and 4.2 and not simply convenient. The steering committee should approve the scope and record the decision.