DEPA for AI Training: What MeitY's New Handbook Actually Changes

India's Ministry of Electronics and Information Technology has launched a DEPA for AI Training handbook, outlining how institutions could let AI developers learn from their data while retaining control over it. The immediate announcement is a framework for collaboration, not a new model or an open dataset anyone can download.

DEPA stands for Data Empowerment and Protection Architecture. The government's October 31 announcement describes a combination of contractual permissions, controlled computing and privacy safeguards, developed with support from iSPIRT Foundation. Data provenance is part of the design: participants should be able to trace where data came from, what permissions applied and how it was used.

For an AI startup, the interesting possibility is access to useful institutional data without requiring the institution to hand over unrestricted copies. The difficult part is making that access practical enough to use repeatedly.

What is new about the DEPA handbook?

The handbook is new; the underlying training architecture is not. DEPA's public technical documentation already described a training framework in 2023. Treating this announcement as the invention of confidential computing, or the opening of a national training-data marketplace, would overstate what has happened.

The new development is MeitY's launch of a handbook and its stated commitment to advancing this approach. The announcement does not identify a generally available service, publish dataset prices or provide an onboarding date for developers. It describes a handbook rather than announcing a new binding law.

Why consent for a service is different from permission to train

The existing DEPA documentation draws an important distinction between inference and training. In its inference cycle, a person consents to data sharing for a particular service. That permission does not automatically extend to training models or combining data for unrelated analytics.

Training also has different practical requirements. Useful labels may arrive long after a record was created, and a model may need records from several institutions. Simply removing obvious identifiers does not necessarily make those combinations safe, because other information can sometimes reveal who a record concerns.

That is why the training framework needs more than a consent checkbox. It needs rules governing both the permitted computation and the information allowed to leave it.

How a confidential clean room works

DEPA's public clean-room design uses hardware-isolated computing environments to process encrypted datasets. The proposed workflow checks signed contracts before accessing data, verifies the computing environment and releases outputs only when contractual constraints are met.

These technical specifications predate the new handbook. They help explain the architecture, but should not be confused with proof that every part is already operating nationally.

There is also a useful correction to the shorthand that data never moves. The published design allows a clean-room provider to download and cache encrypted datasets. The intended protection is against unauthorised access to readable data, not a promise that encrypted bytes always remain on the original institution's servers.

For a developer, that distinction affects deployment choices. Keeping data under an institution's control and keeping it physically in one location are different requirements.

What founders would need before building on DEPA

The contract specifications describe terms covering participants, datasets, duration, permitted usage and revocation. They can also include payment terms and privacy constraints. A dataset reference can carry information about its sources, preprocessing, risks and limitations.

A technically accessible dataset is not yet a usable training agreement. A founder still needs to understand what can be trained, which outputs can be exported, what the arrangement costs and what happens when permissions change. The presence of a secure environment does not answer those commercial and operational questions on its own.

The next meaningful milestone is a repeatable path from a developer's training request to an authorised job and an evaluated model. That is the point at which DEPA becomes something product teams can plan around, rather than an architecture they can only discuss.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help teams explain complex enterprise AI products clearly to technical buyers and decision-makers.

Book a 30-minute call.