MeitY’s DEPA handbook moves the AI-training question from access to control

Collaboration need not begin with copying a dataset

The institutional problem behind the newly reported DEPA handbook is larger than finding more training data. Two organizations can want to collaborate while retaining control of the information they hold. Permission to undertake a task, control over computation and an account of what occurred are related requirements, but none is a substitute for the others.

YourStory’s October 31 report says an official release that Saturday announced the Ministry of Electronics and Information Technology’s handbook. It reports that IT Secretary S Krishnan unveiled it at a Bengaluru roundtable, with development supported by the iSPIRT Foundation. Inc42’s separate report describes a proposed techno-legal architecture for collaborative AI training without directly transferring the underlying datasets.

This article relies on those two reports rather than a direct read of the handbook. It examines the architecture as reported, not its exact requirements or legal effect. The event is introduction of a handbook. It is not evidence of nationwide deployment, a new mandatory rule or proven elimination of privacy risks.

The agreement belongs inside the technical design

The reported approach combines contractual permission, controlled computing environments and privacy safeguards. Treating the agreement as part of the design is significant: a technical system needs to know which work is authorized, while an agreement needs a way to connect that authorization to the work actually performed. Separating them too completely would leave a gap between a permission document and a computation.

This does not mean a contract alone can guarantee protected computation. It specifies authority, whereas an environment and its safeguards constrain activity. Each needs to be evaluated in its own terms. A permitted training purpose and an effective technical control are different propositions, even when a proposed architecture links them.

Inc42 describes proposed independent checks covering bias, fairness, security, safety and explainability. The proposed existence of those checks is not evidence that a model has passed. A meaningful implementation assessment would need to identify the task and the test conditions. The reports do not provide results that let this newsroom measure the safeguards’ effectiveness.

YourStory also reports a provenance component tracing origins, permissions and use through training. This introduces another relationship: the record of the data and its authority must stay connected to the activity. Knowing that information was available at some point is not the same as establishing which use was allowed or which computation relied on it.

Keeping control is more than choosing where the model runs

YourStory attributes to Principal Scientific Adviser Ajay Kumar Sood the explanation that the model travels to the data rather than the reverse. The phrase is useful for understanding the intended direction of computation. It should not be expanded into a claim that trained models or outputs can never reveal sensitive information. No such guarantee is established by the two reports. The report also presents cross-border collaboration as an intended possibility; it does not document a completed international data-sharing arrangement or validate one jurisdiction’s requirements against another’s.

For founders seeking institutional training collaborations, the architectural interest is that authorization, computation and records are being discussed together. The product work would not stop at arranging access to a file. A team would need to understand the allowed purpose, the participating organizations and the treatment of outputs within its particular arrangement. Those are evaluation questions, not features Foundra has tested in an implementation.

The handbook’s reported framing also makes the administrative layer harder to dismiss as a document added after the technical work. Permissions and traceability influence what collaboration means. They help define who can do which work and what can later be explained about it. That is an analytical consequence of the proposed structure, not a conclusion about any individual participant’s compliance.

DEPA’s training handbook is therefore best examined as a design for coordinated authority and computation. Its potential interest lies in that coordination. Its reported publication does not settle whether every implementation will perform effectively, and the article makes no legal-compliance or privacy-performance claim. It preserves the proposal’s three connected concerns without turning a conceptual architecture into an untested operational guarantee.