Target does not have any stores in India.

You won’t find the iconic red shopping carts, seasonal aisle displays, or checkout lanes buzzing with the low-level urgency of a weekday evening grocery run. Even though the company operates roughly 1,960 stores across the United States, not one of them sits on Indian soil. If you were to draw a map of where Target’s customers exist, India would be blank.

And yet, Target runs a global capabilities center in Bengaluru that it publicly describes as “a fully integrated global capability center and strategic partner for Target Corporate,” staffed by more than 5,000 professionals supporting a USD 100 billion business. (Source: Target Corporate Careers, Global page)

That contrast is worth sitting with for a moment.

A retailer whose entire revenue base is American, whose customers are buying dog food and throw pillows in suburban Minneapolis, has decided that meaningful parts of the enterprise brain responsible for making that experience work should be distributed to India. Not the stores. Not the customer-facing product. The operating intelligence underneath it.

Because a modern retailer is not just a store. Underneath all the familiar red logo is software, inventory intelligence, fulfilment logic, personalization engines, pricing data, supplier workflows, cybersecurity operations, cloud reliability, payment systems, demand forecasting, merchandising algorithms, and thousands of operational decisions that have to work at scale, every hour of every day. A significant portion of that machinery runs through Bengaluru.

This is no longer an unusual story. It is, however, the right story for understanding what the global capability center model has actually become, and what it has to become next.

India Has Already Won the Scale Argument

According to the NASSCOM-Zinnov India GCC Landscape Report 2026, India now hosts 2,117 global capability centers, employing 2.36 million professionals and generating USD 98.4 billion in annual market revenue – a 32% expansion since FY2021. More than 506 companies from the Forbes Global 2000 operate GCCs in India. Over 1,200 of those centers have already embedded AI and machine learning capabilities, supported by roughly 250,000 AI professionals in the talent pool. (Source: NASSCOM-Zinnov GCC Landscape Report, FY2026)

We are looking at the world’s largest and most sophisticated ecosystem for distributed enterprise capabilities. Bengaluru is the heartbeat of this movement, accounting for approximately 36% of all GCC talent in the country. The combination of engineering depth, product leadership, global operational experience, and now AI capability has become a structural fact.

So the scale question is settled. India has the people, the cities, the infrastructure, the regulatory experience, and two decades of institutional learning about how to build global capability centers that actually function. Arguing against India at this point is roughly equivalent to arguing against the internet as a distribution channel in 2012. You can do it, but the evidence is not on your side.

What is actually worth a serious board-level conversation is how to design what you want to build. Operating design is the hard question now that scale is proven.

The Problem Is No Longer Where the Work Happens

For most of the last two decades, the primary GCC conversation inside US enterprises was about capacity. Could we move work to India? How much? At what cost savings? How quickly? The center was a destination: you routed work to it, and it delivered.

That framing was fine when the dominant logic was cost arbitrage and execution scale. It produced real results. It also produced a particular kind of center: a delivery organization measured on tickets closed, projects completed, people deployed, and money saved. Capable, efficient, and fundamentally reactive.

The problem is that this delivery-centre model doesn’t describe what enterprises need from global capability centers today, and it doesn’t describe what the best centers are already doing.

The EY GCC Pulse Survey 2025, which gathered responses from more than 65 GCC leaders across sectors, found that 92% of GCC leaders now say their centers contribute beyond cost arbitrage, with growing roles in innovation, transformation, operational excellence, and strategic value creation. The ultimate aspiration has now become ownership.

And that word ‘ownership’ is where the conversation gets genuinely difficult.

Moving work to a center is operationally tractable. You identify tasks, transfer them, hire people, set SLAs, and measure throughput. Moving capability is really tough because capability is not something you do. It is a mix of understanding the situation, making decisions, having the power to choose, getting the right information, deciding what to do, and being responsible for what happens. This combination allows a team to do more than just get the work done. It lets them improve the work, make changes when needed, and sometimes even come up with new ideas.

A Global Competency Center that is in charge of a platform does not wait around for the main office to say that something needs to be changed. The Global Competency Center has an understanding of what is going on, the power to say what needs to be fixed, the technical expertise to make the changes, and the responsibility to get it done and out to people. That is not a delivery center with a nicer name but a distributed capability and a genuine extension of the enterprise’s operating brain.

The distinction between activity and ownership is the central design question in every serious GCC conversation today. How much of what this center does is executing instructions versus exercising judgment? How much is responding to demand versus creating it? Most GCCs, if they are being honest about it, are much further toward the execution end of that spectrum than their organizational narratives would suggest.

AI Makes the Old GCC Model Look Under-Designed

Every few years, a new technology arrives, revealing structural weaknesses in operating models that were already there. AI is doing that now for global capability centers, and the revelation is uncomfortable.

Rather than fixing a weak operating model, AI exposes one.

Especially when you introduce AI agents, automation, and copilots into a center that lacks clear decision rights, fragmented data, late-stage QA, handoff-heavy workflows, and ambiguous ownership, you do not get an intelligent center. Rather, you end up with a faster version of the same problems – where automated handoffs and governance gaps surface data quality issues at production speed rather than downstream.

The EY GCC Pulse Survey 2025 found that 58% of India’s global capability centers are already investing in Agentic AI, systems capable of multi-step reasoning, autonomous decision-making, and workflow execution without constant human intervention. Another 29% plan to scale within the year. 

Centers are deploying AI agents into customer service, finance operations, IT and cybersecurity, supply chain analytics, and software development workflows. The scale of adoption is real but the governance around it, in many cases, is not.

Given this context, we need to ensure human-AI workforce integration in the GCC by changing how we do things. This means people, computers, artificial intelligence systems and machines that can work on their own all work together. Everyone must know what they are responsible for, with robust security measures in place. We must also maintain strict quality control and ensure complete visibility into the operations. Many misunderstand this for getting rid of people’s jobs. But human-AI workforce integration is actually about building a system that makes sure both people and artificial intelligence perform effectively, with clear ways to measure that success. 

A center that added AI to its existing operating model without redesigning the accountability structure around it has not become AI-first. It has become AI-complicated. The centers that are genuinely transforming are the ones where the AI architecture and the human accountability model were designed together, from the start, around the outcomes the business actually needs.

The implication for US enterprises is direct: if you are building or significantly expanding a global capability center now, you are making a design choice about your AI operating model whether you intend to or not. Leaving that design implicit is a choice that tends to be painful to reverse two years later.

The Five Operating Choices That Separate a GCC from a Delivery Center

Here is a practical framework built around five operating choices that consistently separate centers that mature into capability hubs from those that plateau as delivery organizations.

Choice 1: Decide What the GCC Is Allowed to Own

This is the starting point, and it is more fraught than it sounds. Moving work to a center and giving that center ownership of a capability are structurally different decisions. Ownership requires outcomes, not just activity. It requires authority to make decisions within the owned domain, access to relevant data and systems, leadership that carries accountability, and metrics tied to business results rather than operational throughput.

For a retail GCC like Target’s Bengaluru operation, ownership might mean the center owns fulfillment orchestration software including the product roadmap, the engineering decisions, the reliability targets, and the post-deployment analysis. The headquarters sets the business direction, while the centre owns the capability that delivers on it.

For a healthcare enterprise, ownership might mean the center runs clinical data interoperability – the pipelines, the compliance controls, the integration patterns, the quality checks with full accountability for the reliability and regulatory fitness of that infrastructure.

For a logistics company, it might mean the center owns predictive analytics for carrier routing and shipment visibility, including the models, the data quality governance, and the alerting logic. When something breaks or improves, the centre is the accountable party.

None of this happens automatically. It requires explicit agreement between the GCC and headquarters about what the centre is trusted to own, and then the organizational design to back that trust up.

Choice 2: Build Around Capability Clusters, Not Functional Parking Lots

The default organizational design for most GCCs mirrors the parent company’s departmental structure: engineering here, finance there, operations in another wing, analytics somewhere else. Each function reports up its own chain, coordinates across functions mostly at the leadership level, and is measured on function-specific outputs.

This design is logical but produces fragmented capability. The teams that need to work together to improve a customer journey, fix a supply chain problem, or build an AI feature are separated by organizational walls and reporting lines that weren’t designed for cross-functional speed.

Mature global capability centers increasingly organize around cross-functional capability clusters, integrated teams built around business outcomes rather than departmental convenience. A retail commerce cluster might bring together engineers, data scientists, product managers, QA specialists, and security engineers, all working on a single business domain. A cloud reliability cluster might own cloud architecture, incident response, cost optimization, and platform observability as a single accountable team. A cybersecurity cluster might own threat detection, identity management, compliance monitoring, and security training as connected capabilities rather than distributed responsibilities.

The advantage of this model is that it aligns accountability with outcomes. If the retail commerce cluster’s fulfillment software has a problem, there is one team accountable for diagnosing and fixing it, not four departments negotiating ownership over email.

Choice 3: Give the Center Decision Rights, Not Just Delivery Targets

A GCC cannot behave like a capability owner if every meaningful decision requires headquarters approval. This is one of the more common structural problems in centers that have outgrown their original operating model.

The symptom is a center that is technically sophisticated, staffed with excellent engineers and analysts, and chronically slower than it should be. The root cause is almost always the same: decision authority has not been distributed to match the capability that has been built. Architecture decisions, technology choices, workflow redesigns, prioritization trade-offs, and risk escalations all route through a headquarters approval chain that was designed when the center was a delivery satellite, not an operating hub.

Decision rights, meaning explicit agreement about which categories of decisions are made in the center, which require consultation with headquarters, and which require approval — are a governance artifact that most GCCs never formalize. The result is that every significant decision becomes a negotiation, and the center’s speed is bounded by how fast that negotiation can conclude.

Mature centers define decision rights as part of their operating governance. Not unlimited authority, and not autonomy for its own sake. Clear boundaries: the center owns these workflow and architecture decisions; the center consults on these product and roadmap decisions; these risk and compliance decisions require headquarters sign-off. Building that clarity into the governance model from the start is one of the most consequential design choices an enterprise can make.

Choice 4: Design Human-AI Workforce Integration Before AI Adoption Scales

The natural sequence for most organizations – adopt AI tools, observe what breaks, then redesign the governance – is expensive.

An AI-first global capability center requires governance, quality assurance, security controls, model monitoring, auditability, data policies, and workflow redesign to be in place before automation spreads across functions, not as a cleanup exercise afterwards.

This means deciding, before you deploy AI agents into a workflow, who is accountable when the agent makes a wrong decision. It means defining what quality looks like for an AI-generated output — not just whether it was produced, but whether it was accurate, safe, compliant, and aligned with the business intent. It means designing security controls for AI systems that have access to sensitive data and can take autonomous actions. It means establishing a model monitoring and drift-detection system so that AI performance doesn’t quietly degrade after deployment.

For US enterprises, this is especially important because the GCC is often where AI capabilities are being built before they are deployed globally. The governance that gets designed in the center becomes, by default, the governance model for the enterprise. Building it well once is substantially cheaper than rebuilding it at scale.

Choice 5: Measure Value Differently

The metrics most GCCs inherit: headcount, utilization, tickets closed, projects completed, and cost per FTE were designed to measure a delivery organization. They are not designed to measure a capability hub, and using them to evaluate one produces predictable distortions.

A GCC that has taken ownership of a platform should be measured on product velocity, not on developer utilization. A center responsible for cloud reliability should be measured on availability, incident response time, and cloud cost optimization, not on the number of engineers on staff. A center running AI pipelines should be measured on model accuracy, data quality, automation impact, and defect leakage, not on pipeline count.

Broader value metrics worth tracking in a mature center include: cycle time reduction, technical debt reduction, reusable IP created, security posture improvement, customer experience metrics influenced, revenue leakage reduction, and stakeholder satisfaction from internal product owners at headquarters.

This is what global operating model optimization actually means in practice: aligning the center’s measurement system with the outcomes the business cares about, rather than with the operational metrics that were convenient to track when the center was new. Centers that are measured for delivery will optimize for delivery. Centers measured for business outcomes will, over time, optimize for business outcomes.

What This Means for US Enterprises Building in India

BCG’s research is direct on the maturity picture: only 8% of global capability centers have advanced significantly across the three dimensions most critical to enterprise value – innovation, competitive differentiation, and operational efficiency. (Source: BCG, “Rewriting the Global Capability Center Playbook: Scaling Maturity with AI”) The other 92% are somewhere on the journey, with the majority still closer to execution-focused delivery than capability-owning operations.

That gap is entirely an operating design problem, rather than a reflection of India’s talent, which remains unquestioned. Centers that were built for cost and scale, measured on cost and scale, and governed for cost and scale will stay at cost and scale until something explicitly changes the design.

The harder truth is that setup is no longer the difficult question for US enterprises. Building a center in India is well-understood. Setting it up with the right operating architecture, the kind that can mature into genuine capability ownership over 24 to 36 months without a painful organizational redesign is where the real decisions happen.

Here are the questions worth taking seriously at the board level before or during a GCC build or significant scale:

• What capabilities should this center own in the next 12, 24, and 36 months and what does “own” mean specifically in each case?
• Which categories of decisions will be made in the center, and which ones will require headquarters involvement?
• How will success be measured beyond cost savings and headcount, and from day one?
• Where will AI be embedded into workflows, and who is accountable for governance, quality, and security?
• Which cross-functional capability clusters make sense for this business, and how will they be staffed and led?
• How will business context – the institutional knowledge that makes good judgment possible be built and retained in the center over time?
• Which leadership roles must sit in India, and how will the center’s senior leaders be developed and retained?
• How will security, compliance, intellectual property protection, and data governance be designed as structural features rather than afterthoughts?

These are not questions with universal answers. The right answers depend on the industry, the company’s maturity, the competitive pressures it faces, and the specific capabilities it needs from the center. But the companies that ask them explicitly, early, and with the right advisors tend to build centers that grow into strategic assets. The companies that skip them tend to find themselves revisiting the design two years in, at significantly greater cost.

Where Trigent Fits

Trigent works with US enterprises at the intersection of these questions helping companies design and build AI-first global capability centers in India that are built for capability ownership from the start, not retrofitted later.

The company’s services span the full GCC lifecycle: talent acquisition, managed infrastructure, compliance and security support, operating governance, industry-specific delivery pods, and AI-led delivery models. 

For companies that want to move quickly without the operational overhead of a standalone entity, Trigent offers a GCC-in-a-Box model that compresses time-to-operational-readiness. For companies that want to build toward full ownership over time, the Build-Operate-Transfer and Build-Own-Operate-Transfer models allow the GCC to start with managed support and transition to fully owned operations as the center matures.

The practical value of working with a partner like Trigent is not primarily speed to setup, though that matters. It is that the operating design questions ownership structure, governance model, decision rights, AI integration architecture, capability cluster design, and measurement frameworks get answered as part of the setup process rather than after the fact. A GCC designed with the right architecture from the beginning has a substantially different maturity trajectory than one that grows organically and is redesigned under pressure.

For US executives evaluating or scaling global capability centers, the question worth asking a potential partner is not “how quickly can you set it up?” It is: “How have you designed centers that matured into capability owners, and what does that operating design actually look like?”

The GCC as an Operating Brain

Leaders who succeed here made these design choices long before they became urgent necessities.  They defined ownership before the center was large enough to demand it. They built decision rights into the governance model before they felt the friction of not having them. They organized around capability clusters before functional silos became entrenched. They designed human-AI workforce integration before AI adoption made the absence of governance painful.

None of this requires a specific vendor or city. It requires treating the GCC design conversation as seriously as you would any other critical enterprise system, because that is exactly what it is.

The store was never going to be in India. But the operating brain? That decision is still being made.