Sensitive Information Types und trainierbare Klassifizierer: wie Purview erkennt, was schützenswert ist

Es gibt in jedem Purview-Projekt einen Moment, in dem der Datenschutzbeauftragte fragt: „Und woher weiß das Ding, dass das eine Personalakte ist?" Es ist eine sehr gute Frage, und die ehrliche Antwort lautet: gar nicht – es sei denn, jemand hat ihm beigebracht, woran man eine Personalakte erkennt. Purview ist kein Hellseher. Jede DLP-Richtlinie, jede Auto-Labeling-Regel, jeder Insider-Risk-Indikator und jede Empfehlung aus DSPM for AI stützt sich am Ende auf ein Regelwerk, das sagt: Wenn im Dokument dieses Muster steht, in dieser Nähe zu jenem Wort, mindestens so oft – dann ist das ein Treffer. Dieses Regelwerk heißt Sensitive Information Type, und wer es nicht versteht, wundert sich später über Fehlalarme in der einen und Löcher in der anderen Richtung.

Die gute Nachricht: Microsoft liefert über dreihundert vorgefertigte Typen mit, darunter ein gutes Dutzend für Deutschland – IBAN, Personalausweisnummer, Steuer-Identifikationsnummer, Reisepass, Führerschein. Für den Anfang reicht das. Die schlechte Nachricht: Deine Personalnummer, deine Projektkennung, deine Vertragsnummer und dein Personalbogen kennt kein Microsoft-Ingenieur. Die musst du selbst bauen – per Regex mit Schlüsselwörtern, per Dokument-Fingerprint oder per Exact Data Match. Und für alles, was kein festes Muster hat – Verträge, Rechnungen, Lebensläufe, Kündigungsschreiben –, gibt es trainierbare Klassifizierer, die erstaunlich viel können und deren Grenzen kaum jemand kennt, bevor er hineingelaufen ist.

Dieser Artikel zeigt dir, wie ein Sensitive Info Type intern tickt, wie du eigene Typen baust und testest, wann ein trainierbarer Klassifizierer die richtige Wahl ist und wann nicht, und wie das alles in den Betrieb geht, ohne dass die Buchhaltung dich hasst. Wo diese Erkennungsschicht im Gesamtbild von Purview sitzt, zeigt der Überblick zum Kompetenzbereich Microsoft Purview; hier geht es um das Fundament, auf dem DLP und Auto-Labeling stehen.

Anatomie eines Sensitive Info Type: Muster, Umfeld, Häufigkeit

Bevor du den ersten eigenen Typ anlegst, lohnt es sich zu verstehen, wie ein vorgefertigter arbeitet – denn genau diese Mechanik entscheidet später über Fehlalarme. Nimm den Typ „IBAN". Naiv betrachtet ist eine IBAN ein Muster: zwei Buchstaben, zwei Ziffern, dann bis zu dreißig alphanumerische Zeichen. Nach dieser Definition wäre jede Bestellnummer, jeder Lizenzschlüssel und jede Materialnummer eine IBAN. Der Microsoft-Typ tut deshalb drei Dinge zusätzlich: Er rechnet die Prüfsumme nach (Modulo 97), er schaut, ob in der Nähe Wörter wie „IBAN", „Kontonummer" oder „Bankverbindung" stehen, und er vergibt je nach Befund eine Konfidenz. Muster allein: niedrig. Muster mit gültiger Prüfsumme: mittel. Muster, Prüfsumme und Stützwort: hoch.

Primärelement, Stützelemente, Nähe: wie ein Treffer entsteht

Jeder SIT hat genau ein Primärelement je Muster – den regulären Ausdruck, die Schlüsselwortliste, das Wörterbuch oder die Prüffunktion, nach der gesucht wird. Um dieses Primärelement herum liegt ein Nähe-Fenster, standardmäßig 300 Zeichen in beide Richtungen, in dem Purview nach Stützelementen sucht: weiteren Schlüsselwörtern, weiteren Mustern, weiteren SITs. Je mehr Stützelemente gefunden werden, desto höher die Konfidenz. Das ist der ganze Trick, und er ist klug: Eine elfstellige Zahl allein ist nichts. Eine elfstellige Zahl neben „Steuer-ID" oder „IdNr" ist mit hoher Wahrscheinlichkeit eine Steuer-Identifikationsnummer. Wer eigene SITs baut, muss deshalb nicht den perfekten Regex finden – er muss die Wörter finden, die im echten Dokument neben dem Muster stehen.

Skizze 1: Anatomie eines Sensitive Info Type – Primärelement, Stützelemente im Nähe-Fenster und Konfidenz; der Zählwert kommt aus der Richtlinie.

Konfidenz und Zählwert: die zwei Schrauben, die über Fehlalarme entscheiden

Der SIT liefert Treffer mit Konfidenz. Was daraus wird, entscheidet die Richtlinie – und zwar mit zwei Werten, die in fast jedem Projekt zunächst falsch stehen. Die Konfidenzschwelle legt fest, ab welcher Stufe ein Treffer zählt: niedrig nimmt alles mit, hoch nur die Fälle mit Prüfsumme und Stützwort. Der Zählwert legt fest, wie viele Treffer im selben Inhalt nötig sind, bevor die Richtlinie reagiert. Und hier kommt die Erfahrung ins Spiel: Eine einzelne IBAN mit hoher Konfidenz ist in neunzig Prozent aller Fälle die Bankverbindung in der Fußzeile des eigenen Geschäftsbriefs. Zehn IBANs im selben Dokument sind eine Kundenliste. Wer den Zählwert auf eins stellt, markiert jeden Brief; wer ihn auf zehn stellt, findet die Listen. Für die meisten Richtlinien gilt: hohe Konfidenz, Zählwert zwischen drei und zehn, und Kombinationen (IBAN plus Name, Steuer-ID plus Geburtsdatum) statt Einzeltypen.

Die folgende Übersicht zeigt die vorgefertigten deutschen Typen, die in Projekten am häufigsten zum Einsatz kommen, mit ihrer typischen Rolle in Richtlinien. Die genaue Liste wächst regelmäßig; die Namen entsprechen der englischen Portalbezeichnung, weil sie sich in Richtlinien und Berichten so wiederfinden.

Ein Wort zu den benannten Entitäten in den letzten Zeilen: Personennamen, Adressen und medizinische Begriffe erkennt Purview nicht per Regex, sondern mit Sprachmodellen. Das ist mächtig für Kombinationen – „Name plus IBAN" oder „Name plus Diagnose" trifft deutlich präziser als IBAN allein –, aber diese Typen sind rechenintensiver und in manchen Workloads eingeschränkt. Als alleiniges Kriterium taugen sie selten; als Stützelement für ein Personendaten-Bündel sind sie unschlagbar.

Eigene Typen bauen: Regex, Schlüsselwörter, Fingerprint, Exact Data Match

Spätestens wenn die Personalabteilung fragt, ob Purview „unsere Personalnummern" erkennt, ist der Moment für einen eigenen Typ gekommen. Purview bietet dafür vier Werkzeuge, die sich in Aufwand, Präzision und Lizenz unterscheiden. In der Praxis brauchst du meistens das erste, gelegentlich das zweite und nur bei echtem Bedarf das dritte – das vierte gehört ins nächste Kapitel.

Regex plus Schlüsselwörter: der Arbeitsalltag

Ein eigener SIT im Portal besteht aus denselben Bausteinen wie ein vorgefertigter: ein Muster als regulärer Ausdruck, Stützelemente als Schlüsselwortliste, ein Nähe-Fenster, eine oder mehrere Konfidenzstufen. Der Klassiker ist die Personalnummer: Angenommen, sie hat das Format „P" gefolgt von sechs Ziffern. Der Regex ist trivial (\bP\d{6}\b), aber allein trifft er auch Produktcodes und Postfachnummern. Also: hohe Konfidenz nur, wenn im Nähe-Fenster „Personalnummer", „Pers.-Nr." oder „Mitarbeiter-ID" steht; mittlere Konfidenz, wenn eines der Wörter „Gehalt", „Abteilung" oder „Eintrittsdatum" auftaucht; niedrige Konfidenz für das Muster allein. Wichtig ist der Wortgrenzenanker (\b) am Anfang und Ende – ohne ihn trifft dein Muster mitten in längeren Zeichenketten, und die Fehltrefferquote explodiert.

Zwei Handwerksregeln, die mir jedes Projekt bestätigt: Erstens, lass dir vom Fachbereich zwanzig echte Dokumente geben, in denen das Muster vorkommt, und zwanzig, in denen es nicht vorkommen darf – daraus liest du die Stützwörter ab, nicht aus deiner Vorstellung. Zweitens, baue Schlüsselwortwörterbücher für lange Listen (Projektnamen, Produktcodes, Standortkürzel), weil eine Schlüsselwortliste im SIT eine Längenbegrenzung hat und ein Wörterbuch bis zu einer Million Begriffe fasst. Der Portalweg ist bei beidem derselbe: Datenklassifizierung, Klassifizierer, Typen vertraulicher Informationen, neu anlegen, Muster und Stützelemente definieren, Konfidenzstufen zuweisen, testen.

Dokument-Fingerprint: das Formular als Schablone

Manche schützenswerten Dokumente erkennst du nicht an Mustern, sondern an ihrer Form: der Personalbogen, die Vertragsvorlage, das Kündigungsschreiben, das Antragsformular. Für diese Fälle gibt es den Dokument-Fingerprint: Du lädst die leere Vorlage hoch, Purview berechnet daraus einen Abdruck der Struktur, und jedes ausgefüllte Exemplar wird als Treffer erkannt – auch wenn die eingetragenen Werte natürlich jedes Mal anders sind. Das dauert Minuten, braucht keinen Regex und trifft erstaunlich zuverlässig. Ursprünglich funktionierten Fingerprints nur in Exchange-DLP; inzwischen sind sie auch für SharePoint, OneDrive, Teams und Endpunkte verfügbar, in Teilen mit E5-Voraussetzung (Stand 2026 prüfen). Grenzen: Ein Fingerprint erkennt Formulare, keine Freitexte, und wenn die Vorlage jedes Jahr neu gestaltet wird, muss der Fingerprint mit.

Exact Data Match: wenn du die Werte schon kennst

Der präziseste Weg ist zugleich der aufwendigste: Exact Data Match (EDM). Statt nach Mustern zu suchen, gibst du Purview die tatsächlichen Werte – die Kundennummern, die Sozialversicherungsnummern deiner Mitarbeiter, die Vertragsnummern aus dem ERP – als gehashte Tabelle. Purview vergleicht dann Fundstellen mit dieser Tabelle und trifft nur, wenn der Wert wirklich in deinen Stammdaten steht. Der Fehltreffer „Artikelnummer sieht aus wie Kundennummer" ist damit ausgeschlossen. Der Preis: Du brauchst einen Prozess, der die Tabelle regelmäßig neu erzeugt und hochlädt (typisch täglich oder wöchentlich, per Skript vom ERP-Export), du brauchst ein Schema, und du brauchst E5. Für Unternehmen mit großen Kundenstämmen und einem echten Abflussrisiko lohnt sich das; für den Mittelständler mit dreihundert Kunden ist ein guter Regex mit Stützwörtern der bessere Weg.

Trainierbare Klassifizierer: was sie können und wo sie enden

Es gibt Inhalte, die kein Muster haben. Ein Arbeitsvertrag sieht anders aus als der nächste, eine Rechnung folgt keiner Regex, ein Lebenslauf schon gar nicht. Für diese Fälle hat Purview trainierbare Klassifizierer: Modelle, die anhand von Beispielen lernen, eine Dokumentart zu erkennen, und danach auch Dokumente treffen, die kein einziges Schlüsselwort mit den Beispielen teilen. Das ist keine Magie, sondern maschinelles Lernen auf Textmerkmalen – und es hat sehr konkrete Grenzen, die man kennen muss, bevor man darauf eine Richtlinie baut.

Microsoft liefert eine wachsende Zahl vorgefertigter Klassifizierer mit: Verträge, Rechnungen, Finanzberichte, Personalunterlagen, Quellcode, Lebensläufe, IT-Dokumentation, Steuerunterlagen, Belästigung, Bedrohung, Profanität und einige mehr. Sie sind auf Englisch trainiert und mit weiteren Sprachen ergänzt worden; für deutsche Dokumente funktionieren sie inzwischen brauchbar, aber nicht durchgängig gleich gut – testen ist Pflicht. Eigene Klassifizierer trainierst du mit fünfzig bis fünfhundert positiven Beispielen aus einem SharePoint-Ordner, lässt das Modell danach gegen mindestens zweihundert gemischte Testdokumente laufen, prüfst die Ergebnisse von Hand und veröffentlichst den Klassifizierer erst, wenn die Trefferquote stimmt. Rechne mit einigen Wochen; das Training selbst dauert Stunden bis Tage.

Die Grenzen: Ein Klassifizierer ist niemals die Antwort auf „finde alle Zahlen, die so aussehen wie …" – dafür gibt es Regex. Er ist unscharf, er liefert keine Konfidenzstufen im SIT-Sinn, sondern eine Ja-Nein-Einschätzung, und er lässt sich nur begrenzt nachtrainieren – oft ist Neuanlage schneller als Reparatur. Er braucht E5. Und er ist blind für die Frage, ob ein Dokument sensibel ist; er weiß nur, ob es aussieht wie ein Vertrag. Deshalb ist die stärkste Verwendung die Kombination: Klassifizierer „Vertrag" UND SIT „IBAN" UND Container-Label „Öffentlich" – das ist ein Vertrag mit Zahlungsdaten in einem Team, wo er nichts zu suchen hat, und das ist ein Alarm, der sich lohnt.

Skizze 2: Welcher Erkennungsmechanismus – der Entscheidungsbaum vom vorgefertigten Typ bis zum eigenen trainierbaren Klassifizierer.

Als Entscheidungshilfe hier alle Mechanismen nebeneinander mit Eignung, Aufwand und Lizenz. Die Aufwandsangaben sind Erfahrungswerte für die erste Version; der Betrieb (Nachschärfen, Aktualisieren) kommt jeweils dazu.

Testen und in Betrieb nehmen: der Lebenszyklus eines Klassifizierers

Ein Sensitive Info Type ist erst dann fertig, wenn er in einer Richtlinie unter echten Bedingungen gelaufen ist und niemand geschrien hat. Bis dahin ist er ein Entwurf. Der Weg dorthin hat fünf Schritte, und der wichtigste ist die Schleife zurück. Purview unterstützt jeden Schritt mit einem eigenen Werkzeug – man muss sie nur benutzen.

Der erste Test findet im Portal statt: Jeder SIT hat eine Testfunktion, in die du eine Datei hochlädst und sofort siehst, welche Muster mit welcher Konfidenz getroffen wurden. Das dauert Sekunden und ist der richtige Ort für die zwanzig Positiv- und zwanzig Negativbeispiele aus dem Fachbereich. Danach kommt die Simulation: eine DLP-Richtlinie im reinen Überwachungsmodus oder eine Auto-Labeling-Richtlinie in der Simulationsphase über einen realen Bestand – erst dort siehst du, wie sich der Typ auf zwei Millionen Dokumente verhält und welche Fehltreffer im Portal-Test unsichtbar blieben. Wie diese Simulationen im Detail funktionieren, beschreiben die Spokes zur DLP-Einführung im Simulationsmodus und zum Auto-Labeling. Erst nach dieser Schleife geht der Typ in scharfe Richtlinien; und weil derselbe Typ in vielen Richtlinien gleichzeitig steckt, gilt: nie den produktiven Typ „mal eben" ändern, sondern eine Kopie anlegen, testen, umschalten.

Skizze 3: Der Lebenszyklus eines Klassifizierers – bauen, testen, simulieren, einsetzen, beobachten, nachschärfen.

Im Betrieb liefern drei Quellen die Fehltreffer, die du brauchst, um nachzuschärfen: die DLP-Alarme mit ihren Begründungen bei Überschreibungen („kein Kundendokument, das ist unsere Preisliste"), der Activity Explorer mit den Label-Herabstufungen und die schlichten Beschwerden aus den Fachbereichen. Ein monatlicher Blick darauf und eine vierteljährliche Neusimulation je produktivem Typ halten das System sauber. Wer SITs für DLP in Exchange und Teams einsetzt, findet die kanalspezifischen Feinheiten – Anhänge, Betreffzeilen, Chatverläufe – im Spoke zur DLP für Exchange und Teams.

Der Deutschland-Winkel: Art. 9, Trainingsdaten und der Betriebsrat

Sensitive Info Types sind das technische Vokabular, mit dem der Datenschutzbeauftragte seine Datenkategorien in Purview übersetzt – und deshalb sollte er sie mitdefinieren. Besonders wichtig sind die besonderen Kategorien nach Art. 9 DSGVO: Gesundheitsdaten, Religionszugehörigkeit, Gewerkschaftsmitgliedschaft, sexuelle Orientierung. Für Gesundheitsdaten liefert Microsoft mit den medizinischen Begriffen und Diagnoseschlüsseln (ICD-Codes) brauchbare Bausteine; für Religion und Gewerkschaft musst du mit Schlüsselwortwörterbüchern selbst bauen, etwa aus den Kirchensteuermerkmalen und Gewerkschaftsnamen in der Lohnabrechnung. Diese Typen gehören in DLP- und Retention-Richtlinien mit strengeren Regeln als die übrigen – und ihre Existenz gehört ins Verzeichnis der Verarbeitungstätigkeiten, weil sie eine Verarbeitung besonderer Kategorien beschreiben.

Zwei Punkte betreffen die Datenschutzseite der Mechanismen selbst. Exact Data Match lädt eine gehashte und gesalzene Tabelle mit echten Stammdaten in den Purview-Dienst; die Klartextwerte verlassen das Unternehmen nicht, aber der Vorgang gehört dokumentiert und mit dem Datenschutzbeauftragten abgestimmt. Und trainierbare Klassifizierer werden mit echten Dokumenten trainiert – fünfzig bis fünfhundert Arbeitsverträge, Personalbögen, Kündigungen. Diese Trainingsdaten sind personenbezogen, sie liegen in einem SharePoint-Ordner mit Zugriff für die trainierenden Administratoren, und sie sollten nach dem Training gelöscht oder auf Zugriff „nur Purview-Admin" reduziert werden. Der Betriebsrat schließlich hat mit den Erkennungsregeln selbst wenig Streit – ein SIT bewertet Inhalte, keine Menschen. Aber die Richtlinien, die auf SITs aufbauen, erzeugen Alarme, die Namen tragen; das ist Sache der Purview-Betriebsvereinbarung nach § 87 Abs. 1 Nr. 6 BetrVG. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist an den Tisch.

Stolperfallen aus der Praxis

Zählwert eins und niedrige Konfidenz. Die erste Richtlinie soll „nichts übersehen" und schlägt deshalb bei jedem Einzeltreffer an. Ergebnis: Hunderte Alarme am Tag, alle aus Geschäftsbriefen mit Fußzeilen-IBAN. Hohe Konfidenz, Zählwert drei bis zehn, Kombinationen. Lieber die Kundenliste finden als jeden Brief markieren.

Regex ohne Wortgrenzen und ohne Negativtest. Das Muster trifft in Telefonnummern, Zeitstempeln und Bestellnummern. Anker setzen, mit zwanzig Dokumenten testen, in denen das Muster nicht vorkommen darf.

Der produktive SIT wird direkt geändert. Er steckt in vier DLP-Richtlinien und zwei Auto-Labeling-Regeln; die Änderung wirkt überall gleichzeitig, und niemand hat simuliert. Kopie anlegen, testen, in einer Richtlinie nach der anderen umschalten.

Der trainierbare Klassifizierer soll Zahlen finden. „Trainiere ihn auf unsere Kundennummern" – geht nicht, das ist ein Regex-Fall. Klassifizierer erkennen Dokumentarten, keine Muster.

Vorgefertigter Klassifizierer ungetestet für deutsche Dokumente. „Verträge" trifft englische Verträge tadellos und deutsche gemischt. Vor dem Einsatz mit dreißig echten deutschen Dokumenten prüfen; bei Bedarf eigenen Klassifizierer trainieren.

Trainingsdaten bleiben liegen. Der SharePoint-Ordner mit dreihundert echten Personalakten fürs Training existiert zwei Jahre später noch, mit Zugriff für das ganze IT-Team. Nach dem Training löschen oder auf Purview-Admins beschränken – und im Verzeichnis der Verarbeitungstätigkeiten vermerken.

Fazit: Erkennung ist Handwerk, nicht Hellseherei

Alles, was Purview schützt, labelt, bremst oder meldet, beginnt mit der Frage, woran es schützenswerte Inhalte erkennt – und die Antwort sind Sensitive Info Types und Klassifizierer, die jemand bewusst gebaut, getestet und nachgeschärft hat. Vorgefertigte Typen für die Standardfälle, eigene Typen mit Anker und Stützwörtern für die hauseigenen Nummern, Fingerprints für Formulare, Exact Data Match nur bei echtem Bedarf, trainierbare Klassifizierer für Dokumentarten und immer in Kombination: Das ist das Handwerkszeug. Wer es beherrscht, bekommt DLP-Richtlinien, die man scharf schalten kann, und KI-Berichte, die man dem Vorstand zeigen kann. Wo diese Schicht im Gesamtbild sitzt, zeigt der Purview-Überblick; was die Lizenzfragen dazu bedeuten, der Spoke zur Purview-Lizenzierung.

Wenn du eigene Sensitive Info Types und Klassifizierer nicht nur verstehen, sondern im eigenen Tenant bauen und testen willst – mit deinen Personalnummern, deinen Formularen, deinen Fehltreffern: Der zweitägige Hands-on-Workshop aus den Purview-Schulungen macht genau das.

FAQ: Häufige Fragen zu Sensitive Information Types und Klassifizierern

Was ist ein Sensitive Information Type in Microsoft Purview?

Ein Sensitive Information Type (SIT) ist eine Erkennungsregel, mit der Purview schützenswerte Inhalte identifiziert – zum Beispiel IBANs, Personalausweisnummern oder eigene Personalnummern. Er besteht aus einem Muster (Regex, Schlüsselwortliste, Wörterbuch oder Prüffunktion), Stützwörtern im Umfeld und Konfidenzstufen. DLP-, Auto-Labeling-, Retention- und Insider-Risk-Richtlinien greifen SITs auf und legen fest, ab welcher Konfidenz und Trefferzahl sie reagieren.

Welche vorgefertigten Sensitive Info Types gibt es für Deutschland?

Unter anderem IBAN, Personalausweisnummer, Steuer-Identifikationsnummer, Reisepassnummer, Führerscheinnummer, Umsatzsteuer-Identifikationsnummer und deutsche Postanschriften, dazu europaweite Typen für Kredit- und Debitkarten, Sozialversicherungs- und nationale Identifikationsnummern sowie sprachmodellbasierte Entitäten für Personennamen und medizinische Begriffe. Die Liste wächst regelmäßig; die vollständige Aufstellung steht im Purview-Portal unter Datenklassifizierung.

Brauche ich für eigene Sensitive Info Types Microsoft 365 E5?

Nein. Eigene SITs mit Regex und Schlüsselwörtern, Schlüsselwortwörterbücher und Dokument-Fingerprints sind ab Microsoft 365 E3 möglich. E5 oder E5 Compliance brauchst du für Exact Data Match, für trainierbare Klassifizierer und für einige erweiterte Workloads bei Fingerprints (Stand 2026).

Was ist der Unterschied zwischen einem Sensitive Info Type und einem trainierbaren Klassifizierer?

Ein SIT erkennt Muster – Zahlenfolgen, Schlüsselwörter, Prüfsummen – und liefert Treffer mit Konfidenzstufen. Ein trainierbarer Klassifizierer erkennt Dokumentarten ohne festes Muster – Verträge, Rechnungen, Lebensläufe – anhand von Beispielen, mit denen er trainiert wurde, und liefert eine Ja-Nein-Einschätzung. SITs sind präzise und schnell gebaut, Klassifizierer sind unscharf und aufwendig, aber die einzige Wahl für Freitext-Dokumentarten. Am besten wirken beide kombiniert.

Was ist Exact Data Match und wann lohnt es sich?

Exact Data Match (EDM) erkennt Werte, die tatsächlich in deinen Stammdaten stehen – Kundennummern, Sozialversicherungsnummern, Vertragsnummern –, indem du eine gehashte Tabelle dieser Werte in Purview hochlädst. Es hat praktisch keine Fehltreffer, braucht aber einen laufenden Prozess für die Aktualisierung der Tabelle und E5. Es lohnt sich bei großen Stammdatenbeständen mit echtem Abflussrisiko; für kleinere Bestände reicht meist ein guter Regex mit Stützwörtern.

Wie teste ich einen Sensitive Info Type, bevor er in eine Richtlinie kommt?

Zuerst mit der Testfunktion im Purview-Portal, in die du echte Dateien hochlädst – etwa zwanzig, in denen das Muster vorkommt, und zwanzig, in denen es nicht vorkommen darf. Danach in einer DLP-Richtlinie im reinen Überwachungsmodus oder einer Auto-Labeling-Simulation über einen realen Bestand, um Fehltreffer zu finden, die im Einzeltest unsichtbar bleiben. Erst wenn die Stichproben stimmen, gehört der Typ in eine scharfe Richtlinie.

Wo fange ich mit Sensitive Info Types an?

Mit den vorgefertigten deutschen Typen und einer Simulationsrichtlinie: IBAN, Personalausweis, Steuer-ID mit hoher Konfidenz und Zählwert drei bis fünf, vier Wochen im Überwachungsmodus, Ergebnisse mit Datenschutzbeauftragtem und Fachbereichen durchsehen. Erst dann den ersten eigenen Typ – meist die Personal- oder Kundennummer – mit Wortgrenzen, Stützwörtern aus echten Dokumenten und Portal-Test bauen. Trainierbare Klassifizierer kommen später, wenn Freitext-Dokumentarten erkannt werden sollen.