Every GCC leadership team planning its AI program starts with the same question: what should we build? After two decades and 220+ GCC setups, we think that is the wrong question. The one that actually determines whether an AI program scales or stalls is: who is on the team building it?
94% of enterprises have an AI strategy, 70% of GCCs have a roadmap, and 51% are still at the earliest stages of maturity. The budgets are there, the sponsorship is there, the engineering talent is there, and yet programs plateau because the teams executing these strategies were designed for software delivery and never restructured for what AI actually demands. The enterprises reaching production have roles on their GCC AI teams that would never show up on a traditional engineering org chart, and the ones stuck in pilot mode are missing exactly those roles.
The Zinnov-Nasscom-Tiger Analytics GCC AI Maturity Playbook identifies seven of them.
The AI initiatives that work in GCCs share a simple trait. Before anyone started building, someone defined what the initiative would change for the business in terms specific enough to measure, like reducing claims processing time by 40%, cutting manual review effort by 60%, or lifting conversion by 15%. That level of clarity is what gets an initiative funded, adopted, and renewed, because business leaders can track progress against it and a CFO can defend the spend. The Translator is the person who creates that clarity, turning what the enterprise cares about into something an AI team can build toward and leadership can hold them accountable to.
When no one plays the Translator role, the outcome is always the same. The team builds something technically strong, the benchmarks look good, and then no one picks it up because nobody connected the model to a business outcome. 80% of GCCs have AI champions, but champions without a Translator just end up managing a long list of pilots that never add up to anything.
A clearly defined business outcome gets the initiative funded, but it does not mean the team building the solution understands how the business actually runs. In most GCC AI programs, the people with the deepest knowledge of the process being automated are the least involved in the build. They give input early, then step away, and the engineering team fills in the blanks on their own. Those blanks contain exactly the kind of knowledge that determines whether users adopt the solution or reject it, like how a finance team handles invoice exceptions every day in ways they never formally documented, or how relationship managers make decisions through patterns that look nothing like the workflow diagram. With 55% of India’s GCC work portfolio facing AI displacement, most of it in procedural roles where this kind of undocumented process knowledge lives, the cost of getting this wrong only grows.
The Insider is the role that closes this gap by staying in the room for the entire build, not contributing once and leaving. They are a permanent member of the AI team, sitting with engineers daily, pressure-testing every design decision against how the work actually gets done. GCCs that have made this a dedicated, full-time role consistently ship solutions that get adopted on the first rollout rather than cycling through rounds of fixes that cost more than the original build.
The business outcome is defined, the team understands how the work gets done, and the model approach is selected. Then halfway through the build, the team discovers that the data they need is scattered across three systems with inconsistent labeling, missing two years of historical depth, or locked behind a governance policy that takes two months to clear. Almost every GCC AI program that has stalled mid-build traces back to the same root cause. Someone confirmed “yes, we have the data” in a kickoff meeting and nobody validated what that actually meant until the model needed to ingest it.
The Plumber is the data engineer who treats data readiness as a continuous function running alongside model development, not a checkbox completed before the build begins. They assess whether the data exists with adequate depth, clean and structure it into usable pipelines, and build governance pathways so access does not become a bottleneck mid-project. GCCs that score low on even one of the four readiness dimensions the playbook evaluates, availability, quality, structure, and governed access, consistently stall at the pilot stage regardless of engineering talent.
The model is validated, the pilot delivered results, and everyone agrees it should scale. Then it sits in limbo for months. The compliance review has no owner, the integration with the production tech stack depends on three other teams that nobody is coordinating, and the business users who are supposed to operate the model were never trained on it. The engineering team eventually moves on to the next initiative, and the pilot quietly dies. In GCC AI programs, the most expensive failure is not a model that does not work. It is a model that works and never reaches the people it was built for.
The Shipper is the product and program manager who owns the entire journey from proof of concept to production deployment, managing cross-functional dependencies, driving stage-gate progression, and making sure the initiative does not lose momentum between phases. What makes the Shipper distinct from every other role on this list is that they also own adoption. A model that engineering hands over to business users who cannot operate it has not shipped. GCCs that embed customer success functions within the technical team, people responsible for change management, user training, and ROI tracking, consistently close the gap between a working pilot and an adopted product.
The Optimizer: Who Makes Existing Models Work for Your Enterprise
A GCC team spends eight months building a proprietary NLP model for contract analysis that delivers 92% accuracy. A fine-tuned open-source LLM, which would have taken six weeks, benchmarks at 88% for the same task. That 4% gap did not justify the seven-month delay, and during those months, four other high-impact use cases sat in the backlog waiting for capacity. In GCC AI programs, defaulting to custom development when adaptation would have delivered comparable results is one of the most costly resource allocation mistakes.
The Optimizer adapts existing foundation models to enterprise use cases through prompt engineering, fine-tuning, and retrieval-augmented generation. But the most valuable thing they do is make the call on which solutions genuinely need to be built from scratch and which ones just need the right layer added on top of what already exists. They own model selection as a cost decision, matching classical ML to structured prediction, lightweight models to high-volume text tasks, and on-premise deployments to regulated workflows. For GCCs at the emerging and scaling stages, the Optimizer consistently delivers the highest return in the portfolio.
The first five roles on this list help a GCC deliver AI well. The Builder is the role that helps a GCC create something the enterprise could not have built without it. A proprietary model, a patentable approach, a new AI-first product that opens a revenue stream that did not exist before. Without this role, a GCC can become excellent at adapting and deploying AI but will remain a delivery arm executing priorities set elsewhere rather than shaping the enterprise’s AI agenda.
The Builder is the research scientist or ML engineer who develops models from the ground up for problems where existing tools cannot deliver the differentiation the enterprise needs. It is the most expensive role on this list and the hardest to hire for, and it only works when the other six roles are already delivering consistently. Nearly half of GCCs established since FY2021 launched with AI as a core focus, and the ones that have moved from delivery to innovation are the ones that built a track record of shipping and scaling adapted solutions first, and then turned that credibility into the mandate and the budget to create something new.
The Operator: Who Keeps AI Running, Affordable, and Safe
Most GCC AI teams treat production deployment as the finish line. It is actually where a different set of problems begins. Models drift as the data they were trained on stops reflecting reality. Costs climb when prompts are not optimized for the volume of queries hitting them in production. A hallucination surfaces in a customer-facing workflow and nobody catches it because no monitoring was set up. The damage is not just operational. It is reputational, because once leadership loses confidence in a live AI system, getting approval for the next initiative becomes significantly harder.
The Operator is the ML Ops and platform engineer who makes sure none of this happens. They monitor model performance, catch drift before it affects outputs, manage token costs by routing queries intelligently and caching repeated ones, and maintain rollback mechanisms so the team can revert to a stable version the moment something goes wrong. 80% of GCCs are engaged in AI/ML partnerships, and a significant share of those partnerships exist specifically because the Operator role is the one GCCs are slowest to build in-house.
These seven roles are not a hiring checklist. They are a modular system that assembles differently based on what is being built.
Deploying an off-the-shelf AI tool primarily needs the Translator, the Insider, and the Shipper. A fine-tuned model initiative adds the Plumber, the Optimizer, and the Operator. A custom model program activates all seven simultaneously.
AI maturity in GCCs has no correlation with headcount. The difference between programs that scale and programs that stall is not how many people are on the team. It is whether these seven roles are present, at the right depth, for the type of problem being solved.
The full diagnostic framework is available in the Playbook. Download here: Zinnov-Nasscom-Tiger Analytics GCC AI Maturity Playbook. To assess where your GCC stands on AI maturity today, download the GCC AI Maturity Study.
To talk to us about building your GCC AI team, write to info@zinnov.com
THANK YOU
FOR YOUR RESPONSE
