A global capability centre in Pune builds a résumé-screening tool for its US parent. A Hyderabad centre runs a credit-scoring model for a European bank. A Bengaluru team fine-tunes a generative AI assistant that answers customer queries in a dozen countries. All of this is routine today. What is not routine is the answer to a simple question: if the system gets it wrong, who pays?
India now hosts more than 2,100 GCCs, going by the figure cited at the CII GCC summit in July 2026, and the talent base is estimated at around 2.36 million professionals (Zinnov–nasscom, FY2026). The Finance Minister has spoken of reaching about 5,000 centres by 2030. These centres are no longer only support hubs. They increasingly carry mandates in AI, data, cybersecurity and product ownership, which means they are often the team that actually designs, trains, tests and runs the model.
India does not have an AI Act. That does not mean there is no liability. In my view, this is the most common misunderstanding among GCC leadership teams: the absence of a dedicated statute is read as the absence of risk. It is nothing of the sort. This article explains how AI liability is being approached in India, which existing laws already bite, where GCCs sit in the chain of responsibility, and what a prudent centre should be doing now.
India’s approach: no standalone AI law, for now
On 5 November 2025, the Ministry of Electronics and Information Technology (MeitY) released the India AI Governance Guidelines. The drafting committee took the view that a substantial part of AI risk can be handled within existing legislation, and the Guidelines do not propose a separate AI statute at this stage. What they do propose is a graded liability system, under which responsibility depends on the function a party performs, the level of risk involved and whether the party observed due diligence. They also ask for greater clarity on the roles of developers, deployers and users across the AI value chain.
The Guidelines are not binding. Even so, they tell us how MeitY, sectoral regulators and, in time, the courts are likely to think. For a GCC, the message is that function will count for more than label. Describing yourself as a 'captive service provider' offers little comfort if your team built the model, chose the training data and pushed it into production.
Not every AI system carries the same risk
Two GCCs may both say they “use AI” and be in entirely different legal positions. A tool that helps an analyst prepare a recommendation, which the analyst then reviews and signs off, is one thing. A system that takes a decision and acts on it without a person in between is quite another. The first leaves a human decision-maker in the chain. The second moves the question of accountability squarely onto whoever built, configured and switched on the system, and as generative and agentic AI spreads through GCC workflows, the second kind is becoming more common.
So the legal analysis cannot stop at what the law says. It must also ask how the system actually works. Before a system goes live, the centre should be able to answer, at a minimum: what is it for; how much autonomy does it have; what data does it depend on; where does a human step in; and what happens to an individual if the output is wrong, biased or simply unsuitable. The stakes rise sharply where the output is relied upon without checking, where personal data is involved, or where money is at stake.
Responsibility, when something does go wrong, rarely rests with one party. It can be spread across the GCC, the technology provider, the parent company and the human who relied on the output, and the weight each carries will turn on who had control and what oversight was exercised. Even a well-trained and well-tested model can produce a faulty result. What counts, then, is not only whether the system is capable of making a decision, but whether there are real safeguards to review its output, catch errors and intervene in time.
The laws that already apply to your AI systems
Data protection. The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025 and published in the Gazette the next day. The Data Protection Board provisions came into force immediately, consent manager registration follows from November 2026, and the main operational duties apply from mid-May 2027. That is about seven months from today. Until then, section 43A of the IT Act and the SPDI Rules, 2011 continue to govern. For AI work, three points matter. First, a data fiduciary remains responsible for processing done on its behalf by a processor, so handing a model to a vendor does not hand over accountability. Second, reasonable security safeguards are mandatory, and a breach must be reported to the Board and to affected individuals, with a detailed report to the Board within 72 hours. Third, penalties can go up to ₹250 crore for failure to maintain safeguards. Significant Data Fiduciaries carry more: impact assessments, audits and due diligence on the algorithmic software they deploy.
Many GCCs will lean on section 17(1)(d) of the DPDP Act, which exempts the processing of personal data of individuals outside India under a contract with a person outside India. It helps, but it is narrow. It does not displace the fiduciary's responsibility and security safeguard duties under section 8(1) and 8(5), and it does nothing for the data of your own Indian employees, which an AI-driven HR or productivity tool will process in large volumes.
The IT Act and the Intermediary Rules. Section 85 of the IT Act can fasten liability on the persons in charge of a company's business when the company contravenes the Act. Separately, the amendment to the Intermediary Rules notified on 10 February 2026 and effective from 20 February 2026 brought “synthetically generated information”, meaning deepfakes and similar realistic audio-visual content, into the due diligence framework. It requires labelling and provenance metadata, and compresses takedown of flagged unlawful content to three hours. These duties fall on intermediaries, and most GCCs are not intermediaries. A centre that builds or operates a tool allowing users to generate realistic audio or video should still check, carefully, whether it is stepping into that definition.
Consumer protection. Where AI sits inside a product or service reaching Indian consumers, the product liability provisions of the Consumer Protection Act, 2019 can reach the manufacturer, the service provider and the seller. A biased or faulty output that causes loss is easily argued as a defect or a deficiency in service.
Contract, tort and criminal law. Negligence and breach of contract remain the workhorses of civil claims. Section 73 of the Indian Contract Act allows damages for loss naturally arising from breach. On the criminal side, the Bharatiya Nyaya Sanhita, 2023 already covers cheating, forgery and defamation, and Indian courts, the Delhi High Court in particular, have been willing to protect personality rights against deepfakes and unauthorised voice or image cloning.
Sector regulators. A large share of GCCs serve banking, financial services and insurance groups, which are among the most heavily regulated in any jurisdiction. The Reserve Bank of India's FREE-AI report of 2025 sets out what regulated entities can expect, including board-approved AI policies and risk-based AI audits. SEBI, for its part, has placed responsibility for data security, outputs and legal compliance on the regulated entity using an AI tool, whether the tool was built in-house or bought from a third party. The client remains answerable to its regulator, and so it will push that answerability down to the GCC. Expect to be asked to accept these requirements by contract, to agree to audit and incident-reporting commitments, and to map each AI system to its regulatory consequences. Other jurisdictions are likely to follow with similar guidance.
Intellectual property. Questions on training data, ownership of AI-assisted output and infringement are still being tested. In the interim stage of ANI Media v. OpenAI, the Delhi High Court prima facie found that OpenAI's use of ANI's works fell within the fair dealing exception in section 52(1)(a) of the Copyright Act, 1957. That is useful to know, but it was an interim finding on particular facts. It is not a general assurance that training or running an AI system on third-party content is lawful. The practical lesson for a GCC is to establish, before deployment, where the data came from and on what legal basis it is being used. The government has also been examining through a DPIIT committee how copyright law should treat AI training, so the position may move.
Director’s duties. Under section 166(3) of the Companies Act, 2013, a director must act with due and reasonable care, skill and diligence. Directors of an Indian GCC cannot assume that governance of AI is the parent's problem. If the Indian entity is the one operating the system, its board is expected to understand the risk and to show that it asked questions.
The GCC problem: developer, deployer or both?
The standard GCC structure is simple on paper. An Indian subsidiary serves the foreign parent or its affiliates under an intra-group services agreement. The parent owns the IP, sets the policy and carries the commercial risk. The agreement usually says as much.
The difficulty is that a contract between group companies binds only those companies. It does not bind the Data Protection Board, a sectoral regulator, a consumer forum or an employee whose application was rejected by a biased screening tool. As far as Indian regulators are concerned, the entity that is physically in India, employs the people and touches the data is the first door they will knock on. An indemnity from the parent is a right to be reimbursed later. It is not a shield.
There is a second layer. Output built in India frequently ends up in markets with their own AI rules. The EU AI Act, for instance, reaches systems whose output is used in the Union, and its obligations are being phased in, with the timing of some high-risk requirements under active discussion. Being located in India does not, by itself, take a centre outside such a law. A GCC building a system in India for an EU group company has to ask whether that system falls within the Act and, if so, which obligations attach to it as provider or deployer. The country where the system or its output is used therefore belongs in the assessment, next to its purpose, function and risk. Several US states have their own rules as well. The Indian centre will be asked, sooner or later, to produce documentation, testing records and evidence of human oversight for the parent's compliance file. A centre that cannot do so becomes a bottleneck, and in a dispute, a liability.
Cross-border indemnities, cost-sharing and risk allocation between group entities also have transfer pricing and FEMA dimensions. These should be examined with tax advisers before the paper is signed, and not after a claim has arrived.
What a prudent GCC should be doing now
There is no single template, but the following steps are, in my experience, where the real exposure is reduced.
- Build an AI inventory. List every model and AI tool in use or in development, what data it touches, who owns it and who it affects. You cannot govern what you have not counted.
- Move from a general AI policy to a system-by-system assessment. A policy on paper shows intent. An assessment shows diligence. Before each system is deployed, record its purpose and function, the degree of autonomy, the data used to build and run it, the chance of inaccurate or discriminatory outcomes, the Indian, sectoral and foreign laws that apply, who is responsible for what, and the safeguards required. Revisit the assessment whenever any of these factors changes materially, or when the GCC’s own role changes.
- Map roles system by system. For each system, record whether the Indian entity is developer, deployer, data fiduciary or processor. The same centre can be all four across different projects.
- Check the source of your data. Confirm where training and operating data comes from and the legal basis for using it, particularly for third-party content and for personal data of employees or customers.
- Rework the intra-group agreement. Cover liability allocation, indemnities, audit and documentation rights, IP ownership, and who responds to Indian regulators. Generic services templates written before the AI work began rarely do this.
- Start DPDP readiness well before May 2027. Data mapping, notices and consent flows, a breach response playbook that can meet the 72-hour report, and processor agreements with vendors and model providers.
- Put human oversight where decisions affect people. Hiring, credit, insurance, performance and customer eligibility are the obvious ones. Keep records of how a human can review and override the output.
- Frame an employee AI-use policy. Say clearly what may not be fed into public generative AI tools: client data, source code, personal data and privileged material. Back it up with training and technical controls.
- Tighten vendor and model-provider contracts. Look at IP indemnities, restrictions on use of your data for training, incident notification, security standards and limits of liability.
- Involve the board. Give the Indian board a periodic AI risk report, define an incident response route, and ask the insurance broker whether cyber and technology errors-and-omissions cover carries AI exclusions.
None of this is exotic. It is ordinary corporate governance applied to a new kind of system, and the centres that do it early will find the later regulation far easier to absorb.
What to watch next
Four developments deserve attention over the coming months. The first is the DPDP deadline in May 2027, which will turn the data protection regime from a paper obligation into an enforceable one. The second is the national GCC policy framework, reported to be in the final stages, which is meant to simplify setting up and operating centres and guide state policies, though not to offer subsidies or tax breaks. The third is the continuing work on a liability regime under the AI Governance Guidelines, including how safe harbour and apportionment of responsibility across the AI value chain will be addressed. The fourth is the courts, whose rulings on copyright, personality rights and negligence will shape the law faster than any statute.
Whether India eventually enacts a dedicated AI law is an open question. The present direction favours applying existing law with sector-specific guidance, and that is how GCCs should plan.
Conclusion
India’s global capability centres have moved from execution to ownership of technology, and with ownership comes accountability. The regulatory position today is a patchwork rather than a code, but it is a patchwork with sharp edges: data protection penalties running into hundreds of crores, new rules on synthetic content, sector regulators asking harder questions, and the ordinary law of contract, tort and company law available to anyone who is harmed.
The sensible course is to treat AI liability as a design question, not a litigation question. Decide who is responsible for what, write it down, test it, and keep the evidence. The goal should not be merely to show that an AI policy has been adopted. It should be to show that every system was assessed against the relevant factors before it went live. A GCC that can show its work will be in a far better position than one that is explaining, after the event, why it assumed someone else was in charge.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
