The Accountability Gap: India Builds the AI, But Who Answers for It? - Nasscom

The accountability gap appears when responsibility is divided across an AI system, while the system’s consequences arrive as one outcome. A management chart may show reporting lines, but it does not show how data, models, code and decisions combine. The gap matters because an institution may know who reports to whom without knowing how harm happened.

For example, an AI credit-dispute agent may involve an engineer, a GCC, a model provider, a cloud provider, an executive, a risk function and a regulated legal entity. The system can also depend on proprietary data, retrieval, orchestration, permissions and downstream systems. Each may own one piece, while the customer experiences one decision.

The article places India’s GCC ecosystem near the centre of this problem. Mature centres increasingly own architecture, data platforms, models and production leadership. Closing the gap requires connecting the organisation chart with the dependency graph, so causation, control and accountability can be traced together.

India’s GCC ecosystem is large and expanding quickly. The Nasscom-Zinnov GCC Landscape Report 2026 counts 2,117 global capability centres, 2.36 million professionals and $98.4 billion in FY26 revenue. Revenue is up 32 percent since FY21, and more than 500 Forbes Global 2000 companies operate a centre in India.

AI is central to the recent expansion. The report ranks India as the world’s number one AI hiring market. Nearly half of all GCCs established since FY21 were built with AI as a core mandate from the start. This means AI is not only being added to older delivery operations; it is shaping the purpose of many new centres.

That growth increases the importance of governance. Mature GCCs can own architecture, data platforms, model training and production leadership. As technical agency moves into these centres, accountability must keep pace with the capabilities and decisions located there.

A global capability centre is generally an internal part of a multinational enterprise. It is staffed by the company’s own employees and governed by the company’s policies. That differs from an outside technology vendor, which delivers services through a separate commercial relationship. The distinction matters because internal capability can carry direct institutional authority.

Some GCCs remain execution centres. They perform work specified by a delivery contract. More mature centres operate closer to the enterprise’s engineering core. They may own architecture decisions, run data platforms, train or adapt models, and staff leaders who decide how systems behave in production.

India’s GCC growth therefore represents more than relocating technical work. It distributes institutional capability and technical agency across the enterprise. Governance structures have mostly not kept pace with that shift. Responsibility must reflect what a centre actually controls, not simply where it is located or how it is labelled.

A cross-border AI outcome can involve many actors at once. The article’s example includes an engineer and GCC leadership in Bengaluru, a foundation-model lab in the United States, cloud infrastructure in Virginia, customer data governed from Frankfurt, and a borrower in Ohio. The owning institution is headquartered in New York.

Responsibility may also involve the executive who approved deployment, the risk function that validated the system, the regulated legal entity, and regulators connected to the institution or engineering location. The agent may depend on an enterprise data estate, tools, policies and downstream systems. Each actor can affect a different part of the result.

The key mechanism is a dependency graph, not just a reporting chart. It shows how technical and organisational dependencies connect to the customer outcome. Accountability becomes difficult when jurisdiction, control and causation are distributed across companies, locations and system layers.

A production AI system is usually a composition, not a single model. It can combine a foundation model with adaptation layers, retrieval over proprietary data, orchestration logic, policy engines, tool permissions, human approval points and enterprise systems. Harm can therefore arise outside the model itself. The model may generate an expected response while another layer turns it into a bad outcome.

For example, retrieval may supply stale information. Orchestration may send the output through the wrong workflow. A tool permission may be too broad, allowing an action the system should not take. A configuration change that nobody logged may alter behaviour. The downstream enterprise system can then convert that output into a customer consequence.

This is why asking who built the model is often the wrong question. Investigators must trace which node failed, who controlled it and how it connected to the outcome. Governance must cover the full composition, including changes, permissions, data and handoffs.

When an AI system supports a human decision, an identifiable person remains between the output and the consequence. Existing accountability structures are therefore more legible. The human decision point can provide a place to review, constrain or reject the recommendation, even though the wider system still needs governance.

The problem grows as systems move toward automated decisions made without a sign-off. In that setting, the outcome may pass directly from model output and surrounding logic into an enterprise action. Responsibility can then involve the system designers, permission owners, approvers, risk teams, legal entity and leaders who delegated authority.

The article frames this as a distance between causation, control and accountability. The farther those are separated, the harder it is to reconstruct responsibility after an incident. Organisations must therefore identify who could prevent or constrain each action, not only who approved deployment or supplied the model.

Causation, control and accountability are related but different. Causation identifies the component or decision that contributed to an outcome. Control identifies the actor that could have prevented or constrained it. Accountability identifies the person or institution that must answer for it. A single actor may not occupy all three roles.

In an AI system, stale data may contribute to an error, while a platform team controlled the retrieval process and an institution remains accountable to the customer. Similarly, an overbroad tool permission may enable an action, while an executive approved deployment. These links may cross technical teams, companies and jurisdictions.

The dependency graph is essential because it maps how consequences travel. The org chart maps authority and reporting. Neither map alone is enough. Distributed AI governance must connect both, tracing components, decisions, controls and outcomes before or after an incident. That is especially urgent as GCCs gain deeper engineering agency.