A procurement manager at a Bengaluru GCC asked me last May a question that had been circulating in his legal team for weeks. His team was buying a generative-AI assistant from a US vendor. The vendor said "we are a developer, you are the deployer, our EULA shifts the accountability to you." His legal team said "we are only using the tool, we are not making any AI decisions ourselves, the developer should carry the accountability." Nobody was wrong. Everybody was reading the EU AI Act. Nobody was reading MeitY Sutra 5.
Under the EU AI Act, the deployer carries most of the obligation at the deployer-end of the supply chain. Under the MeitY model, accountability follows function. The developer answers for the choices he made in building the model. The deployer answers for the choices he made in using it. The data provider answers for the quality of the data he fed in. All three are accountable, in parallel, for their own functions. Nobody is "transferred" the accountability through a contract clause.
This is deliberately different from the EU model. India picked a function-based model because the Indian AI ecosystem is heavily procurement-dependent, with most deployers using models they did not train and could not fully audit. If the deployer carried the entire burden, deployment would stall. If the developer carried the entire burden through contract, deployer discipline would collapse. The function-based model forces discipline at every function and prevents either end of the chain from offloading.
What a developer is accountable for
The developer is the party that builds the model. The developer makes four kinds of choices for which he is accountable under MeitY Sutra 5 [L3-C1]. Architecture choices, including model family, size, training objective. Training-time choices, including data provenance, filtering, augmentation. Evaluation choices, including benchmark selection, red-teaming scope, bias testing method. And documentation choices, including model cards, system cards and datasheets for the training dataset.
Each of these choices is defensible on the record. The developer must be able to produce evidence that each choice was reasonable given the state of knowledge at the time it was made. "We used the default settings of the base model" is not a defence; "we evaluated three options and chose this one for these documented reasons" is.
For a procured model, the deployer must demand this documentation from the developer. If the developer refuses, the deployer must know that his own accountability under Sutra 5 does not thereby increase; the developer\'s own accountability is activated, and the deployer\'s obligation is to document that the vendor refused to meet basic documentation expectations.
What a deployer is accountable for
The deployer is the party that puts the model into live use for a specific purpose. The deployer makes five kinds of choices for which he is accountable. Use-case selection, including whether the model is appropriate for the task. Deployment-context choices, including which user population will interact with the model and under what conditions. Input-flow choices, including what data goes into the model at inference time and how it is processed. Output-handling choices, including how model outputs are communicated to users and whether human-in-the-loop review is applied. And monitoring choices, including drift detection, feedback loops and incident response.
The deployer is also the party that interfaces with Indian regulators. The DPO who signs a DPDP Section 10 attestation on algorithmic due diligence [L3-C2] sits on the deployer side. The SEBI compliance officer who reports under the AI Advisory sits on the deployer side. The RBI model risk owner under the Draft Model Risk Circular [L3-C3] sits on the deployer side.
For Aarti Capital Markets, the deployer function is clear. The organisation deploys three AI systems: a client-onboarding risk-scoring model, a real-time trade surveillance model and a portfolio-recommendation model. For each, Aarti Capital is the deployer. If any of the three is procured from a vendor, Aarti still carries deployer accountability under Sutra 5; the vendor carries developer accountability in parallel.
What a data provider is accountable for
The data provider is the party that supplies the data used to train, fine-tune or operate the AI system. The data provider makes three kinds of choices. Collection choices, including consent, provenance and categories collected. Preparation choices, including cleaning, labelling and augmentation. And release choices, including under what terms the data flows to the developer or deployer.
Under DPDP, the data provider overlaps with the Data Fiduciary role. If the data is personal data of Indian Data Principals, the data provider must comply with DPDP consent, purpose limitation and retention. For non-personal data, the obligations run through contract and IP law rather than DPDP. For public datasets drawn from government portals under AIKosh [L3-C4] or similar sources, the terms of the portal set the baseline.
The data provider role is where India\'s AI governance regime is still thin on operational detail. The MeitY Guidelines name the function but do not elaborate the obligations in depth. The gap will likely be closed in a future amendment or sectoral circular; for now, teach data-provider accountability as consent + provenance + purpose-fit, verified against DPDP where personal data is involved.
How to allocate accountability in a procurement
In practice, most Indian deployers will procure foundation models or tooling from a developer and provide their own data. The allocation is then clear. The developer is accountable for architecture, training, evaluation and documentation. The deployer is accountable for use case, deployment context, inputs, outputs and monitoring. The deployer is also the data provider for the fine-tuning or RAG data it supplies, and must separately satisfy data-provider accountability for that slice.
Where a vendor contract tries to transfer "all AI accountability" to the deployer through an indemnity, read carefully. Under Sutra 5, accountability for development choices cannot be shifted away from the developer; the developer remains answerable to Indian regulators for its own function. The indemnity may shift civil-law risk, but it does not shift regulatory accountability.
Five failure modes practitioners repeat
Reading Sutra 5 as "the deployer is accountable for everything". It is not. The developer and the data provider are also accountable, in parallel.
Accepting a vendor EULA that purports to shift all AI accountability. Vendor indemnities do not override Sutra 5. The vendor remains accountable for its own function.
Treating "we procured the model" as a defence. Deployer accountability survives procurement.
Ignoring the data-provider function in a procurement. Even if the developer and the deployer are two different parties, the data-provider function may sit with a third. All three roles must be identified and separately held accountable.
Failing to document the allocation. The allocation of accountability across developer, deployer and data provider must sit in the AI inventory for every system. Without this allocation, regulatory interface becomes a reconstruction exercise under pressure.
Your artifact from Lesson 3
Open the capstone workbook and complete the Function Allocation Worksheet for each of your organisation\'s AI systems. For Aarti Capital Markets, pre-populated. For your own organisation, build from a blank. For each AI system, name the developer, the deployer, and the data provider; summarise the specific choices each function made that are accountable under Sutra 5. Save as Artifact 3. Walk the worksheet past Legal in Week 1.