Privacy Impact Assessment durchführen, bevor Sie live gehen

# Privacy Impact Assessment durchführen, bevor Sie live gehen

Ein County in Pennsylvania hat vor einiger Zeit ein Predictive-Risk-Modell gebaut, das markieren sollte, welche Neugeborenen am ehesten von Misshandlung bedroht sind. Es bewertete jede Geburt anhand von County-Registern, Sozialhilfehistorie und Gefängnisdaten, bevor eine Fachkraft die Familie überhaupt gesehen hatte. Dieses Modell, das Allegheny Family Screening Tool, ging erst nach Jahren externer Prüfung live, und zwar genau deshalb, weil jemand vorher die unbequemen Fragen gestellt hat: Wessen Daten stecken hier drin, wer wird überproportional markiert, und was passiert, wenn das leakt oder irrt?

Dieses „vorher fragen" hat einen Namen: Privacy Impact Assessment (PIA), eine strukturierte Prüfung, welche personenbezogenen Daten ein System erhebt, warum, und was schiefgehen kann, bevor es den Datensatz einer einzigen Bürgerin berührt. In den USA sind PIAs für Bundessysteme nach dem E-Government Act of 2002 gesetzlich vorgeschrieben, sobald ein neues System personenbezogene Daten verarbeitet. In der EU ist das Pendant die Datenschutz-Folgenabschätzung (DSFA/DPIA), verpflichtend nach Artikel 35 DSGVO für jede Verarbeitung, die „voraussichtlich ein hohes Risiko" für Personen mit sich bringt, wozu ausdrücklich großflächiges Profiling und automatisierte Entscheidungen über verletzliche Gruppen wie Kinder zählen.

Wenn Sie kurz davor sind, ein Predictive-Risk-Tool in der Kinder- und Jugendhilfe, bei der Polizei, bei Leistungsansprüchen oder im Wohnungswesen auszurollen, ist eine PIA kein Papierkram. Sie ist der letzte Checkpoint, bevor Ihr Modell reale Interventionen im Leben realer Familien mitbestimmt.

Was eine PIA Sie tatsächlich zu beantworten zwingt

Eine saubere PIA arbeitet fünf konkrete Fragen ab. Lassen Sie eine davon aus, fliegen Sie blind.

1. Welche Daten gehen rein? Jedes Quellfeld: Geburtsregister, frühere Kontakte mit der Jugendhilfe, Festnahmeprotokolle, Medicaid-Abrechnungen, Schuldaten.

2. Warum brauchen Sie jedes einzelne Feld? Das ist das Prinzip der Datenminimierung der DSGVO (Artikel 5): nur erheben, was für den genannten Zweck nötig ist. Die Postleitzahl mag Risiko vorhersagen, ist aber oft ein Proxy für Ethnie und Armut, nicht das kausale Risiko selbst.

3. Wer kann aus diesen Daten jemanden re-identifizieren? Selbst „anonymisierte" Datensätze sind es häufig nicht.

4. Was passiert, wenn das Modell falsch liegt, und für wen konkret? False Positives und False Negatives verteilen sich nicht gleichmäßig über Gruppen.

5. Wer trägt die Verantwortung, wenn es schiefgeht? Nennen Sie einen Menschen, kein Gremium.

Direkt zu „lasst uns das Modell bauen" zu springen, ohne diese Punkte durchzugehen, ist der mit Abstand häufigste Fehlermodus im öffentlichen Sektor.

Re-Identifikationsrisiko: der Check, den die meisten Teams auslassen

„Anonymisiert" ist keine technische Garantie, sondern eine Behauptung, die Sie testen müssen. Eine wegweisende Studie von Latanya Sweeney ergab, dass 87 % der US-Bevölkerung allein über Postleitzahl, Geburtsdatum und Geschlecht eindeutig identifizierbar sind (Sweeney, 2000, Data Privacy Working Paper), eine Schätzung, die weiterhin breit zitiert wird, weil sich die zugrunde liegende Kombinatorik nicht geändert hat.

Für ein Tool in der Kinder- und Jugendhilfe ist der praktische Test eine k-Anonymität-Prüfung: Trifft für jede Feldkombination, die Sie veröffentlichen oder teilen wollen (Alter, PLZ, Falltyp, Meldequelle), mindestens *kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →* Personen zu (üblich sind kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →=5 oder kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →=10 als Arbeitsschwelle, nicht als gesetzliche Vorgabe)? Wenn eine Abfrage einen einzigen Haushalt zurückgibt, haben Sie ein Re-Identifikationsproblem, selbst wenn Sie Name und Sozialversicherungsnummer entfernt haben.

Ein einfacher Check, den Sie laufen lassen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, bevor Daten eine sichere Umgebung verlassen:

import pandas as pd

# Quasi-Identifikatoren, die eine Re-Identifikation ermöglichen können
quasi_ids = ["zip_code", "age_bracket", "case_type"]

group_sizes = df.groupby(quasi_ids).size()
risky_groups = group_sizes[group_sizes < 5]  # Schwelle k=5

print(f"{len(risky_groups)} combinations have fewer than 5 people")
print(risky_groups.head(10))

Ist dieser Wert ungleich null, unterdrücken Sie entweder diese Zeilen, generalisieren das Feld (exaktes Alter zu Altersgruppe) oder fügen Rauschen hinzu, bevor irgendjemand weiter unten den Datensatz abfragen kann.

Disparate Impact: der Check, der am meisten zählt

Re-Identifikation schützt Einzelpersonen. Disparate Impact schützt Gruppen, und in der Kinder- und Jugendhilfe ist das das Risiko mit dem höheren Einsatz.

Disparate Impact ist ein Rechtsbegriff aus dem US-Bürgerrechtsrecht (ursprünglich *Griggs v. Duke Power*, 1971, auf algorithmische Entscheidungen angewendet durch das Department of Justice und HUD im Kontext fairen Wohnens): eine dem Anschein nach neutrale Regel oder ein neutrales Modell, das für eine geschützte Gruppe, Ethnie, Geschlecht, Behinderung, deutlich schlechtere Ergebnisse produziert, auch ohne Diskriminierungsabsicht.

Der praktische Test: Berechnen Sie Flag-Rate und Fehlerrate Ihres Modells nach demografischer Untergruppe, nicht nur die Gesamtgenauigkeit.

| Metrik | Gruppe A | Gruppe B | Differenz |

|---|---|---|---|

| Als Hochrisiko markiert | 22 % | 41 % | +19 Pkt. |

| False-Positive-Rate | 14 % | 29 % | +15 Pkt. |

Eine Differenz von 19 Punkten bei den Flag-Raten ist, wenn sie mit Ethnie oder Einkommen korreliert und nicht durch legitime Risikofaktoren erklärbar ist, ein Warnsignal, das schwer genug wiegt, um den Launch zu stoppen. Genau das war die Kritik unabhängiger Forscher am Tool von Allegheny: Familienarmut und frühere Kontakte mit dem System (selbst geprägt durch verzerrtes Meldeverhalten) waren in die „Risiko"-Scores eingebacken, was hieß, dass arme Familien stärker überwacht wurden, was mehr Daten erzeugte, was mehr Überwachung rechtfertigte. Eine gut gemachte PIA benennt diese Feedbackschleife explizit, statt sie nach dem Rollout zu entdecken.

Die Brookings Institution hat eine klare, allgemeinverständliche Erklärung dazu, wie solche Feedbackschleifen in Predictive-Policing- und Sozialleistungstools entstehen: Brookings: Algorithmic bias detection.

Governance: wer zeichnet ab, und wann

Eine PIA ist nur so gut wie die Governance-Struktur dahinter. Drei Dinge müssen vor dem Launch stehen, nicht danach:

• Ein namentlich benannter Datenschutzbeauftragter (DPO) oder eine entsprechende Privacy-Verantwortung, nach DSGVO Artikel 37 für öffentliche Stellen vorgeschrieben und auch in US-Bundesstaatsbehörden zunehmend gängige Praxis, selbst ohne bundesgesetzliche Pflicht.
• Ein unabhängiges Prüfgremium mit der Befugnis, den Launch zu verzögern, nicht nur zu kommentieren. Allegheny County ließ vor der landesweiten Skalierung eine externe Ethikprüfung durchführen (Eubanks, Dare und Chen, beauftragt vom County), und sie veränderte, welche Variablen verwendet wurden.
• Ein dokumentiertes Entscheidungsprotokoll: was aufgefallen ist, was geändert wurde, welches Restrisiko von wem akzeptiert wurde. Wenn Ihre PIA keine Papierspur nach dem Muster „wir wussten von X und haben Y entschieden" hat, ist sie Theater, keine Governance.

Für US-Behörden auf Staats- und Kommunalebene liefert das NIST AI Risk Management Framework (nist.gov/itl/ai-risk-management-framework) genau dafür eine kostenlose, nicht regulatorische, aber breit angenommene Struktur: Risiken abbilden, messen und Governance-Verantwortung zuweisen.

Die Checkliste vor dem Launch

Bevor ein Predictive-Risk-Tool den Datensatz einer Bürgerin berührt, prüfen Sie:

• [ ] Jedes Eingabefeld hat einen dokumentierten, notwendigen Zweck (Datenminimierung)
• [ ] Ein kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →-Anonymitäts- oder gleichwertiger Re-Identifikationstest wurde auf jedem teilbaren Extrakt durchgeführt
• [ ] Flag-Raten und Fehlerraten sind nach geschützten Merkmalen aufgeschlüsselt und auf Disparate Impact geprüft
• [ ] Eine namentlich benannte Person trägt die Verantwortung für das Modell, keine Abteilung
• [ ] Es gibt einen definierten Prozess, mit dem eine Fachkraft den Score übersteuern kann, und dieses Übersteuern wird protokolliert
• [ ] Das PIA-/DSFA-Dokument selbst ist veröffentlicht oder für unabhängige Prüfung verfügbar

🎬 [VIDEO: „Algorithms in Child Welfare: Risk, Bias, and Accountability" - youtube.com - suchen Sie nach Podiumsdiskussionen von Data & Society oder dem AI Now Institute zu Predictive Tools in der Kinder- und Jugendhilfe, die den Fall Allegheny im Detail durchgehen]

Kernaussagen

• Eine PIA (USA, nach dem E-Government Act) oder DSFA (EU, DSGVO Artikel 35) ist eine verpflichtende, strukturierte Prüfung vor dem Launch, keine optionale Dokumentation, sobald ein System verletzliche Gruppen profiliert.
• Testen Sie das Re-Identifikationsrisiko konkret mit einem kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →-Anonymitäts-Check auf Quasi-Identifikatoren (PLZ, Alter, Falltyp); „anonymisiert" ist eine zu prüfende Behauptung, kein Ausgangszustand.
• Disparate Impact misst man über den Vergleich von Flag-Raten und Fehlerraten zwischen geschützten Gruppen, nicht über die Gesamtgenauigkeit des Modells; eine zweistellige Differenz ist ein Warnsignal, das den Launch blockiert.
• Governance braucht eine namentlich verantwortliche Person, ein unabhängiges Prüfgremium mit echter Befugnis zur Verzögerung des Launches und ein dokumentiertes Entscheidungsprotokoll, vor dem Rollout, nicht als Postmortem.
• Predictive-Risk-Tools auf Basis historischer Falldaten laufen Gefahr, vergangene Überwachungsverzerrung in kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ünftige Entscheidungen einzuschreiben; die PIA ist der Ort, an dem Sie diese Schleife abfangen, bevor sie sich aufschaukelt.