Building a GCC That Leads, Not Just Delivers: A Data & AI Playbook
I have spent most of my career inside, or working alongside, delivery centres that serve a business somewhere else. Banking operations at the start, then audit and finance reporting, then data and AI programmes for retail, medtech and insurance. Today I lead Data & AI delivery from a global capability centre in India, with a team spread across India, Europe and the Gulf.
One question comes up again and again when leaders talk about GCCs: how do you move a centre from "the place work gets done cheaply" to "the place the business goes for ideas"? I don't think there is a single answer. But I have seen enough of what works, and what quietly fails, to write down a practical playbook. This is it, written for anyone building or scaling a data and AI capability inside a GCC.
Why the old GCC model runs out of road
The first generation of captive centres was built on labour arbitrage. Headquarters wrote the requirement, the centre built it, and success meant on-time, on-budget delivery. That model still has value. It is also a ceiling.
Data and AI work breaks the model in three ways. First, the requirement is rarely clear at the start; you discover it by working with the data. Second, the value sits in decisions the business makes, not in the code you ship. Third, the risks (model risk, privacy, regulatory scrutiny) need judgement close to the work, not a checklist sent from another time zone.
A centre that only executes tickets cannot do any of this well. It ends up building dashboards nobody opens and models that never leave the notebook. The people are capable. The operating model is the problem.
Shift 1: Own outcomes, not tasks
The single biggest change I push for is moving the conversation from "what do you want us to build?" to "what decision are we trying to improve?"
In practice that means every data or AI initiative starts with a one-page outcome brief:
- The business decision or process being changed, in the business owner's words
- How we will know it worked: one primary measure, agreed before any build starts
- Who on the business side owns adoption once the model or report is live
- What "stop" looks like if the early signal is weak
This sounds basic. It is also the step most often skipped, because it forces an uncomfortable conversation early. When the GCC team writes the brief with the business owner, the centre stops being a vendor and starts being a partner. The brief also becomes the backbone of every steering committee update, which keeps reviews short and honest.
Shift 2: Build product teams, not resource pools
Many centres still staff by headcount requests: three data engineers here, two analysts there, released back to the pool when the project ends. Knowledge leaves with every release.
What works better is a small number of stable, cross-functional teams aligned to a business domain, for example customer intelligence, distribution or operations. Each team has a product owner who understands the business, data engineers, data scientists or analysts, and a clear line to the platform team. The team stays together across initiatives, so it compounds domain knowledge.
Two things make this stick. The product owner must have real authority over the backlog, not just a title. And the team needs to see its work used: invite them to the business reviews where their outputs are discussed. Nothing builds ownership faster than hearing a sales or operations leader argue about your model's recommendations.
Shift 3: Put governance inside the centre
GenAI has made this urgent. If every model, prompt and data pipeline needs sign-off from a committee at headquarters, delivery slows to a crawl and people find ways around the process.
The alternative is to build governance capability in the centre itself. In my experience a practical AI/ML centre of practice needs four pieces:
- A shared playbook: how we scope, build, validate, document and monitor models, including GenAI and agentic use cases
- Responsible AI controls that are part of the delivery lifecycle (bias checks, explainability notes, human-in-the-loop design), not a review bolted on at the end
- A model-risk forum with clear criteria for what needs deeper review and what can move fast
- LLMOps and MLOps standards so that monitoring, versioning and rollback look the same across teams
When this lives in the GCC, the centre earns the right to make more decisions locally. Headquarters still sets policy. The centre shows it can apply that policy consistently, and that is how trust is built.
Shift 4: Treat data foundations as a product
Every AI ambition eventually runs into the same wall: the data is not ready. Customer records are duplicated across systems, definitions differ by country, and nobody owns quality.
The centres that break through treat data foundations as a product with its own roadmap, not as a pre-step every project repeats. That means investing in entity resolution and a trusted customer view, in data-quality rules that run continuously with clear escalation paths, and in documentation that a new analyst can actually use.
This work is not glamorous, and it is hard to fund because its value shows up in other teams' results. My advice is to tie it explicitly to two or three high-visibility use cases. When a cross-sell or retention model performs better because the underlying customer data is cleaner, say so in the steering committee. Make the foundation visible.
Shift 5: Grow leaders, not just specialists
A GCC that wants a seat at the strategy table needs people who can hold that seat. Technical depth is necessary but not enough. The leaders who make the difference can translate between a business problem and a technical design, manage stakeholders across time zones and cultures, and say no with a better alternative.
A few things I have found useful:
- Rotate senior engineers and data scientists through product-owner or delivery-lead roles for a quarter
- Give team leads direct exposure to business stakeholders, rather than routing everything through one senior manager
- Make documentation and knowledge-sharing part of performance expectations, not an extra
- Create a visible path from individual contributor to architect or practice lead, so strong technical people are not forced into people management to grow
Shift 6: Run the portfolio, not the project list
As the centre grows, the number of initiatives grows faster than leadership attention. Without portfolio discipline you get dozens of half-funded projects, each with a sponsor who believes theirs is the priority.
I manage this with a simple quarterly portfolio review. Every initiative is placed on a grid of business value against delivery confidence. High value and high confidence get full funding. High value and low confidence get a time-boxed discovery. Low value gets a direct conversation about stopping. The review is done with business sponsors in the room, so trade-offs are made openly.
Vendor and platform decisions belong in the same review. Cloud and data-platform partners are a big part of the cost base and the risk profile. Reviewing them alongside the initiatives they support keeps spending honest.
Measuring maturity: questions I ask
Instead of a maturity model with five colourful levels, I use a short set of questions. If the answer to most of them is yes, the centre is on its way from delivery hub to capability centre:
- Do business leaders bring problems to the centre, or only requirements?
- Does the centre own at least one end-to-end product, from data to decision?
- Can the centre approve and release a model within an agreed governance framework without escalating every decision?
- Are data-quality issues found by the centre before the business finds them?
- Does the centre have people that headquarters asks for by name?
- Is there a pipeline of local leaders ready to take on bigger scope next year?
What this means for leaders building GCCs now
India's GCC story is often told in numbers: centres opened, seats added, cities expanded. Those numbers matter, but they describe scale, not capability. The next phase is about the work itself. It is about centres that own outcomes, govern AI responsibly close to where it is built, and grow leaders the global business relies on.
None of this needs a grand transformation programme. It needs a series of deliberate choices: write the outcome brief, keep teams stable, build governance locally, fund the data foundation, invest in leaders and run the portfolio openly. Make those choices consistently for a year, and the centre's reputation changes.
I'd like to hear how others are approaching this, especially leaders building data and AI capability in India for businesses in the Gulf, Europe or North America. What has worked for you, and what would you add to this list?
Views are my own and do not represent any employer.
If this was useful, connect with me on LinkedIn, email contactme@mukherjeesuman.com, or read more articles.