A small city has no ML engineers and prefers buy or partner options for a 311 assistant. What is guiding that delivery-model choice?
Select an answer to reveal the explanation.
Short Explanation
No ML crew on payroll? Don’t pretend you’re a research lab. Buy or partner so residents get help without inventing engineers overnight.
Full Explanation
Delivery-model choice for municipal AI must match real organizational capability: skills, capacity, budget, and ability to sustain operations after go-live. A small city with no ML engineers that prefers buy or partner options for a 311 assistant is applying capability-matched sourcing. Commodity resident-facing Q&A can often be delivered via vetted SaaS or a partnership that supplies model operations, while city staff retain product ownership, content stewardship, and escalation paths. Forcing a custom deep-learning build under those constraints creates delivery and sustainment risk the city cannot absorb.
A belief that only custom models ever work for 311 fails because many 311 intents are well served by configurable platforms with curated knowledge and human handoff. Ignoring staffing limits when choosing how to deliver AI fails because staffing is a primary constraint in local government AI programs. Mandating an in-house deep-learning lab before any resident tool fails by inventing a capability prerequisite that blocks service improvements residents could receive through buy or partner paths.
Exam caveat: buy/partner preference for a small city does not remove governance duties—contracts, privacy review, and service-level expectations still apply. Operational check: inventory ML/data engineering capacity, on-call sustainment, and content ownership before selecting a 311 AI delivery model; if in-house ML capacity is near zero, require buy or partner plus a named city product owner rather than a custom model program.