Every CIO right now is under pressure to do something with AI. Manu Narayan, Chief Information Officer at GitLab, put a finer point on what actually gets in the way: many organizations can't give an AI tool real access to their systems without also giving up control of where that data ends up. Solve that problem, and the productivity case takes care of itself. Don't solve it, and no amount of enthusiasm for AI changes the outcome.
This is the first installment of CIO Chat, a series where Whirl AI sits down with the CIOs running some of the most demanding environments in enterprise software to talk through challenges, use cases, and what's actually changing on the ground. This conversation covers the security bar GitLab set before letting any AI tool near its systems, and what that bar made possible once it was cleared.
Every business unit wants AI for its specific use case, its specific team, its specific vertical. That instinct is reasonable on its own terms. Every business unit wants access to tools that can help their team drive impact. The problem shows up the moment IT has to answer what that means for the application stack, the data, and who ends up with access to it. Manu laid out where this actually goes wrong:
A lot of these tools either get spun up or evaluated without all of the right context, without all of the right integrations. So they're less impactful and less meaningful. Or, you give them all of that context, and now your data is being proliferated through a lot of different organizations’ cloud environments.
Manu Narayan
CIO / GITLAB
Read that closely, and it's a security problem wearing a productivity costume. A tool without real context is safe but useless. A tool with real context, absent the right controls, is useful but exposed. Most organizations experience this as a trade-off they have to accept. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls as the reasons. None of that will come as news to anyone who's actually run an IT organization; it's less a prediction than a confirmation of what practitioners have been saying for a while. It’s the same trade-off Manu described, playing out at scale.
Manu’s argument, and GitLab's experience, is that it's actually a sequencing problem: get the security architecture right first, and the trade-off disappears, because you can grant real context without the exposure.
Every company’s security bar starts before an AI tool gets near its data. GitLab applies its own data classification policy as a baseline, then layers on a rubric of required controls scaled to how sensitive that data is. For any AI provider seeking that level of access, the baseline is strict: no data retention beyond what's needed, no training on customer data, strong data isolation, and a contained blast radius if something goes wrong.
Manu put it more concretely when asked why GitLab chose Whirl specifically:
GitLab supports some of the most security-conscious organizations in the world — the vendors we bring into our own revenue systems have to hold up to the same scrutiny our customers apply to us. With Whirl, our environment is ours alone — dedicated AWS infrastructure, immutable infrastructure, no shared risk. That's why we partnered with them.
Manu Narayan
CIO / GITLAB
The security bar has to be an architectural commitment: a dedicated environment rather than a shared one, infrastructure that can't be altered after the fact, and no risk pooled across customers. For a CIO evaluating any AI provider against a security-conscious customer base of its own, that's the starting point. For more on Whirl’s commitment to security, check out our security page or the open letter from our CISO.
The productivity results GitLab describes aren't a separate achievement from the security work. They're what became possible once the security question was already answered.
Manu pointed to a specific example: "Our Salesforce instance is a decade old. We have a lot of technical debt, and our company's grown tremendously in that time." Custom code and metadata had accumulated with no clear map of what depended on what, and that gap wasn't something GitLab's own tooling could close. "Even though we're leveraging GitLab for all the source control and all that management, you don't actually see what's on the platform. You don't see all the references, you don't see where there might be formula fields that are referencing something else," Manu said. That invisibility is what made refactoring and modernization work feel too risky to start.
Closing that visibility gap required something most organizations hesitate to do: give an outside tool real access to their internal systems. GitLab could grant it to Whirl because the security architecture underneath was already in place. With the security question settled, the payoff followed.
That's the visibility that Whirl gives us: this unlock to really see all the dependencies that are mapped across the platform. And so when we think about tech debt modernization, Whirl's unlocked our ability to tackle those projects.
Manu Narayan
CIO / GitLab
The impact compounds as GitLab keeps growing. Manu pointed specifically to the go-to-market and downstream revenue teams as where it shows up most: systems that are now more reliable and scalable, less error-prone, and less dependent on manual intervention to keep running. Work that used to rely on institutional knowledge and trial and error in development environments now gets unpacked “in just minutes”, and projects that once felt too daunting to start became tractable.
When looking at an enterprise with the engineering pedigree of GitLab, it begs the question: why not build this internally? Manu’s reasoning for buying over building is a useful test for any IT leader weighing the same call.
His case comes down to where the real difficulty sits. In his experience, getting to a rough version of the core functionality is reasonably easy. What's hard, and what rarely makes it into the pitch a team gives itself for building something in-house, is everything downstream of that: the integrations, the granular access control, the security and governance and compliance work a real enterprise deployment demands. That layer looks like the smaller piece of the project at the outset. In practice, it becomes most of the engineering lift, and it's ongoing rather than one-time.
Most conversations about enterprise AI treat security as friction: the thing that slows a rollout down or limits what a tool is allowed to touch. GitLab's experience argues the opposite. The security architecture is what made real access, and therefore real value, possible at all. Skip that work, and every AI tool stays stuck choosing between too narrow to matter and too exposed to trust. Solve it first, and that choice stops being necessary.
If your team is sitting on the same kind of invisible tech debt GitLab described, get in touch.
Watch the full conversation: