Governing AI at Gartner UK: Only 5% Say They’re Ready. Here’s Where to Start.
During one AI governance session at the Gartner Security & Risk Management Summit in London, a well-known authority in the GRC world shared a number that stopped the room: only 5% of organizations say they have a mature AI governance program.
Cue the shock and awe.
At the same conference, we were all being told to become orchestrators and build automation on top of AI systems. So what does it mean that almost no one has governance in place for the thing we’re all being asked to build on?
To me, it means going back to basics. Understand your risk, then build policy, technology and process around it.
Governance is a series of decisions, not a document
Here’s an example. Many organizations have already rolled out some kind of enterprise AI tool. So surely anyone with access to PII or PHI gets blocked automatically when they try to paste it into that tool, right?
Or was that never considered?
Maybe that control needs an expensive enterprise browser solution, and for now your maturity looks like this: people with sensitive data access don’t get AI yet, or they only get one specific approved system.
None of these answers is wrong. What matters is that each one is a governance decision, and your policy should state which one you made. If you didn’t make the decision deliberately, it was made for you by default.
Prioritize accuracy over completeness
One of the best pieces of advice I heard all week was this: build a living inventory, and prioritize accuracy over completeness.
I love this. In risk quantification, we don’t try to boil the ocean by quantifying every possible risk. We start with what threatens the crown jewels. AI inventory works the same way. An accurate list of the AI touching your critical systems and data, kept current as you discover more, beats a complete list nobody trusts.
Assign owners
An inventory without owners is just a spreadsheet. The ownership model that came up in the sessions is one you could start using on Monday:
| Function | Owns |
| Security | The data |
| Risk | The scoring |
| GRC | Continuous control monitoring |
| SOC + IT + GRC (jointly) | AI incident response |
Under all of it sits one recommendation: invest in a source-grounded data foundation that both people and AI can use. If your team and your tools are working from different versions of the truth, nothing else in this model holds.
Shadow AI is a visibility problem, not a policy problem
This was the reframe I keep coming back to. Most organizations already have an acceptable-use policy. What they lack is the ability to see what’s actually happening. Practically, that means:
- Track intended use against observed behavior for every AI asset, and reconcile the two regularly.
- Look for toxic combinations of controls, not just individual control failures. Two “medium” gaps on the same AI system can add up to a critical exposure.
- Prioritize exposure by how fast an attacker can move, not by how many issues are in the queue.
The lines I’m still thinking about
Some of the sharpest moments were also the most contrarian:
- “Use AI to fight AI? No.” Adding more AI doesn’t fix an AI problem. Governance, visibility and controls do.
- “Evaluate AI based on the activity.” Judge an AI system by what it actually does and what it touches, not by its label or what the vendor says it does.
- “Vibe coding cybersecurity is a bad idea for 99% of organizations.” Building your own security tools with AI looks fast, but it’s a 5–10 year commitment to maintain. Orchestrate; don’t rebuild your whole security stack.
- “Zero AI objectives!” AI isn’t the objective. It’s the means of reaching a business objective. If your goal is “deploy AI,” you’ve already lost the plot.
We asked ourselves first
At SAFE, we’re building AI into our own platform, so we had to answer the same questions we ask our customers. Before any AI integration goes live, we ask three:
- Who owns the integration?
- What does a successful integration look like?
- Can we defend this data?
If we can’t answer all three, it doesn’t ship. It’s a simple test, and it would catch most of the governance gaps I heard described in London.
How SAFE helps you build an AI governance program
AI risk isn’t a new kind of risk. It’s your existing cyber and third-party risk, reached through a new attack surface. You can measure it the way you already measure everything else: in dollars, by scenario, with the controls that drive it.
SAFE treats it as two tracks with one roll-up:
- AI you build or deploy is modeled in cyber risk quantification. SAFE adds AI attack methods, outcomes and controls to the FAIR model you already use, with the NIST AI RMF assessment providing your actual governance maturity.
- AI your vendors run for you is managed in TPRM. That includes AI questions in vendor intake and tiering, and AI-SPM for supported providers, which shows contract, configuration, outside-in threats and live activity (including PII in prompts) in one place.
The aim is a defensible answer to three questions your risk committee will ask:
- How much AI risk do we carry, in dollars?
- Where does it come from: AI we run, or AI our vendors run?
- Which controls or vendor actions reduce it the most?
One last piece of advice, and it applies whether you use SAFE or not: keep your KPIs and KRIs separate. KPIs show your program is running, such as systems inventoried or assessments completed. KRIs show whether the risk is actually going down. A green KPI next to a rising KRI is a warning, not a win.