A citywide assistant launches in English only while large resident communities primarily use other languages. What scale risk must the program mitigate?
Select an answer to reveal the explanation.
Short Explanation
If the assistant only speaks one language, it scales help for some neighbors and silence for others. Equity isn’t a go-live checkbox—you have to design language access into the expansion.
Full Explanation
Resident-facing scale-up that launches citywide in English only while large communities primarily use other languages creates equity gaps in who benefits from AI-enabled service. Program managers must treat language access as an expansion-risk mitigation and service-design requirement, not optional polish after English metrics look strong. Strong deflection or satisfaction in English can mask unequal access, due-process concerns, and political legitimacy problems when entire neighborhoods cannot use the assistant effectively. Declaring multilingual access irrelevant once English deflection looks strong privileges aggregate KPIs over equitable service and contradicts inclusive municipal duty. Assuming equity risks disappear automatically when a feature is marked production confuses release state with fairness outcomes. Translating only the marketing homepage while the transactional assistant remains English-only does not remediate service inequity; residents need usable assistance in the languages they actually use for city business. Exam caveat: distractors minimize language access as “nice to have”; the tested concept is equity risk at scale for civic AI. Operational check: assess language demand by community, plan multilingual UX or human language pathways before citywide launch, sample answer quality across languages, track usage and outcomes by language cohort, and gate expansion where critical populations would otherwise be excluded.