A city risk register lists permitting AI only under generic technology risk with no AI-specific scenarios. What finding should the auditor raise?

The auditor should raise that AI-specific risks such as model error, bias, and opaque decisions are not identified beyond generic IT categories. Permitting AI can mis-score applications, treat neighborhoods unevenly, or produce decisions applicants cannot understand—failure modes that generic “technology risk” lines do not describe, prioritize, or drive controls for. Effective municipal AI risk management requires naming those scenarios so residual risk, KRIs, and treatments attach to the actual civic harm pathways.

Claiming that existing IT general controls for change management address permitting model validation and bias testing needs fails because change management governs deployment mechanics, not whether the model is accurate, fair, or explainable, leaving model-specific treatments unfunded and unmonitored. Asserting that vendor service level agreements for system uptime provide sufficient coverage of permitting decision quality risks fails conceptually: uptime guarantees keep the system available, they do not ensure decisions are accurate, unbiased, or explainable. Relying on a completed data privacy assessment for applicant records to satisfy the need for documented AI risk scenarios in permitting decisions fails because privacy assessments protect personal data; they do not identify, prioritize, or control AI-specific failure modes such as model error or bias.

Exam caveat: listing AI buzzwords without linking them to permitting workflows, data sources, and decision rights still leaves the register ornamental. Operational check: review the permitting AI risk entries for named scenarios (accuracy, bias, explainability, drift), mapped owners, and treatments, and confirm they differ substantively from generic infrastructure risk language.