A city emergency AI runbook change is made during an incident without post-incident formalization. What should the auditor emphasize?

During a city emergency, responders may need to edit an AI runbook immediately to restore service or protect life. That operational necessity does not cancel governance afterward. The auditor should emphasize post-incident formalization of emergency AI runbook changes into controlled change records—capturing what changed, why, who authorized it under emergency authority, and whether the temporary setting becomes the new baseline or is rolled back. Recording emergency AI runbook changes only in the incident timeline fails because a timeline entry is not a controlled change record; it lacks retrospective approval, updated runbook versioning, and operator communication needed to formalize the change. Routing emergency AI runbook edits through standard change approval prior to operational deployment fails because waiting for routine approval in the moment can delay the fix responders need to restore service or protect life; the control is formalizing the change after emergency action, not gating the emergency action itself. Deferring formalization of emergency AI runbook changes until the next scheduled audit review cycle fails because it leaves the change uncontrolled in the meantime, allowing temporary settings to harden without retrospective approval or updated records. Exam caveat: AAIA often accepts emergency change paths but requires follow-up formalization; recording only in the incident timeline, requiring pre-deployment standard approval, and deferring to the next audit cycle are all incorrect distractors. Operational check: after the incident, verify an emergency AI runbook change ticket linked to the incident, with retrospective approval, updated controlled runbook version, and communication to operators.