No one is asking me anymore whether their team should be using AI. I feel like that conversation is over. That ship has sailed a long time ago. AI is already in your products. It's already in your pipelines. It's in your code reviews. It's in your sprint tooling. And whether you deliberately put it there or not, it's there.
So the question I get now, just about every single week from leaders at every level is, can we actually trust it? That's what today is going to be about.
And I would like to flip something on you right up front because governance sounds like a slowdown. We've even talked about it in the past, but it is not. Done right, governance is exactly what lets you move faster. So let me show you what I mean by MVG, minimal viable governance.
Hi, I'm Lance Dacy, otherwise known as Big Agile. I spend a lot of time gaining scar tissue along with you in organizations trying to figure out why smart teams often get stuck.
So this week is AI Governance Week, and I'm going to walk you through four frameworks that I think are shaping how organizations are thinking about trusted AI right now. And then I'd like to give you a practical model that your team can actually run. I'm not talking about a steering committee. I'm not talking about a policy document that nobody reads.
The Real Problem With AI Governance Today
The story that I keep running into, and I bet it sounds familiar to you as well, is our teams get excited about an AI tool. I was just working with an organization last week that they finally got approval to start experimenting with it. So they're using it. And within a few sprints, it's writing code and summarizing tickets and drafting emails to customers.
But did anybody stop to ask the uncomfortable questions? What happens when that output is wrong? Who's accountable? What data are we feeding this thing? I teach these in my courses too. They're not the wrong things, but who's asking those questions?
And then something breaks. A hallucination ends up in a customer-facing feature. Or a sensitive internal document gets summarized and ends up in a place it never should have been. Or the best one that I saw a couple of weeks ago, legal finds out what has been going into a third-party LLM, and now suddenly everyone is in a room they didn't want to be in.
I've been in that room. It's not a fun room. So let me try to help keep you out of that room as well.
Why Heavier Process Makes Things Worse
I think the instinct after moments like that is to slow everything down, add approval gates. Remember the bandaid story I think I just talked about last week, never take the bandaid off. So we tend to make the process heavier. And I understand that instinct as a diehard process guy, but it almost always makes things worse in my opinion.
Governance does not slow your team down if done correctly. Fear, ambiguity, and incident response, that's what slows your teams down. And when nobody has defined what is acceptable, when the data boundaries are fuzzy, or when there's no clarity on where a human needs to be in the loop, teams slow down on their own. They start second-guessing themselves. They avoid the hard use cases or they ignore risk entirely, which creates real exposure.
Clear governance gives your team clear lanes, and those clear lanes tend to mean more speed if done correctly. That is really the reframe that I want you to hold on to throughout the rest of this piece. Hang tight with me because I want to show you four frameworks that I've come across or elaborated on, and I really think they're worth knowing for your teams as well.
Four AI Governance Frameworks Every Team Should Know
I'm not going to turn this into a standards lecture. You just need to know what each one of these is trying to solve so when somebody drops the name in a meeting, you have context of how to actually use it or what it means.
NIST AI Risk Management Framework (AI RMF)
This was released in January of 2023, and the generative AI profile was actually added in July of 2024. NIST stands for the National Institute of Standards and Technology. To me, it's the closest thing that the US has to a national consensus on standards for trustworthy AI.
There are four functions at the core: govern, map, measure, and manage. Think of that as a loop, not a checklist. Governance is about accountability. Who actually owns AI risk in your organization? Do we even know? If three people give you three different answers to that question, there's your gap.
Map is about visibility. What AI systems do you have running? What decisions are they influencing? Measure is real signals, not vibes. And manage is your process capability when something drifts or goes sideways. Those two work in parallel.
What I genuinely appreciate about the framework is that it scales. A 10-person team can use it. A 10,000-person organization can use it. It's not prescriptive. Think of it as a thinking structure for responsible AI.
ISO/IEC 42001
This one was published in 2023, and it's the first international standard for an AI management system. If NIST is your governance philosophy, ISO is like your audit trail. If your organization already works with ISO 27001 for information security, this is probably familiar territory because it's structurally similar.
The practical reason that product leaders should know it exists is that enterprise customers and regulated industries are increasingly asking for it. Not universally, not yet, but if you sell to healthcare, finance, or government, you will start seeing these things on vendor questionnaires. Having a documented AI management system is quietly becoming a competitive differentiator.
OWASP Top Vulnerabilities for LLM Applications
You probably know OWASP from web application security. In 2023, they published a similar community-driven vulnerability list specifically for large language model applications. They updated it again just recently in 2025. I like to think of these as the four that matter most for product teams.
The first is prompt injection. This is an attacker, or honestly anybody, feeding your model inputs that are designed to hijack what it does. I remember having this problem with SQL injection in my database developer days. Think of it as social engineering for the AI layer. Your model ends up doing something it was never intended or supposed to do.
Second is sensitive information disclosure. The model surfaces private data that it should not surface. This happens to real companies. This is not theoretical.
Third is excessive agency. If you gave an AI agent way too much autonomy, it sends emails, modifies records, and takes actions without a human check. We talk a lot about human in the loop here at Big Agile. The problem is you find out after the fact, and it's almost too late.
The last one is misinformation, confidently producing a wrong answer, and your team or your customer acts on it. AI is extremely convincing. Believe me, I see teams from varying expertise use it. We all get caught at some point.
The reason I bring OWASP into the governance conversation is because it makes things specific. When your engineers say that they're integrating an LLM, these four things are the concrete questions to ask right then. This is not a policy review. We're in the room talking about this.
Digital Provenance (Gartner)
This is the most underappreciated framework in the list. Gartner named digital provenance one of the top 10 strategic technology trends for 2026. The simple version is this: as your organization relies more on third-party software, open-source code, and AI-generated content, you need a credible answer to a single question.
Where did this come from, and can I verify it?
That's a tough one. Digital provenance is the ability to trace and confirm the origin, ownership, and the integrity of software data and its AI output. The tools making this practical right now include things like software bills of materials, attestation databases, and digital watermarking.
Gartner's forecast is direct on this. By 2029, organizations that have not invested in digital provenance will face compliance and sanction risks, potentially running into the billions. This is not a distant problem. The planning window starts now, or yesterday.
The PACE Model: Practical AI Governance Your Team Can Actually Use
So you have a mental map of the frameworks. Here's where I want to get more practical because here's what I see happen almost every time. Leaders hear about NIST, ISO, OWASP, or Gartner provenance, and the first instinct is to form a committee. We're going to assign it to a working group and build some big policy document. We're going to watch that document sit in a shared drive somewhere for six months while the team just keeps shipping AI stuff.
That's not governance. That is the appearance of governance, or theater, my favorite adjective to describe those kinds of acts. They're well-intentioned, but they're just theater.
What actually works in my humble opinion is treating AI governance the same way we treat any complex, evolving problem in product development: iteratively. Practice agile, agilely. Drink our own champagne. Short cycles, team ownership instead of central control. To my agile friends, does that sound familiar? Why don't we apply those same concepts to AI governance? Build it into your definition of done, my Scrum friends. This is not an external thing.
I like to use a four-step model called PACE: Profile, Assign, Create, Evaluate.
Profile: See What You're Working With
Before you can govern anything, you have to see it. Your first move is really simple. Build a living inventory of every AI tool and capability that your team is using or building with.
I've done this exercise with teams and they almost always are surprised by what shows up. There are tools that nobody centrally approved. They're just getting used. There are vendor integrations where "AI powered" is in the marketing copy and nobody thought about what that means for data and your website.
For each item, you want to capture four things: What does it do? What data does it touch? What decisions does it influence? And who actually owns it? That last one, who owns it, is worth some focus. If the answer is nobody, there's your first governance gap right there.
Assign: Tier the Risk
Not all AI is equal and your governance approach should not treat it as if it is. I think of three tiers.
Tier one is AI assists. AI does something and the human decides. Code suggestions, first-draft copy, internal summarization. These are low-friction things.
Tier two is where AI output influences a meaningful decision or touches sensitive data. Human review is required before action, but it does help.
Tier three is AI that acts or directly drives significant business, legal, or customer outcomes. These need documented human-in-the-loop checkpoints and a full audit trail.
Tier the risk, match the oversight to that risk. That's how you stay fast in low-risk areas while still staying careful for the high-stakes ones.
Create: Build Guardrails, Not Walls
For each tier, your team needs three things clearly defined: What is acceptable use? Where does a human need to be in the loop? And what gets logged for later review?
Let's be real. Most AI governance fails not because the policies are necessarily wrong, but because they were written by lawyers and handed to engineers. People whose primary job it is to spot risk and avoidance. Risk is a business decision, not just an auditor directive. No offense to the auditors. You're doing your job. I love it. But I see teams paralyzed from all these inputs and no one assesses if that risk is great enough to warrant the mitigation expense.
My lawyer in business tells me risks in every contract I sign. And I tell her, if I did everything that she said to do, I would never do anything. Business is about taking risks. But like she says, "Well, Lance, it's not a problem until it's a problem." Computational irreducibility in the legal arena right there.
My experience is that the team reads the first paragraph and they just lose interest. They lose the will to live and they quietly ignore everything else. So write your guardrails in a language that your team actually uses. Make them short enough to find in 30 seconds. A single page per tier is the target.
Evaluate: Your Inspect-and-Adapt Loop
This is your inspection and adaptation loop for AI governance. It does not need to be a separate meeting. Add 15 minutes to your sprint retrospective to talk about these things, or set a monthly check-in at the product and engineering lead level, like a community of practice.
Four questions: Did any AI output create a problem this cycle? Is anything behaving differently than expected? Has the risk tier on anything changed? And are we holding the guardrails?
That's it. You're not building bureaucracy. You're just inspecting, seeing how things are going, and then adapting if there are problems. You're building a habit of looking, just like we do in our processes and our systems. This is a system that gets a little better every single cycle, just like we do in our products. It's the very same thing.
Your One Move This Week: Map Your AI Footprint
One move this week that may take 30 minutes or so is to map your team's AI footprint. Just get in a room and talk about it. Where are these things happening? Open up a blank doc or a spreadsheet and just list every single AI tool that your team touches.
The obvious ones that I typically start out with are things like GitHub Copilot, ChatGPT, or whatever LLM is baked into your product stack. And then you move on to the less obvious ones. The vendor integration where "AI powered" is somewhere in the product description. The automated summarizer that somebody plugged in three months ago and nobody remembers approving it.
For each item, write one sentence on what it does and another sentence on what could go wrong. Then score them for risk. I've seen this 30-minute exercise surface more real risk awareness than a full-day AI governance workshop with lawyers, auditors, and attorneys. Because when everything is on a single list and you look at it together, things become visible that weren't visible when they were scattered across individual workflows.
From there, assign a risk tier. That is your MVG. You've heard of MVP before? MVG is minimal viable governance. Everything in that PACE model builds from there. We have MVP for minimal viable product. I also like MVP for minimal viable bureaucracy or process. And now we've got MVG, minimal viable governance. You see the pattern here.
The 2026 AI Conversation Has Changed
Here's what I want you to take away. The 2026 AI conversation is not about whether to use it. That ship has sailed. The conversation now is whether you can be trusted with it. And trust, it turns out, is something you build on purpose. It's not a meeting.
The organizations that are getting this right are not the ones that have the most governance or the most expensive lawyers. They are the ones with the clearest governance and MVG. Clear enough that their teams know the lanes and they feel confident moving fast inside them. That's when speed and safety stop being opposites.
Ready to take your team's agile and product skills to the next level? Explore the training and courses that Big Agile offers and see how we can help your organization move faster with confidence.