The Scope That Excludes the Risk
Ardent Health's AIMS scope statement covers its patient triage chatbot and radiology triage assistant, but excludes a vendor-hosted resume screener used by HR to rank 4,000 applicants a year. The HR tool was bought by a business unit, not IT; the vendor supplies model updates quarterly. The AIMS manager argues the tool is outside scope because Ardent neither develops nor hosts it, and the vendor holds ISO/IEC 27001 certification. Audit notes show two hiring managers override the ranking for about 30% of candidates, and one rejected applicant has complained that the tool screens out candidates with employment gaps. The certification body has asked for the scope justification and the boundary rationale.
1. Is the exclusion of the resume screener defensible under ISO/IEC 42001? Justify your conclusion.
Read the worked answer
No, not as stated. ISO/IEC 42001 requires the AIMS scope to be defined with reference to the organization's context and to the AI systems it develops, provides, or uses. Ardent uses the screener to make employment decisions, so the tool creates AI-related risks and impacts inside Ardent's boundary even though a vendor hosts it.
The exclusion argument confuses technical hosting with management-system responsibility. Vendor hosting and ISO/IEC 27001 certification address information security, not AI-specific impacts such as discriminatory screening. The 30% override rate also shows the tool materially affects decisions, so it cannot be dismissed as a pilot or incidental use.
A defensible scope could exclude the vendor's internal development activities, but it should include Ardent's use of the tool, its procurement, configuration, monitoring, override practice, and complaint handling. If Ardent still wants to exclude it, the scope statement must justify why the tool cannot affect AIMS objectives - a justification the facts do not support.
2. What should Ardent do about scope, the Statement of Applicability, and evidence before the certification audit?
Read the worked answer
Ardent should revise the scope to include the HR screener as a used AI system, then update the Statement of Applicability so Annex A controls are selected or excluded with justification.
Practical steps:
- Boundary rationale: document that vendor development is outside the boundary but Ardent's use, configuration, and oversight are inside it.
- Roles: assign HR, procurement, and IT responsibilities for the tool.
- Impact assessment: assess effects on applicants, including the employment-gap complaint and override patterns.
- Supplier control: add AI-specific expectations to the vendor agreement - notice of model changes, evaluation data, incident reporting, and audit rights.
- Monitoring: track override rates, denial patterns, and complaints as AIMS performance indicators.
- Evidence: retain the revised scope, SoA, risk and impact assessments, supplier review records, and monitoring reports.
The audit question is not whether the tool is inconvenient to include; it is whether excluding it leaves a material AI use unmanaged. On these facts, including it is the defensible position.
3. If Ardent keeps the tool outside the AIMS, what residual obligations and risks remain?
Read the worked answer
Even with a formally excluded tool, Ardent cannot erase all responsibility. It still uses the output to make employment decisions, so legal, ethical, and reputational exposure remains. The complainants and regulators will look at Ardent's decisions, not only at the vendor's model.
Residual obligations include:
- Due diligence: confirming the vendor's claims and the tool's fitness for Ardent's context.
- Human oversight: ensuring overrides are reasoned and recorded, not informal.
- Transparency: telling applicants where required that automated ranking is used.
- Complaint handling: investigating the employment-gap allegation.
- Contractual leverage: securing notice of model changes and performance data.
Residual risks should be recorded in the organization's wider risk process, with an owner and review date, even if they sit outside the AIMS scope. If the tool later becomes material to AIMS objectives, the scope decision should be revisited.
Keeping it outside the AIMS is therefore a high-documentation, high-scrutiny choice. It does not make the tool low-risk; it only makes the risk less visible to the AIMS - which is precisely what an auditor will challenge.