Introduction
I’ve been a Project Manager for about 14 years now. During this time, I’ve seen cloud migrations, mobile transformations, and agile rollouts reshape how teams work, but none of them changed my day-to-day responsibilities as dramatically as AI has over the last eighteen months.
The frameworks I learned back in 2018 still apply to maybe 60% of what I do. The other 40% is stuff I’m figuring out as I go, mostly by tripping over things and then writing down what tripped me.
A lot of those new challenges fall under a term that gets thrown around a lot these days: AI Governance.
It’s a phrase that sounds dry until the moment your support copilot tells a customer something that isn’t true, and the complaint lands in your inbox before you’ve even finished your morning coffee. At its simplest, AI governance is the set of rules, processes, and safeguards that ensure AI systems behave responsibly, comply with regulations, and earn user trust.
So this isn’t a framework post. It’s the honest version of what I’d tell another PM over coffee if they asked me what I’ve learned.
We Shipped Too Fast The First Time
The first real AI feature my team launched was a summarisation tool for internal docs. We were proud of it. The model was good, latency was solid, we hit the deadline. Classic win!
About three weeks in, a customer flagged that the summaries were quietly omitting financial figures. Not always. Just sometimes. The model had apparently decided certain numbers were less important and dropped them. Nobody on the team had thought to test for that, because we’d been busy testing whether the summaries read well.
That’s the trap with AI features. They feel done when they look done. They aren’t.
That incident changed how we test AI features. We now test for accuracy, completeness, consistency, and edge cases, not just whether outputs “look good.”
What Actually Changed in My Job
I used to spend afternoons arguing with engineers about whether a button should be blue or green. Now I spend afternoons arguing about whether the model should refuse to answer when it isn’t confident. The stakes feel different because the failure modes are different. The blue button looks bad. A confident-but-wrong AI answer can damage trust, trigger regulatory scrutiny, or become tomorrow’s viral social media story.
A few things I do now that I didn’t use to:
- I sit in meetings with legal staff that I would’ve skipped two years ago.
- I read the data processing agreement before kickoff, not after we’ve already built something.
- I ask the ML team how they evaluated the model, and I push back when the answer is “we ran some prompts and it looked fine.”
- I think about what happens when the system is wrong, not just when it works.
- I spend more time discussing risk than requirements. Understanding failure modes is now as important as understanding features.
None of this is glamorous. Most of it doesn’t show up on the roadmap. But it’s the work that prevents the awkward customer complaints later.
The Five Questions I Ask Before Greenlighting Anything
When a team brings me an AI feature proposal, there are five things I want answers to before we move forward. They’re not original, I lifted most of them from a colleague at a previous company who’d survived a regulatory audit. I keep them on a sticky note on my monitor.
1. Where is the data coming from, and are we actually allowed to use it?
You’d be surprised how often this question doesn’t have a clean answer. “It’s customer data” is not enough. Customer data for what purpose, with what consent, retained for how long?
2. What’s the worst thing this feature could output?
Not the average bad case, the worst one. If the answer involves words like “lawsuit,” “regulatory issue,” or “viral headline,” we need guardrails before launch, not after.
3. Can a human override it?
If the system makes a decision the user disagrees with, what’s the path back to a human? “Contact support” doesn’t count. There needs to be an actual escape hatch.
4. Can we explain why it did what it did?
If a customer asks why their loan application got flagged or their content got moderated, “the model said so” is not going to survive contact with a regulator, or a journalist.
5. How do we know it’s still working a month from now?
Model performance drifts. Inputs change. Whatever launched well in March can quietly degrade by June, and nobody will notice until the support tickets start piling up.
If a team can’t answer these in plain English, we’re not ready. I’ve gotten more comfortable saying that out loud, even when it’s annoying for everyone involved.
Governance Isn’t a Speed Bump
I’ll admit something: I used to think governance was the thing the legal team did to slow us down. I no longer believe that, and I’ve changed my mind for a pretty practical reason.
The fastest-moving AI teams I know are the ones with the clearest rules. It works like this. When nobody knows what’s allowed, every single decision becomes a debate. Should we use customer data for fine-tuning? Should we let the model take actions on someone’s behalf? Should we log prompts? Every one of those questions, asked from scratch, eats a week of someone’s calendar.
When the rules exist up front, the team just builds. Governance done well is essentially a yes-or-no machine. Good governance doesn’t just reduce risk, it increases confidence. When stakeholders trust the system, they’re more willing to scale it. It saves time. It doesn’t feel like it saves time in the moment, because it removes meetings you never realize you would’ve had.
What I’d Tell A PM Stepping Into This For The First Time
If you’re new to AI product work, here’s the short version of what took me a year to figure out.
You don’t need to understand transformers. You do need to understand what your specific model is good at and what it’s bad at, in very concrete terms. “Good at summarizing” is too vague to be useful. For example, a model might be good at summarizing single-party legal contracts under ten pages but struggle with multi-party agreements and heavily cross-referenced clauses.
You need a relationship with someone on the ML team who’ll tell you the truth. Not the demo-day version of the truth, the real one. Most ML engineers I’ve worked with genuinely want to do this. They just need a PM who won’t punish them for it when they say “actually, this isn’t going to work the way we promised the board.”
You need to write down what could go wrong before you launch, not after. The post-mortem template should exist before there’s anything to post-mortem about.
And you need to be okay with the fact that some of your best work will be the features you decided not to ship.
Where I Think This is Heading
The PMs I see thriving right now aren’t the ones with the most AI features shipped. They’re the ones whose features didn’t blow up. That’s a quiet kind of success, and it doesn’t always show up nicely in a promo packet, but it’s the work that actually matters when the dust settles.
AI capabilities are advancing faster than most governance frameworks can adapt. The pressure to ship quickly isn’t going away, which makes disciplined governance even more important. The teams that figure out how to move quickly without breaking trust are the ones still standing in five years.
Governance isn’t the opposite of speed. It’s what speed looks like when you’ve been doing this long enough to know what hurts.