TL;DR
In September, we published a report called The Control Gap, built on a survey of 300 IT leaders fielded by GLG in June. Its thesis is direct: AI has entered the enterprise, IT can't see it, can't enforce rules on it, and nobody owns it. Therefore, AI is a control problem, and control starts with visibility.
I work at SuperOps. I also think we picked the wrong frame, and since the frame is what determines how IT leaders act on the findings, I want to make the case for a different one.
The report's observations are largely right. Where I'd push is what we did with them.
Start with the premise
The report opens by asserting that IT's core job is to run and safeguard the technology the business depends on.
That is what IT does. It's a set of tasks IT must execute. It isn't the job.
IT's core job is to help the organization fulfill its mission by giving its people the tools and technology they need to execute mission-essential work. Running and safeguarding infrastructure is instrumental to that. That isn't the point.
The distinction sounds academic until you notice what it does to everything downstream. If safeguarding is the job, then anything you can't see is a threat, and the natural response to a blind spot is to shut it down. If mission fulfillment is the job, then a blind spot signals that people are solving problems through channels you didn't build for them, and the natural response is to ask why your channels weren't good enough.
Same data. Opposite posture.
We have been here before
Nothing about the pattern we described is specific to AI.
When SaaS took off, business units discovered they could put a corporate card down and have the capability they wanted by Friday. No procurement cycle, no architecture review, no conversation with IT. We called it shadow IT, then shadow SaaS. The same thing is happening now with LLM subscriptions, vendor copilots bolted onto platforms people already own, and agents nobody can source.
People behave like water. They take the path of least resistance. Give a department head a budget and a business result to hit, and they will route around whatever sits between the two. That isn't a governance failure on their part. It's a rational response to the incentives they were actually given.
This matters because it demotes our central finding from "AI has created a new blind spot" to "AI is the current instance of a recurring structural condition." And the remedy for a recurring structural condition isn't a new category of control tooling. It's fixing the conditions that make circumvention rational in the first place.
Being precise about our own numbers
We're asking IT leaders to hold AI to the same standard they hold everything else they run. We should hold our own reporting to that standard too. A few of the figures in the report deserve a tighter reading than we gave them.
The claim that only 46% of teams have a written AI policy reads a maturity ladder as if it were a set of independent buckets. The chart's categories run: none, ad-hoc, documented, tooled, continuous. Teams at "tooled" and "continuous" necessarily have written policies. The real figure is closer to 65%. The line that follows — that more than half of companies have no rule about what data can go into an AI tool — doesn't hold, since the "none" bar sits at roughly 4%.
The 13% enforcement figure is presented as a share of teams that have a policy. It's a share of all respondents.
Correct both, and the picture gets worse, not better. Roughly 65% have written something down, and roughly a fifth have anything at all enforcing it. The gap between policy and practice is wider than we thought.
The 61% figure comes from a multi-select. The question asks which pain points apply to your team, and respondents tick as many as apply. Governance ambiguity was the most-ticked item, but nine of the thirteen options landed between 30% and 46%. That's a crowded field, not a runaway. "Applies to us" isn't "the hardest part," and we treated one as the other.
Then there's the instrument. Our inventory question asks how confident respondents are that they could produce a complete list of every AI tool, copilot, assistant, and agent within 48 hours. Confidence and competence are different things. Worse, the failure mode we're trying to measure is unknown unknowns—the agents nobody told IT about—and self-reported confidence is precisely the instrument that can't detect them. A respondent who confidently says yes may simply not know what's missing.
I want to be careful here, because this cuts in our favor and I don't want to overclaim in either direction. The finding is almost certainly directionally right, and the real gap is probably worse than 16% suggests. But the survey is measuring sentiment, not capability, and anyone citing that number as evidence of inventory capability is citing the wrong thing.
Two structural limits are worth naming. There's no prior wave, so our claim that AI "arrived faster than IT could track it" is a claim about sequence made without a baseline. And the sample was purposively built from four sectors—healthcare and health tech, financial services, legal services, and PE-backed companies —across North America and Europe. We disclose that in the methodology, then generalize past it in the body.
And the thing I should say plainly, since I'm the one saying it from inside: we sell IT operations tooling. The problem the report diagnoses sits squarely in our category. That doesn't make the findings false, and I don't think anyone involved was being cynical. But it does explain the gravitational pull toward the vocabulary of control, when the same data would have supported a different vocabulary just as well.
Where control is the right word
Let me concede the strongest objection to my own position before someone else makes it.
Our sample is regulated and high-stakes by design. In healthcare, financial services, and legal, control isn't a historical artifact of IT gatekeeping. It's a compliance obligation attached to a named individual, sometimes carrying personal liability. HIPAA, DORA, SOX, GDPR. In those environments, "we enabled the business at the speed the business asked for" is not a defense in an enforcement action.
So the enablement frame needs a boundary. A narrow class of requests exists where IT's job is refusal rather than accommodation, because IT holds accountability it can't delegate to the requester. Naming that class in advance and defending the line is part of what it means for IT to declare what it's responsible for.
Outside that class, which is most of what crosses IT's desk, the control reflex is a liability. Often it's a way to deflect responsibility for failures IT got blamed for but was never resourced to prevent. Organizations still hold IT accountable for integration work, data access, and support nobody funded, because nobody brought IT into the conversation early enough to scope it. Failures exist on both sides.
I'll also grant that our actual recommendations — live inventory, telemetry, policy that executes rather than circulates — are more compatible with enablement than our framing suggests. Inventory isn't gatekeeping. Telemetry isn't a veto. The problem is the vocabulary, and vocabulary drives posture. Call it a control gap, and IT buys a gate. Call it enablement infrastructure, and IT builds a road.
The number I'd read differently
The most interesting result in the survey is the one I think we read backward.
Roughly 72% of respondents want human approval before patches go to production, 71% before audit evidence is handed over, 68% before an AI agent's access is cut. We read this as a trust deficit — humans acting as the fallback control because no system underneath is doing the job.
I don't think that's what it is. We've had the mechanical ability to push patches automatically for twenty years. Nobody is holding that approval gate because they doubt the agent can reach the endpoint.
They're holding it because the mechanics were never the hard part. The hard part is: what does this patch actually touch? Which distribution, which configuration, which revision level? What breaks if a dependency isn't there? Does baking it in require downtime, and can that downtime land somewhere the business won't feel it? For a global retailer heading into peak trading, who has the authority to accept that revenue impact?
Those are risk and impact questions, and most of the information needed to answer them has never been assembled in one place. The human isn't a substitute control. The human is the only party currently holding enough context to make the call, and they're usually making it on intuition and partial information.
That's the actual opportunity, and it points the opposite way from where the report aims. The near-term value of AI in IT operations isn't autonomy in consequential actions. It's decision support: pulling vendor advisories, dependency graphs, configuration state, change calendars, and business-impact context into one place so the person with the authority can make a better decision than they could yesterday.
Autonomy on reversible, low-consequence work is already happening and already fine. Autonomy on irreversible work isn't the prize. Better human decisions on irreversible work is.
What to do with this
Stop asking how to control what people are doing with AI and start asking why they went around you to do it.
Get IT into the conversation at the point where the business decides what it needs, not when it needs an integration built and a support model retrofitted. Declare what IT is accountable for, defend that line, and be explicit about the narrow set of things where the answer has to be no.
Build the inventory and the telemetry. Not so you can say no faster, but because you can't support, fund, or improve what you can't see.
And be careful with maturity as a goal. You can run the most mature IT organization in your industry and still have every customer inside the building routing around you. If that's happening, the maturity score is measuring the wrong thing.