Transit runs local AI pilots under a citywide AI policy while a central office sets standards. What operating-model choice does this reflect?
Select an answer to reveal the explanation.
Short Explanation
You can let Transit fly its own kite while following the city’s weather rules. That’s federation: local pilots within citywide policy and standards.
Full Explanation
A federated municipal AI operating model balances local mission speed with citywide coherence. Transit running local AI pilots under citywide AI policy while a central office sets standards is textbook federation: departments can experiment close to ridership, scheduling, and field operations while following shared guardrails for risk tiers, data classes, model documentation, and procurement. The option describing local pilots under citywide policy and standards is correct because it preserves innovation and interoperability among agencies that share residents, data platforms, and legal exposure. Fully centralized control that forbids department-level pilots suppresses domain expertise, creates bottlenecks, and risks generic tools that miss transit workflows. Having no citywide policy, so departments invent incompatible AI rules, fragments privacy posture, evaluation criteria, and vendor contracts, making citywide risk harder to manage and resident experience inconsistent. Outsourcing all operating-model decisions to an unpaid vendor intern fails because operating-model authority is a civic governance duty; vendors may advise, but cannot own municipal accountability for policy, standards, or public trust. Exam caveat: federation is neither laissez-faire autonomy nor command-and-control centralization; the transit-plus-central-office cue signals shared policy with local execution. Practical check: verify the city AI policy and standards catalog exist, Transit’s pilot charter cites them, and the central office reviews exceptions—not every prompt—while Transit does not invent a parallel rulebook.