DEPA für KI-Training: Erst anonymisieren, dann trainieren
Das Wichtigste in Kürze
DEPA für KI-Training (offiziell „DEPA for AI Training“) ist ein Rahmenwerk, das das indische Ministerium für Elektronik und Informationstechnologie (MeitY) im Oktober 2026 als Diskussionsentwurf veröffentlicht hat. Es regelt, wie sensible Daten für das Training von KI-Modellen geteilt werden können.
Der erste Schritt liegt beim Datenanbieter: Er anonymisiert und verschlüsselt seine Daten, bevor sie registriert oder geteilt werden.
Müssen Datensätze später wieder einer Person zugeordnet werden, sieht DEPA eine Pseudonymisierung vor. Die Schlüssel bleiben dabei beim Dateneigentümer.
Sichere Datenumgebungen und Differential Privacy schützen anschließend das Training und die Ergebnisse des Modells. Sie bauen auf der Anonymisierung an der Quelle auf und machen sie nicht überflüssig.
Ende Oktober 2026 hat das indische Ministerium für Elektronik und Informationstechnologie (MeitY) DEPA für KI-Training vorgestellt: den Vorschlag für ein nationales Rahmenwerk, nach dem sensible Daten für das Training von KI-Modellen geteilt werden können. Das Handbuch ist ausdrücklich ein Diskussionsentwurf. Es beschreibt sichere Datenumgebungen, Differential Privacy, elektronische Verträge und ein Governance-Modell, das die Beteiligten selbst tragen.
Beim genauen Lesen fällt eine Regel auf, die jede Organisation mit wertvollen Daten betrifft: Bevor Daten registriert, geteilt oder für das Training genutzt werden, anonymisiert sie der Datenanbieter. Im Verfahren zum Datenaustausch (Abschnitt 2.4.1) heißt es unmissverständlich: „Personal and sensitive data shall not be shared in raw form.“ Personenbezogene und sensible Daten dürfen also nicht im Rohzustand weitergegeben werden.
Genau dieser erste Schritt ist unser Tagesgeschäft bei Maya. Im Folgenden zeigen wir, was das Rahmenwerk vorsieht, warum es bei der Datenquelle ansetzt und was das für Dateneigentümer in Indien und Europa bedeutet.
Was ist DEPA für KI-Training?
Das Rahmenwerk beschreibt das Problem als „data deadlock“, eine Art Datenstau. Krankenhäuser, Banken, Versicherer und Behörden verfügen über genau die Daten, die KI-Modelle brauchen. Doch diese Daten liegen hinter institutionellen und regulatorischen Mauern, und ihre Eigentümer haben gute Gründe, sie dort zu lassen: Datenschutzrisiken nach dem indischen Digital Personal Data Protection Act 2023 (DPDP Act), die Sorge, Geschäftsgeheimnisse preiszugeben, fehlende vertrauenswürdige Verfahren für den Austausch und Kosten, die beim Dateneigentümer anfallen, während andere den Nutzen haben.
Für einzelne Personen gibt es in Indien bereits eine Einwilligungslösung. Mit DEPA Inference, umgesetzt über das sogenannte Account-Aggregator-System, kann jemand zum Beispiel seine Kontoauszüge für eine einzelne Kreditentscheidung an einen Kreditgeber freigeben. Beim Training sieht das anders aus. Ein Modell lernt aus Millionen von Datensätzen gleichzeitig, und jede einzelne Person um Zustimmung zu bitten, ist in dieser Größenordnung nicht machbar. DEPA für KI-Training schließt diese Lücke für die Nutzung großer Datenbestände.
Dafür legt das Rahmenwerk klare Rollen fest. Datenanbieter, im Rahmenwerk Training Data Providers (TDPs) genannt, etwa Krankenhäuser, Banken und Pharmaunternehmen, bereiten Datensätze auf und stellen sie bereit. Datennutzer, die Training Data Consumers (TDCs), von Start-ups bis zu Forschungseinrichtungen, trainieren damit Modelle. Datenkollektive bündeln Daten innerhalb einer Branche. Das Training läuft in einer sicheren Datenumgebung, Differential Privacy schützt die Ergebnisse, und maschinenlesbare Verträge sorgen dafür, dass Daten nur für den vereinbarten Zweck genutzt werden. Als erste Pilotbereiche nennt das Rahmenwerk das Finanz- und das Gesundheitswesen.
Wo wird in DEPA für KI-Training anonymisiert?
Der Ablauf umfasst fünf Schritte, und der erste liegt beim Dateneigentümer. In Schritt 1 registriert der Datenanbieter einen Datensatz. Zuvor wird dieser anonymisiert und verschlüsselt, sodass er keine personenbezogenen Daten mehr enthält. Erst dann erhält er Metadaten, eine kryptografische Kennzeichnung und einen Eintrag auf einer Datenaustauschplattform.
Für den Betrieb sieht das Rahmenwerk zwei Varianten vor. In der ersten anonymisiert der Datenanbieter seine Daten selbst und übergibt nur anonymisierte Datenbestände. In der zweiten liefert er Rohdaten in die sichere Umgebung der Plattform, und die Plattform übernimmt Anonymisierung und Verschlüsselung als Dienstleistung. In beiden Fällen braucht es eine Anonymisierungslösung. Offen ist nur, wer sie betreibt und wo.
Dabei kommen zwei Begriffe vor, die leicht verwechselt werden. Anonymisierung ist unumkehrbar: Niemand, auch nicht der Dateneigentümer, kann einen Datensatz danach wieder einer Person zuordnen. Pseudonymisierung ersetzt Identifikatoren durch Ersatzwerte, und wer den Schlüssel oder die Zuordnungstabelle besitzt, kann das rückgängig machen. Für KI-Training ist Anonymisierung in der Regel die richtige Wahl, denn ein Modell lernt aus Mustern, und niemand muss wissen, zu wem ein Datensatz gehört. Weitere Fachbegriffe erklären wir in unserem Privacy Glossary.
Manche Anwendungsfälle brauchen trotzdem einen Weg zurück. Ein Krankenhaus möchte vielleicht Folgedaten zu bereits geteilten Datensätzen ergänzen oder einem Patienten ermöglichen, seine Daten zu berichtigen oder zurückzuziehen. Für solche Fälle verlangt das Verfahren zum Datenaustausch eine Pseudonymisierung, bei der die Schlüssel bei der Organisation bleiben, von der die Daten stammen („de-identification with pseudonymized keys held by the originating agency“). Wer die Daten später erhält, kann die Pseudonyme nicht auflösen.
Warum reicht es nicht, Namen zu entfernen?
Mit klassischer Anonymisierung geht das Rahmenwerk hart ins Gericht (Abschnitt 2.3.1). Wer nur direkte Identifikatoren wie Namen, Adressen und Ausweisnummern entfernt, wiegt sich laut Handbuch in falscher Sicherheit. Das Beispiel aus dem Rahmenwerk: Geburtsdatum, Postleitzahl und Geschlecht sind einzeln harmlos, zusammen aber ein Fingerabdruck, der auf eine einzige Person verweist. Werden zwei oder drei solcher Datensätze verknüpft, steigt das Risiko schnell.
Der umgekehrte Fehler ist genauso real. Wer Daten zu stark vergröbert oder zu viel Rauschen hinzufügt, zerstört die Muster, aus denen ein Modell lernen soll. Das Rahmenwerk benennt diesen Zielkonflikt offen: Je gründlicher anonymisiert wird, desto weniger taugen die Daten, und je brauchbarer sie bleiben, desto höher ist das Risiko einer Re-Identifizierung.
DEPA setzt deshalb auf mehrere Schutzschichten. Die Anonymisierung an der Quelle schützt die Eingangsdaten. Die sichere Datenumgebung hält Rohdaten von den Modellentwicklern fern. Differential Privacy mit einem festgelegten Privacy-Budget begrenzt, was das fertige Modell verraten kann: Beim Training wird gezielt statistisches Rauschen hinzugefügt, damit sich das Modell keine einzelnen Datensätze merkt und sie später nicht preisgibt. Jede Schicht deckt ein anderes Risiko ab, und keine macht den ersten Schritt überflüssig.
An der Quelle muss die Anonymisierung drei Dinge zugleich leisten. Sie muss direkte Identifikatoren ersetzen. Sie muss mit indirekten Merkmalen wie Geburtsdaten und Wohnorten sorgfältig umgehen. Und sie muss die Daten stimmig halten: Dieselbe Patientin, derselbe Kunde oder derselbe Versicherungsnehmer erhält in jeder Tabelle und jedem System dieselben Ersatzwerte. Ohne diese Konsistenz kann ein Modell nicht aus einer vollständigen Behandlungshistorie lernen, weil sie in lauter unverbundene Einzelzeilen zerfällt.
Warum die Quellsysteme die eigentliche Hürde sind
Das Rahmenwerk spricht noch ein weiteres Hindernis offen an. Im Kapitel zu Finanzdienstleistungen verweist es auf aktuelle Maßnahmen der indischen Zentralbank (Reserve Bank of India) gegen große Banken wegen IT-Mängeln. Viele etablierte Institute, so das Handbuch, betreiben Altsysteme, die keine moderne sichere Datenumgebung unterstützen.
Das deckt sich mit unserer Erfahrung aus Unternehmenslandschaften. Die Daten, die sich für das Training lohnen, liegen nicht in einer sauberen Tabelle. Sie stecken in ERP-Systemen wie SAP S/4HANA, in Kernbanken- und Bestandsführungssystemen, in Krankenhausinformationssystemen und in den Excel-Listen und PDFs, die zwischen diesen Systemen hin- und hergehen. Ein Patientendatensatz berührt Aufnahme, Abrechnung, Apotheke und Labor. Ein Versicherungsnehmer taucht in Antragsprüfung, Schadenbearbeitung und Buchhaltung auf.
Jede Kopie dieser Daten, vom Testsystem über Analyse-Exporte bis zum KI-Prompt, vergrößert die Angriffsfläche. Was das für Unternehmen in Indien bedeutet, haben wir im Beitrag Data anonymization: shrinking India's breach exposure beschrieben.
Daneben nennt das Rahmenwerk ein Risiko, das über personenbezogene Daten hinausgeht. Geschäftsdaten enthalten wettbewerbsrelevante Informationen wie Kundenlisten, Transaktionsmuster und Lieferantenbeziehungen. Ein Pharmaunternehmen oder ein Versicherer, der sich einem Datenkollektiv anschließt, muss auch diese Informationen schützen, bevor Daten das Haus verlassen.
Ein Beispiel: Eine Klinikgruppe und ein Pharmaunternehmen wollen nach dem DEPA-Modell ein KI-Modell mit Behandlungsergebnissen trainieren. Die Klinikgruppe ist der Datenanbieter. Ihre erste Aufgabe ist ein Datensatz, in dem alle Patientinnen und Patienten über klinische Daten und Abrechnungsdaten hinweg einheitlich anonymisiert sind, in dem Datumsangaben und Orte keinen Rückschluss auf Personen zulassen, dessen Rohdaten die Klinik nie verlassen und der trotzdem echte klinische Muster abbildet. Alles Weitere, von der Austauschplattform bis zum Training mit Differential Privacy, steht und fällt mit diesem Schritt.
Wie Maya Daten an der Quelle anonymisiert
Maya entwickelt Technologie zum Schutz personenbezogener Daten (Privacy-Enhancing Technology) für genau diesen ersten Schritt: Wir anonymisieren in der eigenen Infrastruktur des Dateneigentümers, bevor Daten bewegt werden. Wie das für KI- und ML-Teams aussieht, zeigt unsere Seite zum Training Data Management.
AppSafe™ anonymisiert Daten direkt in laufenden Anwendungen und Datenbanken, in SAP S/4HANA ebenso wie in Nicht-SAP-Datenbanken wie Oracle, PostgreSQL und SQL Server. Namen, Geburtsdaten und andere Identifikatoren werden durch realistische Werte ersetzt, ein Geburtsdatum zum Beispiel durch ein anderes Datum im selben Jahr. So verhalten sich die Daten in Analysen und im Training weiterhin wie echte Daten. Dieselbe Person erhält in allen Systemen dieselben Ersatzwerte, und die Beziehungen zwischen Tabellen und Anwendungen bleiben erhalten. Braucht ein Anwendungsfall den Weg zurück, pseudonymisiert AppSafe™ stattdessen, und die Zuordnung bleibt beim Dateneigentümer, genau wie es das DEPA-Verfahren zum Datenaustausch vorsieht. AppSafe™ läuft als Container in der Umgebung des Kunden und benötigt im Betrieb keine Internetverbindung.
FileSafe™ kümmert sich um die Dokumente, die neben den strukturierten Daten existieren: Excel-Dateien, PDFs und Bilder. AISafe™ schützt sensible Daten in KI-Pipelines. Es entfernt personenbezogene Daten, bevor Inhalte ein Sprachmodell oder einen Trainingsprozess erreichen. Muss ein Ergebnis wieder der realen Person zugeordnet werden, pseudonymisiert AISafe™ und stellt den Personenbezug unter der Kontrolle des Dateneigentümers wieder her.
Maya ergänzt die sichere Datenumgebung und Differential Privacy. Wir setzen davor an, beim Datenanbieter, also genau dort, wo DEPA die Verantwortung verortet. In der zweiten DEPA-Variante kann dieselbe Technologie als Anonymisierungsdienst innerhalb einer Austauschplattform laufen. Maya hat seinen Hauptsitz in Dublin und ist nach ISO 27001:2022 und SOC 2 zertifiziert.
Ein Krankenhaus in Norwegen nutzt Maya seit drei Jahren mit echten Patientendaten. Die Patientendaten werden in der eigenen Umgebung des Krankenhauses anonymisiert und fließen dann in Testsysteme, in die Einarbeitung neuer Mitarbeitender und in Schulungen. Weder Externe noch die Nutzer dieser Umgebungen arbeiten mit echten Patientenidentitäten.
Was bedeutet DEPA für Dateneigentümer in Europa?
Laut Handbuch ist DEPA für KI-Training mit dem indischen DPDP Act, der europäischen Datenschutz-Grundverordnung (DSGVO) und dem EU AI Act abgestimmt. Europäischen Dateneigentümern ist die Grundregel vertraut. Nach der DSGVO bleiben pseudonymisierte Daten personenbezogen, solange sie sich mit Zusatzinformationen einer Person zuordnen lassen. Anonyme Daten fallen dagegen nicht unter die Verordnung (Erwägungsgrund 26). Ein Grund mehr, überall dort zu anonymisieren, wo es der Anwendungsfall zulässt, und die Schlüssel an der Quelle zu behalten, wo das nicht geht.
Neu an DEPA ist, dass die Reihenfolge für KI-Training schriftlich festgelegt ist: an der Quelle anonymisieren, in einer geschützten Umgebung trainieren, die Ergebnisse absichern und den Verwendungszweck vertraglich festschreiben. Wer in Europa Daten für KI bündeln will, ob im Pharma-Konsortium, in der Versicherungsgruppe oder im Gesundheitsdatenprojekt, kann diese Reihenfolge schon heute als Checkliste nutzen.
Das Rahmenwerk soll weiterentwickelt werden, und MeitY lädt Wirtschaft und Wissenschaft ausdrücklich ein, Vorschläge einzubringen. Wir verfolgen, wie sich die Pilotprojekte im Finanz- und Gesundheitswesen entwickeln.
Wenn Sie über Daten verfügen, mit denen andere trainieren möchten, beginnen Sie mit dem ersten Schritt: Finden Sie heraus, wo Ihre sensiblen Daten liegen, und stellen Sie sicher, dass nur anonymisierte Daten Ihre Systeme verlassen, einheitlich über alle Anwendungen hinweg. Sie möchten sehen, wie das in Ihren SAP- oder Kernsystemen funktioniert? Demo buchen.
Häufige Fragen zu DEPA für KI-Training
Weitere Antworten rund um Anonymisierung, SAP-Testdaten und KI finden Sie in unseren FAQ.
Was ist DEPA für KI-Training?
DEPA für KI-Training (offiziell „DEPA for AI Training“) ist ein Rahmenwerk des indischen Ministeriums für Elektronik und Informationstechnologie (MeitY), das im Oktober 2026 als Diskussionsentwurf erschienen ist. Es legt fest, wie Krankenhäuser, Banken, Versicherer und Behörden sensible Daten für das Training von KI-Modellen teilen können: mit Anonymisierung an der Quelle, sicheren Datenumgebungen, Differential Privacy und maschinenlesbaren Verträgen. Erste Pilotbereiche sind das Finanz- und das Gesundheitswesen.
Verlangt DEPA für KI-Training Anonymisierung oder Pseudonymisierung?
Das hängt vom Anwendungsfall ab. In Schritt 1 anonymisieren und verschlüsseln die Datenanbieter ihre Datensätze, bevor sie diese registrieren. Muss ein Dateneigentümer Datensätze später wieder einer Person zuordnen können, verlangt das Verfahren zum Datenaustausch (Abschnitt 2.4.1) eine Pseudonymisierung, bei der die Schlüssel bei der Ursprungsorganisation bleiben.
Ist DEPA für KI-Training rechtlich verbindlich?
Nein. Das Handbuch ist ein Diskussionsentwurf und soll weiterentwickelt werden. MeitY bittet Wirtschaft und Wissenschaft um Vorschläge, und den Anfang machen Pilotprojekte im Finanz- und Gesundheitswesen.
Ersetzt Differential Privacy die Anonymisierung?
Nein. Differential Privacy fügt beim Training gezielt Rauschen hinzu, damit ein Modell keine einzelnen Datensätze preisgibt. In DEPA kommt sie in der sicheren Datenumgebung der Plattform zum Einsatz. Die Anonymisierung an der Quelle schützt dagegen die Eingangsdaten, sodass echte Identitäten den Dateneigentümer gar nicht erst verlassen. DEPA setzt auf beide Schichten.
Spielt DEPA für KI-Training für Unternehmen in der EU eine Rolle?
DEPA ist ein indisches Rahmenwerk, laut Handbuch aber mit DSGVO und EU AI Act abgestimmt, und seine Reihenfolge eignet sich als Checkliste für jedes KI-Datenprojekt. Nach der DSGVO fallen anonyme Daten nicht unter die Verordnung, pseudonymisierte Daten bleiben dagegen personenbezogen (Erwägungsgrund 26).
Kann Maya SAP-Daten für KI-Training anonymisieren, ohne dass die Daten unsere Systeme verlassen?
Ja. AppSafe™ läuft als Container in Ihrer eigenen Infrastruktur, auch in Umgebungen ohne Internetzugang (air-gapped), und anonymisiert die Daten direkt in SAP S/4HANA und in Nicht-SAP-Datenbanken. Identifikatoren werden durch realistische Werte ersetzt, und dieselbe Person bleibt über alle Systeme hinweg einheitlich.
Kommentare