A citywide 311 call center is deciding whether to centralize citizen-request data into one repository or keep it federated across department systems before deploying an AI routing tool. Which approach best supports a solid data foundation for the AI initiative?
Select an answer to reveal the explanation.
Short Explanation
Think of city data like plumbing before you install a fancy faucet: if the pipes underneath don't match, water still won't flow right. What matters isn't whether data lives in one building or many, it's whether every department speaks the same data language. Get the standards and interoperability sorted first, and the AI routing tool has something solid to work with.
Full Explanation
An AI routing tool depends on consistent, comparable inputs from every department's request data, field names, categories, and formats need to line up whether the data sits in one database or several. That's the mechanism: interoperability, not physical location, determines whether an AI system can reason across sources reliably. Forcing full centralization before launch conflates a data-architecture preference with a genuine prerequisite; many federated environments work fine for AI once a shared schema and access layer exist, and mandating consolidation can stall the initiative on infrastructure that wasn't actually required. Assuming the model will silently reconcile mismatched formats misreads how these systems work, inconsistent inputs produce inconsistent routing decisions, not automatic correction. Pushing the governance conversation to a later phase treats a foundational risk as an afterthought, which tends to surface as unreliable routing only after residents are affected. Scope caveat: the right data-architecture choice varies by agency size and legacy systems. Operational check: audit whether request records from two departments use compatible category and status fields before launch.