From Senate Ops to AI Governance

I spent four years directing operations for a U.S. Senator across five committees: Finance, Banking, Commerce, Veterans' Affairs, and Aging. When people ask how that prepared me to govern AI at a publicly traded investment bank, the answer is: almost perfectly, and in ways that aren't obvious until you've done both.

Senate operations and AI governance share a structural problem that most people in technology don't recognize because they've never worked in a high-stakes regulatory environment: you have to build systems that function under constraints you didn't choose, with stakeholders who have competing interests, at a speed that outpaces your ability to fully analyze every decision. That's the daily reality of a Senate office covering five committee jurisdictions. It's also the daily reality of governing AI in financial services.

The first parallel is the most fundamental: compliance isn't optional, and it isn't an afterthought. In the Senate, every action, every communication, every decision sits inside a web of rules — ethics requirements, committee procedures, legislative protocols, constituent obligations. You don't build a process and then check whether it complies. You build compliance into the process from the start, or the process fails in ways that create real consequences for real people.

That instinct transferred directly to AI governance. When I built the AI function at the bank, I didn't build the workflows first and then ask legal and compliance to review them. I built governance into the architecture from day one. Mandatory verification standards, source-citation requirements, data-handling protocols — these weren't bolted on. They were structural. The Senate taught me that governance baked into the system is invisible and efficient. Governance applied after the fact is visible, slow, and resented.

The second parallel is stakeholder management across competing interests. A Senate office covering Finance, Banking, and Commerce is managing constituencies that sometimes want opposite things. Financial institutions want regulatory flexibility. Consumer advocates want tighter oversight. Industry groups want certainty. Advocacy organizations want change. You learn, fast, that your job isn't to make everyone happy. Your job is to build a framework where competing interests can coexist without the system breaking.

AI governance inside a large firm has the same dynamics. Practice groups want maximum flexibility to use AI in their work. Compliance wants maximum control over AI outputs. IT wants standardization. Individual professionals want customization. Leadership wants ROI metrics. Risk management wants audit trails. Every one of those stakeholders has legitimate interests that partially conflict with every other stakeholder's legitimate interests. The skill isn't choosing sides. It's designing a system that accommodates all of them without satisfying none of them.

The third parallel — and the one I think about most — is building frameworks that survive leadership transitions. In the Senate, leadership changes are a structural feature, not a bug. Committees get new chairs. Priorities shift. Staff turns over. If your systems only work because one specific person is running them, they don't work. You have to build processes, documentation, and institutional knowledge that persist independent of any individual.

I built our AI program with the same principle. The skills library, the governance framework, the training infrastructure, the measurement dashboards — all of it is documented and systematized to function without me in the room. That's not modesty. It's Senate-trained pragmatism. Any system that depends on a single person is one resignation away from collapse. In an environment where leadership transitions are inevitable, durability is a design requirement.

The fourth parallel is the one that feels most urgent right now: governing at the speed of the thing you're governing. Legislative issues don't wait for your analysis to be complete. A committee hearing gets scheduled, a floor vote gets called, a crisis breaks — and you have to respond with the best framework you have, not the perfect framework you wish you had. You build a decision-making structure that lets you act on incomplete information while maintaining accountability.

AI moves the same way. Model capabilities change quarterly. Regulatory guidance is evolving in real time — the percentage of publicly traded companies disclosing AI-related risks in their annual filings has climbed significantly year over year, and the regulatory bodies are actively developing frameworks as the technology shifts underneath them. You can't wait for the regulatory landscape to settle before building your governance approach. The landscape isn't going to settle. You need a governance structure that is itself adaptive — one that has clear principles and decision rights but can update its specific policies as the ground shifts.

What the Senate doesn't prepare you for is the technical dimension of AI governance. I had to build that knowledge from practice — understanding model behavior, learning prompt architecture, developing intuitions about where AI outputs are reliable and where they need human verification. But the structural skills — building compliant systems, managing competing stakeholders, creating durable frameworks, governing at speed — those transferred wholesale. They're the reason I was able to build a governance framework that earned trust from both the professionals using the tools and the compliance teams overseeing them.

People in technology sometimes undervalue government operations experience. They see it as bureaucratic, slow, political. They're wrong about the slow part. At its best, government operations is about making complex systems work under pressure, with accountability, at scale. That's exactly what enterprise AI governance demands. The venue changed. The skillset didn't.