Technical Program Manager

How did you establish an AI governance framework?

Also asked as: Can you walk me through your experience with AI governance? · Can you walk me through your experience building an AI governance framework from scratch, and how you ensured it was adopted by engineering teams?

Earn TrustThink BigDeliver ResultsOwnershipInsist on the Highest Standards

Opening Statement (~60 sec)

I built and operationalized an enterprise AI Governance and Compliance Program at a financial services company scaling generative AI across employee productivity, internal knowledge access, and core business workflows. As Technical Program Manager, my job wasn't to write policy — it was to turn responsible-AI principles into an executable, repeatable process engineering teams could actually follow. I did that in four moves: defined a risk-tiered operating model so review effort scaled with actual risk, not paperwork; aligned engineering, security, legal, product, and platform stakeholders around shared ownership; embedded governance directly into the delivery lifecycle instead of bolting it on as a separate gate; and scaled adoption through a pilot, feedback, and enablement. The result: 1,300+ engineering teams onboarded and deployment velocity up 70%, with zero ungoverned high-risk launches.

Situation

In my current financial services role, the company was expanding its use of generative AI across employee productivity, internal knowledge access, and critical business workflows. As that adoption accelerated, we needed a structured way to manage risk, meet regulatory expectations, and scale responsibly.

Task

As the Technical Program Manager, I was responsible for leading the cross-functional effort to build and operationalize the company's AI Governance and Compliance Program in a way that engineering teams could adopt at scale.

Action

1.Defined the program scope, success criteria, and governance standards aligned to the company's risk posture.
2.Aligned stakeholders across engineering, security, legal, product, and platform teams to create shared ownership and a clear decision-making model.
3.Built a risk-based operating model with clear intake, review, and risk-tiered approval paths so teams knew exactly how to move AI use cases forward.
4.Partnered with engineering teams to embed governance into the delivery lifecycle (CI/CD, policy-as-code), so it became part of normal execution rather than a separate checkpoint.
5.Piloted the framework with early teams and incorporated their feedback — including technical and engineering feedback on intake friction, RAG guidance, and CI/CD review bottlenecks — then scaled adoption through templates, reusable patterns, and enablement.

Result

We upskilled more than 1,300 engineering teams, increased deployment velocity by 70%, and created a repeatable operating model for consistent policy enforcement and scalable AI adoption — including standardized intake and review paths, automated policy-as-code checks embedded directly in CI/CD, faster onboarding for pilot teams, and shorter approval cycles across business units.

Closing Statement (~60 sec)

What made this work wasn't the policy — it was treating governance as a TPM execution problem, not a compliance-writing exercise. Security and legal could tell me what acceptable risk meant; they couldn't tell me how to sequence a nine-month rollout across 1,300+ teams or turn a policy document into a CI/CD check an engineer would actually hit. That's the gap I closed. The pattern I'd bring here is the same: start from a risk-tiered, proportional model instead of one-size-fits-all review, embed controls into workflows people already use instead of adding a parallel process, and pilot before you scale so adoption resistance gets solved with eight teams instead of thirteen hundred. Governance that engineering teams route around isn't governance — it's theater. The goal is always to make the compliant path the fastest path.

Two challenges determined whether this program could scale past the pilot: adoption resistance from engineering teams, and the fact that there was no internal precedent for generative-AI-specific risk criteria to build on. I treated both the same way — name the resolution before scaling, not after.

What were the biggest challenges you faced in building and scaling this framework?

#	Challenge
1	Adoption resistance — engineering teams believed governance would slow delivery down, and treating it as a tax on speed risked outright disengagement or teams quietly routing around the process.
2	No internal precedent for generative-AI risk criteria — the company already had risk frameworks for things like third-party vendor risk, but nothing calibrated to AI-specific failure modes such as hallucination or data leakage through retrieval, so the risk-tiering criteria had to be built and proven from scratch before teams would trust it.

How did you resolve the adoption resistance challenge?

Step	Action
1	Integrated governance into existing delivery workflows instead of creating a separate process.
2	Piloted the model with early teams and incorporated their feedback.
3	Provided templates and clear guidance to reduce ambiguity at the point of adoption.
4	Positioned governance as an enabler rather than overhead in all team-facing messaging.

How did you resolve the lack of precedent for AI risk-tiering criteria?

Step	Action
1	Started from the risk dimensions security and legal already cared about — data sensitivity, customer exposure, regulatory impact — instead of inventing a parallel framework from scratch.
2	Drafted an initial set of tiering criteria and tested it against the 8 pilot teams' real use cases rather than finalizing it on paper first.
3	Adjusted the criteria where pilot use cases didn't cleanly map to a tier — for example, adding an explicit data-quality dimension once RAG-based use cases showed it was needed.
4	Published the finalized criteria with worked examples from the pilot, so teams could match their own use case to a tier without guessing or escalating every time.