Finden, nicht durchleuchten

IT öffnet den Catalog „für Transparenz“. Search indexiert die HR-Site. Copilot findet den Gehaltsbrief neben dem KPI-Pack. HR stoppt den Crawl — und Teams verstecken Owner wieder im privaten Drive.

Hier: drei Schichten — Arbeit auffindbar, Akte geschlossen, Directory mit Wahl. Keine Transparenz-Policy für alles. Workforce-DSDR bleibt in der HR-Landschaft; Zweck und DPIA in DSGVO Foundations.

Problem

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 den Crawl komplett. verantwortliche Person, Pack und KPI verschwinden mit. Die nächste Funktion startet 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. Arbeit: Need-to-share. Akte: Need-to-know. Directory: Pflichtkern plus Wahl. Kein globaler Schalter.
2. Ein Accountable je Schicht. Data Owner für Arbeit. HR Owner für die Akte. HR plus Person für den Wahlkern. Privacy/Legal beraten, werden nicht heimliches A.
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. Visibility-Contract von Practice; HR/Privacy gegenzeichnen das Crawl-Gate.

Nach 30 Tagen ist das Pack auffindbar und die Akte unsichtbar im Index. Das ist der Test — nicht ein offener Tenant.

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. Visibility-Contract 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 keinen verantwortliche Person.
• Catalog-Admin als HR-verantwortliche Person. Scheitert, weil Plattformmacht keine Akten-Freigabe ist.
• Preference als Analytics-Freigabe. Scheitert, weil Wahlkern keine People-Analytics-Rechtsgrundlage ist.

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 — Finden, nicht durchleuchten
• Lernpfad — Finden, nicht durchleuchten

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.

30 Tage: Drei Defaults sagbar. Eine HR-Site außerhalb des Index. Ein Pack im Catalog. Kein Tenant-weiter Crawl.

90 Tage: Ein Visibility-Contract mit Gegenzeichnung. Negative Tests gehalten. Dann Teil 2.

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

Die drei Defaults aus Teil 1 nützen wenig, wenn Owner, Pack und KPI wieder in Chat und privatem Drive liegen. Silos entstehen in Schicht 1 — nicht weil HR schützt, sondern weil Arbeit unauffindbar bleibt. Gegenreaktion „alles auf“ öffnet Schicht 2. Dieser Teil schneidet die Allowlist der Arbeit.

Der Korridor macht Keys joinbar. Hier wird sichtbar, wo das Pack liegt — ohne die Person hinter dem Owner-Namen zu öffnen.

← Vorheriger Teil · Nächster Teil →

z der Person versteckt das Arbeitsprodukt. Die nächste Funktion findet weder Owner noch Pack und baut ein Schatten-Mart.

Lösung: Eine Work-Allowlist im Catalog: Titel, Owner-Rolle, Status, Zweck, Join-Keys. Keine Aktenfelder, keine privaten Kanäle als führende Quelle.

In einem Satz: Die Arbeit muss auffindbar sein — die Person dahinter nicht.

Entscheidung

1. Allowlist der Arbeit, nicht des Menschen. Catalog zeigt Pack-Titel, KPI-ID, Owner-Rolle, Vertreter, Status, Zweck. Kein Gehalt, kein Foto-Zwang, kein Aktenlink.
2. Owner ist eine Rolle am Produkt. Name und dienstliche Mail dürfen Schicht-1-Metadaten sein. Sie ziehen Schicht 2 nicht nach.
3. Standard-Dateinamen bleiben Need-to-share. kpi-cards.csv, join-pack.md, visibility-contract.md — Welche Artefakte entstehen?.
4. Kontrolliertes Local bleibt erlaubt. Unkontrolliertes Shadow bleibt verboten — When Shadow BI is allowed. Verstecken ins Private Drive ist kein Schutz.
5. Nachbar findet den Join, nicht die Vita. Consulted prüft Auffindbarkeit und Joinbarkeit. Kein zweites A, kein People-Profil als Pflicht.

Sizing

Anwendungsbeispiel: Owner versteckt, Finance startet neu

Ausgangslage: Nach dem HR-Crawl-Stop löscht Sales den Catalog-Eintrag „aus Datenschutz“. Das Forecast-Pack lebt in einem privaten Teams-Channel. Controlling sucht den Owner, findet eine alte Mail und baut forecast_v3.xlsx. Der Join zum Close fehlt. Der Korridor war nie das Problem — die Auffindbarkeit war es.

Korrektur:

1. Pack zurück in den Catalog: Titel, Status, KPI-IDs, Deal-ID.
2. Owner = Rolle plus dienstliche Mail. Kein Link zur Personalakte.
3. Privater Channel wird Local mit Ablauf, nicht führende Wahrheit.
4. Finance findet das Pack in Search ohne HR-Treffer.
5. Visibility-Contract: Schicht 1 Allowlist ja, Schicht 2 weiter Deny.

Betriebsablauf (nummeriert)

1. Ein Arbeitsprodukt benennen, das die nächste Funktion braucht.
2. Mindestfelder der Work-Allowlist schreiben: Titel, Owner-Rolle, Status, Zweck, Dateiname.
3. Akten- und Profilfelder explizit ausschließen.
4. Shadow-Pfad inventarisieren und als Local oder Stop markieren.
5. Search-Probe: Pack gefunden, Akte nicht.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Datenschutz = Catalog leeren. Scheitert als Silo; Finance baut Schatten.
• verantwortliche Person-Name als Akte. Scheitert, weil Metadaten der Arbeit mit Schicht 2 vermischt werden.
• Privater Channel als führendes Pack. Scheitert, weil die nächste Funktion nichts findet.
• Metadatenimport der Personenprofile. Scheitert als Durchleuchtung unter dem Label Transparenz.
• Join-Pack ohne Catalog-Zeile. Scheitert, weil Keys existieren, aber niemand sie findet.
• Ein Search für Arbeit und HR. Scheitert in Teil 3.

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 — Finden, nicht durchleuchten
• Lernpfad — Finden, nicht durchleuchten

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.

30 Tage: Ein Pack im Catalog mit Owner-Rolle. Search-Probe: Arbeit ja, Akte nein.

90 Tage: Allowlist je erster Domain. Kein privater Channel als führende Quelle. Dann Teil 3.

Checkliste

• Work-Freigabeliste nennt Titel, verantwortliche Person-Rolle, Status, Zweck, Dateiname.
• Aktenfelder sind aus der Work-Suche ausgeschlossen.
• Privater Channel ist Local oder Stop, nicht führend.
• Nachbar findet das Pack ohne Vita des Owners.
• Join-Keys bleiben im Korridor; Auffindbarkeit ist dieser Teil.

Artefakt

Work-Allowlist (eine Seite): Produkte, Mindestfelder, ausgeschlossene Personenfelder, Search-Scope, Local-vs-Shadow.

Tools

• Visibility-Vereinbarung — Schicht 1 Freigabeliste im selben Pack.
• Join-Pack — Keys, die die nächste Domain erbt.
• Stakeholder Matrix — verantwortliche Person vs. HR vs. technischer Betreiber.

Weiterführend

• Die nächste Funktion nicht verbauen
• Metadata Catalog Lineage
• When Shadow BI is allowed
• Welche Artefakte entstehen?

Die Work-Allowlist aus Teil 2 schützt den Catalog. Die größere Lücke sind Dateien: Vertrag, Gehaltsbrief, AU, Zielvereinbarung, Ausweis-Scan liegen in SharePoint, Mail, Chat und Tickets. Search und Copilot crawlen sie mit, wenn niemand ein Gate setzt. Felder haben eine Allowlist — HR Analytics-Allowlist. Dateien brauchen denselben Default-Deny.

← Vorheriger Teil · Nächster Teil →

zu Search-Treffern, während das Pack weiter unauffindbar bleibt oder mitgesperrt wird.

Lösung: Aktenklasse, HR-Pfad, Crawl-/Export-Gate und Side-Copy-Inventar vor jedem Index. Arbeit bleibt in einem anderen Scope.

In einem Satz: Personalakten bleiben im HR-Pfad — Search und Copilot erben sie nicht.

Entscheidung

1. Default-Deny für Akten. Vertrag, Gehalt, Gesundheit, Leistung, Disziplin, Ausweis — kein Search, kein Copilot, kein allgemeiner Mart.
2. HR-Pfad ist der einzige Kanal. HRIS plus benannte Record-Site. Private Drives, Chat-Anhänge und Ticket-PDFs sind Shadow — Nonprod, Exports, Caches.
3. Klassifizieren vor dem Crawl. Label, Hold, Zweck — sonst landet Entwurf neben Record — Content vor dem Crawl.
4. Analytics bleibt Allowlist. Kein Self-Service mit allen Worker-Attributen — Zweckbindung und Maskierung.
5. Stop, wenn der Index die Akte kennt. Ein Treffer auf Gehaltsbrief oder AU ist Publish-Fail, nicht „wir filtern später“.

Sizing

Anwendungsbeispiel: Copilot findet den Gehaltsbrief

Ausgangslage: Die Policy-Site ist „AI-ready“. Dieselbe Connector-Konfiguration crawlt HR-Personal. Ein Team Lead fragt Copilot nach „Vergütung Nord“. Die Antwort zitiert ein PDF. HR stoppt alles — inklusive der KPI-Packs aus Teil 2.

Korrektur:

1. Estate-Map: Policy-Site vs. Record-Site — Content-Estate.
2. Record-Site aus Search, Copilot und Vector-Index.
3. Side copies: Mail-Anhänge, Ticket-PDFs, Nonprod-Refresh inventarisieren.
4. Pack-Scope bleibt an. Akte bleibt Deny.
5. Visibility-Contract: Crawl-Gate-Zeile mit Owner und Testdatum.

Betriebsablauf (nummeriert)

1. Aktenquellen listen: Site, Mailbox, Export, Ticket, Nonprod.
2. Klasse je Quelle: Record / Arbeit / unbekannt. Unbekannt ist blocked.
3. Crawl- und Export-Gate setzen, bevor der nächste Job läuft.
4. Side-Copy-Inventar mit Owner und Ablauf.
5. Negative Test: Query auf Gehalt oder AU darf nichts aus Schicht 2 liefern.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Ein Connector für Richtlinien und Personal. Scheitert als Durchleuchtung unter KI-Ready.
• „Wir filtern in der UI“. Scheitert, weil der Index die Akte schon kennt.
• HR-Export in den allgemeinen Lake. Scheitert an Zweckbindung — Governance in HR.
• Crawl-Stop für den ganzen Tenant. Scheitert als Silo für Schicht 1.
• Ticket-PDF ignorieren. Scheitert, weil die Akte im Anhang lebt.
• Foto-Preference als Akten-Freigabe. Scheitert in Teil 4.

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 — Finden, nicht durchleuchten
• Lernpfad — Finden, nicht durchleuchten

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.

30 Tage: Eine Record-Site außerhalb von Search und Copilot. Ein negativer Test dokumentiert.

90 Tage: Side-Copy-Inventar mit Owner. Kein HR-Export in den allgemeinen Lake. Dann Teil 4.

Checkliste

• Aktenquellen sind klassifiziert; unbekannt ist blocked.
• Crawl- und Export-Prüfpunkt haben Config-Nachweis.
• Arbeit und Akte nutzen getrennte Index-Scopes.
• Side copies (Mail, Ticket, Nicht-Produktion) sind inventarisiert.
• Negativer Test: Gehalt/AU nicht im Index.

Artefakt

Akten-Gate-Seite: Quellen, Klasse, Block, Side copies, Testdatum, Stop wenn der Index die Akte kennt.

Tools

• Visibility-Vereinbarung — Crawl-Prüfpunkt-Zeile.
• personenbezogene Daten Richtlinie Generator — Feldklassen, wenn Exporte nötig sind.
• personenbezogene Daten Unreviewed Prüfpunkt — Ungeprüftes bleibt draußen.

Weiterführend

• Analytics-Freigabeliste
• Content vor dem Crawl klassifizieren
• Clean before retrieve
• BDSG, Beschäftigtendaten und Betriebsrat

Schicht 1 macht Arbeit auffindbar. Schicht 2 hält die Akte geschlossen. Schicht 3 ist das interne Directory: wer darf Foto, Bio, Skills, privates Telefon sehen? Ohne Schnitt wird das Häkchen zur Pseudo-Einwilligung für Analytics — oder jedes optionale Feld verschwindet und das Unternehmen verliert den Pflichtkern.

Im Beschäftigungsverhältnis ist Einwilligung oft unfrei. Deshalb gilt dasselbe Muster wie im Marketing — Zweck und Rechtsstatus getrennt vom Kanalwunsch — Consent- und Preference-Contracts. Nur die Rechtsgrundlage ist eine andere: Erforderlichkeit für den Pflichtkern, Preference nur für das Optionale. People Analytics bleibt Zweck- und Wirkungsentscheidung — BDSG.

← Vorheriger Teil

z, Search und Analytics gleichzeitig tragen. Oder optionale Felder werden mit der Akte gesperrt — der Pflichtkern stirbt mit.

Lösung: Pflichtkern aus dem Beschäftigungsverhältnis; Wahlkern mit Audience; Preference-Record; Widerruf bis Index. Analytics und Akte bleiben draußen.

In einem Satz: Die Person wählt, wem sie optionale Felder zeigt — nicht, ob die Akte oder People Analytics erlaubt ist.

Entscheidung

1. Pflichtkern ist kein Opt-in. Name, Rolle, Team, dienstliche Mail, Vertreter, Owner-Zuordnung zu Datenprodukten — Erforderlichkeit, minimiert, zweckgebunden.
2. Wahlkern hat Audience. Foto, Kurzbio, Skills, Pronomen, privates Telefon: nur ich · Team · Funktion · Unternehmen · nicht im Search/AI-Index.
3. Preference ≠ Consent ≠ Analytics-Freigabe. Der Record speichert Audience und Zeit. Er legalisiert keine Joins auf Leistung, Abwesenheit oder Gehalt.
4. Widerruf trifft den Index. UI, Graph, Search, Copilot, Caches — sonst ist Preference Folie. Gleiches Muster wie DSDR bis in Exporte — HR DSDR.
5. Stop, wenn Foto Gehalt nachzieht. Negativer Test bleibt Abnahme. Practice exportiert visibility-contract.md — nicht Sales.

Sizing

Anwendungsbeispiel: Häkchen soll das People-Dashboard tragen

Ausgangslage: People Analytics will ein Engagement-Dashboard. Legal sagt „wir holen Einwilligung im Directory“. Alle klicken, weil sonst das Foto fehlt. Das Dashboard joint Krankheitstage. Der Betriebsrat stoppt. IT löscht das Directory. Schicht 1 verliert den Owner-Namen.

Korrektur:

1. Pflichtkern bleibt: Name, Rolle, dienstliche Mail am Pack.
2. Foto und Bio nur nach Preference — unabhängig vom Dashboard.
3. People Analytics als eigene Zweckentscheidung mit Mitbestimmung — nicht über das Häkchen.
4. Widerruf der Bio entfernt den Chunk aus Search und Copilot innerhalb der vereinbarten Frist.
5. Visibility-Contract: Pflichtkern, Wahlkern, Preference-Record, Stop-Zeile, Nachbar HR/Privacy.

Betriebsablauf (nummeriert)

1. Pflichtkern und Wahlkern listen — Felder, Zweck, Audience.
2. Preference-Record: Person, Feld, Audience, Zeit, Textversion.
3. Index-Gate: Wahlkern nur nach Audience; nicht im Search heißt nicht im Index.
4. Widerruf-Pfad testen: UI und Index.
5. Export visibility-contract.md. Analytics bleibt ein anderes Produkt.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Ein Häkchen für Foto und People Analytics. Scheitert als unfreie Einwilligung und als Zweckvermischung.
• Alle optionalen Felder sperren. Scheitert, weil der Pflichtkern mitstirbt und Schicht 1 zum Silo wird.
• Widerruf nur in der UI. Scheitert, weil Copilot den Chunk behält.
• Marketing-Consent 1:1 auf HR. Scheitert: Kunden-Opt-in ist nicht Beschäftigtenrecht.
• Foto öffentlich, Gehalt folgt. Scheitert am negativen Test aus Teil 1.
• Catalog-Admin setzt Preference für alle. Scheitert, weil Plattformmacht keine Personenwahl ist.

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 — Finden, nicht durchleuchten
• Lernpfad — Finden, nicht durchleuchten

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.

30 Tage: Pflichtkern und Wahlkern getrennt. Ein Widerruf-Test an Foto oder Bio.

90 Tage: Ein Visibility-Contract mit Gegenzeichnung. Preference legalisiert kein Analytics-Produkt. Serie STOP — Practice behält den Contract.

Checkliste

• Pflichtkern ist minimiert und nicht opt-in.
• Wahlkern hat Audience-Stufen inklusive Search/KI-Nein.
• Preference-Record ist von Analytics-Zweck getrennt.
• Widerruf trifft UI und Index.
• visibility-contract.md hat Stop-Zeile und Nachbar-verantwortliche Person.

Artefakt

visibility-contract.md: Kopf (Organisation, Datum), drei Schichten, Work-Allowlist, Akten-Gate, Pflichtkern, Wahlkern, Preference-Record, Widerruf-Pfad, Nachbar-Owner (HR/Privacy), Stop wenn Foto Gehalt nachzieht oder der Index die Akte kennt.

Tools

• Visibility-Vereinbarung — dieses Artefakt erzeugen.
• personenbezogene Daten Richtlinie Generator — Feldklassen, wenn Analytics ein eigenes Produkt wird.
• Decision Brief — Destination ohne gläserne Person.

Weiterführend

• BDSG, Beschäftigtendaten und Betriebsrat
• Consent- und Preference-Vereinbarungen
• Auskunfts- und Löschrechte und Workforce-Exporte
• Der gemeinsame Weg ist das Ziel
• HR-Landschaft
• DSGVO Foundations
• Korridor für Folgeprojekte