When the Service Provider Is an Algorithm: What Chapter VII's AI Problem Means for Indian Captives

A captive Indian entity, such as a GCC, a KPO, or a testing centre like the one at the heart of the Honda R&D India ruling this month, performs a defined function for its overseas parent. The transfer pricing analysis asks three questions: whether a service was rendered, whether the recipient derived a benefit, and what cost-plus markup reflects an arm's length charge for that service.

This is the architecture of Chapter VII of the OECD Transfer Pricing Guidelines, and it underlies most of India's Safe Harbour Rules, most APAs for ITES/BPO structures, and a large share of the ITAT docket. It works cleanly as long as the item being delivered is recognisably a service: bounded, routine, and separable from any underlying intangible.

In June 2026, the OECD's Working Party 6 released a discussion draft proposing a substantive rewrite of Chapter VII, including a new accurate-delineation analysis, an expanded benefit test, a sharper shareholder/stewardship distinction, and new guidance on the boundary between a service and an intangible. Comments closed on 22 July, and the OECD published the full set of responses on 24 August: more than one hundred submissions from businesses, industry bodies, and advisory firms.

A recurring theme across those submissions was a call for clearer distinctions between intra-group services and intangible transfers, particularly for AI-enabled and digital service models. This suggests that practitioners find the existing framework difficult to apply to AI-delivered outputs, a chapter otherwise treated as settled doctrine since the 1990s.

The captive/GCC model is central to India's transfer pricing practice, not a peripheral segment of it. Thousands of Indian entities are remunerated on a cost-plus basis for the kind of routine, human-performed functions that Chapter VII was built to price: testing, market research, back-office processing, and KPO analytics. Many of these entities are, in 2026, incorporating agentic AI into the delivery of these functions, which changes what sits inside the service line item rather than replacing it.

If a GCC's cost-plus-remunerated data analytics service is increasingly produced by an AI agent trained on group data, proprietary models, or a parent's algorithms, the question is whether the Indian entity is still delivering a 'service' in the Chapter VII sense, or something closer to an output derived from an intangible it does not own. That distinction could imply a different pricing method, a different DEMPE analysis, and possibly disqualification from the Safe Harbour margins (now consolidated into the unified 15.5% IT Services band) that assume a routine, low-risk service function.

Two other developments this week bear on the same issue. Turkey's Tax Inspection Board launched an AI system in August built specifically to flag transfer pricing risk in related-party transactions, which suggests some revenue authorities are building AI capability aimed at this kind of transaction. On the advisory side, Nexdigm's alliance with the AI-native TP platform infer360 shows Indian mid-tier firms building AI-TP capability of their own, partly in anticipation of this characterisation issue becoming a live audit question rather than an academic one.

Whether the CBDT should clarify, before the 2027 filing season, whether AI-enabled service delivery inside a GCC/ITES structure remains within the Safe Harbour and cost-plus framework, or whether it needs a separate carve-out, is a question worth raising now. The Chapter VII revision will not be finalised until after the November 2026 Paris consultation, so India has a window to shape its own domestic position rather than import whatever the OECD eventually adopts.

Given how much of India's outbound service economy sits on this fault line, practitioners advising GCC and ITES clients would do well to flag the characterisation risk in current TP documentation, ahead of any assessment order that forces the issue.

DEMPE's Human-Centric Assumptions Face a Test as AI Performs Development and Enhancement Functions

The DEMPE framework determines which group entity is entitled to the return on an intangible by examining which entity performed the Development, Enhancement, Maintenance, Protection and Exploitation functions, made the key decisions, bore the risk, and had the people and capability to control what was happening. The analytical apparatus, functional interviews, organisation charts, decision logs, and the contemporaneous email trail showing an engineer approving a design change, rests on an assumption that a human being performed the function. A recent piece of Australian tax commentary notes that this assumption is becoming harder to sustain. The Australian Taxation Office's guidance on intangibles migration, PCG 2024/1, sets out the evidence it expects a multinational to produce when documenting its DEMPE functions. That evidence regime, the commentary observes, presumes human decision-making and physical performance. It does not address what happens when the decision is made by a model.

PCG 2024/1 has been in force since January 2024. The law itself has not changed; what has changed is a growing recognition that the gap between the rule and the operating reality is becoming practically significant. AI systems are themselves valuable intangible assets under ordinary transfer pricing principles: the algorithms, the training data, and the fine-tuned models sitting inside a captive centre's codebase. A separate issue arises one level up. When an AI system performs the actual development and enhancement work, writing and testing code, running design iterations, flagging defects, optimising a process, the question is who counts as the DEMPE contributor. It could be the engineers who built and supervise the model, the entity hosting the compute, the parent that trained the underlying model elsewhere, or no clearly identifiable party if performance becomes diffuse. The commentary frames this as a mismatch between a human-centric international tax architecture and an operating reality that is automating functions the architecture was built to track.

The implications are likely to be more pressing for India than for Australia. India's transfer pricing landscape relies heavily on captive centres and GCCs performing the kind of granular, iterative technical work, software development, testing, engineering support, and increasingly research, that is most amenable to AI augmentation and, potentially, AI substitution. For two decades, the Indian TP dispute over these centres has centred on characterisation: whether a centre is a routine cost-plus service provider or a genuine value-creating R&D contributor, and which comparables support either position. That analysis has assumed the underlying question, who did the work, could be answered by examining headcount, job descriptions, and reporting lines. If an increasing share of the development and enhancement work inside these centres is performed by AI tools that the centre operates but did not necessarily build, the functional analysis becomes harder to write convincingly in either direction. A TPO could argue that the Indian entity performs less genuine DEMPE work than its cost base suggests, because the model does the underlying processing. A taxpayer could equally argue that the Indian entity deserves more than a routine cost-plus return, because supervising, curating, and directing an AI system that performs high-value technical work is itself a sophisticated function that current benchmarking studies are not equipped to price.

The functional analysis may need a distinct category, one that asks not only who performed the function but who exercised meaningful control and judgment over the system performing it. Whether existing documentation templates, functional interviews, organisation charts, decision logs, can capture that distinction without substantial revision is unclear.

A related institutional question follows. If DEMPE evidentiary standards assume human decision-makers, and the CBDT's own scrutiny and risk-selection processes are moving toward AI-driven flagging at the same time, the tax administration sits on both sides of the same conceptual gap: applying a human-centric framework through tools that are themselves not human-centric. For practitioners, the practical implication is to begin documenting, now, the extent of human supervision, curation, and judgment exercised over AI tools used in development and enhancement work inside Indian captive centres, since existing DEMPE templates may not capture that distinction without adaptation.

AI-Performed DEMPE Functions and the Limits of Transfer Pricing's Intangibles Framework

The OECD's DEMPE framework was designed to stop groups from parking valuable intangibles in a low-tax entity that holds legal title but performs none of the underlying work. The test traces the relevant functions, development, enhancement, maintenance, protection and exploitation, back to the people who exercise judgment over them: who decided to pursue a research direction, who approved a patent filing, who manages commercialisation risk. For two decades this test has worked reasonably well because those functions were, in fact, performed by identifiable people.

That assumption is being tested where AI systems perform DEMPE functions. Commentary in Australia has raised this issue in relation to the ATO's Practical Compliance Guideline 2024/1 on intangibles migration, which requires multinationals to self-assess and disclose where DEMPE activities for offshore-held intangibles actually occur, using a risk-zone framework that determines how closely the ATO will scrutinise a taxpayer's position. The commentary notes that the PCG's evidence requirements assume human decision-makers, leaving a gap where AI systems (training models, tuning algorithms, monitoring outputs, iterating on protection measures) perform these functions without a person who can be identified as the locus of judgment.

A companion piece extends this analysis to M&A due diligence. It argues that AI systems, including the algorithms, training data and infrastructure, are themselves valuable intangibles under transfer pricing principles, and that a target lacking DEMPE documentation for its AI footprint may carry dormant tax risk that an acquirer inherits on completion.

This is not confined to Australia, and it is not a distant issue for India. India's global capability centre sector has moved well beyond routine coding and support work. Commentary directed at India's GCC market has told clients that where a captive centre designs a core AI algorithm used across the global group, arm's-length pricing cannot be justified by comparing developer hourly rates; the pricing must reflect that creative, value-creating contribution. That is a DEMPE argument, framed in language close to the ATO's, applied to the kind of AI-first GCC that has become common in Bengaluru, Hyderabad and Pune over the last two years.

The timing adds to the difficulty. The Finance Act 2026 safe-harbour rationalisation consolidated software, ITeS, KPO and contract R&D into a single IT-services category, set a flat 15.5% margin, and raised the eligible transaction threshold to ₹2,000 crore. The change was presented as compliance simplification for routine captive units. A captive unit whose engineers are training or fine-tuning a model whose commercial exploitation happens offshore may not be 'routine' in the DEMPE sense, even if it fits comfortably within the new safe-harbour band. A group that elects into the safe harbour for five years on the strength of a routine cost-plus characterisation may be locking in a margin that a DEMPE-consistent functional analysis would not support. That exposure may surface only when the safe-harbour election lapses and a TPO examines what the unit was actually doing.

This raises a harder question about the DEMPE test itself. DEMPE and the 'significant people functions' concept exist to identify who exercises judgment over value creation. Where that judgment is distributed across a model's training run, a human supervisor who approves outputs in bulk, and an infrastructure team in a different jurisdiction, none of these resembles the risk-bearing decision-maker the framework was written for. Tribunals and tax authorities have decades of practice tracing DEMPE to people, but little developed practice for tracing it to a system.

Whether CBDT, the ITAT or the OECD develops a workable answer first, and whether India follows the ATO's disclosure-and-self-assessment approach or adopts something more prescriptive, remains unclear. For now, practitioners advising GCCs and AI-heavy captives should treat DEMPE documentation for AI-performed functions as a present compliance issue, and should examine whether a safe-harbour election understates the functional profile of a unit that is doing more than routine service delivery.