A city CIO office finds staff pasting resident data into consumer chatbots that are not city-approved. Which organizational security control addresses that risk?

When a city CIO office finds staff pasting resident data into consumer chatbots that are not city-approved, the organizational security control that addresses that shadow-AI risk is to require staff to use only AI tools on the city’s approved allow-list. Allow-listed tools are ones the city has reviewed for contract terms, data residency, retention, training-use restrictions, logging, and integration with municipal identity. Binding day-to-day use to that list reduces uncontrolled leakage of resident and case data into vendors the city does not govern and makes acceptable-use enforceable rather than aspirational.

Banning all browsers so no AI tool can ever be reached is operationally destructive and fails as a proportional control: staff still need browsers for legitimate civic work, and blanket denial invites workarounds. Allowing any chatbot as long as staff promise not to paste sensitive fields relies on hope instead of technical and policy control; promises do not bind consumer products’ training or logging behavior. Deleting the city’s written AI policy so informal tools feel less restricted removes the governance baseline that defines approved tools and prohibited data classes, increasing rather than reducing risk.

Exam caveat: an allow-list is an organizational control; it complements—not replaces—DLP, browser controls, and training. Operational check: publish the allow-list, block or warn on known unapproved consumer GenAI destinations where feasible, require SSO to approved tools, and sample help-desk tickets for shadow-AI paste incidents.