What Building Real AI Governance Actually Looks Like


By Chris Green, OSCP, CISSP, CISA, CRISC, CRISC, Structured GRC Director —

Most organizations didn’t set out to have an AI problem. They set out to be more efficient. Somewhere along the way, AI tools showed up in nearly every department without anyone quite deciding they should. Marketing runs copy through a generative tool. Finance launched a model flagging anomalies. Customer service is testing a chatbot. HR screens resumes with something a vendor swore was “just automation.”

None of it happened through a single approved channel, and that’s exactly the point. AI doesn’t arrive through the front door anymore. It shows up in browser extensions, SaaS add-ons, and vendor updates that quietly turn on a new feature nobody asked to review.

That’s not a criticism of any one team. It’s just how adoption works when a technology is this useful and this easy to access. But it does mean that a lot of organizations are further along in using AI than they are in governing it, and that gap is where the real risk lives.

Regulators are paying attention, customers are asking harder questions about how their data gets used, and boards want to know that somebody, somewhere, actually understands what the company’s AI footprint looks like. Governance isn’t the fun part of AI adoption, but it’s the part that determines whether everything else holds up.

And the gap tends to widen quietly. Nobody notices it in a single quarter. A tool gets adopted here, a vendor rolls out a new feature there, and six months later an organization looks up and realizes it has dozens of AI touchpoints and no consistent way of thinking about any of them. By the time that becomes obvious, it’s usually because something forced the issue, whether that’s a customer question the legal team couldn’t answer confidently, an auditor asking for documentation that doesn’t exist, or a near miss that made everyone realize how little oversight was in place.

We spend a lot of time helping organizations work through exactly this, and what we’ve found is that a real AI governance program isn’t a single document or a one-time project. It’s a series of connected efforts that build on each other, and skipping ahead usually just means redoing the work later once the gaps become obvious. Here’s how we think about what a full build-out involves.

You Can’t Govern What You Haven’t Found

The first step is always discovery, and it’s almost never as simple as it sounds. Most companies assume they have a decent handle on their AI usage until they go looking, and then they find models embedded in tools they’ve used for years, such as AI features that got switched on by default in a recent update or entire workflows built around tools that IT never approved or even heard about.

A proper inventory doesn’t just catalog the obvious stuff like chatbots and copilots. It traces where AI touches data, which systems it connects to, and who’s really using it day to day. Without that foundation, everything that follows is built on guesswork.

Knowing Where You’re Exposed

Once you know what you’re working with, the next step is to identify risk. A risk and gap assessment looks at each AI use case against the organization’s actual risk tolerance, its regulatory obligations, and its security posture. And it asks some uncomfortable questions along the way, including:

  • Does this tool have access to sensitive data it doesn’t need?
  • Is there a human in the loop where one should be?
  • Would this decision hold up if someone had to explain it after the fact?

The goal isn’t to slow everything down. It’s to figure out which use cases need attention now and which ones can wait, because trying to fix everything at once usually means nothing gets fixed well.

The Vendors You Didn’t Know Were Part of This

Third-party risk is where a lot of AI governance conversations get uncomfortable, because the truth is that most organizations don’t build their own models. They buy software, and increasingly that software has AI baked into it somewhere, sometimes without much fanfare or disclosure.

Managing that risk means asking vendors direct questions about how their models were trained, what data gets shared back to them, and what happens if their AI makes a mistake that affects your customers. It also means building that scrutiny into procurement itself, so it’s not an afterthought that happens after the contract is already signed.

Deciding Who Owns This

In every organization, there needs to be a clear answer to who’s responsible when an AI decision goes wrong. Today, a lot of companies genuinely don’t have one.

Designing AI governance structure is about building that clarity before it’s needed rather than scrambling to figure it out during an incident. That usually means forming a cross-functional committee that includes legal, security, IT, and the business units using the tools — and giving that group authority to approve, pause, or shut down AI initiatives.

It’s not about adding red tape but about making sure decisions don’t get made by whomever happens to be in the room.

Turning Principles Into Something People Can Follow

It’s one thing to say an organization values responsible AI use. It’s another to write policies specific enough that an employee knows what to do when evaluating a new tool or wondering whether it’s okay to paste customer data into a chatbot.

Policy and procedure development takes the governance structure’s decisions and turns them into something usable, covering acceptable use, data handling, model evaluation, and approval workflows in language that doesn’t require a law degree to interpret.

The best policies we’ve seen are the ones written by people who have first-hand knowledge about how the tools get used, not just how they’re supposed to be used.

Planning for When Something Breaks

Even a well-governed AI program will eventually have a moment where something doesn’t go as planned. A model hallucinates in front of a customer. A tool exposes data it shouldn’t have touched. A decision made with AI assistance turns out to be biased in a way nobody caught in testing.

Incident response planning for AI borrows a lot from traditional security incident response, but it must account for some genuinely different failure modes, like a model behaving unpredictably rather than a system simply going down. Having a plan in place before that happens is the difference between a contained issue and a much bigger one.

Keeping Up With a Moving Regulatory Target

The last piece is making sure everything above lines up with the frameworks and regulations that apply to the organization. In truth, this is a space that keeps shifting.

Between myriad regulatory requirements, such as the NIST AI Risk Management Framework, the EU AI Act, GDPR, and a growing patchwork of state-level rules here in the U.S., organizations need a clear map of which requirements apply to them and where their existing controls already satisfy those requirements.

Mapping this out isn’t a one-time exercise since the regulatory landscape is still very much being written. A program that’s aligned today needs to be built in a way that can adapt as the rules change.

Why This Ends Up Being a Business Advantage, Not Just a Compliance Task

It’s easy to frame all of this as risk avoidance, and a lot of it is, but that undersells what a mature program does for an organization.

Customers and partners increasingly ask how a company handles AI before they’ll sign a contract. Having real answers instead of vague reassurances is starting to matter in ways it didn’t even a couple of years ago.

Employees also move faster when the rules are clear. A team that knows exactly what’s approved — and what is disallowed — will ship new AI-powered work far quicker than one that’s guessing and hoping nobody asks questions later.

Governance done well doesn’t slow innovation down. It’s usually what lets an organization say yes to more ideas, more quickly, because the guardrails are already built and everyone trusts they’ll hold.

AI Governance is a Program, Not a Project

What ties all seven of these pieces together is that none of them work particularly well in isolation. An incident response plan without a governance structure behind it has no teeth. A regulatory mapping exercise without an accurate asset inventory is just guessing.

The organizations that end up in a strong position aren’t the ones that moved fastest on AI adoption. They’re the ones that built the muscle to govern as it grew, and that muscle takes real, deliberate work to build.

If any of this sounds familiar, you’re not behind, you’re just at the point nearly every organization reaches once AI stops being a side project and starts being part of how the business runs. The work of getting ahead of it looks different for every organization, but the phases above are a reasonable map of the territory. It’s worth having a real conversation, internally or with people who do this for a living, about where your organization really stands.


About the Author

Chris Green excels at translating complex cybersecurity and compliance challenges into practical, business-focused strategies. He works collaboratively with executive leadership, IT teams, and stakeholders to build consensus, strengthen governance, and drive meaningful risk reduction. Known for his consultative approach and ability to align security initiatives with organizational objectives, Chris helps customers develop resilient programs that support compliance, improve decision-making, and foster long-term operational success.

Chris holds several certifications, including the OffSec Offensive Security Certified Professional (OSCP), ISC2 Certified Information Systems Security Professional (CISSP), ISACA Certified Information Systems Auditor (CISA), and Certified Risk and Information Systems Control (CRISC), demonstrating his ability to perform thorough penetration tests, audit a variety of environments against compliance standards, and manage and assess IT risks.