DEPA for AI Training: why anonymization comes first
At the end of October 2026, India's Ministry of Electronics and Information Technology (MeitY) published DEPA for AI Training, a proposed national framework for sharing sensitive data to train AI models. The handbook is marked as a draft for discussion and covers secure data environments, differential privacy, electronic contracts, and a governance model run by the ecosystem itself.
Read it closely and one rule stands out for every organization that holds valuable data. Before anything is registered, shared, or trained on, the data provider anonymizes it. The framework's data sharing procedure (section 2.4.1) puts it plainly: "Personal and sensitive data shall not be shared in raw form."
That first step, before anything is shared, is where Maya works every day. This article walks through what the framework says, why it starts at the source, and what that means for data owners in India and Europe.
What DEPA for AI Training sets out to fix
The framework calls the problem the "data deadlock". Hospitals, banks, insurers, and public agencies hold the data that AI models need. That data sits behind institutional and regulatory walls, and each holder has good reasons to keep it there: privacy risk under India's Digital Personal Data Protection (DPDP) Act 2023, the fear of exposing business secrets, no trusted procedure for sharing, and costs that land on the data owner while the benefits go to someone else.
India already has a consent layer for individual data. DEPA Inference, run through the Account Aggregator system, lets a person share their bank statements with a lender for a single loan decision. Training is a different job. A model learns from millions of records at once, and asking each person for consent at that scale isn't practical. DEPA for AI Training adds the missing layer for that aggregate use.
It defines clear roles. Training Data Providers (TDPs) such as hospitals, banks, and pharmaceutical companies prepare and contribute datasets. Training Data Consumers (TDCs), from startups to research institutions, train models. Data Collectives pool data within a sector. A secure data environment hosts the training, differential privacy protects the outputs, and machine-readable contracts enforce purpose limits. Finance and healthcare are named as the first pilot sectors.
Anonymization happens before anything moves
The workflow in the framework has five steps, and the first one belongs to the data owner. In Step 1, the TDP registers a dataset. Before that happens, the dataset is anonymized and encrypted to remove personally identifiable information. Only then does it get metadata, a cryptographic tag, and a listing on a data exchange platform.
The framework describes two operating options. In the first, the data provider anonymizes its own data and hands over anonymized bulk data. In the second, the provider sends raw data into the exchange platform's secure environment, where the platform handles anonymization and encryption as a service. Both options need an anonymization engine. The only question is who runs it and where.
The framework also uses a second term, and the two are easy to mix up. Anonymization is irreversible: nobody, the data owner included, can link a record back to a person. Pseudonymization replaces identifiers with substitutes, and whoever holds the key or mapping can reverse it. For AI training, anonymization is usually the right choice, because a model learns from patterns and nobody needs to know who a record belongs to.
Some use cases do need a way back. A hospital may want to add follow-up data to records it contributed earlier, or act on a patient's request to correct or withdraw data. For those cases, DEPA's data sharing procedure calls for "de-identification with pseudonymized keys held by the originating agency". The keys stay with the data owner, and nobody downstream can reverse the pseudonyms.
Why removing names isn't enough
The framework is blunt about traditional anonymization (section 2.3.1). Stripping direct identifiers such as names, addresses, and ID numbers gives a "false sense of security". Its own example: a date of birth, a pincode, and a gender, each harmless on their own, can combine into a fingerprint that identifies one person. Link two or three such datasets and the risk grows quickly.
The opposite failure is just as real. Push generalization and noise too far and the data loses the patterns a model needs to learn. The framework names this trade-off directly: anonymize aggressively and lose utility, preserve utility and risk re-identification.
DEPA's answer is to stack protections. Anonymization at the source protects the input. The secure data environment keeps raw data away from the model builder. Differential privacy, with a governed privacy budget, protects what the trained model can reveal. Each layer covers a different risk, and none of them replaces the first step.
For the source layer, anonymization has to do three things at once. It has to replace direct identifiers. It has to handle quasi-identifiers such as birth dates and locations with care. And it has to keep the data consistent, so the same patient, customer, or policy holder gets the same replacement values in every table and every system. Without that consistency, a model can't learn from a patient's full treatment history, because the history falls apart into unconnected rows.
The hard part sits in the source systems
The framework is candid about one more obstacle. In its financial services section, it points to recent action by the Reserve Bank of India against major banks over IT deficiencies, and notes that many incumbents run legacy systems that can't support a modern secure data environment.
That matches what we see in enterprise landscapes. The data worth training on doesn't sit in one clean table. It sits in ERP systems such as SAP S/4HANA, in core banking and policy systems, in hospital information systems, and in the spreadsheets and PDFs that move between them. A patient record touches admission, billing, pharmacy, and lab systems. A policy holder appears in underwriting, claims, and finance.
The framework also raises a risk beyond personal data. Business datasets carry competitively sensitive information: customer lists, transaction patterns, supplier relationships. A pharma company or an insurer that joins a data collective needs to protect those too before data leaves its walls.
Picture a hospital group and a pharmaceutical company that want to train a model on treatment outcomes under a DEPA-style arrangement. The hospital is the TDP. Its first job is to produce a dataset where every patient is anonymized consistently across clinical and billing data, dates and locations can't be used as a fingerprint, the raw data never leaves the hospital, and the result still reflects real clinical patterns. Everything after that, from the exchange platform to the differentially private training run, depends on getting this step right.
Where Maya fits
Maya builds privacy-enhancing technology for this first step: anonymization inside the data owner's own infrastructure, before any data moves.
AppSafeā¢ anonymizes data in live applications and databases, including SAP S/4HANA and non-SAP systems. It replaces names, birth dates, and other identifiers with realistic values, for example a different birth date in the same year, so the data still behaves like real data in analysis and training. The same individual gets the same replacement values across systems, so relationships between tables and applications stay intact. Where a use case needs records to be linked back, AppSafeā¢ pseudonymizes instead, and the mapping stays with the data owner, the model DEPA's data sharing procedure describes. AppSafeā¢ runs as containers inside the customer's environment and needs no internet connection while operating.
FileSafeā¢ covers the documents that sit alongside structured data: Excel files, PDFs, and images. AISafeā¢ protects sensitive data in AI pipelines. It removes personal data before content reaches a language model or a training job, and where a workflow needs results mapped back to the real person, it pseudonymizes and re-identifies under the data owner's control.
Maya works alongside a secure data environment and differential privacy. It sits in front of them, at the data provider, where DEPA puts the responsibility. In DEPA's second option, the same capability can run as the anonymization service inside an exchange platform.
A hospital in Norway has run Maya on real patient data for three years. Patient records are anonymized inside the hospital's own environment, and the result feeds its test systems, employee onboarding, and staff training. Nobody outside the hospital, and nobody using those environments, works with real patient identities.
Why this matters beyond India
DEPA for AI Training states that it aligns with India's DPDP Act, the EU's General Data Protection Regulation (GDPR), and the EU AI Act. For European data owners, the core rule is familiar. Under GDPR, pseudonymized data that can be linked back with additional information still counts as personal data, while anonymous data falls outside the regulation (Recital 26). That's one more reason to anonymize wherever the use case allows it, and to keep the keys at the source where it doesn't.
What DEPA adds is a written order of operations for AI training: anonymize at the source, train in a protected environment, protect the outputs, and enforce the purpose by contract. Organizations in Europe that plan to pool data for AI, in pharma consortia, insurance groups, or health data projects, can use that order as a checklist today.
The framework is a living document, and MeitY invites recommendations from industry and academia. We'll follow how the pilots in finance and healthcare develop.
If you hold data that others want to train on, start with the first step: find where your sensitive data lives, and make sure only anonymized data leaves your systems, consistent across every application. Want to see how this works on your own SAP or core systems? Book a demo.
Comments