Governing AI Without Getting in the Way
TL;DR: Most AI governance responses are missing two specific gaps: the contract you signed predates the platform you’re now running, and the binary approved/not approved model doesn’t fit an environment where AI is embedded across the stack at varying levels of risk. Both are fixable. Neither is being addressed consistently.
If this one was useful, share it with someone who is working through what AI governance actually looks like in practice. Thank you :)
A few weeks ago I wrote about how AI had already arrived inside most organisations, often quietly, through vendor updates and employee habits, before anyone had made a deliberate decision about it. The response I kept hearing back was some version of; “yes, and now what?” So this is the now what.
The instinct to reach for tighter controls is normal. And the need for some of those controls absolutely applies. But some governance gaps keep coming up that I don’t think are getting enough attention, and they need different responses.
The contract you probably haven’t renegotiated
If the last article was about how AI got in, this one is about what the organisation is now responsible for. The short version, a product decision got made inside your vendor’s organisation, it landed in your environment, and the contract you’re running on almost certainly predated it.
To be fair to the major vendors, this isn’t the unguarded wild west it was two years ago. Microsoft, Google, and Atlassian have all published meaningful commitments for their enterprise AI features. Some of the measures they have put in are things such as: no training on customer data in certain contexts, encryption in transit, tenant isolation, admin controls, and audit logs. That’s real progress, and it’s worth acknowledging the progress that has been made as opposed to just generalising with statements such as “vendors can’t be trusted”.
The risk, though, hasn’t gone away, it’s slightly shifted. The issue is no longer simply whether a vendor is training on your data. It’s whether AI features have been added to existing systems without a corresponding update to your contracts, controls, approval processes, or your understanding of which outside companies your vendor is routing data through. Even when a vendor has good controls, those controls have to be configured, enabled, and understood. What changed when the feature landed, in terms of data access, user permissions, purpose of processing, or where your data is now being processed, may never have been reviewed at all. Whether the vendor made that review possible is a different question from whether it happened. And to top it off, the controls may exist, they just weren’t configured, enabled, or reviewed before the feature went live.
The gap is potentially bigger again with smaller vendors. Many smaller platforms have bolted AI onto their product. In those cases, your real exposure can include the application vendor, the model provider, and any connected tooling, each with different commitments and different controls. The application vendor may say “we don’t train on your data” while having no meaningful ability to audit what happens downstream of the API call.
The question most organisations are asking is “does this vendor have an AI policy?” That needs to be asked, but it may not be as useful as reframing it. The more useful question could be, “what changed when AI was enabled in this platform?” Specifically in terms of data access, retention, sub-processors, user permissions, and contractual commitments? If the answer is “nothing changed and nothing was reviewed,” that’s where the gap lives. And that gap is the organisation’s responsibility to close, not the vendor’s. Vendors have a strong commercial incentive to ship features quickly. What we’re often slower to do is understand what we’ve accepted when those features land.
This is fixable at renewal time as a genuine conversation. We can simply start to enquire with: What AI capabilities have been added since we signed? What data do they touch and under which terms? Are there feature-level controls that let you enable or restrict specific capabilities by team, role, or data type? None of these should be a difficult questions to ask or conversations to have. They’re the ones any platform owner running mature enterprise systems should be able to answer clearly. If your vendor struggles to answer them, that’s in itself is a useful tell before you renew.
The risk-tiering problem
In the last piece I said the answer isn’t to block everything. What I left unanswered was slightly harder: once you’ve decided not to block, how do you actually work out which systems or tools need what level of review?
Most organisations are still managing this with the basic approach of; approved or not approved, and I totally get why. It’s the governance model that already exists, and reaching for it is the path of least resistance. The problem is it wasn’t built for an environment where AI is embedded across the stack at varying levels of depth, and access. Approved or not approved made sense when AI tools were a distinct category sitting outside your existing platforms. That’s not the environment most of us are operating in now though.
What works better, as far as I can tell, is thinking about any given tool across two dimensions: the business value it delivers, and the data exposure it creates. Not as a formal framework, but as a way of reasoning about where the actual risk sits and whether the governance response is proportionate to it.
A general-purpose tool that helps someone draft internal communications with no access to your systems is a fundamentally different problem from a tool connected to your data warehouse that can query records and surface patterns across multiple systems. And somewhere between those two sits a browser extension that quietly scrapes to provide improved suggestions, which tends to sit much closer to the second end than most people who install it realise. Treating all three the same way creates friction that doesn’t match the risk. And that’s when people start to make excuses. “It’s not that sensitive” or “There’s so much red tape”. And once people have decided that, they don’t argue with the process, they just stop following it or bypass it.
In practice, that means tools with high value and genuinely low exposure are worth approving quickly, supporting properly, and making easy to access. Tools with high value and real data exposure need proper controls before they’re deployed, not a blanket ban, but a clear conversation about what makes the use acceptable. Tools with low value and high exposure are the ones worth blocking, and it’s worth being explicit with people that the concern is the data, not some general resistance to AI.
The category that wastes the most governance energy is the low value, low risk end. Not everything someone wants to try needs a full governance assessment cycle. Allow some experimentation but have some oversight. Blocking something because nobody has reviewed it yet is not the same as blocking it because the risk requires it.
Keeping up with what you can't fully see
Here’s the honest part. A governance model built even twelve months ago may not align to the environment you’re actually operating in today. The tools have changed, and so has the data use, the habits of the people using them, and the overall risk profile. The question isn’t just whether you’ve approved the right things. It’s whether the governance framework you have in place is still aligned to the environment your organisation is actually operating in.
The ones I see getting ahead of this aren’t necessarily the ones with the most complete policy documentation. They’re the ones where the governance conversation is continuous, the questions being asked of vendors at renewal time have changed, and the response to a new tool isn’t overly cautious but flexible.
Writing a policy, as painful as that process can be, is still the easy part. The harder thing is building something that actually reflects how people work and flexes with their needs. A policy that sits outside of that isn’t really governing anything. It’s just a document that exists. That is usually enforced after an event.
I haven’t fully worked out what that means in practice, and I don’t think most organisations have either. It does make me wonder whether any governance model can actually keep pace with the rate this technology is moving. But I think the ones willing to keep asking that question are already in a better position than the ones that have decided it’s already been handled via a Yes or No.
~ Pete G