A city completed a DPIA/PIA for a CRM, then added an AI scoring layer without updating the assessment. What should audit require?
Select an answer to reveal the explanation.
Short Explanation
Bolting AI scoring onto a CRM changes the privacy story — new inferences, new risks. Refresh the PIA/DPIA for that AI processing instead of pretending the old write-up still covers it. Just logging the scoring layer in the inventory and keeping the old scope won't cut it.
Full Explanation
Audit should require updating the privacy impact assessment to cover AI-specific processing introduced by the scoring layer. Adding AI scoring to a CRM changes inferences, profiling, and decision influence on residents even if the scoring layer is merely documented in the system inventory. DPIA/PIA processes must be refreshed when processing materially changes so AI-specific privacy risks—automated ranking, opacity, and secondary use of scores—are assessed and treated.
Documenting the scoring layer in the system inventory while retaining the original risk analysis scope fails because inventory continuity does not preserve processing continuity. Requesting the vendor bias test summary as a substitute for updating the internal assessment fails conceptually: a vendor summary does not replace the organization's own assessment obligation. Directing the privacy review toward vendor contract terms while postponing analysis of scoring logic fails because contract terms are administratively insufficient without analyzing the actual scoring logic; triggers must be processing changes such as new AI scoring.
Exam caveat: a one-line addendum that says “AI added” without analyzing score inputs, outputs, human review, and retention of inferences is not a meaningful update. Operational check: compare the current scoring-layer data flows to the last PIA/DPIA scope; require a revised assessment with AI-specific risks and residual treatments before broader scoring use.