Datenfelder als direkte, indirekte oder Nicht-PII einstufen

Er erkennt typische Hinweise wie E-Mail, Reisepass, Geburtsdatum, Postleitzahl, Gerätekennung und gewöhnliche Geschäftskennzahlen. Das Ergebnis enthält für jede Entscheidung eine kurze Begründung sowie Summen je Kategorie. Damit eignet es sich für ein erstes Datenschutzinventar, eine Schemaprüfung oder eine wiederholbare Kontrolle in einer Datenpipeline. Da Namen statt gespeicherter Werte untersucht werden, arbeitet das Verfahren schnell und deterministisch. Sie sollten die Ergebnisse dennoch anhand der Bedeutung und Inhalte des tatsächlichen Datensatzes bestätigen.

Beginnen Sie das Datenschutzinventar mit dem Schema

Eine Feldliste ist häufig die am schnellsten verfügbare Übersicht über einen Datensatz. Übermitteln Sie die kanonischen Namen genau so, wie sie in einer Datenbank, Ereignisdefinition, Tabellenüberschrift oder einem API-Vertrag stehen. Der Klassifikator vereinheitlicht verbreitete Schreibweisen wie Snake Case, Kebab Case, Leerzeichen und Camel Case, bevor er jeden Namen mit ausgewählten Signalen vergleicht. Namen, die auf E-Mail-Adresse, Telefonnummer, vollständigen Namen, amtliche Kennung, Bankkonto, Zahlungskarte, genaue Anschrift, IP-Adresse oder biometrische Kennung hindeuten, werden als wahrscheinlich direkte PII markiert. Solche Felder können eine Person oft ohne viele weitere Merkmale bestimmen. Die Antwort bewahrt die ursprüngliche Schreibweise, nennt die Einstufung und erläutert das auslösende Signal. Dadurch lässt sie sich einfach mit einem Schemaexport verbinden oder in ein Prüfblatt übernehmen. Senden Sie ausschließlich Feldnamen, keine Beispieldatensätze oder persönlichen Werte. Eine leere Liste wird abgelehnt, weil sie kein sinnvolles Inventar ermöglicht; zudem muss jedes Element eine nicht leere Zeichenfolge sein.

Bewerten Sie indirekte PII im jeweiligen Zusammenhang

Indirekte PII identifizieren eine Person nicht immer allein, können aber eine Personengruppe eingrenzen oder Aktivitäten mit einer beständigen Person verknüpfen, wenn weitere Felder hinzukommen. Namen zu Geburtsdatum, Alter, Geschlecht, grobem Standort, Postgebiet, Geräte- oder Cookie-Kennung, Kontonamen, Beschäftigungsangaben und ähnlichen Merkmalen gelten als wahrscheinlich indirekte PII. Diese Kategorie fordert bewusst eine Kontextprüfung und ist keine rechtliche Feststellung. Eine Postleitzahl in einer landesweiten Statistiktabelle besitzt ein anderes Risikoprofil als dasselbe Feld neben Geburtsdatum und Mitarbeiterkennung. Ebenso kann eine Kundenkennung in einem System pseudonym sein, während eine Zuordnungstabelle sie andernorts direkt zurechenbar macht. Prüfen Sie indirekte Ergebnisse zusammen mit Zugriffskontrollen, Verknüpfungsschlüsseln, Aufbewahrungsfristen, Populationsgröße und verfügbaren externen Quellen. Die festen Regeln machen Scans verschiedener Schemaversionen vergleichbar, erkennen jedoch keine undokumentierte Bedeutung und können nicht feststellen, ob Merkmalskombinationen eine Person herausheben.

Nutzen Sie das Ergebnis als Prüfsignal, nicht als Beweis

Namen ohne erkanntes Signal werden als Nicht-PII zurückgegeben. Das bedeutet lediglich, dass der Name selbst keinen üblichen Datenschutzhinweis enthält. Ein vages Feld wie Wert, Nutzlast, Notiz, Antwort oder Daten kann dennoch personenbezogene Informationen tragen. Umgekehrt könnte ein Feld namens customer_email nur ein Testtoken statt einer echten Adresse enthalten. Ergänzen Sie die Einstufung durch Datenprofilierung, Dokumentationsprüfung und Rücksprache mit den Systemverantwortlichen. Speichern Sie bei automatisierten Abläufen das Ergebnis zusammen mit der Schemaversion, lassen Sie neue direkte oder indirekte Felder prüfen und vergleichen Sie die Kategoriesummen bei Änderungen. Die Ausgabe ist besonders als schlanke Kontrolle geeignet, bevor Sie Auszüge teilen, Analyseereignisse anlegen oder eine Integration genehmigen. Sie ersetzt weder eine Datenschutz-Folgenabschätzung noch Rechtsberatung oder landesspezifische Richtlinien. Der Algorithmus nutzt kein Netzwerk, Modell, Zufallsverfahren oder die aktuelle Zeit; gleiche Eingaben liefern daher gleiche Ausgaben. Eine API-Anfrage kostet $0.002, und die Begründungen erleichtern die Prüfung regelbasierter Entscheidungen.