Several municipal departments purchase SaaS AI copilots without involving the enterprise architecture office. Which control best prevents uncontrolled AI sprawl?

Requiring AI solution intake through governance that includes enterprise architecture review before purchase or deployment is the control that prevents uncontrolled municipal AI sprawl. Departmental SaaS copilots create identity, data-classification, integration, and vendor-risk exposures that sit outside any single bureau’s credit-card view. EA participation at intake evaluates architecture fit, data paths, SSO, logging, and standards before money and data flow—turning sprawl into a governed portfolio.

Publishing an approved AI copilot catalog with architecture standards for departments to consult during selection fails because a catalog doesn’t require intake or review before purchase; departments can still buy unlisted copilots, so sprawl isn’t prevented. Consolidating AI copilot invoices under finance for quarterly spend tracking after departmental purchases proceed fails because post-hoc spend tracking doesn’t prevent uncontrolled deployment; it only observes the sprawl, not governs the intake, so architecture, data paths, and standards remain unreviewed. Directing departmental data stewards to validate copilot outputs and document use cases following SaaS deployment approval fails because post-deployment validation and documentation don’t prevent sprawl; they’re a reactive check, not a control that stops uncontrolled purchases or ensures architecture review before connection.

Exam caveat: intake gates that exist only on paper—or that IT can bypass with emergency purchases—do not constrain sprawl; the control must bind purchase and connection, not merely request forms. Operational check: reconcile recent SaaS AI invoices and SSO app registrations against intake tickets with EA review evidence, and flag any live copilots lacking an approved intake record.