Klassifikation vor dem Crawl

Der Policy-Bot crawlt SharePoint „Policies“ und eine HR-Mailbox ohne Label und Hold-Status. So landen Entwurf und Record, Freigabe und Legal Hold gleichwertig im Index.

Akten-Sites gehören nicht in denselben Index wie Policies — Personalakten bleiben im HR-Pfad.

Die Estate-Map aus Teil 1 sagt wo. Dieser Teil ist das Klassifikations- und Hold-Gate vor jedem Content-Ingest.

Vorher: Content ist auch ein Estate. Weiter: Zweckbindung: Assistenz ≠ Archiv ≠ Training.

In einem Satz: Kein Crawl ohne Klasse, Record-Status und Hold-Flag — unlabeled und gehaltenes Material bleiben draußen.

Entscheidung

Bevor eine Content-Quelle den AI-Pfad betritt:

1. Label oder Default-Block — unlabeled ist blocked, bis Steward oder Owner eine Klasse setzt;
2. Records ≠ Working Copy — nur freigegebene Record-Versionen dürfen Policy-/Vertragsfragen grounden;
3. Hold stoppt Mutation und Ingest-Refresh — Legal Hold blockt Purge und neue Snapshots; Scope in Teil 5;
4. Klasse steuert AI-Aktion — Preview in Teil 3: restricted → kein Training, höchstens minimiertes Assistenz-Retrieval;
5. Owner für Klassen-Semantik, Steward für Coverage, Custodian für Crawl-Allowlist, Legal für Holds.

Normative Retention: Data Lifecycle & Retention.

Klassifikations-Workflow

1. Estate-Zeilen mappen

Der Steward hängt Sensitivity- und Record-Status an jede Estate-Zeile aus Teil 1. Owner bestätigt, was Record ist. Ohne Mapping crawlt der Job persönliche Postfächer und Project-Sites mit derselben Policy.

2. Unlabeled blocken

Custodian setzt Default: unlabeled = blocked auf der Crawl-Allowlist. Steward misst Label-Coverage vor Enablement. Ein Crawl, der „General“ als Klasse akzeptiert, indexiert den Entwurf neben Vertrag_final.pdf.

3. Records von Entwürfen trennen

Owner trennt Record-Libraries von Working-Draft-Ordnern. Steward schreibt die Trennregel in die Matrix. Custodian allowlistet nur Record-Pfade für Grounding. Wer beides im selben Ordner lässt, zitiert den Entwurf als geltende Policy.

4. Holds verdrahten

Legal liefert Case-ID und Hold-Owner. Custodian verknüpft System-IDs und stoppt Ingest-Refresh plus Purge. Ein Hold nur auf der Mailbox, während der Index weiter snapshotet, ist das zweite Versagen — Legal Hold.

5. Coverage als Gate

Steward verlangt die Coverage-Metrik vor Job-Start. Owner gibt den Pilot erst frei, wenn ein unlabeled oder held Item den Index nicht mehr erreicht. Coverage nach dem ersten Embed nachzuziehen heißt, den Bot mit Entwürfen zu füttern.

Handoffs

Anti-Patterns

• Index-Jobs auf „alles unter /Knowledge“ starten
• Records und Working Copies im selben Crawl belassen
• Legal Hold auf der Quelle setzen, den Index aber weiter refreshen
• Persönliche Postfächer und Record-Sites gleich behandeln
• Klasse erst nach dem ersten Embedding nachziehen

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Mails & Dokumente vor KI
• Lernpfad — Mails & Dokumente vor KI

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Estate-Zeilen des Pilots auf Sensitivity- und Record-Status mappen.
2. Default unlabeled = blocked auf der Crawl-Allowlist setzen.
3. Aktive Legal Holds mit System-IDs verknüpfen und Ingest stoppen.
4. Record-Libraries von Draft-Ordnern in der Allowlist trennen.