Fairness

Fairness

In Salesforce-Architekturen bedeutet Fairness, Lösungen zu entwickeln, die den Benutzern durch barrierefreie Oberflächen, Verzerrungserkennung und -minderung, transparente Entscheidungen und ethische Unternehmensführung gleichermaßen dienen. Die Prognosen von Einstein beeinflussen die Ergebnisse, die sich auf Kunden und Mitarbeiter auswirken. Das bedeutet, dass Architekten Systeme entwerfen sollten, die gruppenübergreifend gerechte Ergebnisse erzielen und gleichzeitig für Benutzer mit Behinderungen zugänglich bleiben.

Salesforce bietet Plattformfunktionen, die auf Fairness ausgerichtet sind, und wir sind bestrebt, WCAG 2.2 AA zu erfüllen. Bei ordnungsgemäßer Verwendung stellt das Salesforce Lightning Design System (SLDS) Komponenten bereit, die dieses Ziel unterstützen. Sehen wir uns die einzelnen Komponenten genauer an.

  • Die Shield Platform Encryption schützt sensible Attribute wie demografische Daten und die Ereignisüberwachung bietet die Überwachungsprotokolle, die die transparente Datenverarbeitung unterstützen.
  • Die Einstein Trust Layer (ETL) erfasst einen sicheren Überwachungspfad für Eingabeaufforderungen und Antworten mit generativer AI zu Überwachungs- und Compliance-Zwecken.
  • Experience Cloud enthält Steuerelemente für den barrierefreien Zugriff.
  • Das Feld-Aktivierungsprotokoll bietet eine langfristige Aufbewahrung des Datenänderungsverlaufs auf Feldebene, wodurch die algorithmische Verantwortlichkeit unterstützt wird, wenn AI-Entscheidungsdaten in verfolgten Feldern gespeichert werden.

Mit diesen Funktionen können Sie die Betriebskosten von Salesforce-Fairnesspraktiken senken.

Bei Salesforce funktioniert Fairness in drei Dimensionen, um Lösungen bereitzustellen. Dank des integrierten Designs können Lightning Web Components (LWC), Visualforce-Seiten und Experience Cloud-Sites vollständig aufgerufen werden. Mithilfe von KI-Fairness-Praktiken können Einstein-Prognosen mithilfe von Verzerrungserkennung, vielfältigen Trainingsdaten und kontinuierlicher Überwachung angemessene Ergebnisse erzielen. Governance bietet die Prozesse und Kontrollen, um Fairness bei der Weiterentwicklung von Modellen und der Ausweitung von Anwendungsfällen zu gewährleisten.

Wenn Fairness vernachlässigt wird, entsteht ein Verschlechterungsrisiko. Nicht zugängliche Experience Cloud-Sites können Organisationen mit Rechtsstreitigkeiten gegen den Americans with Disabilities Act (ADA) und für Bundesbehörden und deren Vertragsnehmer mit Verstößen gegen § 508 Konformitätsbestimmungen befassen. Abhängig von der Risikoklassifizierung des Systems und den neuen Gesetzen zur algorithmischen Verantwortlichkeit können verzerrte Einstein-Prognosen gegen die Anforderungen des EU-AI Act verstoßen. Nur automatisierte AI-gestützte Entscheidungen mit rechtlichen oder ähnlich bedeutenden Auswirkungen, bei denen keine aussagekräftigen Informationen über die Entscheidungslogik vorliegen, können gegen die Informationsrechte der DSGVO gemäß Artikel 22 und Artikel 15 Absatz 1 Buchstabe h verstoßen.

Organisationen, die auf Fairness ausgerichtet sind, reduzieren in der Regel den vorhersehbaren Schaden für Kunden, Mitarbeiter und Communities, die von ihren Systemen betroffen sind. Misserfolge der Fairness können betroffenen Personen spürbaren materiellen Schaden zufügen, einschließlich wirtschaftlicher Schäden, verweigerter Opportunities, emotionaler Belastung und Verstärkung systemischer Diskriminierung. Regulatorische Angleichung neigt dazu, betroffenen Personen gut zu dienen.

Verwenden Sie diese Grundsätze, um Ihre architektonischen Entscheidungen für Fairness auf der Plattform zu leiten.

  • Design für Lightning-Muster für den barrierefreien Zugriff. Verwenden Sie beim Erstellen das Lightning Design System und standardmäßige Lightning Web Components, die den barrierefreien Zugriff auf WCAG 2.2 AA nach Möglichkeit unterstützen. Wenn Sie mit SLDS erstellen, nutzen Sie eine Bibliothek, in der der barrierefreie Zugriff ein zentrales Designprinzip ist. SLDS-Komponenten werden auf Barrierefreiheit und Kompatibilität mit Hilfstechnologien überprüft. Viele enthalten einen Abschnitt für den barrierefreien Zugriff mit Tipps für Entwickler. Wenn eine benutzerdefinierte Komponente erforderlich ist, müssen die explizite Implementierung von barrierefreien Rich-Internet-Anwendungen (WAI-ARIA), semantische HTML- und Tastaturnavigationsmuster durch unterstützende Technologietests validiert werden.
  • Verringern und überwachen Sie Verzerrungen mit den richtigen Tools für jeden Modelltyp. Validieren Sie AI-Ausgaben für gerechte Ergebnisse über demografische Gruppen hinweg vor der Bereitstellung und kontinuierlich in der Produktion. Erfassen Sie für Prognosemodelle Entscheidungsdaten über Einstein Discovery und benutzerdefinierte Instrumente und analysieren Sie sie in CRM Analytics, um Fairness-Kennzahlen zu messen. Verwenden Sie für Funktionen der generativen AI und Agentforce den Einstein Trust Layer-Aktivierungsprotokoll mit Aufforderungen und Antworten. Dokumentieren Sie Entscheidungen, um regulatorische Transparenzanforderungen zu erfüllen.
  • Nutzen Sie Shield Platform Encryption für Datenschutzkontrollen. Verwenden Sie die Shield Platform Encryption mit deterministischen Schemas für sensible Attribute, für die Abfragen mit exakter Übereinstimmung erforderlich sind und die gleichzeitig persönliche Daten schützen. Leiten Sie Ereignisüberwachungsprotokolle an ein externes SIEM-System (Security Information and Event Management) weiter, um manipulationssichere Überprüfungsprotokolle zu unterstützen, wenn das SIEM einmal schreibgeschützten Speicher und Zugriffstrennung erzwingt, die die nativen Salesforce-Aufbewahrungsfenster für erforderliche Vorschriften überschreiten.
  • Entwerfen Sie Workflows zur Überprüfung von Prognosen mit hohem Einsatz. Konfigurieren Sie Genehmigungsprozesse und Überprüfungsmechanismen im Salesforce-Flow, um sicherzustellen, dass Einstein-Prognosen, die sich auf Folgeentscheidungen auswirken, eine angemessene menschliche Überprüfung erhalten. Verwenden Sie Konfidenzschwellenwerte und Geschäftsregeln, um zu bestimmen, wann Prognosen validiert werden müssen, bevor Maßnahmen ergriffen werden.
  • Wenden Sie organisationsweite Standardeinstellungen (OWD) und Feldebenensicherheit (FLS) für Nichtdiskriminierung an. Entwerfen Sie Datenzugriffsmuster mithilfe von OWD und FLS, um den Zugriff standardmäßig einzuschränken, und gewähren Sie nur den zusätzlichen Zugriff, den jede Rolle mithilfe von Freigaberegeln benötigt. Erteilen Sie Profilen keinen übermäßigen Zugriff, der sensible Attribute offenlegen und diskriminierende Entscheidungen ermöglichen kann.
  • Aktivieren Sie die Benutzeragentur über die Plattformeinwilligung. Verwenden Sie die Einwilligungsverwaltungsfunktionen in Data 360 oder benutzerdefinierte Einwilligungsobjekte mit dem Feld-Aktivierungsprotokoll, um die detaillierte AI-Einwilligung pro Anwendungsfall zu verfolgen. Ermöglichen Sie es Benutzern, sich von AI-gestützten Funktionen abzumelden und menschliche Alternativen bereitzustellen (sofern möglich).

Datenarchitekturentscheidungen bestimmen die Populationen, die in Salesforce-Systemen sichtbar und unsichtbar werden. Schlechte Datenqualität ist nicht nur ein technisches Problem. Wenn Datenlücken bestimmte demografische Gruppen systematisch benachteiligen, wird dies zu einem Fairnessproblem.

  • Überprüfen Sie Pflichtfelder auf Datenverfügbarkeit. Wenn bei Pflichtfeldern die Informationsverfügbarkeit je nach demografischen Daten variiert, wird die Vollständigkeit der Daten diskriminierend. Benutzer, die die erforderlichen Informationen nicht bereitstellen können, werden in Systemen, die unvollständige Datensätze ablehnen, unsichtbar.
    • Durch die Anforderung von E-Mail-Adressen werden Populationen ausgeschlossen, die nicht über zuverlässigen Internetzugang oder persönliche E-Mail-Adressen verfügen.
    • Wenn US-amerikanische Sozialversicherungsnummern erforderlich sind, werden internationale Kunden und aktuelle Einwanderer ausgeschlossen, denen noch kein Stettiner Sozialversicherungsnummer ausgestellt wurde.
    • Durch die Anforderung von Straßenanschriften werden obdachlose Bevölkerungsgruppen und Benutzer mit nicht traditionellen Anschriften ausgeschlossen.
  • Überprüfen Sie die geschäftlichen Begründungen für Pflichtfelder. Für jedes Pflichtfeld müssen Sie dokumentieren, warum die Informationen obligatorisch und nicht optional sind. Wenn Prozesse ohne bestimmte Daten über alternative Ansätze funktionieren können, legen Sie diese Felder als optional fest und entwerfen Sie Systeme, um fehlende Werte ordnungsgemäß zu verarbeiten. Dadurch wird sichergestellt, dass Benutzer, die solche Daten nicht bereitstellen können, nicht ausgeschlossen werden.

Namensfelder, die westlichen Benennungskonventionen folgen (Vorname, Nachname), können Kulturen mit unterschiedlichen Benennungspraktiken ausschließen.

Viele Kulturen verwenden:

  • Einzelne Namen (oder Mononyme) ohne Familiennamen
  • Patronymische Systeme, bei denen sich “Nachname” generativ ändert
  • Mehrere Vornamen oder Familiennamen
  • Namen, die sich anhand von Lebensereignissen oder sozialem Kontext ändern
  • Namen, bei denen “Vorname” und “Nachname” kulturlos sind

Entwerfen Sie Namensarchitekturen mit einem einzelnen vollständigen Namensfeld oder einer flexiblen, mehrteiligen Struktur, die allgemeine Benennungskonventionen berücksichtigt. Vermeiden Sie es, Annahmen über die Namensreihenfolge, Übernahmemuster oder kulturelle Normen zu treffen.

Testen Sie die Namensarchitektur mit verschiedenen internationalen Namen, um sicherzustellen, dass Namensfelder Folgendes akzeptieren:

  • Einzelwortnamen (z. B. Sukarno, Cher und Teller)
  • Lange Namen, die allgemeine Obergrenzen für Feldlängen überschreiten
  • Namen mit Diakritika, Apostrophen, Bindestrichen und Leerzeichen
  • Namen mit nicht lateinischen Schriften (z. B. Arabisch, Chinesisch, Kyrillisch und Devanagari)

Wenn die Namensvalidierung den legitimen Namen eines Benutzers ablehnt, wird er aufgrund seiner kulturellen Identität vom System abgelehnt.

Adressvalidierungsservices sind oft für US-amerikanische und westeuropäische Formate optimiert und erkennen häufig Folgendes nicht:

  • Internationale Adressformate mit unterschiedlicher Feldreihenfolge
  • Ländliche Adressen ohne Straßennamen
  • Militärische Adressen (z. B. APO und FPO)
  • Postfächer und alternative Zustellungsstandorte
  • Stammländer mit eindeutigen Adresssystemen
  • Länder mit nicht-lateinischen Skripts für Adresskomponenten

Wenn Adressvalidierungen nicht traditionelle Adressformate ablehnen, werden Accounterstellung, Versand und Servicebereitstellung für Benutzer verhindert, deren Adressen nicht den Erwartungen der Validierungsdatenbank entsprechen.

Im Folgenden finden Sie einige Möglichkeiten, Adressvalidierungen unter Berücksichtigung des barrierefreien Zugriffs zu entwerfen:

  • Implementieren Sie die Validierung zulässiger Adressen.
  • Akzeptieren Sie die Eingabe von Freiformadressen, wenn strukturierte Validierungen fehlschlagen.
  • Speichern Sie Adressen so, wie sie von Benutzern eingegeben werden, statt Benutzer zu ungültigen Korrekturen zu zwingen.
  • Verwenden Sie die Adressvalidierung für die Datenanreicherung und die Duplikaterkennung, nicht zum Validieren der Adressformatierung.

Statt Datenerfassungen im Voraus zu blockieren, sollten Sie die Adressüberprüfung in Abwicklungsprozesse integrieren, bei denen es operativ auf die Genauigkeit der Adresse ankommt.

Universelle Zugriffsannahmen für bestimmte Kommunikationskanäle schließen Populationen mit unterschiedlichem Technologiezugriff oder unterschiedlichen Voreinstellungen aus.

Nur-E-Mail-Kommunikation schließt Folgendes aus:

  • Benutzer ohne zuverlässigen Internetzugang
  • Ältere Bevölkerungsgruppen, die weniger komfortabel mit der Verwendung von E-Mails sind
  • Benutzer in Regionen, in denen SMS- oder Messaging-Anwendungen die primäre Kommunikationsmethode sind

Bei der reinen Telefonkommunikation sind ausgeschlossen:

  • Gehörlose und schwerhörige Benutzer
  • Benutzer ohne Telefonzugriff oder Benutzer mit freigegebenen Telefonen

Entwerfen Sie eine Omnikanal-Kommunikationsarchitektur, mit der Benutzer Kanalvoreinstellungen steuern können. Speichern Sie bevorzugte Kommunikationsmethoden in Kontaktdatensätzen und berücksichtigen Sie die Präferenzen in allen ausgehenden Kommunikationssystemen einheitlich. Stellen Sie eine Vielzahl von Kommunikationsalternativen bereit, statt davon auszugehen, dass Einzelkanalmethoden universell funktionieren.

Die Erfassung demografischer Daten für die Fairnessüberwachung erfordert eine sorgfältige Architektur, um Missbrauch zu vermeiden.

Das Sammeln und Verarbeiten von demografischen Daten ist gerichtsstandsabhängig und rechtlich eingeschränkt (in der EU werden sie gemäß Artikel 9 der DSGVO als Daten spezieller Kategorien behandelt, die eine spezifische Rechtsgrundlage erfordern; in den USA basiert die Verzerrungsüberwachung in der Regel auf der freiwilligen Selbstidentifizierung von EEOs). Wenn eine Rechtsgrundlage besteht, verwenden Organisationen demografische Daten für folgende Zwecke:

  • Überwachen von Fairness-Kennzahlen, die nach geschützten Gruppen stratifiziert sind
  • Erkennen von Verzerrungen in Automatisierungs- und AI-Systemen
  • Nachweisen der Einhaltung gesetzlicher Vorschriften zur Bekämpfung von Diskriminierungen

Die Erfassung demografischer Daten birgt bestimmte Risiken:

  • Daten können für diskriminierende Zwecke verwendet werden, wenn die Zugriffssteuerung fehlschlägt
  • Benutzer können Sammlungsmethoden misstrauen und ungenaue Daten angeben
  • Sammlung kann sich invasiver oder diskriminierender anfühlen

Entwerfen Sie die freiwillige Selbstidentifikation und die demografische Datenerfassung anhand folgender Informationen:

  • Übersichtlich erklärt mit einem transparenten Zweck (z. B. Fairness-Monitoring oder Compliance-Bericht)
  • “Freiwillig” mit der Option “Nicht antworten” ist immer verfügbar
  • Getrennt von Betriebsdaten mit strenger FLS, um unangemessenen Zugriff zu verhindern
  • Aggregiert für Berichte und Analysen und nicht mit einzelnen Entscheidungen verknüpft
  • Überwacht über die Shield-Ereignisüberwachung für die Überprüfung von Zugriffsmustern

Es ist wichtig, in Datenschutzerklärungen genau zu dokumentieren, wie demografische Daten verwendet werden und wie nicht. Die Verletzung des User Trust durch die Nutzung nicht offengelegter Daten kann die Glaubwürdigkeit erheblich beeinträchtigen, was sich als schwierig erweisen kann.

Die Anreicherung von Drittanbieterdaten, die demografische, firmografische oder verhaltensbasierte Daten an Salesforce-Datensätze anhängt, kann zu Verzerrungen führen durch:

  • Ungenaue Rückschlüsse, die auf Stereotypen basieren
  • Unvollständige Abdeckung mit Lücken, die mit demografischen Daten korrelieren
  • Proprietäre Algorithmen, die unbekannte Fairness-Eigenschaften verwenden
  • Daten, die aus verzerrten historischen Datensätzen stammen

Bevor Sie Datenanreicherungsservices implementieren, sollten Sie Folgendes überprüfen:

  • Fairnesstests und Verzerrungsminderungspraktiken für Anbieter
  • Datenabdeckung und Genauigkeit über demografische Gruppen hinweg
  • Rückschlussmethoden und -funktionen, die zum Erstellen von Prognosen verwendet werden
  • Nutzungseinschränkungen und Aufbewahrungsrichtlinien für Vertragsdaten

Beachten Sie, dass Drittanbieterdaten, die in Ihre Salesforce-Organisation gelangen, sich auf Entscheidungen auswirken können, wodurch vom Anbieter eingeführte Verzerrungen entstehen, die sich auch als Verzerrungen in Ihrer Organisation widerspiegeln.

In Salesforce-Kontexten bezieht sich der barrierefreie Zugriff auf die Erstellung von Lightning Web Components, Visualforce-Seiten und Experience Cloud-Sites, die für Benutzer mit Behinderungen geeignet sind. Standardmäßige Lightning-Komponenten bieten bei ordnungsgemäßer Verwendung grundlegenden barrierefreien Zugriff. Für die benutzerdefinierte Entwicklung und Experience Cloud-Konfiguration ist jedoch eine explizite Implementierung des barrierefreien Zugriffs erforderlich.

Lightning Design System-Komponenten unterstützen die WCAG 2.2 AA-Konformität, wenn sie bestimmungsgemäß verwendet werden. Salesforce ist bestrebt, die vollständige Konformität zu gewährleisten, zertifiziert sie jedoch nicht. Wenn Sie von SLDS Mustern abweichen oder benutzerdefinierte Komponenten ohne Berücksichtigung des barrierefreien Zugriffs erstellen, entstehen Barrieren für Benutzer mit Behinderungen.

Standardmäßige Lightning Webkomponenten bieten integrierten Zugriff. Komponenten wie Lightning, Lightning-combobox, Lightning-datatable und Lightningcard enthalten automatisch die richtigen ARIA-Attribute, Bezeichnungszuordnungen, Tastaturnavigation und Fokusverwaltung. Verwenden Sie nach Möglichkeit Standardkomponenten, statt benutzerdefinierte Alternativen zu erstellen, die ähnlich aussehen, jedoch möglicherweise nicht über die entsprechende Infrastruktur für den barrierefreien Zugriff verfügen.

  • Verwenden Sie semantischen HTML-Code in benutzerdefinierten Lightning Web Components. Verwenden Sie beim Erstellen von benutzerdefinierten Komponenten semantische HTML-Elemente (
    ,
  • Implementieren Sie ARIA in benutzerdefinierten Komponenten. Wenden Sie ARIA-Landmarks, -Rollen und -Eigenschaften an, wenn semantische HTML-Elemente kein Oberflächenverhalten vermitteln können. Dynamische Inhaltsaktualisierungen erfordern Arien-Live-Bereiche, in denen Änderungen an Bildschirmleseprogrammen angekündigt werden. Benutzerdefinierte interaktive Komponenten benötigen explizite Rollendefinitionen, die ihrem Verhalten entsprechen. Lightning-Basiskomponenten verarbeiten ARIA automatisch. Benutzerdefinierte Komponenten müssen jedoch manuell über Bildschirmleseprogramme validiert werden.
  • Test mit Hilfstechnologie: Validieren Sie Lightning-Komponenten mit Bildschirmleseprogrammen (beispielsweise JAWS und NVDA für Windows, VoiceOver für macOS und iOS und TalkBack für Android). Basierend auf der groß angelegten Studie von Deque erfassen automatisierte Tools wie axe-core etwa 57 % der Probleme mit dem barrierefreien Zugriff nach Volumen. Die verbleibenden Probleme erfordern manuelle Tests mit Hilfstechnologien von Personen, die die Navigationsmuster von Bildschirmleseprogrammen verstehen.
  • Verwenden Sie die Fokusverwaltung in Lightning Flows. Wenn Modalfenster geöffnet, dynamische Inhalte geladen oder Benutzer Flows mit mehreren Schritten abschließen, sollten Sie den Fokus programmgesteuert verwalten, um Tastaturbenutzer zu neuen Inhalten zu führen. Die modalen Lightning-Komponenten und Popover-Komponenten bieten eine grundlegende Fokusverwaltung. Komplexe Flows benötigen jedoch eine explizite Fokuslogik, um den Fokus bei Inhaltsänderungen entsprechend zu verschieben.

Experience Cloud-Sites dienen externen Benutzern, einschließlich Kunden, Partnern und öffentlichen Zielgruppen, die ein barrierefreies Design benötigen, das möglicherweise die Anforderungen des ADA, Abschnitt 508 und/oder des Europäischen Barrierefreiheitsgesetzes (je nach Zuständigkeitsbereich, Zielgruppe und Organisationstyp) erfüllen muss.

  • Verwenden Sie barrierefreie Vorlagen. Experience Cloud-Vorlagen, die mit Lightning Web Runtime (LWR) erstellt wurden, sind barrierefrei. Standardvorlagen wie “Kundenaccountportal” und “Hilfecenter” bieten WCAG 2.2 AA-Grundlagen, wenn sie richtig konfiguriert sind. Benutzerdefinierte Vorlagen erfordern eine explizite Implementierung für den barrierefreien Zugriff, einschließlich semantischem Markup, Tastaturnavigation und Bildschirmleseprogramm-Kompatibilität.
  • Überprüfen Sie die WCAG-Konformität bei Themen. Benutzerdefinierte Themen und Sites mit Branding erfordern eine Farbkontrastvalidierung. Über die Themeneinstellungen des Erfahrungsgenerators werden Farben, Typografie und Abstände gesteuert. Stellen Sie sicher, dass der gesamte Text den Kontrast 4,5:1 für normalen Text (unter 18 pt für regulären Text oder unter 14 pt für Fettdruck) und 3:1 für großen Text (18 pt oder größer für regulären Text oder 14 pt oder größer für Fettdruck) und Benutzeroberflächenkomponenten erfüllt. Verwenden Sie Browser-Entwicklertools oder Online-Kontrastprüfungen, um die Einhaltung zu überprüfen. Testen Sie mit Browserzoom auf 200 %, um sicherzustellen, dass der Text skaliert wird, ohne Inhalt oder Funktionen zu verlieren.
  • Verwenden Sie die Tastaturnavigation in Navigationsmenüs. Experience Cloud-Navigationskomponenten müssen den reinen Tastaturbetrieb ohne Mausabhängigkeit unterstützen. Benutzer müssen mit den Tasten “Registerkarte”, “Eingabetaste”, “Escape” und “Pfeil” ohne Fokusfallen in Dropdown-Menüs, Mega-Menüs und Flyout-Navigation navigieren. Testen Sie alle Navigationspfade nur mit der Tastatur, um den barrierefreien Zugriff zu überprüfen.
  • Aktivieren Sie den barrierefreien Zugriff auf Formulare in Experience Cloud. Ordnen Sie allen Formulareingaben explizit Bezeichnungen zu, indem Sie die richtigen Bezeichnungselemente oder aria-labelledby verwenden. Platzhaltertext alleine weist keine Barrierefreiheitsanforderungen auf, da der Text sofort nach Beginn der Dateneingabe ausgeblendet wird, wodurch Bildschirmleseprogrammbenutzer keinen ausreichenden persistenten Kontext mehr haben. Lightning-Eingabekomponenten bieten eine integrierte Bezeichnungszuordnung, wenn sie mit den erforderlichen Bezeichnungsattributen konfiguriert werden. Für benutzerdefinierte Visualforce-Formulare ist eine explizite Bezeichnungseingabezuordnung erforderlich.
  • Testen Sie Experience Cloud-Sites mithilfe von Hilfstechnologien. Bevor Sie öffentliche Experience Cloud-Sites starten, müssen Sie umfassende Tests für den barrierefreien Zugriff mit Bildschirmleseprogrammen, reiner Tastaturnavigation und Browserzoom durchführen. Es ist wichtig, Benutzer mit Behinderungen in Benutzerfreundlichkeitstests einzubeziehen, um praktische Barrieren für die gelebte Erfahrung aufzuzeigen, die Expertenbewertungen möglicherweise verfehlen. Wenn Sie nur interne Lightning-Seiten testen, ohne den externen Experience Cloud-Zugriff zu validieren, sind öffentlich zugängliche Sites anfällig für Beschwerden und Rechtsstreitigkeiten hinsichtlich des barrierefreien Zugriffs.
  • Verwenden Sie alternativen Text für Bilder und Symbole. Alle informativen Bilder, Symbole und grafischen Inhalte in Experience Cloud erfordern alternativen Text. Dekorative Bilder verwenden leeren Alt-Text (alt=""), wodurch Bildschirmleseprogramme sie überspringen können. Informative Bilder bieten aussagekräftigen alternativen Text, der Inhalt und Funktion beschreibt. Konzentrieren Sie sich beim Schreiben von Alt-Text für Symbole auf die Aktion oder den Zweck des Symbols und nicht auf dessen visuelles Erscheinungsbild (so sollte der Alt-Text beispielsweise sein funktionales Dienstprogramm “Site durchsuchen” angeben, statt ein Lupensymbol als “Lupe” zu beschreiben). Beim Verwalten von Bildern muss das CMS Inhaltsautoren zur Eingabe von Alt-Text auffordern oder das Bild explizit als dekorativ markieren (wodurch alt=” festgelegt wird). Dadurch wird der barrierefreie Zugriff gewährleistet, da fehlender Alt-Text und erzwungene Beschreibungen für ästhetische Bilder verhindert werden.

Vollständiger barrierefreier Zugriff auf die Tastatur bedeutet, dass Benutzer über ihre Tastatur auf alle Funktionen zugreifen können, ohne dass eine Maus- oder Touchinteraktion erforderlich ist.

  • Verwenden Sie auf Lightning-Seiten die logische Fokusreihenfolge. Stellen Sie sicher, dass die Fokusreihenfolge dem visuellen Layout und dem Interaktions-Flow folgt. Wenn Benutzer die Tabulatortaste drücken, sollte sich der visuelle Fokus durch interaktive Elemente in der Reihenfolge bewegen, die Benutzer basierend auf dem visuellen Design erwarten. Der Lightning-Anwendungsgenerator und der Erfahrungsgenerator richten die Fokusreihenfolge anhand der Komponentenplatzierung ein. Benutzerdefinierte Komponenten erfordern eine explizite Registerkartenindexverwaltung, um den logischen Fokusfortschritt zu gewährleisten.
  • Verwenden Sie sichtbare Fokusindikatoren, um die Kontrastanforderungen zu erfüllen. Lightning Design System bietet Fokusstile, um die WCAG-Anforderungen für die meisten Komponenten zu erfüllen. Benutzerdefinierte Komponenten benötigen möglicherweise erweiterte Fokusindikatoren, um die 3:1-Kontrastanforderung gegenüber umgebenden Inhalten zu erfüllen. Fokusanzeigen müssen deutlich sichtbar sein, damit Benutzer mit eingeschränktem Sehvermögen über die Tastatur navigieren können. Entfernen Sie Fokusindikatoren niemals mit CSS (Umriss: Keine) ohne alternativen Stil mit sichtbarem Fokus.
  • Verwenden Sie Abhilfemaßnahmen für Tastaturfallen in Modalfenstern und Overlays. Modaldialoge sollten den Fokus im Modalfenster einschließen, während es geöffnet ist, wodurch verhindert wird, dass Tastaturbenutzer zu verdeckten Hintergrundinhalten gelangen. Die Fokusfalle sollte beim Schließen des Modalfensters freigegeben werden und den Fokus an das Auslöseelement zurückgeben. Eingebetteter Inhalt, einschließlich iframes und Drittanbieter-Widgets, darf ohne Escape-Mechanismus nicht dauerhaft den Tastaturfokus erfassen.
  • Verwenden Sie Tastenkombinationen ohne Konflikte. Lightning bietet standardmäßige Tastenkombinationen, die in der Salesforce-Hilfe dokumentiert sind. Benutzerdefinierte Tastenkombinationen müssen so konzipiert sein, dass Konflikte mit standardmäßigen Browsersteuerungen und Bildschirmleseprogramm-Navigationsbefehlen vermieden werden. In Übereinstimmung mit den WCAG-Erfolgskriterien dürfen einstellige Tastenkombinationen (beispielsweise durch Drücken eines einzelnen Buchstabens oder Satzzeichens) keine globalen Aktionen auslösen. Sie müssen die Aktivierung entweder auf den aktiven Fokus einer bestimmten Komponente beschränken oder Benutzern die Möglichkeit bieten, die Tastenkombination zu deaktivieren oder neu zuzuordnen.

Erstellen Sie eine Validierung des barrierefreien Zugriffs in CI/CD-Pipelines, um bei jeder Bereitstellung automatisch strukturelle Probleme zu finden, statt den barrierefreien Zugriff als regelmäßige manuelle Prüfungen zu behandeln.

  • Verwenden Sie sa11y für Lightning Web Component Accessibility-Tests. Die sa11y-Bibliotheken von Salesforce (das Paket @sa11y/jest) umschließen das Axe-Core-Modul für den barrierefreien Zugriff, um einen toBeAccessible()-Matcher für Jest-Einheitentests hinzuzufügen. Schreiben Sie automatisch Tests für den barrierefreien Zugriff, die die ordnungsgemäße ARIA-Nutzung, Bezeichnungszuordnungen, Kontrastverhältnisse und semantische Aufschläge im Rahmen von Einheitentests validieren. Konfigurieren Sie Builds so, dass sie fehlschlagen, wenn wichtige Probleme beim barrierefreien Zugriff erkannt werden.
  • Verwenden Sie Lighthouse CI für Experience Cloud. Google Lighthouse prüft den barrierefreien Zugriff auf Webseiten, einschließlich Experience Cloud-Sites. Integrieren Sie Lighthouse CI in Bereitstellungspipelines, um öffentliche Seiten auf Probleme beim barrierefreien Zugriff zu überprüfen. Konfigurieren Sie Bewertungsschwellenwerte so, dass vor Bereitstellungsgenehmigungen Mindestbewertungen für den barrierefreien Zugriff erforderlich sind.
  • Verwenden Sie den über das Salesforce DX MCP-Paket verfügbaren Agenten für den barrierefreien Zugriff. In MCP-kompatiblen Umgebungen oder in Agentforce Vibes überprüft es Code anhand von WCAG-Standards, zeigt gezielte Korrekturen an und kann eine Pull-Anforderung an einen Techniker zum Überprüfen, Validieren und Zusammenführen generieren.

Verzerrungen gab es in der deterministischen Salesforce-Automatisierung lange bevor die KI ins Spiel kam. Zuweisungsregeln, Flow-Entscheidungen, Validierungsregeln und das Regionsdesign codieren menschliches Urteilsvermögen, das Diskriminierung aufrechterhalten kann. Im Gegensatz zu KI-Verzerrungen – die von Architekten umfassend hinterfragt werden – werden Automatisierungsverzerrungen oft nicht untersucht, da sich deterministische Logik objektiv anfühlt.

  • Befolgen Sie Lead- und Kundenvorgangszuweisungsregeln. Verteilen Sie Arbeit auf Vertriebs- und Serviceteams. Wenn die Zuweisungslogik Kriterien verwendet, die mit geschützten Merkmalen korrelieren, führt die Automatisierung zu systematischen Unterschieden in Bezug auf die Servicequalität und den Opportunity-Zugriff.
  • Zuweisungsregeln, die Regions-, Postleitzahlen- oder Accounteigenschaften verwenden, können Opportunities mit hohem Wert unverhältnismäßig an bestimmte Teams weiterleiten, während Arbeit mit geringerem Wert an eine andere Stelle weitergeleitet wird. Wenn Regionsgrenzen mit Kundendemografien und Vergütungsstrukturen korrelieren, die sich zwischen den Regionen unterscheiden, führt die Zuweisungsautomatisierung zu wirtschaftlicher Diskriminierung.
  • Prüfen Sie regelmäßig die Ergebnisse von Zuweisungsregeln. Berechnen Sie Zuweisungsverteilungen zwischen Regionen und Teams, die nach Kundendemografien stratifiziert sind. Wenn sich Enterprise-Accounts auf bestimmte Regionen konzentrieren, während KMU-Accounts anderswo verteilt werden – und wenn Enterprise-Regionen bessere Vergütungen oder Ressourcen erhalten –, können Zuweisungsregeln zu ungerechten Ergebnissen führen, die eine Überprüfung der Fairness rechtfertigen.
  • Überprüfen Sie die fertigkeitsbasierte Omnikanal-Weiterleitung. Dies kann sich auf die Servicequalität zwischen Kundengruppen auswirken. Wenn die Weiterleitungslogik implizit davon ausgeht, dass bestimmte Fertigkeiten mit dem Kundenwert oder der Problemkomplexität korrelieren, erhalten Kunden möglicherweise unterschiedliche Serviceergebnisse basierend auf demografischen Proxys.

Es ist wichtig, die durchschnittliche Bearbeitungszeit, die Lösungen für den ersten Kontakt und die Kundenzufriedenheit über alle Weiterleitungspfade hinweg zu überwachen. Unterschiede können angeben, ob bestimmte Kundensegmente systematisch weniger erfahrene Agenten oder weniger Weiterleitungsoptionen erhalten.

  • Überprüfen Sie die Salesforce-Flow-Automatisierungen. Durch Genehmigungsentscheidungen, Anspruchsbestimmungen oder Zugriffsgewährungen kann diskriminierende Logik durch scheinbar harmlose Geschäftsregeln codiert werden. Bestimmte Flows führen zu indirekter Diskriminierung, wenn die Kriterien mit geschützten Merkmalen korrelieren.
  • Überprüfen Sie Flow-Entscheidungen unter Berücksichtigung der Fairness. Für jeden Flow, der Folgeentscheidungen trifft, die sich auf Benutzer auswirken, ist Folgendes wichtig:
  • Was geschieht mit Benutzern, die nicht zum typischen Kundenprofil passen?
  • Korrelieren Entscheidungskriterien mit demografischen Merkmalen?
  • Werden Ausnahmen und Randfälle gleich behandelt oder werden bestimmte Gruppen systematisch benachteiligt?

Es ist wichtig, Flow-Entscheidungslogik und Fairnessüberlegungen in Architekturentscheidungsdatensätzen zu dokumentieren und Flows mit hohem Einsatz denselben Ethiküberprüfungsrichtlinien wie AI-Systeme zu unterziehen.

  • Überprüfen Sie Validierungsregeln. Durch das Verhindern der Dateneingabe können gültige Daten von Benutzern ausgeschlossen werden, deren Informationen nicht mit den Systemannahmen übereinstimmen. Validierungsregeln, die legitime Daten ablehnen, führen zu unsichtbaren Populationen. Benutzer, deren Daten nicht mit Validierungsmustern übereinstimmen, können nicht mit bestimmten Systemen interagieren. Validierungsfehler werden oft nicht gemeldet, da Benutzer ihre Anforderungen verwerfen, statt technische Fehler zu melden. Im Folgenden finden Sie mehrere häufige Validierungsverzerrungsmuster:
  • Bei Namensvalidierungen, für die lateinische Zeichen erforderlich sind, können Namen mit Diakritika und nicht lateinischen Skripts ausgeschlossen werden.
  • Telefonnummernvalidierungen verwenden häufig US-amerikanische/westliche Formate, wodurch internationale Nummern und alternative Kommunikationsmethoden ausgeschlossen sind.
  • Adressvalidierungen erkennen keine nicht standardmäßigen Adressen (z. B. Postfächer, ländliche Routen, Stammesgebiete und internationale Formate).
  • E-Mail-Validierungen, für die persönliche E-Mail-Adressen erforderlich sind, können für Benutzer ohne persönlichen E-Mail-Zugriff von Nachteil sein.
  • Testen Sie Validierungsregeln mit verschiedenen Daten. Schließen Sie internationale Adressen, nicht westliche Namen und alternative Telefonformate in Validierungstests ein. Wenn die Validierung legitime Daten ablehnt, müssen Sie die Validierungslogik erweitern, um zu vermeiden, dass gültige Benutzer ausgeschlossen werden.
  • Überprüfen Sie die Vertriebsregionsdesigns. Kundensegmentierungsstrategien und Vertriebsregionsdesigns bestimmen die Ressourcenzuteilung zwischen Kundenpopulationen. Wenn Regionsgrenzen oder Segmentierungskriterien mit demografischen Daten korrelieren, die zu einer ungleichen Ressourcenzuteilung führen, kann diese Zuteilung zu diskriminierenden Ergebnissen führen. Regionsdesigns, die geografische Grenzen verwenden, korrelieren aufgrund von Wohntrennungsmustern oft mit rassischen, ethnischen und wirtschaftlichen demografischen Daten. Wenn sich die Vergütung, die Personalausstattung oder die Ressourceninvestitionen je nach Region unterscheiden, kann die geografische Region zu einem Mechanismus für die diskriminierende Ressourcenzuteilung werden.
  • Analysieren Sie Regionsdemografien, bevor Sie Entwürfe fertigstellen. Ordnen Sie Kundendemografien über vorgeschlagene Regionsgrenzen hinweg zu. Wenn sich demografische Konzentrationen abzeichnen, sollten Sie bewerten, ob die Ressourcenzuteilung unabhängig von der demografischen Zusammensetzung für alle Regionen gerecht wird. Wenn die geschäftliche Begründung unterschiedliche Ressourcenebenen in den einzelnen Regionen erfordert (z. B. Marktreife, Wettbewerbsintensität und Wachstumspotenzial), dokumentieren Sie diese Begründung explizit und überwachen Sie die Ergebnisse, um sicherzustellen, dass unterversorgte Regionen angemessene Investitionsmöglichkeiten erhalten, um verankerte Unterschiede zu vermeiden.
  • Sorgen Sie für Transparenz bei der Automatisierungslogik. Dokumentieren Sie Geschäftsregeln, Zuweisungskriterien und Flow-Entscheidungslogik in Salesforce Knowledge oder Architekturentscheidungsdatensätzen. Durch die transparente Automatisierung kann die Fairness so überprüft werden, dass eine versteckte Logik verhindert wird.
  • Prüfen Sie regelmäßig die Ergebnisse. Planen Sie vierteljährliche Prüfungen, um Automatisierungsergebnisse zu analysieren, die möglicherweise nach Kundendemografien stratifiziert sind. Beachten Sie, dass Ungleichheiten Untersuchungen und potenzielle Korrekturen auslösen.
  • Es ist wichtig, Folgendes zu verfolgen:
  • Zuweisungsverteilungen über Teams und Regionen hinweg
  • Genehmigungsraten für Flows, die Berechtigungsentscheidungen treffen
  • Ablehnungsraten von Validierungsregeln nach Datenmuster
  • Regionsleistung und Ressourcenzuteilung
  • Überprüfen Sie die Automatisierung mit hohem Einsatz durch eine ethische Linse. Unterziehen Sie Flows und Zuweisungsregeln, die sich auf Beschäftigung, Kredite, Servicezugriff oder andere Folgeergebnisse auswirken, demselben Ethiküberprüfungsprozess wie AI-Systeme. Automatisierungsverzerrungen erfordern dasselbe Maß an Überprüfung wie algorithmische Verzerrungen.

Bei Salesforce liegt der Fokus der KI-Fairness auf der Verwendung von Einstein, um zu validieren, dass Prognosen in allen demografischen Gruppen zu gerechten Ergebnissen führen. Einstein Discovery und die benutzerdefinierte Instrumentierung erfassen Entscheidungsdaten für Prognosemodelle, die die Verzerrungserkennung ermöglichen. CRM Analytics-Dashboards verfolgen Fairness-Kennzahlen. Das Feld-Aktivierungsprotokoll und die Ereignisüberwachung erfassen Entscheidungsdaten für die algorithmische Verantwortlichkeit.

Für Einstein-Prognosen, die sich auf Folgeentscheidungen auswirken (z. B. Leadbewertung, Opportunity-Prognose und Kundensegmentierung), sind Fairnessbewertungen vor der Bereitstellung erforderlich, die als obligatorischer gleichwertiger Schritt fungieren (ähnlich wie Sicherheitsüberprüfungen).

Analysieren Sie alle Prognosemodellfunktionen mit statistischen Methoden auf Korrelation mit geschützten Merkmalen. Entfernen oder transformieren Sie Proxy-Funktionen, nachdem Sie ausgewertet haben, ob ihr Prognosewert die Aufnahme trotz Proxy-Effekten rechtfertigt.

  • Überprüfen Sie Salesforce CRM-Daten vor dem Training. Salesforce-Organisationen enthalten jahrzehntelange menschliche Entscheidungen, die auf historischen Praktiken basieren. Wenn Vertriebsteams in der Vergangenheit bestimmte demografische Daten priorisiert haben, lernt die Einstein-Leadbewertung diese Muster kennen und behält sie bei. Bevor Sie Prognosemodelle für historische Daten trainieren, ist es wichtig, diese Daten auf demografische Darstellungslücken und Messinkonsistenzen zwischen Kundensegmenten zu überprüfen.
  • Berechnen Sie Fairness-Kennzahlen für demografische Gruppen. Bevor Sie Prognosemodelle bereitstellen, ist es wichtig, die demografische Parität, die Chancengleichheit und die ungleichen Auswirkungsverhältnisse zwischen geschützten Gruppen zu berechnen. Auf dieser Grundlage können Sie die erforderlichen demografischen Daten erfassen und verarbeiten. Wenn Einstein Leadbewertungen Segment A 50 % der Fälle, Segment B jedoch nur 30 % der Fälle hohe Bewertungen zuweisen, versagt eine 60 %-Quote bei der Vier-Fünftel-Regel (80 %) und erfordert eine Untersuchung und Abhilfe. Bei dem Wert von 80 % handelt es sich um einen Screening-Auslöser und nicht um eine Linie für rechtliches Bestehen/Fehler: Die Vier-Fünftel-Regel ist eine Faustregel des US-Bundes für die Beschäftigungsauswahl, und ihre Beseitigung ist kein sicherer Hafen – eine statistisch signifikante Disparität kann eine Prüfung bei höheren Quoten rechtfertigen und andere Regelungen messen negative Auswirkungen anders (das EU-Recht für indirekte Diskriminierung schaltet beispielsweise ein, ob eine Praxis einen „besonderen Nachteil“ ohne festen Schwellenwert schafft). Kalibrieren Sie Untersuchungsschwellenwerte auf die Rechtsordnungen und Anwendungsfälle, in denen Sie tätig sind.
  • Erfassen Sie Prognosemodell-Entscheidungsdaten für die Verzerrungserkennung. Erfassen Sie Entscheidungsdaten über Einstein Discovery und benutzerdefinierte Instrumente, um Verzerrungen in Prognosemodellen wie Leadbewertung und Opportunity-Bewertung zu erkennen: Speichern Sie Prognoseeingaben, -ausgaben und -modellversionen in verfolgten Feldern und aktivieren Sie “Feld-Aktivierungsprotokoll”. Analysieren Sie diese Daten in CRM Analytics, um Entscheidungsmuster über demografische Gruppen hinweg im Laufe der Zeit zu verfolgen, und erstellen Sie Dashboards, die Sie warnen, wenn Kennzahlen zur demografischen Parität oder zur Chancengleichheit über akzeptable Schwellenwerte hinausgehen.
  • Ermitteln Sie Proxy-Funktionen in Prognosemodellen. Funktionen, die mit geschützten Merkmalen korrelieren, ermöglichen eine indirekte Diskriminierung, selbst wenn geschützte Merkmale aus den Modellen ausgeschlossen werden.
    • Salesforce-Daten enthalten häufig Proxy-Funktionen:
  • Region oder Postleitzahl (Stellvertreter für Rasse, ethnische Zugehörigkeit und Einkommen)
  • Accountnamensmuster (Proxys für Organisationsgröße und Branchendemografie)
  • Kommunikationsaktivitätszeiteinteilung (Proxys für Zeitzonen, Religion und Fürsorgeaufgaben)
  • Gerätetyp oder Browser aus Aktivitätsdaten (Proxys für Einkommensniveau)

Wenn in Einstein Prognosen Verzerrungen erkannt werden, müssen Sie in der entsprechenden Pipeline-Phase (auf der Grundlage der Ursache und technischer Einschränkungen) Abhilfe schaffen.

  • Bilanzieren Sie Daten vor dem Modelltraining. Gleichen Sie Salesforce CRM-Daten aus, indem Sie unterrepräsentierte Kundensegmente überabtasten oder überrepräsentierte Segmente unterabtasten, bevor Sie Prognosemodelle trainieren. Verwenden Sie Data 360, um Daten über mehrere Organisationen hinweg zu aggregieren und so verschiedene Schulungssets sicherzustellen. Synthetische Datengenerierung kann spärliche Segmente ergänzen und gleichzeitig die Privatsphäre durch differenzielle Datenschutztechniken wahren.
  • Entfernen Sie Proxys in der Funktionsentwicklung. Wenn Proxy-Funktionen identifiziert werden, ersetzen Sie sie durch alternative Funktionen, die Prognosekraft ohne demografische Korrelation bieten. Wenn die Region als demografischer Proxy fungiert, sollten Sie die Branchenklassifizierung oder die Unternehmensgröße als Alternativen in Betracht ziehen. Wenn Accountnamensmuster mit demografischen Daten korrelieren, verwenden Sie stattdessen firmografische Attribute.
  • Anpassen von Schwellenwerten während der Nachbearbeitung. Passen Sie die Entscheidungsschwellenwerte pro demografischem Segment an, um die Ergebnisraten nach Schulungsmodellen anzugleichen. Bei beschäftigungsbezogenen Entscheidungen ist dies grundsätzlich verboten: Titel VII (Civil Rights Act von 1991) verbirgt die Anpassung von Bewertungen oder die Verwendung unterschiedlicher Hell-Dunkel-Bewertungen nach geschützter Klasse, und es gibt keine ausreichend dokumentierte Begründung, die die Praxis rechtmäßig macht. Dokumentieren Sie Schwellenwertanpassungen, sofern dies nicht verboten ist, mit betriebswirtschaftlicher Begründung für eine differenzielle Behandlung, wenn Prognosen automatisierte Entscheidungen beeinflussen.
  • Schulen Sie Modelle regelmäßig mithilfe aktualisierter Daten neu. Planen Sie die Modellneuschulung vierteljährlich (oder wenn erhebliche Datenverteilungsverschiebungen auftreten). Die erneute Schulung anhand aktueller Daten erfasst auftretende Verzerrungsmuster und korrigiert alle Abweichungen von den ursprünglichen Fairness-Basiswerten. Aktualisieren Sie die Fairness-Kennzahlen für jede Modellversion vor der Produktionsbereitstellung erneut, um sicherzustellen, dass die Umschulung keine neuen Verzerrungen mit sich bringt.

Die Einstein Trust Layer erfasst Eingabeaufforderungen, Antworten und Trust Signale für Funktionen der generativen AI und Agentforce und unterstützt so Transparenz und die Einhaltung gesetzlicher Vorschriften für die generative AI. Bei Prognosemodellen stammen Transparenz und Entscheidungslinien von Einstein Discovery und dem Modell-Manager, die eine benutzerdefinierte Instrumentierung erfordern, um Überprüfungsdaten aufzubewahren.

Erstellen Sie Erklärbarkeit in Einstein Lösungen aus der ursprünglichen Architektur, statt Erklärungen nach der Bereitstellung auf opaken Systemen nachzurüsten.

  • Erläuterungen zu Einstein Discovery an Entscheidungspunkten anzeigen. Einstein Discovery bietet Prognosefaktorenerklärungen, die zeigen, welche Variablen bestimmte Prognosen mit richtungsbezogener Auswirkung am stärksten beeinflusst haben. Architekt Lightning-Komponenten, die Benutzern diese Erläuterungen am Entscheidungspunkt anzeigen, statt die Navigation zum Trennen von CRM Analytics-Dashboards erforderlich zu machen. Wenn sich Entscheidungen auf Benutzer auswirken, benötigen sie Transparenz und keine abstrakten Modellleistungskennzahlen.
  • Ebenenerläuterungen für unterschiedliche Zielgruppen. Geben Sie eine Erklärungstiefe an, die für jede Zielgruppe geeignet ist:
  • Geschäftsbenutzer: “Dieser Lead hat eine hohe Bewertung erhalten, da der Jahresumsatz 1 Mio. EUR überschreitet und die Engagementbewertung unter den besten 10 % liegt.”
  • Technische Benutzer: Stellen Sie eine Einstein Discovery-Modellkarte mit Funktionsgewichtungen, Trainingsdateneigenschaften und Validierungskennzahlen bereit.
  • Kunden: “Diese Empfehlung basiert auf Ihren letzten Käufen und Kunden mit ähnlichen Voreinstellungen.”
  • Prüfer: Geben Sie die Entscheidungslinie aus Einstein Discovery und dem Modell-Manager an – Modellversion, Eingabewerte und die Faktoren, die die Prognose ausgelöst haben –, die durch benutzerdefinierte Instrumentierung erfasst werden.
  • Kommunizieren Sie Vertrauen entsprechend. Zeigen Sie die Prognosekonfidenz in benutzergerechten Begriffen an und vermeiden Sie grobe Wahrscheinlichkeitsbewertungen, die Benutzer möglicherweise falsch interpretieren. Statt “73 % Konfidenz” anzuzeigen, kommunizieren Sie dies mithilfe von Kategorien (z. B. “Hohe Konfidenz”, “Moderne Konfidenz” und “Überprüfung erforderlich”) mit Erläuterungen dazu, was jede Konfidenzstufe für die Entscheidungssicherheit bedeutet und welche zusätzlichen Überprüfungen vorgenommen werden.

Verwalten Sie umfassende, unveränderliche Audit-Trails, die die Verantwortlichkeit, das Debugging und die Einhaltung gesetzlicher Vorschriften für alle AI-gestützten Entscheidungen unterstützen, die sich auf Benutzer auswirken.

  • Erfassen Sie Prognose-Aktivierungsdaten mit den richtigen Tools. Speichern Sie Prognosemodell-Aktivierungsdaten (Prognoseeingaben, -ausgaben und -modellversionen) in verfolgten Feldern mit aktiviertem Feld-Aktivierungsprotokoll. Entwerfen Sie Datenaufbewahrungsrichtlinien, um die gesetzlichen Anforderungen zu erfüllen, die je nach Branche und Gerichtsbarkeit variieren:
    • Finanzdienstleistungsregeln legen die Aufbewahrung pro Verordnung fest (z. B. legt FINRA-Regel 4511(b) einen standardmäßigen Aufbewahrungszeitraum von sechs Jahren für Datensätze fest, für die gemäß FINRA-Regeln oder SEA-Regel 17a-4 kein anderer Aufbewahrungszeitraum festgelegt ist).
    • Die Aufbewahrung von Gesundheitsakten unterliegt auch spezifischen Regeln (HIPAA erfordert beispielsweise mindestens sechs Jahre für Compliance-Dokumentationen; die Aufbewahrung von Krankenakten wird durch einzelne Gesetze in den einzelnen Bundesstaaten festgelegt) und nicht nur einem unbefristeten Aufbewahrungsauftrag.
  • Analysieren Sie Prognosemodell-Entscheidungsdaten mit CRM Analytics. Erstellen Sie CRM Analytics-Dashboards anhand der erfassten Prognosemodell-Entscheidungsdaten (Prognoseeingaben, -ausgaben und -modellversionen in verfolgten Feldern), um Entscheidungsmuster, Fairness-Kennzahlen und die Modellleistung im Laufe der Zeit zu analysieren. Erstellen Sie Linsen, die Prognoseverteilungen nach Konfidenzstufe, demografischem Segment und Ergebnistyp anzeigen. Konfigurieren Sie Einstein Discovery-Artikel, die anormale Muster identifizieren, die einer zusätzlichen Untersuchung bedürfen.
  • Verwenden Sie das Feld-Aktivierungsprotokoll für die langfristige Aufbewahrung. Der Standardfeldverlauf verfolgt Änderungen für 18 Monate auf der Benutzeroberfläche und bis zu 24 Monate über die API. Mit dem Feld-Aktivierungsprotokoll können Sie den Feldverlauf für benutzerdefinierte Objekte, die AI-Entscheidungsdaten speichern, unbegrenzt beibehalten. Der Verlauf wird standardmäßig nach bis zu 18 Monaten archiviert. Anschließend werden die archivierten Daten so lange gespeichert, bis Sie sie löschen. Aktivieren Sie “Feld-Aktivierungsprotokoll” für Objekte, die Einwilligungsdatensätze, Überschreibungsentscheidungen und Verzerrungsberichte enthalten, um gesetzliche Aufbewahrungsanforderungen zu erfüllen.
  • Verwenden Sie die Ereignisüberwachung für Agentforce-Interaktionen. Die Ereignisüberwachung erfasst Ereignisse auf Aufrufebene für Agentforce, beispielsweise wenn Aktionen und Flows ausgeführt werden. Exportieren Sie Ereignisüberwachungsdaten in ein externes SIEM – standardmäßige Ereignisprotokolldatei-Daten über die API und die Teilmenge der Ereignisse der Echtzeit-Ereignisüberwachung über Plattformereignisse – für Speicher, der das native Salesforce-Aufbewahrungsfenster überschreitet. Manipulationsnachweise hängen von einem bestimmten SIEM-Verhalten ab, das die einmalige Speicherung und Zugriffstrennung erzwingt. Konfigurieren Sie SIEM-Abfragen, um Verzerrungsmuster in großen Volumen von Agentforce Interaktionen zu erkennen.
  • Überprüfen Sie Agentforce-Unterhaltungen mit der Einstein Trust Layer. Die Einstein Trust Layer erfasst den Prüfpfad der in Data 360 gespeicherten Agentforce-Unterhaltungsaufforderungen und -Antworten und stellt den Datensatz auf Abschriftsebene für Transparenz und Einhaltung gesetzlicher Vorschriften bereit.

Werfen wir einen genaueren Blick auf die Transparenzfunktionen von Architekten, die für die Einhaltung der aktuellen und neu entstehenden AI-Vorschriften in mehreren Rechtsordnungen positioniert sind.

  • Transparenzanforderungen des EU-AI-Gesetzes. AI-Systeme mit hohem Risiko gemäß dem EU-AI Act erfordern Transparenzdokumentation, technische Dokumentation, menschliche Aufsichtsfunktionen und Kennzahlen zur Genauigkeit/Fairness. Die Einstein Trust Layer-Aktivierungsprotokolle und Einstein Discovery-Modellkarten bieten die Grundlage für diese Anforderungen. Dokumentmodell mit Trainingsdatendemografien, Validierungsansätzen und bekannten Einschränkungen in Architekturentscheidungsdatensätzen.
  • Recht auf Erklärung. Die DSGVO gibt den betroffenen Personen in der EU das Recht, aussagekräftige Informationen über die Logik einer Entscheidung zu erhalten, wenn diese ausschließlich auf einer automatisierten Verarbeitung beruht und rechtliche oder ähnlich bedeutende Auswirkungen hat. Dieses Recht ergibt sich aus Artikel 15 Absatz 1 Buchstabe h und Artikel 22 Absatz 3 in Verbindung mit Erwägungsgrund 71 und wurde vom EuGH in der Rechtssache Dun & Bradstreet (2025) klargestellt. Entwerfen Sie Systeme, die bei Bedarf kohärente Erklärungen für historische Entscheidungen innerhalb der Zeitrahmen für die Anforderung von Zugriffen betroffener Personen generieren, die (je nach Zuständigkeit) zwischen 15 und 45 Tagen variieren. Mit den von Ihnen erfassten Prognosemodellentscheidungsdaten (Prognoseeingaben, Ausgaben, Modellversionen und Einstein Discovery-Erklärungsfaktoren) können Sie Erklärungen rekonstruieren, wenn sie mit ausreichender Aufbewahrung gespeichert werden.
  • Gesetze zur algorithmischen Verantwortlichkeit. Gesetze zur algorithmischen Rechenschaftspflicht auf US-Bundesstaaten verlangen zunehmend Folgenabschätzungen und Transparenzberichte für automatisierte Entscheidungssysteme. Die von Ihnen erfassten Prognosemodell-Entscheidungsdaten und das Dashboard zur Überwachung der Fairness in CRM Analytics bieten die Datengrundlage für diese Berichte. Führen Sie algorithmische Folgenabschätzungen durch, bevor Sie konsequente AI als proaktive Compliance und nicht als reaktive Antwort auf behördliche Anfragen bereitstellen.

OWDs, Freigaberegeln und Feldebenensicherheit (Field-Level Security, FLS) bestimmen die Datenzugriffsmuster, die bestimmen, welche Informationen Benutzer überprüfen und für Entscheidungen verwenden können. Die richtige Konfiguration verhindert diskriminierenden Zugriff auf sensible Attribute und gewährleistet gleichzeitig einen gleichmäßigen Service.

Entwerfen Sie OWDs und Feldebenensicherheit, um den Zugriff standardmäßig einzuschränken. Verwenden Sie bei Freigaberegeln das Prinzip der geringsten Berechtigung (PoLP), um nur den zusätzlichen Zugriff zu gewähren, den jede Rolle berechtigterweise benötigt, wodurch diskriminierende Entscheidungen aufgrund geschützter Merkmale verhindert werden.

  • Aktivieren Sie restriktive Einmalkennwörter als Standard. Verwenden Sie private Einmalkennwörter für Objekte, die vertrauliche Kundendaten enthalten, und erteilen Sie den Zugriff nach Rollenhierarchie und Freigaberegeln. Öffentliche Lese-/Schreibzugriffsberechtigungen machen das Einschränken des Zugriffs später störend – das Verschärfen der Standardeinstellung löst eine Freigabeneuberechnung aus und wird erst nach Abschluss wirksam – statt unmöglich. Private OWDs mit expliziten Freigabegewährungen erstellen überprüfbare Zugriffsmuster, die die Einhaltung von Diskriminierungsverboten unterstützen.
  • Wenden Sie die Feldebenensicherheit auf sensible Attribute an. Blenden Sie sensible Felder mit geschützten Merkmalen (z. B. Ethnie, Religion und Behinderungsstatus) für Benutzer aus, die aus legitimen Geschäftszwecken keinen Zugriff benötigen. Konfigurieren Sie FLS so, dass der Lesezugriff für sensible Felder in den meisten Profilen entfernt wird. Wenn diese Felder für bestimmte Zwecke erforderlich sind (z. B. Berichte zur Vielfalt und angemessene Unterkünfte), gewähren Sie minimalen Zugriff mithilfe von Berechtigungssätzen mit dokumentierter geschäftlicher Begründung.
  • Entwerfen Sie Zuweisungs- und Freigaberegeln für gerechte Ergebnisse. Verwenden Sie Zuweisungsregeln, Warteschlangen und die Omnikanal-Weiterleitung, um die Arbeit gleichmäßig auf Regionen, Teams und Serviceagenten zu verteilen. Vermeiden Sie die manuelle Freigabe, die hochwertige Opportunities oder Kunden mit bestimmten Benutzergruppen ohne dokumentierte geschäftliche Begründung konzentriert. Konfigurieren Sie automatische Freigaberegeln auf der Grundlage objektiver Kriterien (z. B. Branche, geografische Daten und Produktlinie) und nicht anhand des Ermessensspielraums des subjektiven Managers, was Verzerrungen ermöglichen kann.
  • Bereitstellen von Berechtigungssätzen für den temporären Zugriff. Gewähren Sie temporären Zugriff auf sensible Daten über Berechtigungssätze, statt Profile zu ändern, was sich dauerhaft auf alle Benutzer auswirkt. Wenn Benutzer Zugriff auf demografische Daten für bestimmte Projekte benötigen (z. B. Diversitätsanalysen und Unterkunftsanfragen), weisen Sie Berechtigungssätze mit dokumentierten Ablaufdaten zu. Geplante Flows können Berechtigungssätze nach definierten Zeiträumen automatisch widerrufen.

Verwenden Sie die Shield-Ereignisüberwachung und Berichte, um Datenzugriffsmuster zu erkennen, die auf eine potenzielle Diskriminierung oder Verzerrung bei der Datennutzung hinweisen.

  • Überprüfen Sie mithilfe der Shield-Ereignisüberwachung den Zugriff auf sensible Daten. Verwenden Sie die Ereignisüberwachung, um Zugriffsereignisse auf Objektebene (Berichtexporte, API-Abfragen und Seitenaufrufe) für Objekte zu erfassen, die geschützte Merkmale oder sensible Attribute enthalten. Konfigurieren Sie Abfragen über diese Ereignisse, um festzustellen, wer wann und in welchem Kontext auf das Objekt zugegriffen hat, und um anormale Muster (z. B. plötzliche Spitzen und Zugriff durch unerwartete Benutzer) als Auslöser für Untersuchungen zu behandeln.
  • Bericht zu Freigaberegelverteilungen. Erstellen Sie Berichte, die analysieren, wie Datensätze auf Benutzer, Teams und Regionen verteilt sind. Berechnen Sie Verteilungsstatistiken nach Kundendemografien, um sicherzustellen, dass hochwertige Accounts und Opportunities gleichmäßig verteilt sind. Identifizieren Sie Konzentrationen, bei denen bestimmte Benutzergruppen unverhältnismäßigen Zugriff auf wertvolle Datensätze erhalten, ohne dass eine dokumentierte geschäftliche Begründung vorliegt.
  • Überprüfen Sie CRUD- und FLS-Verstöße. Überprüfen Sie das Setup-Aktivierungsprotokoll auf Änderungen an OWD-Einstellungen, Freigaberegeln, FLS-Konfigurationen und Berechtigungssätzen. Nicht autorisierte Änderungen an Datenzugriffssteuerungen können auf Versuche hinweisen, unangemessen auf sensible Daten zuzugreifen. Verwenden Sie Transaktionssicherheitsrichtlinien, um auf Ereignisse der Echtzeit-Ereignisüberwachung mit hohem Risiko zu reagieren (z. B. anormale API-Aktivität, verdächtige Anmeldungen und große Exporte vertraulicher Daten in Berichte oder Listenansichten). Da die Transaktionssicherheit nur für diese Laufzeitereignisse und nicht für DML- oder FLS-Änderungen auf Datensatzebene verwendet wird, müssen Sie sich auf das Setup-Aktivierungsprotokoll und dokumentierte Genehmigungen der Änderungsverwaltung für FLS- und Freigabeänderungen verlassen.

Bei Salesforce bedeutet Benutzeragentur, dass Kunden und Mitarbeiter eine sinnvolle Kontrolle darüber behalten, wie sich KI auf ihre Erfahrung auswirkt. Salesforce-Einwilligungsverwaltungsfunktionen, Data 360-Einwilligungsobjekte und benutzerdefinierte Einwilligungsobjekte ermöglichen eine genaue Kontrolle über AI-Interaktionen.

Entwerfen Sie die Einwilligungsverfolgung mithilfe der Data 360-Einwilligungsverwaltung, Marketing Cloud-Einwilligungsobjekten oder benutzerdefinierten Einwilligungsobjekten, die das Field Audit Trail für AI-spezifische Einwilligungsanforderungen verwenden.

  • Aktivieren Sie die detaillierte Einwilligung pro AI-Anwendungsfall. Aktivieren Sie die Einwilligung pro AI-Anwendungsfall, statt eine allgemeine AI-Einwilligung zu verwenden. Kunden können Einstein Produktempfehlungen zustimmen, AI-gestützte Kreditentscheidungen jedoch ablehnen. Aktivieren Sie “Feld-Aktivierungsprotokoll” für Einwilligungsobjekte, um die Daten langfristig zu speichern und behördliche Anforderungen zu erfüllen. Entwerfen Sie benutzerdefinierte Einwilligungsobjekte mit Feldern, die Folgendes verfolgen:
  • Einwilligungszweck (z. B. Einstein Leadbewertung, Einstein Antwortempfehlungen und Einstein Empfehlungsgenerator)
  • Einwilligungserteilungsdatum und Erteilungsmethode (z. B. Webformular, API, Telefon und E-Mail)
  • Widerrufsdatum der Einwilligung (falls zutreffend)
  • Zugehöriger Benutzer oder Kontakt-ID
  • Verwenden Sie die Data 360-Einwilligung für die Personalisierung. Verwenden Sie die Data 360-Einwilligungsverwaltung für Einstein-Personalisierungen. Data 360 erfasst und speichert Einwilligungsvoreinstellungen aus vorgelagerten Systemen über Konnektoren, die dem Datenschutzdatenmodell zugeordnet sind. Dadurch können Sie diese Einwilligungsattribute als Filterkriterien bei der Segmentierung und bei der Aktivierung verwenden. Zuordnen von Einwilligungsattributen zu bestimmten AI-Anwendungsfällen, damit sich Benutzer von der Personalisierung abmelden können und gleichzeitig die zentralen Services beibehalten werden
  • Aktivieren Sie die Marketing Cloud-Einwilligungsintegration. Integrieren Sie die Marketing Cloud-Einwilligung in Einstein Messaging-Statistiken und AI-gestützte Marketingfunktionen. Berücksichtigen Sie den Marketing Cloud-Abonnementstatus und die Einwilligung in alle AI-gestützten Kommunikationen.

Stellen Sie sinnvolle Abmeldungen von AI-gestützten Funktionen mit barrierefreien Steuerelementen bereit, die Benutzerpräferenzen über menschliche Alternativen vergleichbarer Qualität berücksichtigen.

  • Bereitstellen von barrierefreien Abmeldungen in den Profileinstellungen. Ermöglichen Sie es Benutzern, sich von AI-gesteuerten Interaktionen abzumelden, indem Sie die Steuerelemente für barrierefreie Voreinstellungen in den Experience Cloud-Profileinstellungen oder “Meine Einstellungen” in internen Anwendungen verwenden. Geben Sie eine klare Beschreibung dazu an, was die einzelnen Abmeldungen bedeuten und welche alternativen Erfahrungen Benutzer nach der Abmeldung erhalten. Speichern Sie Voreinstellungen in Benutzer- oder Kontaktdatensätzen.
  • Bereitstellen persistenter Voreinstellungsoptionen über mehrere Kanäle hinweg. Speichern Sie AI-Voreinstellungen in Benutzer- oder Kontaktdatensätzen, um die Konsistenz zwischen Kanälen (z. B. Web, Mobiltelefon, Telefon und E-Mail) sicherzustellen. Fragen Sie Voreinstellungen in allen Interaktions-Flows konsistent ab, um zu verhindern, dass Benutzer Voreinstellungen in verschiedenen Kanälen wiederholt bestätigen müssen.

Die ethische AI-Governance bietet Organisationsstrukturen, die dazu beitragen, die Fairness bei der Weiterentwicklung von Modellen, Datenverschiebungen und Anwendungsfällen zu gewährleisten. Ohne Governance verschlechtern sich die anfänglichen Bemühungen um Fairness, wenn sich die Aufmerksamkeit der Organisation verschiebt.

Richten Sie vor der Einstein Bereitstellung eine obligatorische Dokumentation ein und überprüfen Sie die Prüfpunkte. Stellen Sie sich dies als ein Tor vor, das genauso wichtig ist wie Sicherheitsüberprüfungen.

  • Stellen Sie eine Modelldokumentation bereit. Speichern Sie die Modelldokumentation in Salesforce mit einem benutzerdefinierten Modellobjekt oder Salesforce Files, die an Projekte angehängt sind, um die Durchsuchbarkeit und Versionskontrolle zu ermöglichen. Dokumentieren Sie jedes Produktionsprognosemodell mit:
  • Trainingsdatendemografie und bekannte Darstellungslücken (für vom Kunden trainierte Prognosemodelle wie Einstein Discovery und den Prognosegenerator)
  • Fairness-Kennzahlen vor der Bereitstellung, die nach demografischer Gruppe berechnet werden
  • Vorgesehene Anwendungsfälle und bekannte unangemessene Verwendungen
  • Strategien zur Verzerrungsminderung, die während der Entwicklung angewendet werden
  • Fairness-Monitoring-Ansatz und Warnschwellenwerte
  • Humane Aufsichtsanforderungen und Genehmigungsworkflows
  • Überprüfen von Plänen und Verantwortlichen
  • Regulatorische Überlegungen und Compliance-Positionierung
  • Aktivieren Sie Fairness-Gates vor der Bereitstellung. Modelle, bei denen Gate-Tests fehlschlagen, dürfen nicht in die Produktion übergehen. Behandeln Sie Fairness-Gates mit der gleichen Strenge wie Sicherheits-Gates. Anders ausgedrückt: Sie sind berechtigt, Bereitstellungen zu blockieren. Bevor Sie Einstein-Prognosen in der Produktion bereitstellen können, müssen Sie:
  • Überprüfen Sie die Trainingsdatenüberprüfungen. Alle Darstellungslücken müssen analysiert und dokumentiert werden.
  • Überprüfen Sie Fairnesskennzahlen (beispielsweise müssen die demografische Parität, die Chancengleichheit und die ungleichen Auswirkungen berechnet und bestätigt werden, damit Schwellenwerte erreicht werden).
  • Überprüfen Sie die Folgenabschätzungen. Bewerten Sie potenzielle Schäden in allen betroffenen Populationen.
  • Design mit menschlicher Aufsicht. Alle Eskalationsmuster, Genehmigungsworkflows und Überschreibungsmechanismen müssen entsprechend konzipiert und getestet werden.
  • Führen Sie eine Transparenzüberprüfung aus. Erklärungsfunktionen müssen für alle Entscheidungstypen validiert werden.
  • Vollständige Dokumentation. Alle erforderlichen Artefakte der Modelldokumentation müssen genehmigt werden.

Richten Sie Überprüfungsprozesse für AI-Anwendungen mit hohem Anteil ein, die eine funktionsübergreifende Aufsicht bieten und über Durchsetzungsbefugnisse verfügen.

  • Zusammensetzung des Überprüfungsboards. Schließen Sie technische Experten (z. B. Architekten und Datenwissenschaftler), Beteiligte der Wirtschaft (z. B. Produktinhaber und Betriebspersonal), Rechtsbeistände, Datenschutzspezialisten und Vertreter betroffener Communities (sofern möglich) ein. Denken Sie daran, dass unterschiedliche Perspektiven Fairnessprobleme aufdecken, die homogene Gruppen oft vermissen.
  • Überprüfen Sie alle Auslöser, für die eine Genehmigung durch die Ethikkommission erforderlich ist. Definieren Sie, welche AI-Anwendungsfälle vor der Bereitstellung überprüft werden müssen:
  • Entscheidungen, die sich auf Beschäftigungs-, Kredit-, Wohnungs-, Gesundheits- oder Rechtsansprüche auswirken
  • Automatisierte Systeme, die mehr als 10.000 Benutzer oder Transaktionen pro Jahr betreffen
  • AI-Anwendungen, die sensible personenbezogene Daten verwenden, einschließlich Gesundheits-, Finanz- oder demografischer Daten
  • Neuartige Anwendungsfälle ohne etablierten Organisationspräzedenzfall
  • Systeme, bei denen potenzielle Verzerrungen Einzelpersonen oder Gruppen erheblich schaden können
  • Überprüfen und bestimmen Sie, wer zum Blockieren von Bereitstellungen berechtigt ist. Ethik-Überprüfungsgremien sollten die Befugnis haben, Änderungen zu verlangen, Überwachungsbedingungen aufzuerlegen oder Bereitstellungen zu blockieren, die ethischen Standards nicht entsprechen. Überprüfungen nur für die Beratung (ohne Durchsetzungsbefugnis) können die Effektivität des Governance-Prozesses einschränken. Dokumentieren Sie alle Überprüfungen in benutzerdefinierten Salesforce-Objekten, die Folgendes verfolgen: Anwendungsname, Überprüfungsdatum, geltend gemachte Bedenken, Anforderungen an die Abhilfe und Genehmigungsbedingungen.

Die Fairnessüberwachung ist ein fortlaufender Prozess, der kontinuierliche Aufmerksamkeit erfordert, um Verzerrungen zu erkennen, wenn sich Datenverteilungen ändern und Benutzerpopulationen geändert werden.

  • Erstellen Sie CRM Analytics-Dashboards für Fairness. Erstellen Sie Dashboards, die Fairness-Kennzahlen mithilfe der von Ihnen erfassten Prognosemodell-Entscheidungsdaten verfolgen. Überwachen Sie die demografische Parität, die Chancengleichheit, die ungleichen Auswirkungsverhältnisse und die Kennzahlen zur Prognosequalität nach Kundensegmenten. Konfigurieren Sie CRM Analytics-Benachrichtigungen, die ausgelöst werden, wenn Fairness-Kennzahlen definierte Schwellenwerte überschreiten und eine Untersuchung erfordern.
  • Aktivieren Sie die benutzerdefinierte Überwachung auf Fairnesssignale. Erstellen Sie eine benutzerdefinierte Fairness-Überwachung, um Signale zu erkennen (z. B. plötzliche Änderungen der Entscheidungsverteilungen nach demografischer Gruppe, Spitzen in verzerrten Kundenvorgangs-Datensätzen oder Verschlechterung der Modellleistung für bestimmte Populationen).
  • Planen Sie Fairness-Audits. Führen Sie umfassende, vierteljährliche Fairness-Prüfungen für AI-Systeme mit hohem Anteil (z. B. Kredite, Beschäftigung und Gesundheitswesen) und halbjährliche Prüfungen für Systeme mit niedrigem Anteil (z. B. Empfehlungen und Personalisierung) durch. Audits sollten aktuelle Fairness-Kennzahlen untersuchen, Überschreibungsmuster im Genehmigungsverlauf überprüfen, Benutzerfeedback und Verzerrungsberichte analysieren und validieren, dass die Governance-Kontrollen wirksam bleiben.
  • Implementieren Sie die Vorfallsreaktion für Fairnessfehler. Richten Sie klare Prozesse ein, die in Salesforce Knowledge dokumentiert sind und in denen erläutert wird, wie bei erkannter Verzerrung reagiert werden soll:
  • Sofort: Bewerten Sie den Schweregrad und den Umfang, indem Sie die Entscheidungsdaten des Prognosemodells in CRM Analytics abfragen. Wenn der Vorfall schwerwiegend ist, setzen Sie alle automatisierten Entscheidungen bis zur Untersuchung aus.
  • Kurzfristig: Implementieren Sie temporäre Abhilfestrategien (z. B. eine höhere menschliche Aufsicht über angepasste Konfidenzschwellenwerte, Funktionsdeaktivierung oder vollständige Agentenaussetzung).
  • Untersuchung: Führen Sie eine Ursachenanalyse aus, um zu ermitteln, wie die Verzerrung in das System gelangt ist oder sich entwickelt hat. Analysieren Sie während der RCA Trainingsdaten, Modellversionen und Konfigurationsänderungen über das Feld-Aktivierungsprotokoll.
  • Abhilfe: Implementieren Sie eine dauerhafte Korrektur durch Datenkorrektur, Modellneuschulung oder Prozessänderungen.
  • Kommunikation: Benachrichtigen Sie betroffene Benutzer über Kundenvorgänge, E-Mails oder Experience Cloud-Ankündigungen.
  • Prävention: Verarbeiten Sie Änderungen, um Wiederholungen zu verhindern, und dokumentieren Sie die Präventionsmethoden in Runbooks.

Verwenden Sie diese Checkliste bei Architekturüberprüfungen, vor der Produktionsbereitstellung und regelmäßig für die fortlaufende Bewertung.

Datenqualität und Darstellungsgerechtigkeit

  • Legen Sie Felder als optional fest, bei denen ein Prozess ohne die Daten funktionieren kann, und entwerfen Sie nachgelagerte Prozesse so, dass fehlende Werte verarbeitet werden, sodass Benutzer, die keine Informationen bereitstellen können (E-Mail, Stettiner Straße, Anschrift), nicht ausgeschlossen werden.
  • Felder vom Typ “Architektname” als einzelnes vollständiges Namensfeld oder flexible mehrteilige Struktur, die Mononyme, nicht-lateinische Skripts, Diakritika und Langnamen akzeptiert, statt die westliche Vor-/Nachreihenfolge anzunehmen.
  • Implementieren Sie die zulässige Adressvalidierung, die Freiform- und internationale Formate akzeptiert, indem Sie Adressen wie eingegeben speichern, statt die Datensatzerstellung bei Formatabweichungen zu blockieren.
  • Speichern Sie Kommunikationskanal-Voreinstellungen in Kontaktdatensätzen und unterstützen Sie Omnikanal-Alternativen (E-Mail, SMS, Telefon, Post, Chat, Voice), statt anzunehmen, dass ein einzelner Kanal alle Benutzer erreicht.
  • Erfassen Sie demografische Daten durch freiwillige Selbstidentifizierung mit der Option “Nicht antworten”; sie werden separat unter Private OWD mit FLS gespeichert, für Berichte aggregiert und über die Shield-Ereignisüberwachung überwacht.
  • Überprüfen Sie Anreicherungsdrittanbieter auf Fairnesstests, demografische Abdeckung und Rückschlussmethoden, bevor Sie demografische oder verhaltensbasierte Daten an Datensätze anhängen.

Barrierefreiheit und inklusives Design

  • Verwenden Sie Lightning Design System-Komponenten, die den barrierefreien Zugriff auf WCAG 2.2 AA unterstützen. Beachten Sie, dass Salesforce die Konformität anstrebt, Komponenten jedoch weiterhin ordnungsgemäß verwendet werden müssen.
  • Validieren Sie benutzerdefinierte Lightning Web Components mit Bildschirmleseprogrammtests (z. B. JAWS, NVDA und VoiceOver).
  • Stellen Sie sicher, dass die vollständige Tastaturnavigation auf Lightning-Seiten und Experience Cloud-Sites ohne Mausabhängigkeit vorhanden ist.
  • Überprüfen Sie mithilfe von Browser-Entwicklertools oder Kontrastprüfungen, ob Kontrastverhältnisse bei normalem Text 4,5:1 erfüllen.
  • Integrieren Sie sa11y- oder Lighthouse-Scans für den barrierefreien Zugriff in CI/CD-Pipelines, bei denen Builds bei wichtigen Problemen fehlschlagen.
  • Testen Sie Experience Cloud-Sites vor der öffentlichen Einführung mithilfe von Hilfstechnologien.
  • Überprüfen Sie das akustische Feedback, indem Sie sicherstellen, dass alle dynamischen Änderungen (z. B. Fehlerstatus, Ladevorgänge oder erweiterte Menüs) klar angekündigt sind und der gesprochene Inhalt dem visuellen Intent der Benutzeroberfläche entspricht.

Fairness in Salesforce Automation

  • Überprüfen Sie Zuweisungs- und Weiterleitungsregeln auf Korrelation mit geschützten Merkmalen, die günstige oder ungünstige Ergebnisse in bestimmten demografischen Gruppen konzentrieren könnten.
  • Überwachungs-Flow und Prozessautomatisierungs-Entscheidungslogik für Verzerrungen, Dokumentieren von Geschäftsregeln und -kriterien in Salesforce Knowledge- oder Architekturentscheidungsdatensätzen.
  • Werten Sie Validierungsregeln für Ablehnungsraten aus, die sich unverhältnismäßig auf bestimmte Datenmuster oder Populationen auswirken.
  • Analysieren Sie Regions- und Segmentierungsdesigns auf demografische Korrelation, dokumentieren Sie explizite geschäftliche Begründungen und überwachen Sie unterversorgte Regionen, um eine gerechte Ressourcenzuteilung zu gewährleisten.
  • Unterziehen Sie Flows mit hohem Einsatz und Zuweisungsregeln (Beschäftigung, Kredit, Servicezugriff) demselben Ethiküberprüfungsprozess wie AI-Systeme und planen Sie vierteljährliche Überprüfungen der nach demografischen Daten stratifizierten Automatisierungsergebnisse.

AI-Fairness und Verzerrungserkennung

  • Überprüfen Sie Salesforce CRM-Daten vor dem Prognosemodelltraining auf demografische Darstellungslücken.
  • Berechnen Sie vor der Bereitstellung demografische Parität, Chancengleichheit und ungleiche Auswirkungsverhältnisse pro demografischer Gruppe.
  • Implementieren Sie Fairnessbewertungen als obligatorisches Bereitstellungs-Gate (stellen Sie sich dies als Äquivalent zu einer Sicherheitsüberprüfung vor).
  • Erstellen Sie CRM Analytics-Dashboards, die Fairness-Kennzahlen mithilfe von Prognosemodell-Entscheidungsdaten verfolgen, die mit dem Field Audit Trail erfasst wurden.
  • Analysieren Sie Prognosemodellfunktionen auf Proxy-Korrelation mit geschützten Merkmalen (z. B. Regions- und Accountnamensmuster).
  • Planen Sie umfassende, vierteljährliche Fairness-Prüfungen für alle AI-Systeme mit hohem Anteil.

Transparenz und Überprüfbarkeit

  • Zeigen Sie Einstein Discovery-Prognoseerklärungen an Entscheidungspunkten in Lightning-Komponenten an.
  • Konfigurieren Sie Einstein Trust Layer-Aktivierungserfassungen mithilfe von Aufbewahrungsmethoden, die die gesetzlichen Anforderungen erfüllen.
  • Aktivieren Sie “Feld-Aktivierungsprotokoll” für alle benutzerdefinierten Objekte, in denen AI-Entscheidungsdaten für die langfristige Aufbewahrung gespeichert werden.
  • Exportieren Sie Ereignisüberwachungsdaten in ein externes SIEM – Ereignisprotokolldatei-Daten über die API und Ereignisse der Echtzeit-Ereignisüberwachung über Plattformereignisse – für Speicher, der die native Aufbewahrung überschreitet, mit SIEM-seitigen Steuerelementen zum Einmalschreiben für Manipulationsnachweise.
  • Stellen Sie eine benutzergerechte Konfidenzkommunikation bereit (z. B. “Hoch”, “Mittel” und “Niedrig”) anstelle von Rohwahrscheinlichkeiten.

Menschliche Übersicht mit Salesforce Automation

  • Konfigurieren Sie vertrauensbasierte Eskalationsschwellenwerte in “Flow” und leiten Sie Prognosen mit niedrigem Konfidenzniveau an eine menschliche Überprüfung weiter.
  • Verwenden Sie Salesforce-Genehmigungsprozesse für Entscheidungen mit hohem Anteil, für die mehrstufige Überprüfungsketten erforderlich sind.
  • Integrieren Sie Agentforce und die Omnikanal-Weiterleitung, um eine nahtlose Eskalation für menschliche Agenten zu ermöglichen.
  • Stellen Sie auf Agentforce-Oberflächen eine persistente Option “Mit menschlichem Agenten verbinden” bereit, um die Benutzeragentur zu berücksichtigen.
  • Für Agentforce-Überschreibungen, die in benutzerdefinierten Feldern erfasst werden, ist eine dokumentierte Verfolgung von Gründen und Genehmigungsverläufen erforderlich.

Nichtdiskriminierung mit Datenzugriffssteuerungen

  • Aktivieren Sie Private OWD und erteilen Sie dann zusätzlichen Zugriff über Rollenhierarchie und Freigaberegeln.
  • Konfigurieren Sie die Feldebenensicherheit so, dass sensible demografische Felder für Benutzer ausgeblendet werden, die keinen Zugriff benötigen.
  • Überwachen Sie Zugriffsereignisse auf Objektebene (Berichtexporte und API-Abfragen) über die Shield-Ereignisüberwachung auf sensible Daten und analysieren Sie sie auf anomale Zugriffsmuster.
  • Erstellen Sie Berichte, die Verteilungen von Freigaberegeln analysieren, um eine gleichmäßige Datensatzzuteilung über Regionen hinweg sicherzustellen.
  • Überprüfen Sie das Setup-Aktivierungsprotokoll auf nicht autorisierte Änderungen an der OWD-, Freigaberegel- oder FLS-Konfiguration.

Benutzeragentur und Einwilligung

  • Entwerfen Sie benutzerdefinierte Einwilligungsobjekte mithilfe des Feld-Aktivierungsprotokolls, um die detaillierte AI-Einwilligung pro Anwendungsfall zu verfolgen.
  • Integrieren Sie die Einwilligung in Data 360 oder Marketing Cloud in die Funktionen für Einstein-Personalisierung und Agentforce.
  • Speichern Sie AI-Voreinstellungen in Benutzer- oder Kontaktdatensätzen, um die Konsistenz zwischen Kanälen (z. B. Web, Mobilgerät und Telefon) sicherzustellen.
  • Stellen Sie über die Omnikanal-Weiterleitung barrierefreie Abmeldungen in Profileinstellungen und menschliche Alternativen bereit.
  • Fragen Sie Einwilligungsdatensätze in Flow ab, bevor sich Einstein-Prognosen oder Agentforce Engagement auf Benutzer auswirken.

Ethische AI-Governance

  • Dokumentieren Sie alle Produktionsprognosemodelle, einschließlich Fairness-Kennzahlen und Abhilfestrategien. Dokumentieren Sie bei vom Kunden trainierten Prognosemodellen (z. B. Einstein Discovery und Prognosegenerator) auch Trainingsdatendemografien.
  • Richten Sie obligatorische Fairness-Gates vor der Bereitstellung ein, die die Bereitstellung blockieren, bis alle Fairness-Kriterien erfüllt sind.
  • Erstellen Sie ein AI-Ethiküberprüfungsgremium als Durchsetzungsbehörde für alle AI-Anwendungen mit hohem Einsatz.
  • Erstellen Sie CRM Analytics-Dashboards, um Fairness-Kennzahlen in einem geplanten Rhythmus über CRM Analytics-Benachrichtigungen zu überwachen.
  • Definieren Sie Vorgehensweisen zur Reaktion auf Vorfälle bei Fairnessfehlern und dokumentieren Sie den Prozess in Salesforce Knowledge.
  • Planen Sie vierteljährliche Fairness-Audits, die Überschreibungsmuster und Benutzerfeedback für alle Systeme mit hohem Einsatz analysieren.

Teilen Sie uns Ihr Feedback zum Well-Architected Framework mit.