A city risk office must approve a generative benefits chatbot. Which action best defines AI risk thresholds before go-live?

Before go-live, AI risk governance requires defined residual-risk thresholds and acceptable residual risk criteria so approval of a generative benefits chatbot is an informed decision against municipal appetite—not an unbounded experiment. Thresholds clarify when controls are sufficient, when treatment is mandatory, and when leadership must accept, mitigate, transfer, or avoid remaining risk related to benefits advice, eligibility misunderstanding, or data exposure.

Defining pre-deployment thresholds using inherent-risk scores before applying chatbot controls gets the sequence wrong, because thresholds must be set against residual risk after controls, not inherent risk before them, and it leaves early production without agreed limits. Adopting the municipal cybersecurity risk appetite for benefits eligibility decisions directly abandons AI-specific risk management, because cybersecurity appetite does not cover residual risks like benefits advice errors, eligibility misunderstanding, or chatbot data exposure. Requiring bias testing results and chatbot service availability targets as formal risk thresholds is too narrow, because those are specific metrics rather than the full municipal residual-risk criteria needed to govern AI appetite.

Exam caveat: thresholds should be revisited when the chatbot's scope, data sources, or resident impact change; a one-time pre-go-live number is not permanent. Operational check: before production approval, document the residual-risk rating, the threshold it is measured against, and the named approver who accepts residual risk within that criterion.