AI-Ethik und -Governance – Muster

Erfahren Sie mehr über “Gute Fairness – ethische AI-Governance praktizieren”

Muster

Wohin schauen	Wie gut aussieht
Einstein \| Trainingsdaten	✅ Salesforce CRM-Daten werden vor dem Training von Prognosemodellen auf demografische Darstellungslücken und Messinkonsistenzen überprüft
Einstein \| Trainingsdaten	✅ Historische Konvertierungsdaten werden anhand von Kundendemografien analysiert, um unterrepräsentierte Segmente zu identifizieren, die eine Überabtastung oder zusätzliche Datenerfassung erfordern
Einstein \| Bereitstellung	✅ Die Fairnessbewertung wird als obligatorisches Gate behandelt, das einer Sicherheitsüberprüfung entspricht, bevor Prognosemodelle die Produktion erreichen
Einstein \| Bereitstellung	✅ Demografische Parität, Chancengleichheit und ungleiche Auswirkungsverhältnisse werden vor der Bereitstellung über geschützte Gruppen hinweg berechnet
Einstein \| Bereitstellung	✅ Fairness-Kennzahlen werden vor der Modellbereitstellung für alle Kundensegmente als Screening-Auslöser – nicht als legale Pass/Fehlschlag-Linie – anhand der Vier-Fünftel-Regel (80 %-Schwellenwert) ausgewertet
Einstein Discovery \| Instrumentierung	✅ Prognosemodellentscheidungsdaten – Prognoseeingaben, -ausgaben und -modellversionen – werden über Einstein Discovery und benutzerdefinierte Instrumentierung erfasst, die die Verzerrungserkennung ermöglichen
CRM Analytics \| Überwachung	✅ CRM Analytics-Dashboards analysieren erfasste Prognosemodell-Entscheidungsdaten für Entscheidungsmuster über demografische Gruppen hinweg im Laufe der Zeit
CRM Analytics \| Überwachung	✅ CRM Analytics-Benachrichtigungen werden ausgelöst, wenn die Kennzahlen für demografische Parität oder Chancengleichheit über akzeptable Schwellenwerte hinausgehen
Einstein \| Funktionsentwicklung	✅ Alle Prognosemodellfunktionen werden mit statistischen Methoden auf Korrelation mit geschützten Merkmalen analysiert
Einstein \| Funktionsentwicklung	✅ Proxy-Funktionen (Region, Postleitzahl, Accountnamenmuster, Aktivitätszeiteinteilung, Gerätetyp) werden identifiziert und auf demografische Korrelation hin ausgewertet
Einstein \| Funktionsentwicklung	✅ Proxy-Funktionen werden entfernt oder umgewandelt, nachdem ausgewertet wurde, ob der Prognosewert die Aufnahme trotz Proxy-Effekten rechtfertigt

Antimuster

Wohin schauen	Wie schlecht sieht
Einstein \| Trainingsdaten	⚠️ Die Leadbewertung wird anhand von historischen Daten aus 10 Jahren trainiert, ohne die demografische Darstellung oder Servicequalitätsunterschiede zu untersuchen.
Einstein \| Trainingsdaten	⚠️ Historische Konvertierungsdaten werden direkt verwendet, ohne zu prüfen, ob unterschiedliche demografische Daten unterschiedlich behandelt wurden
Einstein \| Bereitstellung	⚠️ Einstein Funktionen werden ausschließlich anhand von allgemeinen Genauigkeitskennzahlen ohne Fairnessbewertung bereitgestellt.
Einstein \| Bereitstellung	⚠️ Demografische Parität oder ungleiche Auswirkungsverhältnisse werden vor der Produktionsbereitstellung nicht berechnet
Einstein \| Trust Layer	⚠️ Agentforce Interaktionen werden bereitgestellt, ohne die Trust Layer-Aktivierungserfassung für die Verzerrungserkennung zu aktivieren
CRM Analytics \| Überwachung	⚠️ Entscheidungsmuster werden im Laufe der Zeit nicht von demografischen Gruppen verfolgt; Verzerrungsabweichungen werden nicht erkannt
Einstein \| Funktionsentwicklung	⚠️ Geschützte Eigenschaften werden aus Trainingsdaten entfernt, vorausgesetzt, dies beseitigt automatisch Verzerrungen.
Einstein \| Funktionsentwicklung	⚠️ Regions-, Postleitzahlen- und Accountnamensmuster werden als Funktionen ohne Proxy-Korrelationsanalyse verwendet
Einstein \| Funktionsentwicklung	⚠️ Proxy-Funktionen, die als perfekte demografische Proxys dienen, werden beibehalten, ohne Alternativen zu bewerten

Muster

Wohin schauen	Wie gut aussieht
Agentforce \| Analytics	✅ CRM Analytics-Dashboards verfolgen Agentforce-Entscheidungsergebnisse anhand von Kundendemografien mithilfe von Einstein Trust Layer-Aktivierungsdaten
Agentforce \| Analytics	✅ Genehmigungsraten, Serviceantwortzeiten, Eskalationsraten und Zufriedenheitsbewertungen werden stratifiziert nach demografischer Gruppe überwacht
Agentforce \| Analytics	✅ CRM Analytics-Benachrichtigungen werden so konfiguriert, dass sie ausgelöst werden, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten, die untersucht werden müssen
Agentforce \| Ereignisüberwachung	✅ Ereignisüberwachungsprotokolle werden zur langfristigen Aufbewahrung an externes SIEM weitergeleitet, das die nativen Aufbewahrungsobergrenzen überschreitet
Agentforce \| Ereignisüberwachung	✅ SIEM-Abfragen identifizieren anomale Konzentrationen negativer Ergebnisse für bestimmte Benutzerpopulationen
Agentforce \| Feld-Aktivierungsprotokoll	✅ Das Feld-Aktivierungsprotokoll ist für benutzerdefinierte Objekte aktiviert, in denen Agentforce-Entscheidungsdaten gespeichert werden, wobei der archivierte Verlauf unbegrenzt bis zum Löschen beibehalten wird
Agentforce \| Feld-Aktivierungsprotokoll	✅ Field Audit Trail unterstützt langfristige Fairness-Überprüfungen und behördliche Untersuchungen, die eine Rekonstruktion historischer AI-Entscheidungen erfordern
CRM Analytics \| Überwachung	✅ CRM Analytics-Dashboards verfolgen Fairness-Signale: Plötzliche Änderungen in Entscheidungsverteilungen, Spitzen in verzerrten Kundenvorgängen, Leistungseinbußen für bestimmte Populationen
CRM Analytics \| Überwachung	✅ Warnungen werden ausgelöst, wenn die Genehmigungsraten für ein Kundensegment im Wochenvergleich um mehr als 15 % sinken, was eine Fairness-Untersuchung erfordert

Antimuster

Wohin schauen	Wie schlecht sieht
Agentforce \| Analytics	⚠️ Entscheidungsergebnisse werden nicht anhand der demografischen Daten verfolgt; Verzerrungsabweichungen bleiben unentdeckt, wenn sich Datenverteilungen verschieben
Agentforce \| Analytics	⚠️ Servicequalitätskennzahlen werden nicht nach demografischer Gruppe stratifiziert; ungleiche Ergebnisse bleiben unsichtbar
Agentforce \| Ereignisüberwachung	⚠️ Ereignisüberwachungsprotokolle basieren auf nativen Aufbewahrungsobergrenzen ohne externes SIEM für langfristige Fairness-Audits
Agentforce \| Ereignisüberwachung	⚠️ Entscheidungsmuster werden nicht über große Volumen von Interaktionen hinweg analysiert; anomale Konzentrationen werden übersehen
Agentforce \| Feld-Aktivierungsprotokoll	⚠️ Das Feld-Aktivierungsprotokoll ist nicht aktiviert. Entscheidungen mit historischer AI können für behördliche Untersuchungen nicht rekonstruiert werden
CRM Analytics \| Überwachung	⚠️ Fairnesssignale werden nicht überwacht; plötzliche Änderungen in Entscheidungsverteilungen bleiben unbemerkt

Muster

Wohin schauen	Wie gut aussieht
Einstein \| Trainingsdaten	✅ Salesforce CRM-Daten werden vor dem Training durch Überabtastung unterrepräsentierter Segmente oder Unterabtastung überrepräsentierter Segmente neu ausgeglichen
Data 360 \| Architektur	✅ Data 360 aggregiert Daten über mehrere Organisationen hinweg und stellt so verschiedene Trainingssets für Prognosemodelle sicher
Einstein \| Trainingsdaten	✅ Synthetische Datengenerierung ergänzt spärliche Segmente und schützt gleichzeitig die Privatsphäre durch differenzielle Datenschutztechniken
Einstein \| Funktionsentwicklung	✅ Proxy-Funktionen werden durch alternative Funktionen ersetzt, die Prognoseleistung ohne demografische Korrelation bieten
Einstein \| Funktionsentwicklung	✅ Branchenklassifizierung oder Unternehmensgröße werden anstelle der Region verwendet, wenn die Region als demografischer Proxy dient
Einstein \| Funktionsentwicklung	✅ Firmenspezifische Attribute werden anstelle von Accountnamenmustern verwendet, wenn Namen mit demografischen Daten korrelieren
Agentforce \| Nachbearbeitung	✅ Entscheidungsschwellenwerte werden pro demografischem Segment angepasst, um die Ergebnisraten nach dem Modelltraining anzugleichen, mit dem Unterschied, dass in den Vereinigten Staaten gemäß Titel VII (Civil Rights Act von 1991) keine Anpassung der Bewertungen oder Cutoffs nach geschützter Klasse für beschäftigungsbezogene Entscheidungen möglich ist und andere Rechtsordnungen ihre eigenen Einschränkungen auferlegen
Agentforce \| Nachbearbeitung	✅ Unterschiedliche Konfidenzschwellenwerte werden für unterschiedliche Kontexte verwendet, um gleiche Genehmigungsraten zu erzielen, während dasselbe zugrunde liegende Prognosemodell verwendet wird
Agentforce \| Nachbearbeitung	✅ Schwellenwertanpassungen werden mit einer geschäftlichen Begründung für eine unterschiedliche Behandlung dokumentiert, wobei anerkannt wird, dass in den Vereinigten Staaten keine Dokumentation für beschäftigungsbezogene Entscheidungen gemäß Titel VII die Bewertung pro Gruppe oder die Anpassung der Obergrenze als rechtmäßig ansieht
Einstein \| Modellumschulung	✅ Ein vierteljährlicher oder ereignisgesteuerter Umschulungsplan wird erstellt, um auftretende Verzerrungsmuster zu erfassen und die Abweichung von den ursprünglichen Fairness-Basiswerten zu korrigieren
Einstein \| Modellumschulung	✅ Fairness-Kennzahlen werden für jede Modellversion vor der Produktionsbereitstellung neu validiert, um sicherzustellen, dass die erneute Schulung keine neuen Verzerrungen verursacht hat

Antimuster

Wohin schauen	Wie schlecht sieht
Einstein \| Trainingsdaten	⚠️ Trainingsdaten werden direkt verwendet, ohne unter- oder überrepräsentierte Segmente neu auszugleichen
Einstein \| Trainingsdaten	⚠️ Demografische Segmente werden nicht durch synthetische Daten oder organisationsübergreifende Aggregation ergänzt
Einstein \| Funktionsentwicklung	⚠️ Proxy-Funktionen werden beibehalten, ohne alternative Funktionen auszuwerten, die Prognosekraft ohne demografische Korrelation bieten
Agentforce \| Nachbearbeitung	⚠️ Für alle demografischen Segmente gelten dieselben Konfidenzschwellenwerte, ohne die Ergebnisraten zu entzerren
Agentforce \| Nachbearbeitung	⚠️ Eine unterschiedliche Behandlung durch Schwellenwertanpassungen ist nicht dokumentiert oder wird in den USA überhaupt auf beschäftigungsbezogene Entscheidungen angewendet, wenn Titel VII die Anpassung von Bewertungen oder Cutoffs nach geschützter Klasse unabhängig von der Dokumentation verbietet.
Einstein \| Modellumschulung	⚠️ Modelle werden bereitgestellt und nie neu trainiert; neu auftretende Verzerrungsmuster und Drift werden nicht korrigiert
Einstein \| Modellumschulung	⚠️ Umschulung erfolgt ohne erneute Validierung von Fairnesskennzahlen; neue Verzerrung wird stillschweigend eingeführt

Muster

Wohin schauen	Wie gut aussieht
Einstein Discovery \| UX	✅ Einstein Discovery-Erläuterungen, die Prognosefaktoren zeigen, werden in Lightning-Komponenten am Entscheidungspunkt angezeigt
Einstein Discovery \| UX	✅ Erläuterungen zeigen, welche Variablen bestimmte Prognosen am stärksten beeinflusst haben, mit richtungsbezogenen Auswirkungen für Benutzer an Entscheidungspunkten
Einstein Discovery \| UX	✅ Erklärungen sind für verschiedene Zielgruppen mehrschichtig: Geschäftsbenutzer, technische Benutzer, Kunden und Prüfer
Einstein Discovery \| UX	✅ Geschäftsbenutzern wird “Dieser Lead wurde hoch bewertet, da der Jahresumsatz über 1 Mio. EUR liegt und die Engagementbewertung unter den besten 10 % liegt” angezeigt
Einstein Discovery \| UX	✅ Technische Benutzer sehen Modellkarten mit Funktionsgewichtungen, Trainingsdateneigenschaften und Validierungskennzahlen
Einstein Discovery \| UX	✅ Kunden wird angezeigt “Diese Empfehlung basiert auf Ihren letzten Käufen und Kunden mit ähnlichen Voreinstellungen”
Einstein Discovery \| UX	✅ Prüfern wird die vollständige Entscheidungslinie von Einstein Discovery und dem Modell-Manager mit Modellversion, Eingabewerten und den Faktoren angezeigt, die die Prognose ausgelöst haben
Einstein Discovery \| UX	✅ Die Prognosekonfidenz wird benutzergerecht als Kategorien (Hohe Konfidenz, Mäßige Konfidenz, Überprüfung erforderlich) mit Erläuterungen angezeigt
Einstein Discovery \| UX	✅ Konfidenzkategorien erläutern, was Konfidenzniveau für die Zuverlässigkeit von Entscheidungen bedeutet und welche zusätzliche Überprüfung erfolgen wird

Antimuster

Wohin schauen	Wie schlecht sieht
Einstein Discovery \| UX	⚠️ Erläuterungen werden nach der Bereitstellung auf opake Systeme umgerüstet, statt die Erklärbarkeit von Anfang an in die Architektur einzubauen
Einstein Discovery \| UX	⚠️ Prognoseerklärungen erfordern die Navigation zum Trennen von CRM Analytics-Dashboards, statt sie an Entscheidungspunkten anzuzeigen
Einstein Discovery \| UX	⚠️ Benutzern werden abstrakte Modellleistungskennzahlen anstelle transparenter Erklärungen angezeigt, wenn sie von Entscheidungen betroffen sind
Einstein Discovery \| UX	⚠️ Erläuterungen variieren nicht je nach Zielgruppe. Technische Modellkarten werden Kunden oder Geschäftsbenutzern angezeigt
Einstein Discovery \| UX	⚠️ Rohprognosebewertungen (0,73) werden ohne Erklärung angezeigt, was die Zahl bedeutet oder welche Faktoren die Prognose angetrieben haben
Einstein Discovery \| UX	⚠️ Konfidenz wird als Wahrscheinlichkeitsprozentsatz angezeigt, den Benutzer ohne Kontext hinsichtlich Zuverlässigkeit oder Überprüfung falsch interpretieren

Muster

Wohin schauen	Wie gut aussieht
Einstein \| Trust Layer	✅ Einstein Trust Layer protokolliert Eingabeaufforderungen, Antworten, Erdungsquellen und Trust Signale automatisch ohne benutzerdefinierte Instrumentierung
Einstein \| Trust Layer	✅ Datenaufbewahrungsrichtlinien werden so konzipiert, dass sie die gesetzlichen Anforderungen erfüllen, die je nach Branche und Gerichtsbarkeit variieren (beispielsweise legt FINRA-Regel 4511(b) einen standardmäßigen Aufbewahrungszeitraum von sechs Jahren fest und HIPAA schreibt für die Konformitätsdokumentation mindestens sechs Jahre vor).
CRM Analytics \| Überwachung	✅ CRM Analytics-Dashboards analysieren erfasste Prognosemodell-Entscheidungsdaten auf Entscheidungsmuster, Fairness-Kennzahlen und die Modellleistung im Zeitverlauf
CRM Analytics \| Überwachung	✅ CRM Analytics-Linsen zeigen Prognoseverteilungen nach Konfidenzstufe, demografischem Segment und Ergebnistyp an
CRM Analytics \| Überwachung	✅ Einstein Discovery Artikel identifizieren anormale Muster, die untersucht werden müssen
Plattform \| Feld-Aktivierungsprotokoll	✅ Das Feld-Aktivierungsprotokoll ist für benutzerdefinierte Objekte aktiviert, in denen AI-Entscheidungsdaten gespeichert werden, wobei der archivierte Verlauf für Einwilligungsdatensätze, Überschreibungsentscheidungen und Verzerrungsberichte unbegrenzt beibehalten wird
Plattform \| Ereignisüberwachung	✅ Die Ereignisüberwachung erfasst Agentforce-Unterhaltungsabschriften, Toolaufrufe und Entscheidungspunkte
Plattform \| Ereignisüberwachung	✅ Ereignisüberwachungsprotokolle werden über Plattformereignisse zur manipulationssicheren Speicherung an externes SIEM weitergeleitet
Plattform \| Ereignisüberwachung	✅ SIEM-Abfragen erkennen Verzerrungsmuster in großen Volumen von Agentforce Interaktionen

Antimuster

Wohin schauen	Wie schlecht sieht
Einstein \| Trust Layer	⚠️ Agentforce-Interaktionen werden bereitgestellt, ohne die Trust Layer-Aktivierungserfassung zu aktivieren oder Aufbewahrungsrichtlinien zu definieren
Einstein \| Trust Layer	⚠️ Aufbewahrungsrichtlinien berücksichtigen keine branchenspezifischen regulatorischen Anforderungen (Finanzdienstleistungen, Gesundheitswesen)
CRM Analytics \| Überwachung	⚠️ Die erfassten Entscheidungsdaten des Prognosemodells werden nicht analysiert. Entscheidungsmuster und Fairness-Kennzahlen werden im Laufe der Zeit nicht verfolgt
Plattform \| Feld-Aktivierungsprotokoll	⚠️ Standardmäßiger 18-monatiger Feldverlauf für AI-Entscheidungs-Aktivierungsprotokolle ohne Berücksichtigung gesetzlicher Aufbewahrungsanforderungen
Plattform \| Feld-Aktivierungsprotokoll	⚠️ Das Feld-Aktivierungsprotokoll ist für Objekte mit Einwilligungsdatensätzen, Überschreibungsentscheidungen und Verzerrungsberichten nicht aktiviert
Plattform \| Ereignisüberwachung	⚠️ Ereignisüberwachungsprotokolle basieren auf nativen Aufbewahrungsobergrenzen ohne externes SIEM für manipulationssichere Langzeitspeicherung
Plattform \| Ereignisüberwachung	⚠️ Agentforce-Interaktionsprotokolle werden nicht auf Verzerrungsmuster in großen Volumen analysiert

Muster

Wohin schauen	Wie gut aussieht
Governance \| EU AI Act	✅ AI-Systeme mit hohem Risiko werden mit Transparenzdokumentation, technischer Dokumentation, menschlichen Aufsichtsfunktionen und Genauigkeits-/Fairnesskennzahlen dokumentiert
Governance \| EU AI Act	✅ Einstein Trust Layer-Aktivierungsprotokolle und Discovery-Modellkarten bieten Grundlagen für die Transparenzanforderungen des EU-AI-Gesetzes
Governance \| EU AI Act	✅ Modelltrainingsdatendemografien, Validierungsansätze und bekannte Einschränkungen werden in Architekturentscheidungsdatensätzen dokumentiert
Unternehmensführung \| DSGVO	✅ Systeme generieren kohärente Erklärungen für jede historische Entscheidung auf Anforderung innerhalb des Zeitrahmens für die Zugriffsanforderung der betroffenen Person (der je nach Zuständigkeit zwischen 15 und 45 Tagen variiert)
Unternehmensführung \| DSGVO	✅ Erfasste Prognosemodell-Entscheidungsdaten und Einstein Discovery Erklärungsfaktoren werden mit ausreichender Aufbewahrung gespeichert, um die Erklärungsrekonstruktion für das Recht auf Erklärung der DSGVO zu ermöglichen
Governance \| Algorithmische Verantwortlichkeit	✅ Algorithmische Folgenabschätzungen werden durchgeführt, bevor konsequente AI als proaktive Compliance und nicht als reaktive Reaktion bereitgestellt wird
Governance \| Algorithmische Verantwortlichkeit	✅ Erfasste Prognosemodell-Entscheidungsdaten und CRM Analytics-Dashboards zur Fairness-Überwachung bieten Datengrundlagen für Berichte zur algorithmischen Verantwortlichkeit

Antimuster

Wohin schauen	Wie schlecht sieht
Governance \| EU AI Act	⚠️ AI-Systeme mit hohem Risiko werden ohne Transparenzdokumentation, menschliche Aufsichtsfunktionen oder Fairnesskennzahlen bereitgestellt
Governance \| EU AI Act	⚠️ Demografische Daten zum Modelltraining und bekannte Einschränkungen sind in Architekturentscheidungsdatensätzen nicht dokumentiert
Unternehmensführung \| DSGVO	⚠️ Systeme können keine kohärenten Erklärungen für historische Entscheidungen innerhalb des Zeitrahmens der DSGVO-Anforderungen für den Zugriff betroffener Personen generieren
Unternehmensführung \| DSGVO	⚠️ Die Datenaufbewahrung im Prognosemodell für Entscheidungen reicht nicht aus, um die Erklärungsrekonstruktion für vergangene Entscheidungen zu unterstützen
Governance \| Algorithmische Verantwortlichkeit	⚠️ Algorithmische Folgenabschätzungen werden nicht vor der Bereitstellung von konsequenter AI durchgeführt; die Compliance ist nach behördlicher Untersuchung reaktiv

Muster

Wohin schauen	Wie gut aussieht
Plattform \| OWD	✅ Private organisationsweite Standardeinstellungen werden für Objekte festgelegt, die vertrauliche Kundendaten enthalten, deren Zugriff über Rollenhierarchie und Freigaberegeln erteilt wird
Plattform \| OWD	✅ Private OWDs mit expliziten Freigabegewährungen erstellen überprüfbare Zugriffsmuster zur Unterstützung der Nichtdiskriminierungs-Compliance
Plattform \| Feldebenensicherheit	✅ Vertrauliche Felder mit geschützten Merkmalen (Ethnie, Religion, Behinderungsstatus) werden über FLS für Benutzer ohne legitimen Geschäftsbedarf ausgeblendet
Plattform \| Feldebenensicherheit	✅ Der Lesezugriff auf sensible Felder wird für die meisten Profile über FLS entfernt. Der Zugriff wird nur minimal über Berechtigungssätze mit dokumentierter Begründung gewährt.
Plattform \| Zuweisung und Weiterleitung	✅ Zuweisungsregeln, Warteschlangen und die Omnikanal-Weiterleitung verteilen Arbeit gleichmäßig auf Regionen, Teams und Serviceagenten basierend auf objektiven Kriterien
Plattform \| Freigaberegeln	✅ Automatische Freigaberegeln basieren auf objektiven Kriterien (Branche, geografische Daten, Produktlinie) und nicht auf dem Ermessen des subjektiven Managers
Plattform \| Berechtigungssätze	✅ Der temporäre Zugriff auf sensible Daten wird über Berechtigungssätze mit dokumentiertem Ablauf statt über dauerhafte Profiländerungen gewährt
Plattform \| Berechtigungssätze	✅ Geplanter Flow widerruft Berechtigungssätze automatisch nach definierten Zeiträumen, wenn für bestimmte Projekte Zugriff auf demografische Daten erforderlich ist

Antimuster

Wohin schauen	Wie schlecht sieht
Plattform \| OWD	⚠️ Öffentliche Lese-/Schreibzugriffsberechtigungen machen das Einschränken des Zugriffs später störend (eine strengere Standardeinstellung löst eine Freigabeneuberechnung aus); überprüfbare Zugriffsmuster sind nicht vorhanden
Plattform \| OWD	⚠️ Account-OWD ist auf “Öffentlicher Lese-/Schreibzugriff” festgelegt, wobei ungeschützte demografische Felder für alle Benutzer sichtbar sind und eine subjektive Verzerrung aktiviert ist
Plattform \| Feldebenensicherheit	⚠️ Vertrauliche demografische Felder sind für alle Profile ohne FLS-Einschränkungen sichtbar; diskriminierende Datennutzung wird nicht verhindert
Plattform \| Freigaberegeln	⚠️ Die manuelle Freigabe konzentriert hochwertige Opportunities auf bestimmte Benutzergruppen ohne dokumentierte geschäftliche Begründung
Plattform \| Freigaberegeln	⚠️ Freigaberegeln basieren auf dem Ermessen des subjektiven Managers und nicht auf objektiven Kriterien, die eine Verzerrung ermöglichen
Plattform \| Berechtigungssätze	⚠️ Profile werden dauerhaft für alle Benutzer geändert, statt temporären Zugriff über Berechtigungssätze zu gewähren
Plattform \| Berechtigungssätze	⚠️ Berechtigungssätze, die Zugriff auf sensible Daten gewähren, laufen nicht automatisch ab. Der Zugriff bleibt nach Abschluss des Projekts unbegrenzt

Muster

Wohin schauen	Wie gut aussieht
Shield \| Ereignisüberwachung	✅ Die Shield-Ereignisüberwachung verfolgt den Zugriff auf Felder mit geschützten Merkmalen oder sensiblen Attributen
Shield \| Ereignisüberwachung	✅ Ereignisüberwachungsabfragen verfolgen, wer wann und in welchem Kontext auf demografische Felder zugreift und anormale Muster erkennt
Shield \| Ereignisüberwachung	✅ Anomale Zugriffsmuster (plötzliche Spitzen, Zugriff durch unerwartete Benutzer) lösen Untersuchung auf potenziellen Missbrauch aus
Plattform \| Berichte	✅ In Berichten wird analysiert, wie Freigaberegeln Datensätze auf Benutzer, Teams und Regionen verteilen, um Verteilungsstatistiken nach Kundendemografien zu berechnen.
Plattform \| Berichte	✅ Berichte identifizieren Konzentrationen, in denen bestimmte Benutzergruppen unverhältnismäßigen Zugriff auf wertvolle Datensätze ohne dokumentierte Begründung erhalten
Plattform \| Setup-Aktivierungsprotokoll	✅ Setup-Aktivierungsprotokoll wird auf Änderungen an OWD-Einstellungen, Freigaberegeln, FLS-Konfigurationen und Berechtigungssätzen überprüft, die nicht autorisierte Änderungen erkennen
Plattform \| Transaktionssicherheit	✅ Transaktionssicherheitsrichtlinien reagieren auf Ereignisse der Echtzeit-Ereignisüberwachung mit hohem Risiko (anomale API-Aktivität, verdächtige Anmeldungen, großer Export vertraulicher Daten); FLS- und Freigabeänderungen basieren auf dem Setup-Aktivierungsprotokoll und dokumentierten Genehmigungen für die Änderungsverwaltung

Antimuster

Wohin schauen	Wie schlecht sieht
Shield \| Ereignisüberwachung	⚠️ Der Zugriff auf sensible demografische Felder wird nicht überwacht; potenzieller Missbrauch wird nicht erkannt
Shield \| Ereignisüberwachung	⚠️ Anomale Zugriffsmuster (Spikes, unerwartete Benutzer) werden nicht verfolgt oder untersucht
Plattform \| Berichte	⚠️ Verteilungen von Freigaberegeln werden nicht analysiert; unverhältnismäßiger Zugriff auf wertvolle Datensätze bleibt unsichtbar
Plattform \| Berichte	⚠️ Bei Konzentrationen von Accounts mit hohem Wert und bestimmten Benutzergruppen fehlt eine dokumentierte geschäftliche Begründung
Plattform \| Setup-Aktivierungsprotokoll	⚠️ Das Setup-Aktivierungsprotokoll wird nicht überprüft. Nicht autorisierte Änderungen an Datenzugriffssteuerungen, die den Zugriff auf sensible Daten ermöglichen, werden nicht erkannt
Plattform \| Transaktionssicherheit	⚠️ Ereignisse der Echtzeit-Ereignisüberwachung mit hohem Risiko (anomale API-Aktivität, großer Export vertraulicher Daten) werden nicht mit Transaktionssicherheitsrichtlinien verarbeitet

Muster

Wohin schauen	Wie gut aussieht
Plattform \| Benutzerdefinierte Objekte	✅ Die granulare Einwilligung pro AI-Anwendungsfall wird durch den benutzerdefinierten Zweck der Einwilligungsobjektverfolgung, das Datum/die Methode der Erteilung, das Widerrufsdatum und die zugehörige Benutzer-/Kontakt-ID aktiviert
Plattform \| Benutzerdefinierte Objekte	✅ Kunden stimmen Einstein Produktempfehlungen zu, während sie AI-gestützte Kreditentscheidungen über separate Einwilligungsdatensätze pro Anwendungsfall ablehnen
Plattform \| Feld-Aktivierungsprotokoll	✅ Das Feld-Aktivierungsprotokoll ist für das Einwilligungsobjekt für die langfristige Aufbewahrung aktiviert, die den gesetzlichen Anforderungen entspricht
Data 360 \| Einwilligung	✅ Die Data 360-Einwilligungsverwaltung wird für Funktionen der Einstein-Personalisierung verwendet. Dabei werden Einwilligungsvoreinstellungen über Konnektoren aufgenommen und gespeichert, die dem Datenmodell für den Datenschutz zugeordnet sind.
Data 360 \| Einwilligung	✅ Einwilligungskategorien werden bestimmten AI-Anwendungsfällen zugeordnet, sodass Benutzer sich von der Personalisierung abmelden und gleichzeitig den Kernservice aufrechterhalten können
Marketing Cloud \| Einwilligung	✅ Marketing Cloud-Einwilligung kann in Einstein Messaging Insights und Agentforce Marketing Agenten integriert werden, die den Abonnementstatus berücksichtigen
Marketing Cloud \| Einwilligung	✅ Marketing Cloud-Einwilligungsstatus wird abgefragt, bevor Agentforce die automatisierte Kontaktaufnahme initiiert und unerwünschten Kontakt mit Benutzern verhindert, die sich abgemeldet haben

Antimuster

Wohin schauen	Wie schlecht sieht
Plattform \| Benutzerdefinierte Objekte	⚠️ Die AI-Einwilligung wird in Tabellenblättern verfolgt oder basiert auf der Anmeldung als implizite allgemeine Einwilligung ohne explizite Datensätze
Plattform \| Benutzerdefinierte Objekte	⚠️ Die Einwilligung mit leerer AI wird anstelle einer detaillierten Einwilligung pro Anwendungsfall verwendet. Benutzer können sich nicht von bestimmten AI-Funktionen abmelden
Plattform \| Feld-Aktivierungsprotokoll	⚠️ Das Feld-Aktivierungsprotokoll ist für das Einwilligungsobjekt nicht aktiviert. Die langfristige Aufbewahrung, die den gesetzlichen Anforderungen entspricht, wird nicht beibehalten
Data 360 \| Einwilligung	⚠️ Data 360-Einwilligungen werden nicht zur Einstein-Personalisierung verwendet. Einwilligungskategorien werden keinen bestimmten Anwendungsfällen zugeordnet
Marketing Cloud \| Einwilligung	⚠️ Marketing Cloud-Einwilligung ist nicht in Einstein oder Agentforce integriert. Der Abonnementstatus wird bei der automatisierten Kontaktaufnahme nicht berücksichtigt

Muster

Wohin schauen	Wie gut aussieht
Experience Cloud \| Profileinstellungen	✅ Benutzer können Agentforce-Interaktionen über das barrierefreie Voreinstellungssteuerfeld in den Experience Cloud-Profileinstellungen oder “Meine Einstellungen” mit klaren Beschreibungen deaktivieren
Plattform \| Benutzer-/Kontaktdatensätze	✅ AI-Voreinstellungen werden in Benutzer- oder Kontaktdatensätzen gespeichert, die eine Abfrage in der Entscheidungslogik von Flow und Agentforce ermöglichen
Agentforce \| Omnikanal	✅ Benutzer, die sich von Agentforce abmelden, werden über Omnikanal an menschliche Agenten weitergeleitet, statt einen beeinträchtigten Service zu erhalten
Agentforce \| Flow	✅ Flow überprüft Einwilligungs- und Voreinstellungsfelder vor dem Agentforce Engagement. Wenn sich der Benutzer abgemeldet hat, wird ein Arbeitsdatensatz erstellt und an die menschliche Warteschlange weitergeleitet
Agentforce \| Omnikanal	✅ Human Queue Staffing bietet Benutzern, die sich abgemeldet haben, vergleichbare Wartezeiten wie automatisierte Services
Plattform \| Benutzer-/Kontaktdatensätze	✅ AI-Voreinstellungen werden in Benutzer- oder Kontaktdatensätzen gespeichert, um die Konsistenz zwischen Kanälen (Web, Mobiltelefon, Telefon, E-Mail) zu gewährleisten
Plattform \| Flow	✅ Die Voreinstellung wird in allen Interaktions-Flows konsistent abgefragt und verhindert, dass Benutzer Voreinstellungen in jedem Kanal wiederholt bestätigen müssen

Antimuster

Wohin schauen	Wie schlecht sieht
Experience Cloud \| Profileinstellungen	⚠️ Die Abmeldung ist nur per E-Mail an das Supportteam verfügbar. Steuerelemente für barrierefreie Voreinstellungen sind nicht vorhanden
Plattform \| Benutzer-/Kontaktdatensätze	⚠️ AI-Voreinstellungen werden nicht in Benutzer- oder Kontaktdatensätzen gespeichert. Voreinstellungen können nicht in der Flow- oder Agentforce-Logik abgefragt werden
Agentforce \| Omnikanal	⚠️ Benutzer, die sich abmelden, erhalten einen beeinträchtigten Service als impliziten Druck, KI zu akzeptieren, statt sie an menschliche Agenten weiterzuleiten
Agentforce \| Flow	⚠️ Der Flow überprüft weder Einwilligungs- noch Voreinstellungsfelder vor dem Agentforce Engagement.
Plattform \| Benutzer-/Kontaktdatensätze	⚠️ Die Voreinstellungen sind nicht kanalübergreifend konsistent. Benutzer müssen die Abmeldung in Web, Mobiltelefon, Telefon und E-Mail separat erneut geltend machen

Muster

Wohin schauen	Wie gut aussieht
Governance \| Dokumentation	✅ Jedes Produktionsprognosemodell wird mit Trainingsdatendemografien, Fairnesskennzahlen, vorgesehenen Anwendungsfällen, Strategien zur Verzerrungsminderung und Überwachungsansätzen dokumentiert
Governance \| Dokumentation	✅ Die Modelldokumentation enthält den Fairness-Monitoring-Ansatz, Warnschwellenwerte, Anforderungen an die menschliche Aufsicht, Überprüfungszeitplan und behördliche Überlegungen
Plattform \| Benutzerdefinierte Objekte	✅ Die Modelldokumentation wird in Salesforce mithilfe des benutzerdefinierten Modellobjekts oder der an Projekte angehängten Salesforce Files gespeichert, wodurch die Durchsuchbarkeit und Versionskontrolle ermöglicht wird
Governance \| Bereitstellungstore	✅ Fairness-Gates vor der Bereitstellung erfordern die Überprüfung von Trainingsdaten, die Berechnung von Fairness-Kennzahlen, die Folgenabschätzung, das Design der menschlichen Aufsicht und die Transparenzprüfung vor der Produktion
Governance \| Bereitstellungstore	✅ Trainingsdatendarstellungslücken werden analysiert und als obligatorisches Bereitstellungs-Gate dokumentiert
Governance \| Bereitstellungstore	✅ Demografische Parität, Chancengleichheit und ungleiche Auswirkungen sind berechnete Schwellenwerte für die Einhaltung als obligatorisches Gate
Governance \| Bereitstellungstore	✅ Folgenabschätzung wertet potenzielle Schäden in betroffenen Bevölkerungsgruppen als obligatorisches Tor aus
Governance \| Bereitstellungstore	✅ Das Design der menschlichen Aufsicht, einschließlich Eskalationsmustern, Genehmigungsworkflows und Überschreibungsmechanismen, wurde als obligatorisches Gate konzipiert und getestet
Governance \| Bereitstellungstore	✅ Erklärungsfunktionen werden für alle Entscheidungstypen als obligatorisches Gate validiert
Governance \| Bereitstellungstore	✅ Fairness-Gates werden mit der gleichen Strenge behandelt wie Sicherheits-Gates mit der Berechtigung, Bereitstellungen zu blockieren, bei denen ein Gate fehlschlägt

Antimuster

Wohin schauen	Wie schlecht sieht
Governance \| Dokumentation	⚠️ Einstein Funktionen werden bereitgestellt, ohne Trainingsdaten, Fairnesskennzahlen, Verzerrungsminderung oder Überwachungsansätze zu dokumentieren
Governance \| Dokumentation	⚠️ Die Modelldokumentation enthält weder den Fairness-Monitoring-Ansatz noch die Anforderungen an die menschliche Aufsicht oder behördliche Überlegungen.
Plattform \| Benutzerdefinierte Objekte	⚠️ Die Modelldokumentation wird in Tabellenblättern oder Wikis ohne Durchsuchbarkeit oder Versionskontrolle gespeichert
Governance \| Bereitstellungstore	⚠️ Einstein-Funktionen werden ohne Fairness-Gate in die Produktion übernommen. Die Bereitstellung basiert ausschließlich auf den allgemeinen Genauigkeitskennzahlen.
Governance \| Bereitstellungstore	⚠️ Die Überprüfung von Trainingsdaten, die Berechnung von Fairness-Kennzahlen oder die Folgenabschätzung werden vor der Produktionsbereitstellung übersprungen
Governance \| Bereitstellungstore	⚠️ Human Oversight Design, Transparenzüberprüfung oder Erklärungsvalidierung werden nicht vor der Produktion durchgeführt
Governance \| Bereitstellungstore	⚠️ Fairness-Gates sind nur für Empfehlungen vorgesehen und nicht berechtigt, Bereitstellungen zu blockieren. Modelle werden trotz fehlender Fairness-Kriterien fortgesetzt

Muster

Wohin schauen	Wie gut aussieht
Governance \| Überprüfungsausschuss	✅ Der Überprüfungsausschuss besteht aus technischen Experten (Architekten, Datenwissenschaftlern), Wirtschaftsbeteiligten, Rechtsanwälten, Datenschutzexperten und Vertretern betroffener Communities
Governance \| Überprüfungsausschuss	✅ Diverse Perspektiven zeigen Fairnessprobleme auf, die homogene Gruppen bei der Ethiküberprüfung vermissen
Governance \| Auslöser überprüfen	✅ Überprüfungsauslöser sind definiert: Entscheidungen über Beschäftigung/Kredit/Wohnen/Gesundheitswesen/Rechtsansprüche, Systeme, die jährlich mehr als 10.000 Benutzer betreffen, neue Anwendungsfälle, erhebliches Schadensrisiko
Governance \| Auslöser überprüfen	✅ AI-Anwendungen, die sensible personenbezogene Daten (gesundheitliche, finanzielle, demografische) verwenden, müssen vor der Bereitstellung ethisch überprüft werden
Governance \| Überprüfungsstelle	✅ Ethik-Überprüfungsgremium ist berechtigt, Änderungen zu verlangen, Überwachungsbedingungen aufzuerlegen oder Bereitstellungen zu blockieren, die gegen ethische Standards verstoßen
Plattform \| Benutzerdefinierte Objekte	✅ Alle Überprüfungen sind im Namen des benutzerdefinierten Salesforce-Objekts zur Verfolgung von Anwendungen, im Überprüfungsdatum, in den vorgebrachten Bedenken, in den Anforderungen zur Eindämmung und in den Genehmigungsbedingungen dokumentiert.

Antimuster

Wohin schauen	Wie schlecht sieht
Governance \| Überprüfungsausschuss	⚠️ Dem Überprüfungsausschuss fehlt es an Vielfalt (nur technische Experten); homogene Gruppen vermissen Fairnessprobleme, die sich auf unterschiedliche Populationen auswirken
Governance \| Überprüfungsausschuss	⚠️ Vertreter aus betroffenen Communities werden nicht einbezogen; blinde Flecken in Fairness-Überlegungen resultieren
Governance \| Auslöser überprüfen	⚠️ Überprüfungsauslöser werden nicht definiert. Anwendungen mit AI mit hohem Risiko werden vor der Bereitstellung ohne Ethiküberprüfung ausgeführt
Governance \| Überprüfungsstelle	⚠️ Ethiküberprüfung ist nur beratend ohne Durchsetzung; Bereitstellungen erfolgen trotz mangelhafter ethischer Standards (Rechenschaftspflichttheater)
Plattform \| Benutzerdefinierte Objekte	⚠️ Überprüfungen werden nicht systematisch dokumentiert. Entscheidungen, Bedenken und Minderungen bei historischen Überprüfungen werden nicht verfolgt

Muster

Wohin schauen	Wie gut aussieht
CRM Analytics \| Überwachung	✅ CRM Analytics-Dashboards verfolgen Fairness-Kennzahlen für Einstein und Agentforce aus erfassten Entscheidungsdaten und Trust Layer-Aktivierungsdaten in einem geplanten Rhythmus
CRM Analytics \| Überwachung	✅ Demografische Parität, Chancengleichheit, ungleiche Auswirkungsverhältnisse und Servicequalitätskennzahlen werden nach Kundensegment überwacht
CRM Analytics \| Überwachung	✅ CRM Analytics-Benachrichtigungen werden so konfiguriert, dass sie ausgelöst werden, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten, die untersucht werden müssen
CRM Analytics \| Überwachung	✅ CRM Analytics-Dashboards verfolgen Fairness-Signale: Plötzliche Änderungen in Entscheidungsverteilungen, Spitzen in verzerrten Kundenvorgängen, Leistungseinbußen für bestimmte Populationen
CRM Analytics \| Überwachung	✅ Benachrichtigungen werden für Einstein Opportunity-Bewertungen ausgelöst, wenn die Genehmigungsraten für ein Segment im Wochenvergleich um mehr als 15 % sinken.
Governance \| Geplante Prüfungen	✅ Umfassende Fairness-Prüfungen werden vierteljährlich für AI mit hohem Anteil (Kredit, Beschäftigung, Gesundheitswesen) oder halbjährlich für Systeme mit niedrigem Anteil durchgeführt
Governance \| Geplante Prüfungen	✅ Audits untersuchen aktuelle Fairness-Kennzahlen, überprüfen Überschreibungsmuster, analysieren Benutzerfeedback und Verzerrungsberichte und validieren, dass die Governance-Kontrollen wirksam bleiben
Governance \| Vorfallsreaktion	✅ Klare Reaktion auf Vorfälle werden in Salesforce Knowledge dokumentiert, um bei erkannter Verzerrung zu reagieren
Governance \| Vorfallsreaktion	✅ Sofortige Schweregradbewertung durch Abfragen von Prognosemodell-Entscheidungsdaten in CRM Analytics; starke Verzerrung setzt automatisierte Entscheidungsfindung ausstehender Untersuchungen aus
Governance \| Vorfallsreaktion	✅ Temporäre Abhilfe implementiert eine verbesserte menschliche Aufsicht durch angepasste Konfidenzschwellenwerte, Funktionsdeaktivierung oder vollständige Agentenaussetzung
Governance \| Vorfallsreaktion	✅ Die Ursachenanalyse identifiziert, wie Verzerrungen eingetreten sind oder sich weiterentwickelt haben. Trainingsdaten, Modellversionen und Konfigurationsänderungen werden über den Field Audit Trail analysiert
Governance \| Vorfallsreaktion	✅ Die dauerhafte Korrektur implementiert Datenkorrekturen, Modellumschulungen oder Prozessänderungen mit entsprechender Kommunikation an betroffene Benutzer
Governance \| Vorfallsreaktion	✅ Präventionsmaßnahmen werden in Runbooks dokumentiert, um ein erneutes Auftreten von Verzerrungen zu verhindern

Antimuster

Wohin schauen	Wie schlecht sieht
CRM Analytics \| Überwachung	⚠️ Fairness-Kennzahlen werden in keinem geplanten Rhythmus aus erfassten Entscheidungsdaten oder Trust Layer-Aktivierungsdaten verfolgt. Verzerrungen bleiben unerkannt, wenn sich Datenverteilungen ändern
CRM Analytics \| Überwachung	⚠️ CRM Analytics-Benachrichtigungen sind nicht konfiguriert. Verstöße gegen Fairness-Kennzahlen, die untersucht werden müssen, werden nicht ausgelöst
CRM Analytics \| Überwachung	⚠️ Fairnesssignale werden nicht überwacht; plötzliche Änderungen in Entscheidungsverteilungen werden nicht erkannt
Governance \| Geplante Prüfungen	⚠️ Umfassende Fairness-Audits werden nicht nach einem Zeitplan durchgeführt; Governance-Kontrollen weichen ab und werden ineffektiv
Governance \| Geplante Prüfungen	⚠️ Überschreibungsmuster, Benutzerfeedback und Verzerrungsberichte werden während der Prüfungen nicht systematisch analysiert
Governance \| Vorfallsreaktion	⚠️ Eindeutige Reaktion auf Vorfälle sind nicht dokumentiert; die Verzerrungserkennung führt zu Ad-hoc-Antworten ohne systematischen Ansatz
Governance \| Vorfallsreaktion	⚠️ Temporäre Abhilfe oder dauerhafte Behebung werden nicht systematisch implementiert; Verzerrungen wirken sich weiterhin auf Benutzer aus
Governance \| Vorfallsreaktion	⚠️ Eine Ursachenanalyse wird nicht durchgeführt. Wie eine Verzerrung eingetreten ist oder sich entwickelt hat, bleibt unbekannt
Governance \| Vorfallsreaktion	⚠️ Präventionsmaßnahmen werden nicht dokumentiert; Wiederholungen werden nicht verhindert

Muster

Wohin schauen	Wie gut aussieht
Plattform \| Pflichtfelder	✅ Jedes Pflichtfeld enthält eine dokumentierte geschäftliche Begründung dafür, warum die Daten obligatorisch und nicht optional sind. Felder, ohne die ein Prozess funktionieren kann, werden als optional mit nachgelagerter Verarbeitung für fehlende Werte festgelegt
Plattform \| Pflichtfelder	✅ E-Mail ist optional mit alternativen Kommunikationsmethoden (SMS, Telefon, Post), sodass Benutzer ohne zuverlässiges Internet oder persönliche E-Mails nicht von der Accounterstellung ausgeschlossen werden
Plattform \| Namensfelder	✅ Die Namensarchitektur verwendet ein einzelnes vollständiges Namensfeld oder eine flexible mehrteilige Struktur, die Mononyme, patronymische Systeme und mehrere Vor- oder Nachnamen aufnimmt, ohne Reihenfolge oder Übernahme anzunehmen
Plattform \| Namensfelder	✅ Namensfelder werden mit verschiedenen internationalen Namen getestet und akzeptieren Einzelwortnamen, Langnamen, Diakritika, Apostrophe, Bindestriche und nicht-lateinische Schriften (Arabisch, Chinesisch, Kyrillisch, Devanagari)
Plattform \| Adressvalidierung	✅ Die Validierung zulässiger Adressen akzeptiert die Freiformeingabe, wenn die strukturierte Validierung fehlschlägt, und speichert Adressen, während Benutzer sie eingeben, statt ungültige Korrekturen zu erzwingen
Plattform \| Adressvalidierung	✅ Die Adressüberprüfung ist in Abwicklungsprozesse integriert, bei denen es auf Genauigkeit ankommt, statt die Datenerfassung im Voraus zu blockieren
Plattform \| Kommunikationsvoreinstellungen	✅ Bevorzugte Kommunikationsmethoden werden in Kontaktdatensätzen gespeichert und in allen ausgehenden Systemen einheitlich berücksichtigt, sodass Omnikanal-Alternativen anstelle von Einzelkanalannahmen angeboten werden
Benutzerdefiniertes Objekt \| Demografische Daten	✅ Freiwillige demografische Daten werden über eine separate Umfrage mit der Option “Nicht antworten” erfasst, in einem benutzerdefinierten Objekt mit privatem Einmalkennwort gespeichert, durch das Einmalkennwort eingeschränkt und nur für Analysen der aggregierten Fairness verwendet
Shield \| Ereignisüberwachung	✅ Die Shield-Ereignisüberwachung protokolliert Zugriffsereignisse (Berichtexporte, API-Objektabfragen) für demografische Daten, um Zugriffsmuster zu überprüfen
Plattform \| Drittanbieteranreicherung	✅ Anreicherungsdrittanbieter werden vor der Implementierung auf Fairnesstests, demografische Abdeckung und Genauigkeit, Rückschlussmethodik und Einschränkungen der vertraglichen Datennutzung überprüft

Antimuster

Wohin schauen	Wie schlecht sieht
Plattform \| Pflichtfelder	⚠️ E-Mails sind für die Accounterstellung ohne Alternative erforderlich und die Telefon- oder Adressvalidierung lehnt Formate außerhalb der USA, Postfächer und ländliche Routen ab, ausgenommen Benutzer, die die Daten nicht bereitstellen können
Plattform \| Pflichtfelder	⚠️ Felder werden als Pflichtfelder markiert, ohne zu dokumentieren, ob der Prozess ohne die Daten funktionieren könnte, wodurch unsichtbare Populationen aus abgelehnten unvollständigen Datensätzen erstellt werden
Plattform \| Namensfelder	⚠️ Namensfelder erzwingen westliche Vor-/Nachnamenskonventionen und lehnen Mononyme, Diakritika oder nicht-lateinische Skripts ab, wodurch Benutzer aufgrund ihrer kulturellen Identität vom System abgelehnt werden
Plattform \| Adressvalidierung	⚠️ Die Adressvalidierung erfordert ein US-Postformat und erkennt keine internationalen Adressen, Postfächer, Militäradressen (APO/FPÖ) oder Stammesanschriften, wodurch die Accounterstellung und die Servicebereitstellung blockiert werden
Plattform \| Kommunikationsvoreinstellungen	⚠️ Es wird davon ausgegangen, dass ein einziger Kommunikationskanal universell ist (nur E-Mail oder Telefon), ohne dass Benutzer ohne Internet, ohne Telefonzugriff oder taub oder schwerhörig sind.
Benutzerdefiniertes Objekt \| Demografische Daten	⚠️ Demografische Daten werden aus Namen oder Standorten ohne Benutzer Knowledge abgeleitet, in standardmäßigen Kontaktfeldern gespeichert, die für alle Benutzer sichtbar sind, und ohne Offenlegung in Leadbewertungen oder Prognosen verwendet.
Plattform \| Drittanbieteranreicherung	⚠️ Drittanbieterdaten werden angehängt, ohne die Fairnesspraktiken der Anbieter oder die demografische Abdeckung zu überprüfen, wodurch Verzerrungen durch Anbieter in Organisationsentscheidungen importiert werden

Muster

Wohin schauen	Wie gut aussieht
Plattform \| Zuweisung und Weiterleitung	✅ Zuweisungs- und Weiterleitungsregeln verwenden objektive Kriterien (Produktlinien, SLAs, Sprachanforderungen) und Zuweisungsverteilungen werden vierteljährlich überprüft, stratifiziert nach Kundendemografien, um sicherzustellen, dass keine Konzentrationsmuster auftreten
Plattform \| Omnikanal	✅ Die durchschnittliche Bearbeitungszeit, die Lösung beim ersten Kontakt und die Kundenzufriedenheit werden über die Weiterleitungspfade hinweg überwacht, um festzustellen, ob Kundensegmente systematisch weniger erfahrene Agenten empfangen
Plattform \| Flow	✅ Flows, die Folgeentscheidungen treffen, werden auf Kriterien überprüft, die mit geschützten Merkmalen korrelieren (Accountdauer, Kanalvoreinstellung, Kaufverlauf, Geschäftszeiten) und ihre Entscheidungslogik wird in Architekturentscheidungsdatensätzen dokumentiert
Plattform \| Flow	✅ Flows mit hohem Einsatz, die sich auf den Zugang zu Beschäftigung, Krediten oder Dienstleistungen auswirken, unterliegen demselben Ethiküberprüfungsprozess wie AI-Systeme
Plattform \| Validierungsregeln	✅ Validierungsregeln werden mit verschiedenen Daten getestet (internationale Adressen, nicht westliche Namen, alternative Telefonformate) und erweitert, sobald sie legitime Daten ablehnen. Namensfelder akzeptieren Unicode und alle Skripts
Plattform \| Regionsdesign	✅ Kundendemografien werden über vorgeschlagene Regionsgrenzen hinweg zugeordnet, bevor Designs fertiggestellt werden. Wenn sich Konzentrationen abzeichnen, wird die Ressourcenzuteilung auf Gleichberechtigung hin ausgewertet und die Geschäftsberechtigung dokumentiert und überwacht.
Plattform \| Auditierung	✅ Die Automatisierungslogik (Geschäftsregeln, Zuweisungskriterien, Flow-Entscheidungen) wird in Salesforce Knowledge oder ADRs dokumentiert und die Ergebnisse werden vierteljährlich nach demografischen Daten stratifiziert überprüft.

Antimuster

Wohin schauen	Wie schlecht sieht
Plattform \| Zuweisung und Weiterleitung	⚠️ Zuweisungsregeln priorisieren Leads von bestimmten Postleitzahlen zu “Besten” basierend auf historischen Gewinnraten, ohne zu untersuchen, ob dieser Erfolg Fertigkeiten oder demografische Vorteile widerspiegelt
Plattform \| Omnikanal	⚠️ Kennzahlen zur Weiterleitungsqualität werden nicht kundensegmentübergreifend überwacht, sodass Unterschiede in der Agentenerfahrung oder -lösung nicht erkannt werden
Plattform \| Flow	⚠️ Flow-Entscheidungskriterien korrelieren mit geschützten Merkmalen (Dauer, Kanal, Kaufvolumen, Zeitzone) und werden als objektiv behandelt, da sich deterministische Logik neutral anfühlt
Plattform \| Flow	⚠️ Flows mit hohem Einsatz treffen folgenreiche Entscheidungen ohne Ethiküberprüfung, AS-Dokumentation oder Handhabung für Benutzer außerhalb des typischen Kundenprofils
Plattform \| Validierungsregeln	⚠️ Die Namensvalidierung ist auf A–Z beschränkt und lehnt diakritische oder nicht-lateinische Skripts ab. Für die Adressvalidierung ist das US-Postformat erforderlich. legitime Daten werden abgelehnt und Benutzer verlassen Anfragen, die nicht gemeldet wurden
Plattform \| Regionsdesign	⚠️ Die Regionsgrenzen folgen der geografischen Lage, die mit der demografischen Entwicklung korreliert, wobei die Vergütung oder die Personalausstattung zwischen den Regionen unterschiedlich ist und keine Analyse der demografischen Konzentration erfolgt
Plattform \| Auditierung	⚠️ Die Automatisierungslogik ist undokumentiert und die Ergebnisse werden nie überprüft, sodass diskriminierende Muster bei Zuweisungen, Genehmigungen, Validierungen oder Regionszuteilungen unsichtbar bleiben