The Digital Personal Data Protection Act, 2023 is built on a two-part structure. One party decides why and how personal data is processed. That party is the Data Fiduciary, and it carries the obligations and the liability. Another party processes the data on the Fiduciary's behalf and under its instructions. That party is the Data Processor, and it carries very little directly, answering to the Fiduciary through a contract. This structure is drawn, with changes, from the GDPR's controller and processor model. For ordinary outsourcing, it works. A company decides to host customer records in the cloud, the cloud vendor stores them, the company remains the Fiduciary, and the vendor is the Processor. The Rules set out this exact example.

A machine learning pipeline does not work this way. It involves a series of parties, including a data aggregator, a foundation-model developer, a fine-tuning vendor, a model-hosting platform, an enterprise deploying the model, and an annotation contractor. Each of these parties makes real decisions about personal data, and none of them fits cleanly into either category. The DPDP Act gives us two roles and one contract between them. A typical pipeline involves five or six parties whose decisions overlap. This article sets out where the two-part structure breaks down, why the common answers are wrong, and what practitioners should do before the substantive provisions take effect.

What the statute actually says

Under Section 2(i), a Data Fiduciary is any person who, alone or together with other persons, determines the purpose and means of processing personal data. Under Section 2(k), a Data Processor is a person who processes personal data on behalf of a Data Fiduciary. The Act places almost all substantive obligations on the Fiduciary: lawful basis and consent, notice, purpose limitation, security safeguards, breach notification, erasure, grievance redressal, and responding to Data Principal rights requests. The Processor's position is thin. It processes under a contract with the Fiduciary, and Section 8(2) requires the Fiduciary to engage Processors only under a valid contract.

Two points matter for what follows. First, India's statute leaves out the GDPR's detailed Article 28 obligations on processors and its Article 26 concept of joint controllership. There is no category of "joint Data Fiduciary" in the DPDP Act. The Act recognises only Fiduciaries and Processors, plus the separately designated Significant Data Fiduciary. Second, the words "together with other persons" in Section 2(i) are important. They allow more than one person to jointly determine purpose and means. The Act does not then create a separate regime to govern that situation. It simply treats each such person as a Data Fiduciary. This drafting choice is both the source of the problem and its answer.

The timeline adds urgency. MeitY notified the DPDP Rules, 2025 on 13 November 2025. The main operational obligations, including notice, security safeguards, breach notification, erasure, Significant Data Fiduciary duties, and the rights-management provisions, take effect eighteen months later, on 13 May 2027. Until then, the IT Act regime continues to apply. The period between now and May 2027 is the time for AI deployers to resolve their role classifications, because once the obligations apply, an incorrect classification has real consequences.

Where the structure breaks down: four cases

Case 1: Training the foundation model

Consider a foundation-model developer that builds a training corpus containing personal data such as names, biographical details, images, and posts, gathered or licensed from many sources. Who is the Fiduciary for this processing?

The common view is that the developer is a Processor, because it is building a tool that others will use. This is incorrect. The developer alone decides the purpose, which is building a general-purpose model, and the means, which include the architecture, the data selection, and the training objectives. No client instructed it to train on any particular person's data. Under Section 2(i), the developer determines purpose and means, so it is a Data Fiduciary in its own right for the training activity. It is not a Processor for anyone.

This is a difficult result, because the developer usually has no relationship with the Data Principals whose personal data is in the corpus, no way to obtain their consent, and often no practical way to identify whose data it holds once the corpus is processed and the model trained. But this difficulty does not change the legal position. The argument that the developer is only infrastructure, and that the customer is the controller, does not hold where the developer is making the central decisions about a corpus of personal data. If the developer claims to be a Processor, it must identify whose instructions it was following when it chose its training data. There were none. It chose for itself.

Case 2: The fine-tuning vendor and the enterprise client

Now consider a step further down. An enterprise wants a customer-service model fine-tuned on its own support transcripts, which contain customer personal data. It engages a vendor to do the fine-tuning. Here the position changes, but only in part.

For the fine-tuning of the enterprise's transcripts, the enterprise determines the purpose, which is a support tool for its customers, and the broad means, and the vendor processes on its behalf. For this part, the vendor is a Processor. But the vendor often makes its own decisions as well: which base model to use, what data cleaning and augmentation to apply, whether to keep the fine-tuning data to improve its own service, and whether to use the interaction logs to train future models it will sell to other clients. To the extent any of these decisions serves the vendor's own purposes rather than the enterprise's instructions, the vendor becomes a Fiduciary for that decision.

This is the key point that practitioners often miss. The role is not assigned to an entity as a whole. It is assigned to each processing activity. The same vendor can be a Processor for the contracted fine-tuning and a Fiduciary for its separate use of the same data to improve its own product. The DPDP Act does not treat a person as a Processor in some fixed, overall sense. Section 2(k) ties the role to processing on behalf of a Fiduciary. When the vendor processes for its own purpose, it is no longer acting on behalf of anyone, and the Processor classification no longer protects it for that activity. A party labelled a Processor that trains on client data for its own purposes is, for that activity, a Fiduciary.

Case 3: Inference, logging, and the deployed model

A model in production generates logs, including prompts, outputs, the personal data of the users interacting with it, and often personal data about third parties mentioned in prompts. The deploying enterprise is a Fiduciary for its use of the model to serve its users. The model-hosting platform, which is the API provider sitting between the enterprise and the model, is in a less clear position. If it only runs inference on the enterprise's inputs and returns outputs, it is a Processor. If it stores and retains those interactions to monitor abuse, improve the service, or train future models, it has crossed into Fiduciary territory for that activity, as in Case 2.

There is a further issue that receives little attention. Model outputs can themselves be personal data, including inaccurate personal data, such as a false statement about a named individual. Section 2(t) defines personal data as any data about an identifiable individual. Nothing in the definition requires that the data be accurate. When a model generates a false but identifying statement about a person, the party that determined the purpose and means of generating it is a Fiduciary processing that person's personal data, and the Data Principal's right to correction is, on the text, engaged. Which party handles that correction request, whether the deployer, the hosting platform, or the original model developer, is unresolved, and the answer depends on whose decision produced the output.

Case 4: The annotation and RLHF supply chain

Human-feedback and labelling vendors sit at the bottom of the chain and are the most commonly misclassified. An annotation contractor that handles data sent to it by a model developer, strictly under instruction, is a clear Processor. But annotation work often involves the contractor making its own judgement calls, sub-contracting to a labour platform, and retaining data, and the labour platform below it processes the same personal data again. Each tier needs its own classification. A Section 8(2) contract at the top of the chain does not automatically pass obligations down it. The Fiduciary's duty to bind its Processor by contract is only as effective as the Processor's duty to bind its own sub-processors, and the DPDP Act says little about multi-tier sub-processing compared with the GDPR.

Why the common answers fail

Three quick answers circulate in the market, and each is flawed.

The first is that the deployer is always the Fiduciary and everyone upstream is a Processor. This fails as soon as any upstream party processes for its own purposes, which, as Cases 1 to 3 show, is normal in the AI supply chain rather than exceptional. A foundation-model developer training on a corpus it selected is not anyone's Processor.

The second is that whoever holds the contract with the Data Principal is the Fiduciary, and that settles the matter. Contractual proximity to the Data Principal is evidence of Fiduciary status, but it is not the test. The test in Section 2(i) is the determination of purpose and means. A party can be a Fiduciary with no contract and no relationship with the Data Principal at all, and the training developer is the clearest example. At the same time, holding the customer relationship does not relieve a party of Fiduciary obligations for the processing it controls.

The third, and most risky, is that the parties will simply designate everyone a Processor by contract and move liability up or down the chain. Role under the DPDP Act is a question of fact, decided by who actually determines purpose and means, not a question of labels the parties agree among themselves. A party cannot contract out of being a Fiduciary if its conduct shows it determining purpose and means. A contract that calls a party a Processor while that party trains on the data for its own products will be assessed on the conduct, not on the contract's wording. The Data Protection Board, deciding a breach, will look at who made the decisions, and a self-serving label carries little weight against the actual data flows.

The "together with other persons" answer

The answer the Act provides is not a joint-controller regime, because India did not enact one. It is the under-used language of Section 2(i): a person who determines purpose and means together with other persons is a Fiduciary. Read properly, the Act's response to the multi-party pipeline is not to identify a single Fiduciary and treat everyone else as a Processor. It is that each party that determines purpose and means for any part of the processing is, for that part, a full Data Fiduciary, carrying the full Fiduciary obligations for what it controls.

This is more demanding than the GDPR's joint-controllership model, not less. The GDPR allows joint controllers to allocate responsibilities by arrangement and to give the data subject a single point of contact. The DPDP Act provides no such allocation mechanism and no joint category. Each Fiduciary is independently liable for its own processing. The fine-tuning vendor that trains on client data is independently liable as a Fiduciary for that training. The hosting platform that logs interactions to improve its model is independently liable as a Fiduciary for that logging. The deployer is independently liable for its user-facing processing. There is no shared protection.

For Significant Data Fiduciaries, the requirements are higher. Rule 13 requires SDFs to conduct an annual Data Protection Impact Assessment and an independent audit, and, directly relevant here, to exercise due diligence to verify that the algorithmic software they use for processing personal data does not pose a risk to the rights of Data Principals. An AI deployer designated as an SDF cannot treat its models as closed third-party tools. The duty to examine the algorithmic systems is express. The drafters anticipated algorithmic processing and placed the diligence burden on the deploying Fiduciary.

A framework for classification

The workable approach is to stop labelling entities as a whole and instead classify at the level of each processing activity. For every distinct processing step in the pipeline, ask three questions in order.

First, whose purpose does this step serve? If it serves only the instructing party's purpose, the actor is a possible Processor for that step. If it serves the actor's own purpose, such as model improvement, product development, abuse monitoring beyond the client's instruction, or resale, the actor is a Fiduciary for that step, whatever the contract calls it.

Second, who chose the means? The determination of means, not only purpose, triggers Fiduciary status. An actor that is given a purpose but exercises independent, non-trivial discretion over the means, such as architecture, data selection, or retention, moves toward Fiduciary status even where the purpose was supplied.

Third, is the data being repurposed? Repurposing is the most common trigger that converts a nominal Processor into a Fiduciary in AI pipelines. The fine-tuning vendor retaining data to improve its own service, the hosting platform logging data to train future models, and the annotation vendor keeping a copy are each a repurposing that creates an independent Fiduciary obligation.

After mapping each activity, the contract should do three things. It should state each party's role for each activity rather than overall, recognising that one counterparty may be both Processor and Fiduciary across different steps. It should expressly prohibit the Processor from repurposing data for its own training or product development unless that processing is separately documented and the repurposing party accepts Fiduciary obligations for it. And it should address multi-tier sub-processing expressly, because the DPDP Act will not imply the cascade, and the Section 8(2) contract obligation has to be passed down by drafting, tier by tier.

What remains unresolved

Three questions the Act does not answer clearly, which practitioners should flag to clients rather than gloss over.

The first is the trained model itself. Once a foundation model has been trained on personal data, do the weights contain personal data, so that the model is within scope and an erasure request reaches into it? The Act is silent, the technical position on memorisation and extractability is contested, and there is no Indian guidance. The cautious position is that extractable training data remains personal data and the training Fiduciary's obligations follow it. The practical position is that erasure from model weights is often not feasible today. This tension is unresolved in every jurisdiction, but the DPDP Act's purpose-limitation and erasure provisions give it more force than a soft-law regime would.

The second is the correction of model outputs. As noted in Case 3, a false identifying statement is, on the text, inaccurate personal data subject to the correction right. No mechanism exists for correcting a model's tendency to produce a given output, as distinct from correcting a stored record. How the Board will treat this is unknown.

The third is the attribution of breach liability across the chain. When personal data leaks from a pipeline involving five parties, the Act's per-activity Fiduciary logic means liability attaches to whichever Fiduciary controlled the activity from which the leak occurred. But tracing a leak to a specific activity in a complex pipeline is an evidentiary problem the statute does not help with. The Board is likely to examine who controlled the failed safeguard, which makes documented, activity-level role mapping not merely good practice but the main evidence a party will have to show it was not the responsible Fiduciary.

Conclusion

The DPDP Act asks one question, which is who determines purpose and means, and an AI pipeline answers it differently at each step. The error to avoid is treating the role as a fixed attribute of an entity, settled once in a contract. It is not. It is a per-activity question of fact, and in a machine learning pipeline the same party will often be a Processor for what it does on instruction and a Fiduciary for what it does for itself. The "together with other persons" language confirms that several full Fiduciaries can exist across a pipeline, each independently liable, with no joint-controller category to reduce the exposure. The parties most exposed when enforcement begins will be those that classified themselves once, overall, in a contract, and then found at the Board that conduct, not labels, decides who the Fiduciary is.