Drei Schichten interner Sichtbarkeit

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• Owner — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• Custodian — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Evidence — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Ausgangslage

Vier Muster erzeugen denselben Streit — obwohl niemand „böse“ ist:

• Eine Richtlinie. Search, Catalog und Copilot teilen denselben „intern sichtbar“-Schalter. Der Gehaltsbrief landet neben dem Join-Pack.
• Metadatenimport als Transparenz. Inventur fühlt sich wie Vermessung der Person an. Teams verstecken Definitionen, bevor der Schichtenschnitt steht.
• Einwilligung als Ausweg. Ein Häkchen im Directory soll People Analytics und Aktenzugriff tragen. Im Beschäftigungsverhältnis ist das oft unfrei — BDSG.
• Schutz als Silo. HR sperrt die Suche komplett. Damit verschwinden auch verantwortliche Rollen, Arbeitspakete und Kennzahlen. Der nächste Bereich startet wieder bei null.

Der gemeinsame Weg schützt vor Enteignung der Zahl. Dieser Teil schützt vor der gläsernen Person, ohne Silos zu zementieren.

Entscheidung

1. Drei Schichten, drei Defaults. Freigegebene Arbeitsprodukte: Need-to-share innerhalb des zulässigen Empfängerkreises. Akten: Need-to-know. Directory: begründeter dienstlicher Kern plus separat bewertete optionale Sichtbarkeit. Auch Arbeitsmetadaten können vertraulich oder personenbezogen sein; kein globaler Offen-Schalter.
2. Entscheidungen und Mandate trennen. Data Owner verantwortet die Arbeitssicht, HR die Akten- und Directory-Vorgaben. Die betroffene Person steuert eine zulässig vorgesehene optionale Sichtbarkeit, übernimmt dadurch aber nicht die rechtliche Verantwortung des Arbeitgebers. Privacy/Legal und gegebenenfalls Beschäftigtenvertretung wirken nach ihrem jeweiligen Mandat mit.
3. Metadaten der Arbeit ≠ Inhalt der Person. Catalog darf Owner-Namen und Pack-Titel zeigen. Er darf die Personalakte des Owners nicht indexieren.
4. Preference steuert nur Schicht 3 optional. Sie legalisiert weder Analytics-Joins noch Akten-Crawl.
5. Contract vor Crawl. visibility-contract.md steht, bevor Search oder Copilot eine HR-Site oder ein Directory-Feld erbt.

Sizing

Anwendungsbeispiel: Katalogimport indexiert die HR-Site

Ausgangslage: Ein Mid-Market-Hersteller will „endlich Transparenz“. IT crawlt SharePoint. Die Site HR-Personal liegt im selben Tenant wie KPI-Packs. Copilot beantwortet „Was verdient Team Lead Nord?“ mit einem PDF. HR stoppt den Index. Sales versteckt das Forecast-Pack wieder in einem privaten Channel.

Korrektur:

1. Destination bleibt: beschriftetes Pack, keine Enteignung, keine gläserne Person.
2. Schicht 1: Pack-Titel, Owner, Status bleiben im Catalog.
3. Schicht 2: HR-Personal aus Search, Copilot und Vector-Index — Content vor dem Crawl klassifizieren.
4. Schicht 3: dienstliche Mail bleibt Pflichtkern; Foto und Bio nur nach Preference.
5. Sichtbarkeitsvereinbarung von Practice; HR/Privacy gegenzeichnen das Crawl-Gate.

Der Pilot ist bestanden, wenn das Arbeitspaket auffindbar bleibt und die Personalakte in Suche und KI-Assistenten nicht erscheint. Ein vollständig offener Mandant ist ausdrücklich kein Erfolgsmaßstab.

Betriebsablauf (nummeriert)

1. Drei Schichten auf eine Seite schreiben — Default, Accountable, Stop.
2. Ein Arbeitsprodukt (Pack oder KPI) und eine Akten-Quelle (Site oder Export) benennen.
3. Directory-Pflichtkern von Wahlkern trennen, bevor Search erbt.
4. Negative Tests formulieren: Foto ≠ Gehalt; Owner ≠ Akte; Widerruf trifft den Index.
5. Sichtbarkeitsvereinbarung exportieren, bevor der nächste Crawl läuft.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Ein Schalter „intern sichtbar“. Scheitert, weil Pack und Gehaltsbrief denselben Index teilen.
• Metadatenimport zuerst. Scheitert, weil Nachbarn Personen- und Arbeitsdaten verstecken — Der gemeinsame Weg.
• Einwilligung für alles. Scheitert im Beschäftigungsverhältnis — BDSG.
• Crawl-Stop ohne Schicht 1. Scheitert als Silo: die nächste Funktion findet keine verantwortliche Person.
• Katalogadministration entscheidet über Personalakten. Das scheitert, weil technische Berechtigungen keine fachliche Freigabe ersetzen.
• Preference als Analytics-Freigabe. Scheitert, weil Wahlkern keine People-Analytics-Rechtsgrundlage ist.

Umsetzung im Alltag

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Im verlinkten Arbeitsplan hältst du fest, wer die einzelnen Aufgaben übernimmt, bis wann sie erledigt werden und welche Entscheidungen noch offen sind.

• Arbeitsplan — Finden, nicht durchleuchten
• Lernpfad — Finden, nicht durchleuchten

Starte mit dem kleinsten echten 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.

Pilotkriterium: Ein Arbeitspaket ist im Katalog auffindbar, eine Personalaktenquelle bleibt aus Suche und KI-Index ausgeschlossen, und optionale Verzeichnisfelder lassen sich widerrufen. Erst nach bestandenen Positiv- und Negativtests wird die Regel auf weitere Quellen übertragen.

Checkliste

• Drei Schichten mit Default und einem Accountable — kein globaler Schalter.
• Arbeit und Akte sind getrennte Produkte, nicht zwei Labels auf derselben Site.
• Directory-Pflichtkern ist von Wahlkern getrennt.
• Negative Tests sind schriftlich, bevor Search oder Copilot erbt.
• Visibility-Vereinbarung steht vor dem nächsten Crawl.

Artefakt

Schichtenseite: drei Defaults, Accountable, Stop-Zeile, erste Work-Allowlist, erste gesperrte Akten-Quelle. Die Stance-Map bleibt der Dresscode; diese Seite macht Sichtbarkeit explizit.

Tools

• Visibility-Vereinbarung — Schichten, Crawl-Prüfpunkt, Preference, Stop.
• personenbezogene Daten Richtlinie Generator — Klassifikation und Maskierung für Felder.
• Decision Brief — Destination-Satz ohne gläserne Person.

Weiterführend

• Der gemeinsame Weg ist das Ziel
• Governance in HR
• personenbezogene Daten & Privacy Governance
• Korridor für Folgeprojekte