For most IT teams, AI governance didn’t start with a plan. It started with an announcement. Head of IT and Cybersecurity Aman Karir describes the moment that kicked it off at his company, a familiar sight for plenty of other companies:

“Leadership saw what AI could do and wanted the whole company using it, which is the right instinct. The question for me was how to say yes safely.” (Aman Karir, Head of IT & Cybersecurity)

To understand how IT and compliance leaders are governing AI, AccessOwl spoke to six practitioners. This article merges their insights to give you a picture of what you’re protecting against, where to start, and the components every AI governance strategy ends up needing.

Key Takeaways

• Start small and build on what you have: Most experts extended standards and policies they already had, like ISO 27001 into ISO 42001, and added to them step by step.

• Whether to block non-whitelisted tools depends on your data: Experts in regulated environments blocked everything not on their whitelist by default. At smaller companies with mostly internal data, allowing tools while watching closely is workable.

• No single tool covers every risk: Experts layered device DLP, shadow AI detection and vendor controls. Seeing what people actually shared in AI chats usually needs the vendor’s enterprise plan.

• Training turns a signed policy into habits: Treat AI as an assistant that people are responsible for, assume good intent, and be an office of how, not an office of no.

Meet the Expert Panel

What compliance and security risks does AI actually introduce?

Is AI governance actually new?

Several of the experts we spoke to see AI governance as an extension of what IT already does, not a brand-new discipline.

That doesn’t mean nothing changes. In the same answer, Subha named a new worry: employees and data engineers sending company data to third-party AI tools. For him, that internal risk now outweighs the external one.

Brooke Bowman, Associate Director of IT Compliance at Fountain Life, draws the line between the big picture and the day-to-day work.

“I don’t look at it too differently at a high level. Now, when we’re in the day to day work and doing the more granular aspects of AI governance, yes, it differs significantly.” (Brooke Bowman, Associate Director, IT Compliance)

For Brooke, the differences show up in the details: new vocabulary like drift and hallucination that people need explained, rules around patient consent, and audit trails that many organizations don’t have for AI yet.

Two other experts pointed out additional differences when it comes to AI governance:

1. The surface. Shadow IT used to mean a SaaS login nobody approved. Aman points out that AI now lives in browsers, desktop apps, command-line tools and MCP connectors. One blocklist doesn’t cover all of them.

2. No hard criteria to prove yourself against (yet). Daniel Swithinbank, former Head of IT & Digital at UK charity Catch22, notes that traditional IT governance has certifications like ISO 27001 and Cyber Essentials Plus, where you have to show you follow your own rules. AI governance mostly doesn’t, yet.

The risk surfaces introduced by AI

Before you write a policy or buy a tool, it helps to know which problem you’re solving. “AI risk” is really several risks. Different people in your company lose sleep over different ones. These are the risks the experts raised most.

The primary risks

The less talked-about risks

Where do you start?

Every expert we spoke to started with a different piece. Dan, Brooke and Masha started with policy. Aman started by finding out what was already installed. Subha’s advice is to have shadow IT tooling in place from day one. Ken started with the data itself.

But they all ended up building the same core components: policy, tooling and training.

Which one comes first depends on your organization, and it’s a bit of a chicken-and-egg problem. You may not get budget for tooling without a policy that explains why you need it. But you may not be able to write a clear policy until tooling shows you how big the problem is.

The good news is that the foundation is probably already there. Several of the experts built their AI governance on layers they already had:

• Existing standards: Aman is building ISO 42001 (the AI management standard) alignment on top of existing ISO 27001 controls. Ken built on ISO 42001 and NIST. Brooke added ISO 42001, HITRUST and NIST to her existing control set.

• Existing compliance policies: Subha took his FDA and data privacy policies and applied them to AI.

• Existing shadow IT tools and policies: Subha and Brooke used their shadow IT discovery to find AI tools.

• Existing DLP and endpoint tools: Aman built an initial AI detection system on device management, endpoint security and email data he was already paying for.

From there, it’s a matter of iteration. Ken compares it to learning to walk.

“If you have nothing, that’s the worst. If you have agreements and policies in place, that’s good. If you have hard gates that are auditable and that you can prove are in place at that time, that’s the gold standard.

If you try to hop all the way to the end, it’s gonna be a mountain of work that most people get overwhelmed by and abandon. The best way forward is to crawl, walk, then run to move your implementation through logical steps.” (Ken Getch, Director of Cloud Infrastructure, Security & IT Operations)

Brooke puts it like this:

Component 1: Policy

What did the experts base their frameworks on?

The common thread was starting from an existing framework like ISO 42001 or NIST and building on top of it.

When Subha built the AI policy at BioXcel, a pharmaceutical company in a regulated environment, there was no AI guidance from the FDA, the SEC or SOX to lean on. So he started from what the company already had.

“The foundation is already there. You are protecting other system. You are already on FDA compliances. You are already in SEC requirements for what they need in cybersecurity. You already know what GDPR needs.” (Subhashish Dhar)

Aman did the same: he is building ISO 42001 alignment on top of existing ISO 27001 controls.

Ken based Authenticx’s policy on ISO 42001 and NIST even though in his words, “they’re really not enforceable.” (Ken Getch)

Masha’s team got a sample policy from a consultant.

“I remember when we first started working on it, we looked at it, it was like 20 pages long. That’s too long.” (Masha Nehme)

They cut it down. It grew back over time, but focused on the areas that mattered to their organization.

Should I block all AI tools outside of my white list?

The experts split on this. Aman allows AI tools but makes sure he knows about them. Subha blocks AI by default. The deciding factor is the data. Regulated or sensitive data pushes toward blocking. Mostly internal data makes allow-and-watch workable. Either way, explain the why behind any block so people don’t find workarounds.

The case for not blocking tools

Aman lets people try AI tools, but makes sure he knows about it. His reasoning: if you ban AI at work, people don’t stop using it. They use it at home, on a personal laptop, with their work data.

The only thing Aman blocks by default is software his endpoint security flags as malicious. What makes this approach work is a simple process for employees to follow. Aman set up two ticket types on Tangent’s service desk:

• AI proof of concept: For free tools. Only IT approves it. The ticket asks who’s involved, the vendor link and the business case. While the user tests the tool, Aman checks its permissions, connections and where it stores data.

• AI license: For paid seats on approved tools like Claude or ChatGPT. It goes to IT first, then finance.

Tools that fail the check are blocked. But they go on a register that’s reviewed every couple of months. If the vendor fixes the problem, Aman reaches back out to the person who asked.

The case for blocking tools

Subha takes the opposite approach. BioXcel routes all traffic through a cloud security gateway, and AI is blocked by default.

“I have blocked all AI except the tools approved by company policy.” (Subhashish Dhar)

Ken blocks too, and his reason is accountability. Authenticx blocks known AI domains and reviews that list every month.

The right answer depends on your situation. If you handle sensitive health or financial data, a stricter default makes sense. That’s Subha’s world. If most of your data is internal, Aman’s approach keeps tabs on AI use without globally blocking it.

Three layers to policy: Approved Tools, Acceptable Use, Enforcement

The approval policy is the umbrella. It explains how anyone requests, tests and gets approval for an AI tool. It also sets the basics that apply to every tool, like no personal accounts and the fact that usage is monitored.

The acceptable use policy is written for each approved tool. Tangent’s policy for Fireflies (note-taker tool), for example, covers how SSO is set up, which settings are locked, and why each one is set that way.

The “why” matters:

“The last thing you want is for someone to ask: Why is this blocked? And then you don’t have a good response for that.” (Aman Karir)

Subha adds an important step: everyone reads and signs the policy, and it spells out what data can and can’t be shared and what happens if someone breaks the rules.

Enforcement

A policy gives you the right to say no, and to act when someone breaks the rules. But it doesn’t run itself. The real work is in the procedures underneath: who checks approved tools for changes, how often, and how.

“I have your signature saying you’re not going to do this, and then I have logs saying you did it. So then we have to escalate to HR have some sort of write-up to confront them on it.” (Ken Getch)

“We’re still defining enforcement. But for example, someone could be reprimanded for not following the policy. They can be told no.” (Masha Nehme)

Who monitors?

• Aman Karir: IT. He reviews the findings himself, with a backup when he’s away.

• Brooke Bowman: Controls are assigned to owners. IT sets a cadence for reviews.

• Ken Getch: IT.

• Subhashish Dhar: IT.

How does monitoring and blocking happen?

• Subhashish Dhar: A cloud security gateway (Zscaler) blocks all AI except the tools approved by policy. Employees have no admin rights, so installs go through IT.

• Ken Getch: Claude Enterprise’s compliance API feeds daily chat pulls into Azure for scanning. Device DLP stops files going in. A list of known AI domains is blocked and reviewed monthly.

• Aman Karir: Collectors on every laptop and a browser extension report the AI tools installed and in use, across browsers, desktop apps, command-line tools and MCP servers. Network data and AI sign-up emails add to it. A sign-in with a personal account is flagged for review.

Component 2: Tooling

Here’s how the tools the experts mentioned map to the risks above.

Sensitive data in chatbots (DLP)

Data loss prevention (DLP) checks data before it leaves your control. On a device, it can inspect a file before someone drags it into an AI app, then alert or block the action.

Seeing AI usage is not the same as seeing what was shared. Dan says many companies get this wrong.

“People seem to think if they’ve got a portal and they can see the AI interactions they’re covered. But that’s not actually how it works.” (Daniel Swithinbank)

You can see that an employee used Claude at noon. You usually can’t see what they uploaded without the vendor’s enterprise plan.

Ken runs it in two layers at Authenticx. DLP on each device tries to stop the wrong things going in. Daily scans of every employee’s AI chats from the vendor’s compliance API catch what slipped through.

“We’re actively trying to stop the wrong things from going in with DLP policies at the device level. And then on the opposite side, we’re scanning and reviewing people’s actions to see if there was any sort of data that got in.” (Ken Getch)

For teams that are serious about DLP, it may be necessary to upgrade to an enterprise plan. That’s where the vendors put chat-level visibility. Dan explains why the license matters even if you already have Purview.

“If you’re using Purview, you can’t see everything unless you have the right license from the LLM themselves. ChatGPT, Anthropic is the same, they’ve built a model where they can make money. So whilst we can see the interactions, we can’t actually delve deeper into the interactions without that additional licensing.” (Daniel Swithinbank)

Ken shows what the enterprise tier unlocks.

“When you go enterprise with the major frontier tools you get something like what Claude calls the compliance API. It has two levels. A header level where you can see people’s usage, and then you have like the full chat exposure, where I can go in and daily I can extract the chat data from that API, store it in Azure, and then I can point my Azure Defender tools and Purview tools and DLP tools to look and assess that data on a continual basis.” (Ken Getch)

Shadow AI

Aman didn’t find one tool that covered everything, so he built his own. His approach brings together collectors on laptops, a browser extension, network data from endpoint security, cloud signals and AI sign-up emails. Aman has since extended this into an open source project called Shadow AI Guard and the commercial tool Nyxus.

“The whole concept is just use what you’ve got.” (Aman Karir)

The others lean on tools they already had. Subha blocks AI domains through Zscaler. Ken reviews a list of known AI domains every month, though he admits it isn’t airtight. Brooke’s team is writing scripts to find what employees have signed into.

If you don’t want to build your own, AccessOwl’s shadow IT discovery reads the sign-in logs from your Google Workspace or Microsoft 365 account and scans invitation emails. That’s the same kind of signal Aman pulls from his email system. To see which apps and OAuth permissions are already connected to your workspace, start with our free shadow IT scan.

Agent permissions

AI agents can read your email, search your files and update tickets. They do it with all of your access. Aman hasn’t allowed AI connectors to Outlook, SharePoint, Jira or Confluence yet. If a user with ten sensitive SharePoint sites connects an agent, it can reach all ten.

“That’s ten different ways that you’re basically burnt.” (Aman Karir)

His idea for testing safely is a second account with access to just one site. Ken keeps a person in the loop who approves each action, which he calls a human firewall. He sees the rush to connect everything as a mistake.

“This push to have everything fully integrated is a trap, in my opinion.” (Ken Getch)

Brooke covers it in contracts. When she reviews vendor agreements, she wants AI-agent breaches written in.

“Now, however, if there is a breach because of an AI agent, I want that captured in the agreement as well.” (Brooke Bowman)

AI spend

AI spend is the newest risk on the list, and it’s growing. Masha is seeing it in this fall’s vendor renewals. Many tools are adding AI features and switching from per-seat to usage-based pricing.

“In these cases it makes it very difficult to assess how much we’re gonna be paying because we don’t know how much we’re gonna be using.” (Masha Nehme)

Dan has seen the other side of it: a team that bought an AI tool for tens of thousands and barely used it because nobody knew how.

Ken asks a simpler question: should AI be doing this job at all? He says having a general AI tool re-read company email can cost hundreds a month, when a security tool built for email does it better. His team calls this “tokenomics.”

AccessOwl is building a beta project for AI spend management. If AI spend visibility (license and token costs) is on your radar, get in touch with our team.

The tool categories (and what slice each covers)

Every tool solves a slice

The experts’ biggest frustration with tooling is that no single product covers everything. When Aman sat through demos, he found the same pattern.

“From my perspective it seemed like every company was trying to get one tool out there, but they were focusing primarily on one area of AI governance and security.” (Aman Karir)

Subha runs seven to eight separate tools to cover AI at BioXcel.

“It’s a significant investment from the company standpoint.” (Subhashish Dhar)

That leaves the real blocker: getting budget approved for three or four tools at once. Aman knows the conversation well.

“It’s a difficult thing for me to say, ‘Finance, can you please approve this when it’s not the complete package.’” (Aman Karir)

Component 3: Training & culture

No tool can watch everything. Training covers the gap. These are the habits the experts shared.

1. Assume people mean well. Most AI mistakes are shortcuts, not malice. Dan puts it down to “convenience, quick timing.” (Daniel Swithinbank) Brooke treats a slip-up as a conversation, not a punishment. If someone messes up, “you’re human, you forgot, we can sit down and we can talk and have an organic conversation about this.” (Brooke Bowman)

2. Treat AI as an assistant, not an agent. Ken’s team trains people to own every output. They tell staff “this is your assistant” and that they’re still “ultimately and fully responsible for the outputs of this work.” (Ken Getch)

3. Tailor it to the audience. Brooke’s staff range from their early 20s to their 80s, so one training doesn’t fit. She explains the same control as an ethics issue to HR and as a financial risk to finance.

4. Sign it, then keep repeating it. Subha has every employee sign the AI policy. But a signature isn’t enough. People need reminding “because people forget about it.” (Subhashish Dhar)

5. Be an office of how, not an office of no. Brooke’s line sums up the mindset all the experts shared in some form. Her team is “never an office of no” but “an office of how can we creatively solution to meet your needs.” (Brooke Bowman)

FAQs

What is an AI governance strategy?

An AI governance strategy is the combination of policy, tooling and training a company uses to control how employees use AI. All six experts we spoke to ended up building these same three components. Most built them on top of standards, policies and tools they already had, then improved them step by step.

Where should you start with AI governance?

There is no single starting point. The experts began in different places: with a policy, with an inventory of what was already installed, with shadow IT tooling, or with the data itself. It can be a chicken-and-egg problem, because a policy may be needed to justify tooling budget while tooling shows how big the problem is. What they agreed on was to start small and iterate.

Should you block AI tools that aren’t on your approved list?

It depends on your data. Experts in regulated environments blocked everything not on their approved list by default. At smaller companies with mostly internal data, allowing tools while watching closely was workable. Either way, explain the reason behind any block so people don’t look for workarounds.

How do you detect shadow AI?

The experts used signals they already had. One built an open-source platform that combines collectors on managed laptops, a browser extension, network data and AI sign-up emails. Another routes traffic through a cloud security gateway and blocks AI tools that aren’t approved. Another keeps a list of known AI domains and reviews it monthly.