The trade-off hiding inside every AI tool request

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.

Every business unit wants AI for its specific use case, its specific team, its specific vertical. 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. 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.

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.

What does "secure enough for AI" really require?

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.

What clearing the security bar actually unlocked

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. "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.

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.

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 — systems that are now more reliable and scalable, less error-prone, and less dependent on manual intervention. Work that used to rely on institutional knowledge now gets unpacked "in just minutes".

Why buying beats building, even for an engineering giant like GitLab

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. In practice, it becomes most of the engineering lift, and it's ongoing rather than one-time.

Security is the prerequisite, not the constraint

Most conversations about enterprise AI treat security as friction. 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: