Why AI Governance Matters More Than AI Adoption

That gap is where an AI governance framework needs to start: not a policy written first and hoped to match reality, but visibility into what's happening before deciding what to do about it.

Do you actually know how AI is being used in your organization?

Leadership tends to assume one of two things: that AI use is confined to a handful of approved tools, or that it's already covered under existing IT policy. Neither tends to hold up under closer scrutiny, and we found the same thing when we turned that question on ourselves.

A Gartner survey of 302 cybersecurity leaders across North America, EMEA, and Asia/Pacific found that 69% of their organizations suspect or have evidence that employees are using unsanctioned public GenAI tools. Within that sample, unsanctioned use occurred in more than two-thirds of organizations.

Our IT Director led a review of how AI was being used across our organization.

Collecting telemetry on AI usage gave us visibility into patterns we wouldn't have been able to identify otherwise,

Andres Herrera
IT Director, Adage

 

Andres says. It gave our team a far more detailed picture of how people were actually working, which shaped where we focused training and oversight next.

Esneider Serna, a Technical Lead at Adage, saw the same gap from a different seat. Going in, we assumed AI use was mostly confined to our technical teams. It wasn't.

"AI governance is not about creating barriers," he says. "It is about helping people use AI tools in a responsible way and understand what information they can share."

Different vantage points, a matching pattern: across the organizations in Gartner's sample, and inside our own.

Does AI governance mean restricting AI, or enabling it?

Enabling, when it's done well. The common read on governance is that it exists to slow people down or say no. Both of our subject matter experts pushed back on that framing independently.

Andres puts it directly: "Governance should enable responsible AI adoption, not simply restrict it. The objective is to create enough visibility and control that the organization can confidently say yes to valuable AI use cases while knowing where additional safeguards are necessary."

Esneider sees the same misunderstanding from a different angle. People tend to view control points as barriers built to limit what they can do. What's actually at stake is the information going into these tools and how it's shared.

That includes knowing what's safe to share, especially client, confidential, or personal information, and relying on company-approved tools whose data handling and license terms have already been reviewed. Understanding that risk can help people get more value out of AI, not less, because they're using it with confidence rather than guessing where the lines are.

Policies still matter. But a policy written without visibility into actual usage could be built on assumptions, not something an organization can stand behind with confidence.

Who needs to be in the room for AI governance?

Treating AI governance as an IT-only project tends to leave gaps. It's a tempting approach: write the policy, roll it out, done.

"AI governance needs to involve IT, security, operations, business users, and leadership because each group sees a different part of the problem," Andres says. IT sees the tooling and the data exposure. Security sees the compliance and risk surface.

Operations sees where AI is changing how work gets done day to day. Business users see where it's helping or falling short in practice. Leadership has to weigh all of it against the organization's actual risk tolerance.

Once those perspectives are in the room, the next step is naming who owns what: who approves new tools, who writes the guidelines, who supports employees, and who responds when an issue comes up. That cross-functional ownership is where our AI strategy, readiness, and governance work starts.

Leave any one of those groups out, and the resulting policy risks answering a question nobody in the room was asking.

How often does an AI governance policy need to change?

Not once and done. An AI governance framework holds up best when it's reviewed regularly and updated whenever a new tool, use case, or risk comes into the picture.

That's what Andres and Esneider landed on independently, from opposite ends of the work. On the policy side, the technology can move faster than a static document can keep pace with, which is why governance works better built to flex than fixed to hold. Esneider saw the same pattern on the technical side: a policy treated as finished can start to fall behind whatever teams are actually doing with new tools.

For us, that starts with something simple: talking to people about what they understand about AI, how they're using it, and what they expect from it, then building the risks and best practices into that conversation instead of around it. That feedback, alongside actual usage patterns, shows where policies, controls, or training could use an update.

Does every unapproved AI tool signal a risk?

This piece won't tell you which AI tools to approve or hand you a policy template to adopt as-is. Every organization's risk tolerance, industry, and existing tech stack are different enough that a one-size answer could do more harm than good.

It's also worth being direct about what visibility isn't. Finding out that employees are using a tool you didn't approve doesn't automatically mean something's gone wrong. Much of what shows up in that kind of review tends to be people trying to work faster, not people trying to get around anything.

Governance exists to sort out where that's fine and where it isn't, not to treat every unapproved tool as an incident waiting to happen. That usually means weighing what a tool is for, what information it touches, how the provider handles security and privacy, and whether a person should review its output.

What comes next is specific to your environment: what you're already running, what your teams need, and where the real exposure sits. That's a conversation, not a checklist.