Data & MoreEngineeringDeep dive 05

Von einem Fund zu einer löschen Entscheidung.

Klassifizierung ist das, was ein profiliertes Dokument in eine Handlung überführt. Ein Profiler liefert Befunde, Tags markieren und verfeinern diese, Dokumentklassen heben sie auf die Dokumentebene, und Richtlinien übergeben das Ergebnis an einen Treuhänder, der es validiert und entscheidet, ob das Dokument aufbewahrt, neu klassifiziert oder gelöscht wird. So greifen diese Schichten ineinander – und so sind die dahinterliegenden Elasticsearch-Indizes aufgebaut.

Die Erkennung findet es. Menschen entscheiden, was damit geschieht.

1351Erkennungsalgorithmen
2320Tags pro Mandant
45Dokumentklassen pro Mandant
59Richtlinien pro Mandant
Abschnitt 01Übersicht

Fünf Schichten, von unten nach oben

Klassifizierung ist eine stufenweise Verfeinerung. Jede Schicht ist eine gespeicherte Abfrage, die liest, was die darunterliegende Schicht auf das Dokument geschrieben hat, und anschließend ihren eigenen Marker schreibt. Die Kette verläuft von der maschinellen Erkennung bis zur menschlichen Compliance-Entscheidung. Sie endet nicht bei einem Microsoft Purview-Label: Sie endet bei einer Richtlinie, bei der ein Treuhänder die Klassifizierung validiert und über Aufbewahrung oder Löschung entscheidet. Die MIP-Kennzeichnung ist eine optionale Durchsetzungsmaßnahme – nicht mehr.

ERKENNEN MARKIEREN KLASSIFIZIEREN STEUERN VALIDIEREN Eintragstypen Profiler-Befunde DS_EntryType_List Tags Marker auf Wertebene DS_Tags Dokumentklassen auf Dokumentebene DS_DocumentClass Richtlinie Zweck + Aufbewahrung notification_settings scheduled_delete Treuhänder validiert die Klassifizierung aufbewahren / LÖSCHEN ein Tag kann einen Wissens-Eintragstyp erzeugen if mip_enabled MIP / Purview-Label DS_Status = DELETED
Hauptdatenpfad Bedingt / Rückmeldung Ergebnis / erzwungener Zustand Geschriebene Nutzlast

Die Erkennung, die Eintragstypen erzeugt – der Profiler, der seine Algorithmen ausführt – wird in AI Profiler behandelt. Dieses Handbuch beginnt dort, wo die Befunde eintreffen.

Abschnitt 02Die Schichten

Was jede Schicht leistet

Schicht 01

Eintragstypen

Die vom Profiler geschriebenen Erkennungsbefunde: FULL_NAME, STREET_ADDRESS, S_LOC und die Wissensfamilie S_K_*. Jeder trägt pii, sensitivity und eine Farbe. Sie erscheinen als DS_EntryType_List.

Index entry_types · ~715 · dynamic:false
Schicht 02

Tags

Gespeicherte Abfragen, überwiegend über DS_Value. Sie vergeben DS_Tags, können S_K_*-Eintragstypen erzeugen und Befunde über Flags mutieren:remove_labels, remove_values, rename_data, set_status, sticky.

index tags · ~2320 · dynamic:false
Layer 03

Dokumentklassen

Gespeicherte Abfragen über DS_EntryType_List oder DS_Tags. Sie beantworten die Frage „Um welche Art von Dokument handelt es sich?" und vergeben DS_DocumentClass. Gleiche Engine wie Tags, unterschiedliche Eingabe- und Ausgabefelder.

index document_classes · 45/tenant · dynamic:true
Layer 04

Richtlinien

Klassifizierte Dokumente für einen Compliance-Zweck zusammenfassen. Verantwortlich für den Custodian-Bericht (notification_settings: Registerkarte „Falsch klassifiziert", Löschsteuerung, Zyklus) sowie die Aufbewahrung (scheduled_delete, days_to_delete, duration). Optionale Kanäle: MIP, Gmail, GDrive.

index policies · ~59/tenant · dynamic:true
Tags und Klassen verwenden dieselbe Engine auf zwei unterschiedlichen Ebenen. Bei beiden handelt es sich um gespeicherte Abfragen, die einem Dokument eine ID zuweisen. Sie unterscheiden sich lediglich darin, was sie lesen (Tags lesen Werte, Klassen lesen Eintragstypen oder Tags) und was sie schreiben (DS_Tags gegenüber DS_DocumentClass). Aus diesem Grund teilen sie das Kategoriemodell, den Übersetzungsindex und den Tagging-Task-Code.
Abschnitt 03Nachvollziehbarer Ablauf

„Religionszugehörigkeit", von Anfang bis Ende

Ein realer Ablauf eines einzelnen Mandanten. Er zeigt eine Klasse, die auf tags basiert – nicht direkt auf Eintragstypen – und über zwei unabhängige Routen zur gleichen Klassifizierung gelangt: eine Route, die durch einen erkannten Eintragstyp gesteuert wird, eine weitere durch wörtliche deutsche Dokumentformulierungen.

NACHWEIS TAGS KLASSE STEUERUNG RELIGIOUS_ORIENTATION + FULL_NAME, nicht ausgeschlossen pii 2 · sensitivity 4 · 3914 keywords DS_Value ~ "Kirchenaustritt" wörtliche deutsche Formulierungen Wildcard-Treffer, kein Eintragstyp UN Religious Orientation veUeLZwBiRR6rBsVr02n Route über Eintragstyp GER church resignation1 FOUeLZwBiRR6rBsVs07W Route über Schlüsselwort Religious Orientation cat: Privacy Classification query: DS_Tags (A OR B) Datenschutzrichtlinie Custodian-Bericht Prüfen und anschließend LÖSCHEN
Trefferweg Zur Steuerungsebene Gespeichertes Abfrageobjekt

Die Klassenabfrage besteht aus zwei mit OR verknüpften Blöcken, von denen jeder ein einzelnes DS_Tags-Term enthält. Ein Dokument, das einen der beiden Tags trägt, wird klassifiziert, und die Klassen-ID wird in DS_DocumentClass geschrieben. Von dort erfasst eine Datenschutzrichtlinie die Dokumente, ein Custodian prüft sie, weist Falschpositive auf der Registerkarte „Falsch klassifiziert" zurück, und das Aufbewahrungsfenster der Richtlinie steuert die Löschung. Die Verbindung ist konkret: Die Tag-Ausgabe (DS_Tags) ist die Klassen-Eingabe.

Klassenabfrage

DS_Tags = veU... (UN Religious)
OR
DS_Tags = FOU... (GER church)

Abschnitt 04Indexmodell

Wie die Indizes strukturiert sind

Jeder Klassifizierungsindex teilt einen mandantenfähigen und abonnementbasierten Herkunfts-Rahmen und fügt anschließend eigene Felder hinzu. Alle Mandanten befinden sich in einem Index, getrennt durch company_id; alle Datensätze werden abonnementbasiert aus einer gemeinsamen Ausgangsbasis gespeist.

IndexAnzahl / MandantDynamischCharakteristische Felder
entry_types~715falsename_normalized, method, keywords, redacted, pii, sensitivity, color
tags~2320falsequery, category_id, remove_labels/values/text, set_status, sticky, report_tag
document_classes45truequery, category_id, tag_document_class, corrective_actions
policies~59truequery, enforcement_*, scheduled_delete, days_to_delete, duration, notification_settings, mip_enabled
tag_category~200truename, active, profile_tag, show_in_treeview
document_class_category~21truename, active, show_in_dashboard
tag_names~3625truetag_id, type (tag|class), translated_field, ~40 lang columns
mip_label~30falselabel_id, name, level, tenant, color

Gemeinsamer Rahmen

  • company_id der Mandantenschlüssel (keyword)
  • query die gespeicherte Suchanfrage (object)
  • status Aktiv-Schalter (Kategorien verwenden active)
  • order, risk, personal, profiled, total
  • duration / duration_start / duration_end
  • Herkunft: defined_from_subscriptions, subscription_source, original_subscription_id

Kategorie & Übersetzung

Tags und Klassen werden durch parallele Nebenindizes organisiert und lokalisiert.

Tag-Gruppierungtag_category
Klassen-Gruppierungdocument_class_category
Lokalisierungtag_names (type tag|class)

tag_names ist ein einzelner i18n-Index für beide: etwa 2560 Einträge type:tag und 430 Einträge type:class pro Mandant.

Abschnitt 05Abfragegrammatik

Eine gemeinsame Grammatik für Tags, Klassen und policies

Dasquery Objekt hat überall dieselbe Struktur: ein oder mehrere Blöcke, von denen jeder ein Array von Filtern enthält. Blöcke werden mit ODER verknüpft; Filter innerhalb eines Blocks werden mit UND verknüpft. Diese einheitliche Grammatik ist der Grund, warum eine einzige Matching-Engine alle drei Abfrageebenen bedienen kann.

Filter-Struktur

{
"field": "DS_EntryType_List",
"type": "terms" | "wildcard",
"compare": "equal" | "not_equal",
"values": ["STREET_ADDRESS", ...]
}

  • field das zu lesende Dokumentfeld: DS_Value, DS_EntryType_List, DS_Tags, DS_KnownPersons.
  • type terms für eine exakte Menge, wildcard für Muster.
  • compare equal oder not_equal (der Ausschluss-Guard im Trace verwendete not_equal).
  • Mehrere Blöcke werden mit ODER verknüpft; mehrere Filter werden mit UND verknüpft. Das ist die gesamte Logik.
Zusammenfassung

Die Klassifizierung endet bei einer Person, nicht bei einem Label.

Die Erkennung liefert Tags, Tags speisen Klassen, Klassen speisen Richtlinien, und Richtlinien legen das Ergebnis einem Verwalter vor, der es validiert und über Behalten, Neuklassifizierung oder Löschung entscheidet. MIP-Beschriftung ist eine optionale Ausgabe, niemals das Ziel. Jede Ebene ist mandantenfähig durch company_id, abonnementbasiert initialisiert und auf einer einzigen Stored-Query-Grammatik mit gemeinsamen Kategorie- und Übersetzungsschichten aufgebaut.

support.dataandmore.com/en/knowledge/deep-dive/classification