Transit sits in a uniquely difficult spot when it comes to AI adoption. Unlike tech startups that can “move fast and break things,” transit agencies operate under intense public scrutiny, tight budgets, and zero tolerance for service disruptions. Privacy matters. Safety matters. Public trust matters. So when leadership says “we should use AI,” the harder question is: how do we capture AI’s capability while managing the risks that come with it?
The traditional answer has been top-down procurement—buy an enterprise platform, run a multi-year contract, standardize everything. This works for some functions, but it struggles with the specific, localized problems that frontline teams face daily: summarizing a large number of incident reports, answering repetitive internal questions, triaging customer complaints etc. These tasks don’t justify a major software procurement, but they consume real time. And the people closest to the problems rarely get to weigh in during the procurement of the solutions.
The alternative is now possible: frontline staff building their own AI tools. Large language models have lowered the barrier enough that someone without coding experience can create a useful chatbot, automate a reporting task, or build a knowledge assistant in days rather than months. But this path comes with real risks—data leakage, shadow IT fragmentation, inconsistent quality, and no clear ownership when something goes wrong.
The answer isn’t to pick one approach over the other. It’s to create a governed space where frontline experimentation can happen safely—with clear rules about what data is allowed, what tools are approved, and what “good” looks like—alongside a pathway for the best ideas to graduate into fully supported, enterprise-grade systems. Think of it as structured permission to innovate, with guardrails that protect the public and the agency.
Transit agencies don’t need more AI hype. They need a reliable way to resolve frontline challenges using safe, scalable AI solutions. The agencies that get this right won’t be the ones that move fastest—they’ll be the ones that build a repeatable path from experimentation to production.