Recurring municipal AI incidents are closed in problem management but never feed the city's risk register. What linkage should the auditor recommend?

Linking recurring AI incident and problem trends into continuous risk register updates works because repeated municipal AI failures are risk signals, not isolated ticket clutter. Problem management that closes records without escalating pattern frequency, impact, or control weakness leaves governance blind to rising residual risk. Feeding trends into the city risk register enables prioritization, funding, and oversight for systemic AI issues—drift, data quality, vendor fragility—across departments.

Forwarding recurring problem trend summaries to service continuity plans for recovery testing fails because continuity planning addresses service restoration after disruption, not the registration or prioritization of systemic AI risk on the municipal risk register. Recording recurring AI incident patterns in the problem knowledge base for support reuse fails because knowledge-base reuse helps support staff resolve similar tickets faster but does not feed systemic risk into the city risk register for treatment and oversight. Sending repeat AI failure analyses to change advisory board for release scheduling fails because CAB release scheduling governs when changes deploy, not whether recurring AI problems are assessed as enterprise risk and recorded on the risk register.

Exam caveat: not every closed ticket belongs on the enterprise risk register—use materiality thresholds (recurrence, civic impact, control failure) so the register stays actionable rather than a mirror of the service desk. Operational check: define a monthly problem-to-risk feed for AI incidents (criteria, owners, risk IDs), require risk-register updates when thresholds hit, and have internal audit sample whether recurring AI problems appear in risk discussions and treatment plans.