Eerlijkheid

Eerlijkheid

In Salesforce-architecturen betekent eerlijkheid het bouwen van oplossingen die gebruikers eerlijk dienen door middel van toegankelijke interfaces, detectie en vermindering van vertekening, transparante beslissingen en ethisch bestuur. De voorspellingen van Einstein beïnvloeden uitkomsten die van invloed zijn op klanten en werknemers, wat betekent dat architecten systemen moeten ontwerpen die gelijke resultaten opleveren voor demografische groepen, terwijl ze ook toegankelijk blijven voor gebruikers met een beperking.

Salesforce biedt platformmogelijkheden die speciaal zijn ontwikkeld voor eerlijkheid en we streven ernaar om te voldoen aan WCAG 2.2 AA. Bij correct gebruik biedt het Salesforce Lightning Design System (SLDS) componenten die zijn ontworpen om dit doel te ondersteunen. Laten we elke component nader bekijken.

  • Shield Platform Encryption beschermt gevoelige kenmerken zoals demografische gegevens en Event Monitoring biedt de controletrajecten die transparante gegevensverwerking ondersteunen.
  • De Einstein Trust Layer (ETL) legt een beveiligd controletraject vast voor genererende AI-aanwijzingen en -reacties voor bewakings- en nalevingsdoeleinden.
  • De Experience Cloud omvat toegankelijkheidselementen.
  • Het Veldcontroletraject biedt langdurige bewaring van de historie van gegevenswijzigingen op veldniveau, hetgeen algoritmische verantwoording ondersteunt wanneer AI-beslissingsgegevens worden opgeslagen in bijgehouden velden.

Deze mogelijkheden helpen de operationele kosten van Salesforce-eerlijkheidspraktijken te verlagen.

Bij Salesforce werkt eerlijkheid in drie dimensies om oplossingen te bieden. Inclusief ontwerp helpt Lightning Web Components (LWC), Visualforce pagina’s en Experience Cloud-sites volledig toegankelijk te maken—met naadloze toetsenbordnavigatie, schermlezercompatibiliteit en voorzieningen voor cognitief ontwerp. AI-eerlijkheidspraktijken helpen Einstein voorspellingen eerlijke uitkomsten te produceren met behulp van vertekeningsdetectie, diverse trainingsgegevens en continue bewaking. Governance biedt de processen en controles om eerlijkheid te waarborgen naarmate modellen zich ontwikkelen en gebruikscases zich uitbreiden.

Het verwaarlozen van eerlijkheid creëert risico’s. Ontoegankelijke Experience Cloud-sites kunnen organisaties blootstellen aan rechtszaken van de Americans with Disabilities Act (ADA) en, voor federale instanties en hun contractanten, aan schendingen van artikel 508. Afhankelijk van de risicoclassificatie van het systeem en opkomende algoritmische verantwoordingswetgeving, kunnen vertekende Einstein voorspellingen de vereisten van de EU AI Act schenden. Uitsluitend geautomatiseerde AI-gestuurde beslissingen met juridische of soortgelijke significante gevolgen die geen zinvolle informatie over de beslissingslogica bevatten, kunnen een schending vormen van de informatierechten van artikel 22 en artikel 15, lid 1, onder h).

Organisaties die eerlijkheid hoog in het vaandel hebben staan, beperken de te verwachten schade voor de klanten, werknemers en gemeenschappen die door hun systemen worden beïnvloed. Mislukte billijkheid kan tastbare, materiële schade veroorzaken aan betroffen individuen, waaronder economische schade, geweigerde kansen, emotionele nood en versterking van systemische discriminatie. Regelgevingsuitlijning neigt te volgen uit het goed bedienen van betroffen individuen.

Gebruik deze principes als leidraad voor uw architectonische beslissingen voor eerlijkheid op het platform.

  • Ontwerp voor Lightning toegankelijkheidspatronen. Gebruik bij het samenstellen het Lightning Design System en standaard Lightning webcomponenten die zijn ontworpen om WCAG 2.2 AA-toegankelijkheid waar mogelijk te ondersteunen. Wanneer u met SLDS samenstelt, maakt u gebruik van een bibliotheek waarin toegankelijkheid een kernprincipe van ontwerp is. SLDS componenten worden gecontroleerd op toetsenbordtoegankelijkheid en compatibiliteit met ondersteunende technologie, en vele bevatten een toegankelijkheidssectie met tips voor ontwikkelaars. Als een aangepaste component vereist is, moeten expliciete implementatie-, semantische HTML- en toetsenbordnavigatiepatronen van Toegankelijke Rich Internet-toepassingen (WAI-ARIA) worden gevalideerd door middel van ondersteunende technologietests.
  • Verminder en bewaak vertekening met de juiste tools voor elk modeltype. Valideer AI-uitvoer voor billijke uitkomsten voor demografische groepen vóór implementatie en continu in productie. Leg voor voorspellingsmodellen beslissingsgegevens vast via Einstein Discovery en aangepaste instrumentatie en analyseer deze in CRM Analytics om meetgegevens over eerlijkheid te meten. Gebruik voor generatieve AI- en Agentforce voorzieningen het Einstein Trust Layer (ETL) controletraject van aanwijzingen en reacties. Documenteer beslissingen om te voldoen aan transparantievereisten van regelgeving.
  • Maak gebruik van Shield Platform Encryption voor gegevensbeschermingscontroles. Gebruik Shield Platform Encryption met deterministische schema’s voor gevoelige kenmerken die exacte overeenkomstenquery’s vereisen en tegelijkertijd persoonsgegevens beschermen. Routeer Event Monitoring-logboeken naar een extern SIEM-systeem (Security Information and Event Management) om manipulatie-evidente controletrajecten te ondersteunen—wanneer de SIEM write-once-opslag en toegangsscheiding afdwingt die de native bewaarperioden van Salesforce overschrijden voor vereiste regelgeving.
  • Ontwerp beoordelingswerkstromen voor voorspellingen met grote inzet. Configureer goedkeuringsprocessen en beoordelingsmechanismen in Salesforce Flow om ervoor te zorgen dat Einstein voorspellingen die van invloed zijn op gevolgbeslissingen, de juiste menselijke beoordeling krijgen. Gebruik drempelwaarden voor vertrouwen en bedrijfsregels om te bepalen wanneer voorspellingen validatie vereisen voordat u actie onderneemt.
  • Pas standaardinstellingen voor de hele organisatie (OWD) en beveiliging op veldniveau (FLS) toe voor non-discriminatie. Architecteer gegevenstoegangspatronen met behulp van OWD en FLS om toegang standaard te beperken en verleen alleen de extra toegang die elke rol nodig heeft met behulp van regels voor delen. Vermijd het verlenen van buitensporige toegang aan profielen die gevoelige kenmerken kunnen blootleggen en discriminerende besluitvorming mogelijk kunnen maken.
  • Schakel gebruikersagentschap in via platforminstemming. Gebruik de mogelijkheden voor instemmingsbeheer in Data 360 of aangepaste instemmingsobjecten met Veldcontroletraject om granulaire AI-instemming per gebruikscase bij te houden. Laat gebruikers zich afmelden voor AI-gestuurde voorzieningen en bied menselijke alternatieven (indien mogelijk).

Beslissingen over gegevensarchitectuur bepalen welke populaties zichtbaar en onzichtbaar worden in Salesforce-systemen. Slechte gegevenskwaliteit is niet alleen een technisch probleem. Het wordt een eerlijkheidsprobleem wanneer gegevenshiaten systematisch specifieke demografische groepen benadelen.

  • Controleer verplichte velden op beschikbaarheid van gegevens. Wanneer verplichte velden uitgaan van beschikbaarheid van informatie die varieert tussen demografische gegevens, wordt de volledigheid van gegevens discriminerend. Gebruikers die de vereiste informatie niet kunnen leveren, worden onzichtbaar in systemen die onvolledige records afwijzen.
    • Het vereisen van e-mailadressen sluit populaties uit die geen betrouwbare internettoegang of persoonlijke e-mailadressen hebben.
    • Het vereisen van Amerikaanse burgerservicenummers (SSN) sluit internationale klanten en recente immigranten uit aan wie nog geen SSN is verstrekt.
    • Straatadressen vereisen sluit daklozen en gebruikers met niet-traditionele adressen uit.
  • Controleer bedrijfsrechtvaardigingen voor verplichte velden. Voor elk verplicht veld is het belangrijk om te documenteren waarom de informatie verplicht is in plaats van optioneel. Als processen via alternatieve benaderingen zonder bepaalde gegevens kunnen functioneren, maakt u die velden optioneel en ontwerpt u systemen om ontbrekende waarden netjes af te handelen. Dit helpt ervoor te zorgen dat gebruikers die dergelijke gegevens niet kunnen leveren, niet worden uitgesloten.

Naamvelden die westerse naamgevingsconventies (Voornaam, Achternaam) volgen, kunnen culturen met verschillende naampraktijken uitsluiten.

Veel culturen gebruiken:

  • Enkelvoudige namen—of mononiemen—zonder achternaam
  • Patroniemensystemen waarbij “achternaam” generatie na generatie verandert
  • Meerdere voornamen of familienamen
  • Namen die veranderen op basis van levensgebeurtenissen of sociale context
  • Namen waarbij “voor” en “achter” cultureel betekenisloze verschillen zijn

Ontwerp naamarchitectuur met behulp van één veld met volledige naam of een flexibele structuur met meerdere delen, waarin veelvoorkomende naamgevingsconventies zijn ondergebracht. Maak geen aannames over de volgorde van namen, overervingspatronen of culturele normen.

Test naamarchitectuur met behulp van diverse internationale namen om ervoor te zorgen dat naamvelden het volgende accepteren:

  • Namen van één woord (bijvoorbeeld Soekarno, Cher en Teller)
  • Lange namen die veelvoorkomende veldlengtelimieten overschrijden
  • Namen met diakritische tekens, afbreekstreepjes en spaties
  • Namen met niet-Latijnse schriften (bijvoorbeeld Arabisch, Chinees, Cyrillisch en Devanagari)

Wanneer naamvalidatie de legitieme naam van een gebruiker afwijst, ervaren ze systeemafwijzing die is gebaseerd op hun culturele identiteit.

Adresvalidatieservices zijn vaak geoptimaliseerd voor Amerikaanse en West-Europese indelingen en herkennen vaak niet:

  • Internationale adresnotaties met verschillende veldvolgordes
  • Landelijke adressen zonder straatnaam
  • Militaire adressen (bijvoorbeeld APO en FPO)
  • Postbussen en alternatieve bezorglocaties
  • Stammenland met unieke adressystemen
  • Landen met niet-Latijnse scripts voor adrescomponenten

Wanneer adresvalidaties niet-traditionele adresnotaties afwijzen, verhindert dit het maken, verzenden en leveren van accounts voor gebruikers wier adressen niet overeenkomen met de verwachtingen van de validatiedatabase.

Hier zijn enkele manieren om adresvalidaties te ontwerpen met toegankelijkheid in gedachten:

  • Implementeer validatie van toegestane adressen.
  • Accepteer adresinvoer met vrije vorm wanneer gestructureerde validaties mislukken.
  • Sla adressen op zoals ze door gebruikers zijn ingevoerd, in plaats van gebruikers te dwingen ongeldige correcties aan te brengen.
  • Gebruik adresvalidatie voor gegevensverrijking en duplicaatdetectie, niet voor het valideren van adresopmaak.

In plaats van vooraf het vastleggen van gegevens te blokkeren, bouwt u adresverificatie in leveringsprocessen in waarbij de nauwkeurigheid van het adres operationeel van belang is.

Aannames van universele toegang voor specifieke communicatiekanalen sluiten populaties met verschillende technologische toegang of voorkeuren uit.

Communicatie via alleen e-mail omvat niet:

  • Gebruikers zonder betrouwbare internettoegang
  • Ouderen die minder comfortabel zijn met e-mail
  • Gebruikers in regio’s waar sms- of berichtenapps de primaire communicatiemethode vormen

Communicatie via alleen telefoon omvat niet:

  • Gebruikers die doof en slechthorend zijn
  • Gebruikers zonder telefoontoegang of gebruikers die gedeelde telefoons gebruiken

Ontwerp een communicatiearchitectuur voor alle kanalen waarmee gebruikers kanaalvoorkeuren kunnen bepalen. Sla voorkeurscommunicatiemethoden op in contactpersoonsrecords en respecteer consistent voorkeuren voor alle uitgaande communicatiesystemen. Zorg voor verschillende communicatiealternatieven in plaats van aan te nemen dat methoden met één kanaal universeel werken.

Het verzamelen van demografische gegevens voor fairness monitoring vereist zorgvuldige architectuur om misbruik te voorkomen.

Het verzamelen en verwerken van demografische gegevens is jurisdictieafhankelijk en wettelijk beperkt (in de EU behandelt artikel 9 van de AVG deze als gegevens van speciale categorieën die een specifieke rechtsgrondslag vereisen; in de VS berust vertekeningscontrole doorgaans op vrijwillige zelfidentificatie door de EEO). Wanneer er een wettelijke basis bestaat, gebruiken organisaties demografische gegevens voor:

  • Eerlijkheidsmeetgegevens bewaken die zijn gestratificeerd op beschermde groepen
  • Vertekening detecteren in automatiserings- en AI-systemen
  • Aantonen dat de regelgeving voldoet aan de antidiscriminatievereisten

Het verzamelen van demografische gegevens brengt bepaalde risico’s met zich mee:

  • Gegevens kunnen voor discriminerende doeleinden worden gebruikt als toegangscontroles mislukken
  • Gebruikers kunnen verzamelingsmethoden wantrouwen en onjuiste gegevens verstrekken
  • Verzameling kan als invasief of discriminerend aanvoelen

Architect vrijwillige zelfidentificatie en ontwerp demografische gegevensverzameling met behulp van informatie die:

  • Duidelijk uitgelegd met een transparant doel (bijvoorbeeld fairness monitoring of nalevingsrapportage)
  • Vrijwillig en bevat een optie “Geef er de voorkeur aan om niet te antwoorden” die altijd beschikbaar is
  • Gescheiden van operationele gegevens met strikte FLS om ongepaste toegang te voorkomen
  • Geaggregeerd voor rapportage en analyses en niet gekoppeld aan afzonderlijke beslissingen
  • Bewaakt via Shield Event Monitoring voor controle van toegangspatronen

Het is belangrijk om in privacybeleid vast te leggen hoe demografische gegevens precies wel en niet worden gebruikt. Het schenden van User Trust door middel van niet-openbaar gemaakt gegevensgebruik kan de geloofwaardigheid ernstig schaden, wat moeilijk te herstellen kan zijn.

Externe gegevensverrijking die demografische, firmografische of gedragsgegevens toevoegt aan Salesforce-records, kan leiden tot vertekening door middel van:

  • Onjuiste gevolgtrekkingen die zijn gebaseerd op stereotypen
  • Onvolledige dekking met hiaten die correleren met demografische gegevens
  • Eigen algoritmen die onbekende eerlijkheidseigenschappen gebruiken
  • Gegevens die afkomstig zijn uit vertekende historische records

Voordat u services voor gegevensverrijking implementeert, is het belangrijk om het volgende te controleren:

  • Eerlijkheidstests en vertekeningsbestrijdingspraktijken van leveranciers
  • Gegevensdekking en nauwkeurigheid voor demografische groepen
  • Inferentiemethoden en -voorzieningen die worden gebruikt om voorspellingen te maken
  • Contractuele beperkingen en bewaarbeleidsvormen voor gegevensgebruik

Onthoud dat zodra externe gegevens uw Salesforce-organisatie binnenkomen, dit van invloed kan zijn op beslissingen, waardoor door de leverancier geïntroduceerde vertekening ontstaat die ook tot uiting komt als een vertekening in uw organisatie.

In Salesforce-contexten verwijst toegankelijkheid naar het ontwerpen van Lightning webcomponenten, Visualforce pagina’s en Experience Cloud-sites die werken voor gebruikers met een beperking. Standaard Lightning componenten bieden baseline toegankelijkheid bij correct gebruik; aangepaste ontwikkeling en Experience Cloud-configuratie vereisen echter expliciete implementatie van toegankelijkheid.

Lightning Design System-componenten zijn ontworpen om WCAG 2.2 AA-conformiteit te ondersteunen wanneer ze worden gebruikt zoals ze zijn ontworpen. Salesforce streeft naar volledige conformiteit, maar certificeert dit niet. Als u afwijkt van SLDS patronen of aangepaste componenten maakt zonder rekening te houden met toegankelijkheid, ontstaan er belemmeringen voor gebruikers met een beperking.

Standaard Lightning webcomponenten bieden ingebouwde toegankelijkheid. Componenten zoals Lightning Input, Lightning Combobox, Lightning Datatable en Lightning Card bevatten automatisch de juiste ARIA-kenmerken, labelkoppelingen, toetsenbordnavigatie en focusbeheer. Gebruik, indien mogelijk, standaardcomponenten in plaats van aangepaste alternatieven te maken die er hetzelfde uitzien, maar mogelijk niet over de juiste toegankelijkheidsinfrastructuur beschikken.

  • Gebruik semantische HTML in aangepaste Lightning webcomponenten. Gebruik bij het samenstellen van aangepaste componenten semantische HTML-elementen (
    ,
  • Implementeer ARIA in aangepaste componenten. Pas ARIA-oriëntatiepunten, -rollen en -eigenschappen toe wanneer semantische HTML geen interfacewerking kan overbrengen. Dynamische inhoudsupdates vereisen aria-live regio’s die wijzigingen aankondigen aan schermlezers. Aangepaste interactieve componenten hebben expliciete roldefinities nodig die overeenkomen met hun werking. Lightning basiscomponenten verwerken ARIA automatisch; aangepaste componenten vereisen echter handmatige ARIA-validatie via het testen van schermlezers.
  • Test met ondersteunende technologie: Valideer Lightning componenten met behulp van feitelijke schermlezers (bijvoorbeeld JAWS en NVDA voor Windows, VoiceOver voor macOS en iOS en TalkBack voor Android). Volgens het grootschalige onderzoek van Deque vangen geautomatiseerde tools zoals axe-core ongeveer 57% van de toegankelijkheidsproblemen op volume op. De resterende problemen vereisen handmatig testen met ondersteunende technologie door mensen die inzicht hebben in navigatiepatronen van schermlezers.
  • Gebruik focusbeheer in Lightning stromen. Wanneer modaliteiten worden geopend, dynamische inhoud wordt geladen of gebruikers stromen met meerdere stappen voltooien, moet u de focus programmatisch beheren om toetsenbordgebruikers naar nieuwe inhoud te begeleiden. Lightning modal- en pop-overcomponenten bieden basaal focusbeheer, maar complexe stromen hebben expliciete focuslogica nodig om de focus op de juiste manier te verplaatsen naarmate de inhoud verandert.

Experience Cloud-sites bedienen externe gebruikers, inclusief klanten, partners en openbare doelgroepen, die toegankelijk ontwerp nodig hebben dat mogelijk moet voldoen aan de vereisten van ADA, Section 508 en/of European Accessibility Act (afhankelijk van jurisdictie, doelgroep en organisatietype).

  • Gebruik toegankelijke sjablonen. Experience Cloud-sjablonen die zijn samengesteld met behulp van Lightning Web Runtime (LWR) omvatten baselinetoegankelijkheid. Standaardsjablonen zoals Klantaccountportal en Help-centrum bieden WCAG 2.2 AA-basissen wanneer ze correct zijn geconfigureerd. Aangepaste sjablonen vereisen expliciete implementatie van toegankelijkheid, inclusief semantische mark-up, toetsenbordnavigatie en schermlezercompatibiliteit.
  • Verifieer WCAG-naleving in thema’s. Aangepaste thema’s en sites met “branding” vereisen validatie van kleurcontrast. Met de instellingen voor Thema’s van de Omgevingssamensteller bepaalt u kleuren, typografie en spatiëring. Zorg ervoor dat alle tekst voldoet aan het contrast 4.5:1 voor normale tekst (minder dan 18 punten voor normale tekst of minder dan 14 punten voor vet), en 3:1 voor grote tekst (18 punten of meer voor normale tekst of 14 punten of meer voor vet) en UI-componenten. Gebruik tools voor browserontwikkelaars of online contrastcontroleurs om te valideren voor naleving. Test met browserzoom tot 200% om ervoor te zorgen dat de tekst wordt geschaald zonder inhoud of functionaliteit te verliezen.
  • Gebruik toetsenbordnavigatie in navigatiemenu’s. Experience Cloud-navigatiecomponenten moeten bediening met alleen het toetsenbord ondersteunen zonder muisafhankelijkheid. Gebruikers moeten naar vervolgkeuzemenu’s, megamenu’s en flyoutnavigatie navigeren met behulp van Tab, Enter, Escape en Pijltoetsen zonder focusvallen. Test alle navigatiepaden met behulp van alleen het toetsenbord om toegankelijkheid te valideren.
  • Schakel formuliertoegankelijkheid in Experience Cloud in. Koppel labels expliciet aan alle formulierinvoer met behulp van de juiste labelelementen of aria-labelledby. Op zichzelf voldoet de tekst van de plaatshouder niet aan de toegankelijkheidsvereisten, omdat de tekst verdwijnt zodra de gegevensinvoer begint, waardoor schermlezers onvoldoende, consistente context hebben. Lightning invoercomponenten bieden ingebouwde labelkoppeling wanneer ze worden geconfigureerd met behulp van de vereiste labelkenmerken. Aangepaste Visualforce formulieren vereisen expliciete label-invoerkoppeling.
  • Test Experience Cloud-sites met behulp van ondersteunende technologie. Voordat u openbare Experience Cloud-sites start, moet u uitgebreide toegankelijkheidstests uitvoeren met behulp van schermlezers, navigatie met alleen het toetsenbord en browserzoom. Het is belangrijk om gebruikers met een handicap op te nemen in bruikbaarheidstests om praktische belemmeringen voor de praktijkervaring aan het licht te brengen die expertbeoordelingen vaak over het hoofd zien. Als u alleen interne Lightning pagina’s test zonder externe Experience Cloud-toegankelijkheid te valideren, zijn openbare sites kwetsbaar voor toegankelijkheidsklachten en rechtszaken.
  • Gebruik alternatieve tekst voor afbeeldingen en pictogrammen. Alle informatieve afbeeldingen, pictogrammen en grafische inhoud in Experience Cloud vereisen alternatieve tekst. Decoratieve afbeeldingen gebruiken lege alt-tekst (alt=""), waardoor schermlezers ze kunnen overslaan. Informatieve afbeeldingen bieden betekenisvolle alternatieve tekst die inhoud en functie beschrijft. Wanneer u alternatieve tekst voor pictogrammen schrijft, richt u zich op de actie of het doel van het pictogram in plaats van het visuele uiterlijk ervan (in plaats van een pictogram van een vergrootglas te beschrijven als “Vergrootglas”, moet de alternatieve tekst het functionele nut ervan vermelden, zoals “Site zoeken”). Bij het beheren van afbeeldingen moet het CMS inhoudsauteurs vragen om alt-tekst op te geven of de afbeelding expliciet als decoratief te markeren (waardoor alt=” wordt ingesteld). Dit garandeert toegankelijkheid door ontbrekende alt-tekst en afgedwongen beschrijvingen voor esthetische afbeeldingen te voorkomen.

Volledige toetsenbordtoegankelijkheid betekent dat gebruikers toegang hebben tot alle functionaliteit met behulp van hun toetsenbord zonder dat ze op een bepaald punt een muis of touch nodig hebben.

  • Gebruik logische focusvolgorde in Lightning pagina’s. Zorg ervoor dat de focusvolgorde de visuele lay-out en interactiestroom volgt. Wanneer gebruikers op Tab drukken, moet de visuele focus door interactieve elementen gaan in de volgorde die gebruikers verwachten op basis van visueel ontwerp. Lightning Appsamensteller en Omgevingssamensteller stellen de focusvolgorde vast op basis van de plaatsing van componenten. Aangepaste componenten vereisen expliciet tabindexbeheer om logische focusvoortgang te garanderen.
  • Gebruik zichtbare focusindicatoren om te voldoen aan contrastvereisten. Lightning Design System biedt focusstijlen om te voldoen aan WCAG-vereisten voor de meeste componenten. Aangepaste componenten hebben mogelijk uitgebreide focusindicatoren nodig om te voldoen aan de 3:1-contrastvereiste ten opzichte van omliggende inhoud. Focusindicatoren moeten duidelijk zichtbaar zijn, zodat gebruikers met slecht zicht via het toetsenbord kunnen navigeren. Verwijder nooit focusindicatoren met CSS (overzicht: geen) zonder alternatieve zichtbare focusstyling te bieden.
  • Gebruik oplossingen voor toetsenbordval in modals en overlays. Modale dialogen moeten de focus binnen het modale venster houden terwijl het open is, wat voorkomt dat toetsenbordgebruikers verborgen achtergrondinhoud bereiken. De focusval moet worden losgelaten bij modaal sluiten en de focus terugbrengen naar het triggerelement. Ingebedde inhoud—inclusief iframes en widgets van derden—mag niet permanent de toetsenbordfocus vastleggen zonder een escapemechanisme.
  • Gebruik sneltoetsen zonder conflicten. Lightning biedt standaardsneltoetsen die worden beschreven in de Salesforce Help. Aangepaste sneltoetsen moeten worden ontworpen om conflicten met standaardbrowserbesturingselementen en navigatieopdrachten voor schermlezers te voorkomen. In overeenstemming met de WCAG-succescriteria mogen sneltoetsen van één letter (bijvoorbeeld het indrukken van één letter of leesteken) geen globale acties activeren. Ze moeten de activering beperken tot wanneer een specifieke component een actieve focus heeft, of gebruikers een manier bieden om de snelkoppeling volledig uit te schakelen of opnieuw toe te wijzen.

Bouw toegankelijkheidsvalidatie in CI/CD-pijplijnen in om automatisch structurele problemen bij elke implementatie te vinden in plaats van toegankelijkheid te behandelen als periodieke handmatige audits.

  • Gebruik sa11y voor Lightning Web Component accessibility testing. De sa11y-bibliotheken van Salesforce (het pakket @sa11y/jest) verpakken de axe-core toegankelijkheidsengine om een toBeAccessible()-overeenkomst toe te voegen voor Jest-eenheidstests. Schrijf toegankelijkheidstests die het juiste ARIA-gebruik, labelkoppelingen, contrastverhoudingen en semantische mark-up automatisch valideren als onderdeel van eenheidstests. Configureer samenstellingen om te mislukken wanneer kritieke toegankelijkheidsproblemen worden gedetecteerd.
  • Gebruik Lighthouse CI voor Experience Cloud. Google Lighthouse controleert de toegankelijkheid van webpagina’s, inclusief Experience Cloud-sites. Lighthouse CI integreren in implementatiepijplijnen om openbare pagina’s te scannen op toegankelijkheidsproblemen. Configureer scoredrempelwaarden om minimale toegankelijkheidsscores te vereisen vóór implementatiegoedkeuringen.
  • Gebruik de Accessibility Agent, beschikbaar via het Salesforce DX MCP-pakket. In met MCP compatibele omgevingen of binnen Agentforce Vibes wordt code beoordeeld op basis van WCAG-standaarden, worden doelgerichte oplossingen zichtbaar en kan een pullverzoek worden gegenereerd voor een engineer om te beoordelen, valideren en samen te voegen.

Vertekening bestaat al in deterministische Salesforce-automatisering lang voordat AI in beeld kwam. Toewijzingsregels, stroombeslissingen, validatieregels en territoriumontwerp coderen het menselijke oordeel dat discriminatie in stand kan houden. In tegenstelling tot AI-vertekening – die architecten uitgebreid onderzoeken – gaat automatiseringsvertekening vaak niet onderzocht door omdat deterministische logica objectief aanvoelt.

  • Volg de regels voor lead- en casetoewijzing. Werk verdelen over verkoop- en serviceteams. Wanneer toewijzingslogica criteria gebruikt die correleren met beschermde kenmerken, leidt automatisering tot systematische verschillen in servicekwaliteit en opportunitytoegang.
  • Toewijzingsregels die territorium, postcode of accountkenmerken gebruiken, kunnen opportunities met een hoge waarde onevenredig naar specifieke teams routeren, terwijl werk met een lagere waarde elders wordt gerouteerd. Als territoriumgrenzen correleren met demografische gegevens van klanten en beloningsstructuren die verschillen tussen territoria, leidt toewijzingsautomatisering tot economische discriminatie.
  • Audit uitkomsten van toewijzingsregels regelmatig. Bereken toewijzingsverdelingen over territoria en teams die zijn gestratificeerd op demografische gegevens van klanten. Als Enterprise-accounts zijn geconcentreerd in specifieke territoria, terwijl SMB-accounts elders worden gedistribueerd—en als Enterprise-territoria betere compensatie of resources ontvangen—kunnen toewijzingsregels onbillijke uitkomsten opleveren die een eerlijke beoordeling rechtvaardigen.
  • Beoordeel op vaardigheden gebaseerde routering voor alle kanalen. Dit kan van invloed zijn op de servicekwaliteit voor alle klantengroepen. Als routeringslogica er impliciet van uitgaat dat bepaalde vaardigheden correleren met klantwaarde of complexiteit van problemen, kunnen klanten verschillende service-uitkomsten krijgen op basis van demografische proxy’s.

Het is belangrijk om de gemiddelde afhandelingstijd, oplossingen voor het eerste contact en klanttevredenheid binnen routeringstrajecten te bewaken. Verschillen kunnen aangeven of bepaalde klantsegmenten systematisch minder ervaren agenten of minder routeringsopties krijgen.

  • Bekijk Salesforce-stroomautomatiseringen. Het nemen van goedkeuringsbeslissingen, subsidiabiliteitsbeslissingen of toegangstoewijzingen kan discriminerende logica coderen via ogenschijnlijk onschuldige bedrijfsregels. Bepaalde stromen leiden tot indirecte discriminatie wanneer de criteria correleren met beschermde kenmerken.
  • Beoordeel stroombeslissingen met eerlijkheid in gedachten. Voor elke stroom die belangrijke beslissingen neemt die van invloed zijn op gebruikers, is het belangrijk om het volgende te vragen:
  • Wat gebeurt er met gebruikers die niet voldoen aan het normale klantprofiel?
  • Correleren beslissingscriteria met demografische kenmerken?
  • Worden uitzonderingen en randgevallen eerlijk afgehandeld of benadelen ze systematisch specifieke groepen?

Het is belangrijk om overwegingen bij beslissingen over stromen en eerlijkheid te documenteren in architectuurbeslissingsrecords en om stromen met een hoge inzet te onderwerpen aan hetzelfde beleid voor ethische beoordeling als AI-systemen.

  • Beoordeel validatieregels. Als u gegevensinvoer verhindert, worden geldige gegevens mogelijk uitgesloten van gebruikers wier informatie niet overeenkomt met systeemaannames. Validatieregels die legitieme gegevens afwijzen, maken onzichtbare populaties. Gebruikers van wie de gegevens niet overeenkomen met validatiepatronen, kunnen niet werken met bepaalde systemen. Validatiefouten worden vaak niet gemeld omdat gebruikers hun verzoeken opgeven in plaats van technische fouten te melden. Hier zijn verschillende veel voorkomende validatievertekeningspatronen:
  • Naamvalidaties die Latijnse lettertekens vereisen, kunnen namen met diakritische tekens en niet-Latijnse schriften uitsluiten.
  • Telefoonnummervalidaties gebruiken vaak Amerikaanse/westerse notaties, wat internationale nummers en alternatieve communicatiemethoden uitsluit.
  • Adresvalidaties herkennen niet-standaardadressen (bijvoorbeeld postbussen, landelijke routes, stamlanden en internationale notaties).
  • E-mailvalidaties die persoonlijke e-mailadressen vereisen, kunnen een nadeel vormen voor gebruikers die geen persoonlijke e-mailtoegang hebben.
  • Test validatieregels met behulp van diverse gegevens. Neem internationale adressen, niet-westerse namen en alternatieve telefoonnotaties op in validatietests. Wanneer de validatie legitieme gegevens afwijst, moet u de validatielogica uitbreiden om te voorkomen dat geldige gebruikers worden uitgesloten.
  • Beoordeel ontwerpen van verkoopterritoria. Klantsegmenteringsstrategieën en ontwerpen van verkoopterritoria bepalen de resourcetoewijzing binnen klantpopulaties. Wanneer territoriumgrenzen of segmenteringscriteria correleren met demografische gegevens die leiden tot ongelijke resourcetoewijzing, kan die toewijzing discriminerende uitkomsten opleveren. Territoriumontwerpen die geografische grenzen gebruiken, correleren vaak met raciale, etnische en economische demografie vanwege patronen van residentiële segregatie. Als compensatie, personeelsniveau of resource-investeringen verschillen tussen territoria, kan geografie een mechanisme worden voor discriminerende resourcetoewijzing.
  • Analyseer territoriumdemografie voordat u ontwerpen afrondt. Wijs demografische gegevens van klanten toe over voorgestelde territoriumgrenzen heen. Wanneer demografische concentraties ontstaan, evalueert u of de resourcetoewijzing billijk is voor alle territoria, ongeacht de demografische samenstelling. Als de zakelijke rechtvaardiging verschillende resourceniveaus voor verschillende territoria vereist (bijvoorbeeld marktrijpheid, concurrentie-intensiteit en groeipotentieel), documenteert u die rechtvaardiging expliciet en bewaakt u de uitkomsten om ervoor te zorgen dat territoria die te weinig worden bediend, voldoende investeringsmogelijkheden krijgen om verankerde verschillen te voorkomen.
  • Zorg voor transparantie in automatiseringslogica. Documenteer bedrijfsregels, toewijzingscriteria en stroombeslissingslogica in Salesforce Knowledge of architectuurbeslissingsrecords. Transparante automatisering maakt het mogelijk om eerlijkheid te beoordelen op een manier die verborgen logica voorkomt.
  • Regelmatig resultaten controleren. Plan driemaandelijkse audits om automatiseringsuitkomsten te analyseren die mogelijk zijn gestratificeerd op basis van demografische gegevens van klanten. Houd er rekening mee dat ongelijkheden leiden tot onderzoeken en potentiële oplossingen.
  • Het is belangrijk om het volgende bij te houden:
  • Toewijzingsverdelingen over teams en territoria
  • Goedkeuringsscores voor stromen die beslissingen nemen over aanspraak
  • Aantal afgewezen validatieregels op gegevenspatroon
  • Territoriumprestaties en resourcetoewijzing
  • Beoordeel automatisering met grote inzet door een ethische lens. Onderwerp Stromen en toewijzingsregels die van invloed zijn op werkgelegenheid, krediet, toegang tot services of andere gevolguitkomsten, aan hetzelfde proces van ethische beoordeling als AI-systemen. Automatiseringsvertekening vereist hetzelfde niveau van controle als algoritmische vertekening.

Bij Salesforce richt AI Fairness zich op het gebruik van Einstein om te valideren dat voorspellingen eerlijke uitkomsten opleveren voor alle demografische groepen. Einstein Discovery en aangepaste instrumentatie leggen beslissingsgegevens van voorspellingsmodellen vast die vertekeningsdetectie mogelijk maken. CRM Analytics-dashboards houden meetgegevens over eerlijkheid bij. Veldcontroletraject en Event Monitoring leggen beslissingsgegevens vast voor algoritmische verantwoording.

Einstein voorspellingen die van invloed zijn op gevolgbeslissingen (bijvoorbeeld leadscores, opportunityprognoses en klantsegmentering) vereisen evaluaties van de eerlijkheid vóór de implementatie die als een verplichte equivalente stap functioneren (vergelijkbaar met beveiligingsbeoordelingen).

Analyseer alle predictieve modelvoorzieningen voor correlatie met beschermde kenmerken met behulp van statistische methoden. Verwijder of transformeer proxyvoorzieningen nadat is geëvalueerd of hun voorspellende waarde opname rechtvaardigt ondanks proxyeffecten.

  • Auditeer Salesforce CRM-gegevens vóór de training. Salesforce-organisaties bevatten tientallen jaren aan menselijke beslissingen die zijn gebaseerd op historische praktijken. Als verkoopteams uit het verleden prioriteit hebben gegeven aan bepaalde demografische gegevens, leert Einstein Leadscores deze patronen en bestendigt deze. Voordat u voorspellingsmodellen voor historische gegevens traint, is het belangrijk om die gegevens te controleren op demografische hiaten en meetinconsistenties in klantsegmenten.
  • Bereken meetgegevens over eerlijkheid voor demografische groepen. Voordat u voorspellingsmodellen implementeert, is het belangrijk om demografische gelijkheid, gelijke kansen en ongelijksoortige impactratio’s voor beschermde groepen te berekenen, waarbij u een wettelijke basis hebt om de vereiste demografische gegevens te verzamelen en verwerken. Als Einstein Leadscores 50% van de tijd hoge scores toewijst aan Segment A, maar slechts 30% van de tijd aan Segment B, voldoet een verhouding van 60% niet aan de viervijfde regel (80%) en vereist dit onderzoek en vermindering. Het cijfer van 80% is een screeningtrigger, geen wettelijke “pass/fail line”: de viervijfde regel is een federale vuistregel voor de selectie van werkgelegenheid in de VS, en clearing is geen veilige haven – een statistisch significante ongelijkheid kan aanleiding geven tot controle bij hogere verhoudingen, en andere regimes meten negatieve gevolgen verschillend (EU-wetgeving inzake indirecte discriminatie, bijvoorbeeld, schakelt in of een praktijk een “bijzonder nadeel” creëert, zonder vaste drempel). Kalibreer onderzoeksdrempelwaarden voor de rechtsgebieden en gebruikscases waarin u actief bent.
  • Leg beslissingsgegevens van voorspellingsmodellen vast voor vertekeningsdetectie. Als u vertekening wilt detecteren in voorspellingsmodellen zoals Leadscores en Opportunityscores, legt u beslissingsgegevens vast via Einstein Discovery en aangepaste instrumenten: sla voorspellingsinvoer, uitvoer en modelversies op in bijgehouden velden en schakel Veldcontroletraject in. Analyseer die gegevens in CRM Analytics om beslissingspatronen bij te houden voor demografische groepen in de loop van de tijd en dashboards samen te stellen die waarschuwen wanneer meetgegevens over demografische gelijkheid of gelijke kansen acceptabele drempelwaarden overschrijden.
  • Proxyvoorzieningen detecteren in voorspellingsmodellen. Voorzieningen die correleren met beschermde kenmerken, maken indirecte discriminatie mogelijk, zelfs wanneer beschermde kenmerken worden uitgesloten van de modellen.
    • Salesforce-gegevens bevatten doorgaans proxyvoorzieningen:
  • Territorium of postcode (proxy’s voor ras, etniciteit en inkomen)
  • Accountnaampatronen (proxy’s voor organisatiegrootte en demografische gegevens van de sector)
  • Tijdstippen voor communicatieactiviteiten (volmachten voor tijdzones, religie en verantwoordelijkheden voor zorg)
  • Apparaattype of browser uit activiteitsgegevens (proxy’s voor inkomensniveau)

Wanneer vertekening wordt gedetecteerd in Einstein voorspellingen, moet u de reductie toepassen in de juiste pijplijnfase (op basis van de hoofdoorzaak en technische beperkingen).

  • Saldogegevens vóór modeltraining. Breng Salesforce CRM-gegevens opnieuw in balans door overbemonstering van ondervertegenwoordigde klantsegmenten of onderbemonstering van oververtegenwoordigde segmenten voordat u voorspellingsmodellen traint. Gebruik Data 360 voor het aggregeren van gegevens binnen meerdere organisaties om diverse trainingssets te garanderen. Synthetische gegevensgeneratie kan spaarzame segmenten aanvullen en privacy behouden door middel van differentiële privacytechnieken.
  • Verwijder proxy’s in engineering van voorzieningen. Wanneer proxyvoorzieningen worden geïdentificeerd, vervangt u deze door alternatieve voorzieningen die voorspellend vermogen bieden zonder demografische correlatie. Als territorium dient als demografische proxy, houd dan rekening met sectorclassificatie of bedrijfsgrootte als alternatieven. Als accountnaampatronen correleren met demografische gegevens, gebruikt u in plaats daarvan firmografische kenmerken.
  • Pas drempelwaarden aan tijdens naverwerking. Pas de beslissingsdrempels per demografisch segment aan om de uitkomstscores na trainingsmodellen gelijk te trekken. Voor beslissingen op het gebied van werkgelegenheid is dit ronduit verboden: Titel VII (Civil Rights Act van 1991) verbiedt het aanpassen van scores of het gebruik van verschillende afkapscores per beschermde klasse, en geen enkele hoeveelheid gedocumenteerde rechtvaardiging maakt de praktijk wettig. Documenteer drempelwaardenaanpassingen met zakelijke rechtvaardiging voor een verschillende behandeling wanneer voorspellingen geautomatiseerde beslissingen ondersteunen.
  • Train modellen periodiek opnieuw met behulp van bijgewerkte gegevens. Plan modelhertraining elk kwartaal (of wanneer er significante gegevensdistributieverschuivingen plaatsvinden). Hertraining voor nieuwe gegevens vangt opkomende vertekeningspatronen op en corrigeert eventuele afwijkingen van oorspronkelijke fairness baselines. Valideer fairness-meetgegevens opnieuw voor elke modelversie vóór productie-implementatie om ervoor te zorgen dat hertraining geen nieuwe vertekening veroorzaakt.

De Einstein Trust Layer legt aanwijzingen, reacties en Trust signalen vast voor generatieve AI en Agentforce voorzieningen, en ondersteunt transparantie en naleving van regelgeving voor generatieve AI. Voor voorspellingsmodellen zijn transparantie en afstamming van beslissingen afkomstig van Einstein Discovery en Modelbeheer, die aangepaste instrumentatie vereisen om controlegegevens te bewaren.

Bouw uitlegbaarheid in Einstein oplossingen in vanuit de initiële architectuur in plaats van verklaringen achteraf in te bouwen in ondoorzichtige systemen na implementatie.

  • Surface Einstein Discovery verklaringen op beslissingspunten. Einstein Discovery biedt verklaringen voor voorspellingsfactoren die laten zien welke variabelen specifieke voorspellingen het meest hebben beïnvloed met directionele impact. Architect Lightning componenten die deze uitleg weergeven aan gebruikers op het moment van de beslissing in plaats van navigatie naar afzonderlijke CRM Analytics dashboards te vereisen. Wanneer beslissingen van invloed zijn op gebruikers, hebben ze transparantie nodig, geen abstracte meetgegevens over modelprestaties.
  • Laagverklaringen voor verschillende doelgroepen. Geef een uitlegdiepte op die geschikt is voor elke doelgroep:
  • Zakelijke gebruikers: “Deze lead scoort hoog omdat de jaaromzet hoger is dan $ 1 miljoen en de betrokkenheidsscore in de top 10% zit.”
  • Technische gebruikers: Lever een Einstein Discovery modelkaart met functiegewichten, kenmerken van trainingsgegevens en validatiemeetgegevens.
  • Klanten: “Deze aanbeveling is gebaseerd op uw recente aankopen en klanten met soortgelijke voorkeuren.”
  • Controleurs: Bied beslissingsafstamming vanuit Einstein Discovery en Modelbeheer (modelversie, invoerwaarden en de factoren die de voorspelling hebben aangestuurd), vastgelegd via aangepaste instrumentatie.
  • Communiceer het vertrouwen op de juiste manier. Geef vertrouwen in voorspellingstermen weer die geschikt zijn voor gebruikers en voorkom ruwe waarschijnlijkheidsscores die gebruikers mogelijk verkeerd interpreteren. In plaats van “73% vertrouwen” te tonen, communiceert u dit met behulp van categorieën (bijvoorbeeld Groot vertrouwen, Vertrouwen modereren en Beoordeling nodig) met uitleg over wat elk vertrouwensniveau betekent voor de betrouwbaarheid van beslissingen, evenals welke extra beoordelingen er zullen plaatsvinden.

Onderhoud uitgebreide, onveranderbare controletrajecten die verantwoording, foutopsporing en naleving van regelgeving ondersteunen voor alle AI-gestuurde beslissingen die van invloed zijn op gebruikers.

  • Leg voorspellende auditgegevens vast met de juiste tools. Sla controlegegevens van voorspellingsmodellen (invoer van voorspellingen, uitvoer en modelversies) op in bijgehouden velden waarvoor Veldcontroletraject is ingeschakeld. Beleidsvormen voor het bewaren van gegevens door architecten om te voldoen aan wettelijke vereisten, die variëren per sector en jurisdictie:
    • Regels voor financiële diensten bepalen de bewaartermijn per verordening (zo stelt FINRA-regel 4511(b) een standaardbewaartermijn van zes jaar in voor records die anders geen opgegeven bewaartermijn hebben krachtens FINRA-regels of SEA-regel 17a-4).
    • Het bewaren van medische dossiers wordt ook geregeld door specifieke regels (zo vereist HIPAA een minimum van zes jaar voor nalevingsdocumentatie; het bewaren van medische dossiers wordt bepaald door individuele staatswetten) in plaats van algemene bewaarplichten voor onbepaalde tijd.
  • Analyseer beslissingsgegevens van voorspellingsmodellen met CRM Analytics. Stel CRM Analytics-dashboards samen op basis van de beslissingsgegevens van het voorspellingsmodel die u vastlegt (invoer van voorspellingen, uitvoer en modelversies in bijgehouden velden) om beslissingspatronen, meetgegevens over eerlijkheid en modelprestaties in de loop van de tijd te analyseren. Maak lenzen die voorspellingsverdelingen tonen op vertrouwensniveau, demografisch segment en uitkomsttype. Configureer Einstein Discovery story’s die abnormale patronen identificeren die extra onderzoek vereisen.
  • Gebruik Veldcontroletraject voor langdurige bewaring. Standaardveldhistorie houdt wijzigingen gedurende 18 maanden bij in de UI en maximaal 24 maanden via de API. Met Veldcontroletraject kunt u veldhistorie voor onbepaalde tijd bewaren voor aangepaste objecten die AI-beslissingsgegevens opslaan. De historie wordt standaard na maximaal 18 maanden gearchiveerd en vervolgens worden de gearchiveerde gegevens bewaard totdat u deze verwijdert. Schakel Veldcontroletraject in voor objecten die instemmingsrecords, overschrijvingsbeslissingen en vertekeningsrapporten bevatten om te voldoen aan wettelijke bewaarvereisten.
  • Gebruik Event Monitoring voor Agentforce interacties. Event Monitoring legt events op aanroepniveau vast voor Agentforce, zoals wanneer acties en stromen worden uitgevoerd. Exporteer Event Monitoring-gegevens naar een externe SIEM (standaard Event Log File-gegevens via de API en de subset van Real-time Event Monitoring via Platform Events) voor opslag die de oorspronkelijke bewaarperiode van Salesforce overschrijdt. Bewijs van manipulatie is afhankelijk van bepaalde SIEM-werking die write-once-opslag en toegangsscheiding afdwingt. Configureer SIEM-query’s om vertekeningspatronen te detecteren voor grote volumes Agentforce interacties.
  • Audit Agentforce gesprekken met de Einstein Trust Layer. De Einstein Trust Layer legt het controletraject vast van Agentforce gespreksaanwijzingen en -responsen, opgeslagen in Data 360, en biedt de record op transcriptieniveau voor transparantie en naleving van regelgeving.

Laten we eens wat beter kijken naar de transparantiemogelijkheden van de architect die zijn gepositioneerd voor naleving van huidige en opkomende AI-regelgeving in meerdere rechtsgebieden.

  • Transparantievereisten van de EU AI Act. AI-systemen met een hoog risico op grond van de EU-AI-wet vereisen transparantiedocumentatie, technische documentatie, mogelijkheden voor menselijk toezicht en meetgegevens over nauwkeurigheid/eerlijkheid. De Einstein Trust Layer audit trails en Einstein Discovery modelkaarten vormen de basis voor deze vereisten. Documentmodeltrainingsgegevens, validatiebenaderingen en bekende beperkingen in architectuurbeslissingsrecords.
  • Recht op uitleg van de AVG. De AVG geeft EU-betrokkenen het recht op zinvolle informatie over de logica van een beslissing wanneer die beslissing uitsluitend is gebaseerd op geautomatiseerde verwerking en juridische of soortgelijke significante gevolgen heeft. Dit recht vloeit voort uit artikel 15, lid 1, onder h), en artikel 22, lid 3, in de zin van overweging 71 en werd door het HvJ-EU verduidelijkt in de zaak Dun & Bradstreet (2025). Ontwerp systemen die op verzoek coherente verklaringen genereren voor historische beslissingen binnen de tijdsbestekken voor toegangsverzoeken van betrokkenen, die variëren (afhankelijk van jurisdictie) tussen 15 en 45 dagen. De beslissingsgegevens van het voorspellingsmodel die u vastlegt (voorspellingsinvoer, uitvoer, modelversies en Einstein Discovery verklaringsfactoren) stellen u in staat om verklaringen te reconstrueren wanneer deze met voldoende bewaring worden opgeslagen.
  • Algoritmische verantwoordingswetten. Amerikaanse wetgeving inzake algoritmische verantwoording op staatsniveau vereist steeds vaker effectbeoordelingen en transparantierapportage voor geautomatiseerde beslissingssystemen. De beslissingsgegevens van het voorspellingsmodel die u vastlegt, en CRM Analytics-dashboards voor eerlijkheidscontrole vormen de gegevensbasis voor deze rapporten. Voer algoritmische effectbeoordelingen uit voordat u AI met gevolgen implementeert als proactieve naleving in plaats van als reactieve reactie op vragen over regelgeving.

OWD’s, regels voor delen en beveiliging op veldniveau (FLS) bepalen de toegangspatronen voor gegevens die bepalen welke informatie gebruikers kunnen beoordelen en gebruiken om beslissingen te nemen. De juiste configuratie voorkomt discriminerende toegang tot gevoelige kenmerken en garandeert tegelijkertijd een eerlijke service.

Ontwerp OWD’s en beveiliging op veldniveau om toegang standaard te beperken. Gebruik voor regels voor delen het beginsel van de minste rechten (PoLP) om alleen de extra toegang te verlenen die elke rol legitiem nodig heeft, hetgeen discriminerende besluitvorming op basis van beschermde kenmerken voorkomt.

  • Schakel beperkend OWD in als standaard. Gebruik privé-OWD’s voor objecten die gevoelige klantgegevens bevatten en verleen toegang op basis van rollenhiërarchie en regels voor delen. Openbare OWD’s voor lezen/schrijven maken het beperken van toegang later verstorend (het aanscherpen van de standaardwaarde activeert een nieuwe berekening voor delen en wordt pas van kracht nadat deze is voltooid) in plaats van onmogelijk. Privé-OWD’s met expliciete subsidies voor delen creëren controleerbare toegangspatronen die naleving van non-discriminatie ondersteunen.
  • Pas beveiliging op veldniveau toe voor gevoelige kenmerken. Verberg gevoelige velden die beschermde kenmerken (bijvoorbeeld etniciteit, religie en handicapstatus) bevatten, voor gebruikers die geen toegang nodig hebben voor legitieme bedrijfsdoeleinden. Configureer FLS om leestoegang voor gevoelige velden in de meeste profielen te verwijderen. Wanneer deze velden verplicht zijn voor specifieke doeleinden (bijvoorbeeld diversiteitsrapportage en redelijke accommodatie), verleent u minimale toegang met behulp van machtigingensets met gedocumenteerde zakelijke rechtvaardiging.
  • Ontwerp toewijzings- en deelregels voor billijke uitkomsten. Gebruik toewijzingsregels, wachtrijen en Omni-Channel-routering om werk eerlijk te verdelen over territoria, teams en serviceagenten. Vermijd handmatig delen dat opportunities van hoge waarde of klanten concentreert met specifieke gebruikersgroepen zonder gedocumenteerde zakelijke rechtvaardiging. Configureer automatische regels voor delen op basis van objectieve criteria (bijvoorbeeld sector, geografie en productlijn) in plaats van subjectieve managersdiscretie, wat vertekening kan inschakelen.
  • Machtigingensets bieden voor tijdelijke toegang. Verleen tijdelijke toegang tot gevoelige gegevens via machtigingensets in plaats van profielen te wijzigen, wat permanent gevolgen heeft voor alle gebruikers. Wanneer gebruikers toegang nodig hebben tot demografische gegevens voor specifieke projecten (bijvoorbeeld diversiteitsanalyse en accommodatieaanvragen), wijst u machtigingensets met gedocumenteerde vervaltijden toe. Geplande stromen kunnen machtigingensets automatisch na gedefinieerde perioden intrekken.

Gebruik Shield Event Monitoring en rapporten om gegevenstoegangspatronen te detecteren die duiden op potentiële discriminatie of vertekening in gegevensgebruik.

  • Gebruik Shield Event Monitoring om toegang tot gevoelige gegevens te controleren. Gebruik Event Monitoring om toegangsevents op objectniveau (rapportexports, API-query’s en paginaweergaven) vast te leggen voor objecten die beschermde kenmerken of gevoelige kenmerken bevatten. Configureer query’s op deze events om zichtbaar te maken wie er wanneer en in welke context toegang tot het object heeft gehad, en behandel abnormale patronen (bijvoorbeeld plotselinge pieken en toegang door onverwachte gebruikers) als triggers voor onderzoek.
  • Rapporteren over distributies van regels voor delen. Stel rapporten samen die analyseren hoe records worden gedistribueerd tussen gebruikers, teams en territoria. Bereken distributiestatistieken op basis van demografische gegevens van klanten om ervoor te zorgen dat accounts en opportunities met een hoge waarde eerlijk worden gedistribueerd. Identificeer concentraties waarbij specifieke gebruikersgroepen onevenredige toegang krijgen tot waardevolle records zonder gedocumenteerde zakelijke rechtvaardiging.
  • Controleren van CRUD- en FLS-schendingen. Controleer het Set-up controletraject op wijzigingen in OWD-instellingen, regels voor delen, FLS-configuraties en machtigingensets. Ongeautoriseerde wijzigingen in besturingselementen voor gegevenstoegang kunnen duiden op pogingen om ongepast toegang te krijgen tot gevoelige gegevens. Gebruik beleidsvormen voor transactiebeveiliging om te reageren op events van Realtime Event Monitoring met hoog risico (bijvoorbeeld abnormale API-activiteit, verdachte logins en exports van grote rapporten of lijsten met gevoelige gegevens). Aangezien transactiebeveiliging alleen werkt op deze run-time events in plaats van DML- of FLS-wijzigingen op recordniveau, moet u vertrouwen op Set-up controletraject en gedocumenteerde goedkeuringen voor wijzigingsbeheer voor FLS en wijzigingen voor delen.

Bij Salesforce betekent gebruikersbureau dat klanten en werknemers betekenisvolle controle behouden over de manier waarop AI hun ervaring beïnvloedt. Salesforce-mogelijkheden voor instemmingsbeheer, Data 360-instemming en aangepaste instemmingsobjecten maken fijnmazige controle over AI-interacties mogelijk.

Ontwerp het bijhouden van instemming met behulp van Data 360-instemmingsbeheer, Marketing Cloud-instemming of aangepaste instemmingsobjecten die Veldcontroletraject gebruiken voor AI-specifieke instemmingsvereisten.

  • Schakel granulaire instemming in per AI-gebruikscase. Schakel instemming per AI-gebruikscase in in plaats van een algemene AI-instemming te gebruiken. Klanten kunnen instemmen met Einstein productaanbevelingen, maar door AI gestuurde kredietbeslissingen afwijzen. Schakel Veldcontroletraject voor instemmingsobjecten in voor langdurige bewaring en om te voldoen aan wettelijke vereisten. Ontwerp aangepaste instemmingsobjecten met velden die het volgende bijhouden:
  • Doel van instemming (bijvoorbeeld Einstein Leadscores, Einstein Aanbevelingen voor antwoorden en Einstein Aanbevelingensamensteller)
  • Datum van verlening van instemming en verleningsmethode (bijvoorbeeld webformulier, API, telefoon en e-mail)
  • Datum van intrekking van instemming (indien van toepassing)
  • Gerelateerde gebruiker of contactpersoons-ID
  • Gebruik instemming van Data 360 voor personalisering. Gebruik Data 360-instemmingsbeheer voor Einstein Personalisering. Data 360 neemt instemmingsvoorkeuren op en slaat deze op vanuit systemen verderop in de stroom via connectoren die zijn toegewezen aan het gegevensmodel Privacy, waardoor u die instemmingskenmerken kunt gebruiken als filtercriteria bij segmentering en bij activering. Wijs instemmingskenmerken toe aan specifieke AI-gebruikscases om gebruikers de mogelijkheid te bieden zich af te melden voor personalisatie en tegelijkertijd kernservices te behouden
  • Schakel Marketing Cloud-integratie van instemming in. Instemming voor Marketing Cloud integreren met Einstein Messaging Insights en AI-gestuurde marketingvoorzieningen. Respecteer de Marketing Cloud-abonnementsstatus en -instemming in alle AI-gestuurde communicatie.

Bied zinvolle afmeldingen van AI-gestuurde voorzieningen met toegankelijke besturingselementen die gebruikersvoorkeuren respecteren via menselijke alternatieven van vergelijkbare kwaliteit.

  • Bied toegankelijke afmeldingen in profielinstellingen. Laat gebruikers zich afmelden voor AI-gestuurde interacties via toegankelijke voorkeurenbesturingselementen in Experience Cloud-profielinstellingen of Mijn instellingen in interne apps. Geef duidelijke beschrijvingen van wat elke afmelding inhoudt en van de alternatieve ervaring die gebruikers krijgen wanneer ze zich afmelden. Sla voorkeuren op in gebruikers- of contactpersoonsrecords.
  • Bied opties voor aanhoudende voorkeuren voor alle kanalen. Sla AI-voorkeuren op in gebruikers- of contactpersoonsrecords om consistentie te waarborgen voor alle kanalen (bijvoorbeeld web, mobiel, telefoon en e-mail). Voer een consistente query uit op voorkeuren in alle interactiestromen om te voorkomen dat gebruikers voorkeuren in verschillende kanalen herhaaldelijk opnieuw moeten opgeven.

Ethische AI-governance biedt organisatiestructuren die helpen ervoor te zorgen dat rechtvaardigheid blijft bestaan naarmate modellen zich ontwikkelen, gegevensverschuivingen en gebruikscases zich uitbreiden. Zonder governance verslechteren aanvankelijke inspanningen op het gebied van rechtvaardigheid naarmate de aandacht van de organisatie verschuift.

Stel verplichte documentatie op en controleer controlepunten voordat Einstein wordt geïmplementeerd. Beschouw dit als een poort die net zo belangrijk is als beveiligingsbeoordelingen.

  • Zorg voor modeldocumentatie. Sla modeldocumentatie op in Salesforce met behulp van een aangepast modelobject of Salesforce Files die zijn bijgevoegd bij Projecten om doorzoekbaarheid en versiebeheer in te schakelen. Documenteer elk voorspellingsmodel voor productie met behulp van:
  • Demografie van trainingsgegevens en bekende representatiehiaten (voor door klanten getrainde voorspellingsmodellen zoals Einstein Discovery en Voorspellingensamensteller)
  • Eerlijkheidsmeetgegevens van vóór de implementatie die worden berekend op demografische groep
  • Beoogde gebruikscases en bekend ongepast gebruik
  • Vertekeningsverminderingsstrategieën die worden toegepast tijdens de ontwikkeling
  • Eerlijkheidsbewakingsbenadering en waarschuwingsdrempels
  • Vereisten voor menselijk toezicht en goedkeuringswerkstromen
  • Planningen en verantwoordelijken beoordelen
  • Overwegingen bij regelgeving en positionering van naleving
  • Schakel Fairness Gates vóór implementatie in. Modellen die niet voldoen aan poorttests, mogen niet worden geproduceerd. Behandel fairnesspoorten met dezelfde strengheid als beveiligingspoorten. Met andere woorden, ze hebben de bevoegdheid om implementaties te blokkeren. Voordat u Einstein voorspellingen implementeert naar productie, moet u:
  • Beoordeel audits van trainingsgegevens. Alle representatiehiaten moeten worden geanalyseerd en gedocumenteerd.
  • Beoordeel billijkheidsmeetgegevens (zo moeten demografische gelijkheid, gelijke kansen en ongelijksoortige gevolgen worden berekend en bevestigd om aan drempelwaarden te voldoen).
  • Effectbeoordelingen beoordelen. Evalueer potentiële schade voor alle betrokken populaties.
  • Ontwerp met menselijk toezicht. Alle escalatiepatronen, goedkeuringswerkstromen en overschrijvingsmechanismen moeten op de juiste manier worden ontworpen en getest.
  • Voltooi een transparantiebeoordeling. Verklaringsmogelijkheden moeten worden gevalideerd voor alle beslissingstypen.
  • Volledige documentatie. Alle vereiste artefacten voor modeldocumentatie moeten worden goedgekeurd.

Beoordelingsprocessen opzetten voor AI-toepassingen met een hoge inzet die interfunctioneel toezicht bieden en afdwingingsbevoegdheid hebben.

  • Samenstelling beoordelingscommissie. Neem technische experts (bijvoorbeeld architecten en datawetenschappers), zakelijke belanghebbenden (bijvoorbeeld producteigenaars en operationeel personeel), juridisch adviseurs, privacyspecialisten en vertegenwoordigers van betroffen community’s (indien mogelijk) op. Vergeet niet dat vanuit verschillende perspectieven eerlijkheidsproblemen naar boven komen die homogene groepen vaak over het hoofd zien.
  • Beoordeel alle triggers die goedkeuring van de ethische raad vereisen. Definieer welke AI-gebruikscases een ethische beoordeling vereisen vóór implementatie:
  • Beslissingen die van invloed zijn op werk, krediet, huisvesting, gezondheidszorg of wettelijke rechten
  • Geautomatiseerde systemen die meer dan 10.000 gebruikers of transacties per jaar betreffen
  • AI-toepassingen die gevoelige persoonsgegevens gebruiken, inclusief gezondheids-, financiële of demografische gegevens
  • Nieuwe gebruikscases die geen vastgesteld organisatorisch precedent hebben
  • Systemen waarin potentiële vertekening aanzienlijke schade kan veroorzaken aan individuen of groepen
  • Beoordeel en bepaal wie de bevoegdheid heeft om implementaties te blokkeren. Ethische beoordelingscommissies moeten de bevoegdheid hebben om wijzigingen te eisen, controlevoorwaarden op te leggen of implementaties te blokkeren die niet voldoen aan ethische normen. Beoordeling door uitsluitend adviserende instanties (zonder handhavingsautoriteit) kan de doeltreffendheid van het governanceproces beperken. Documenteer alle beoordelingen in aangepaste Salesforce-objecten die het volgende bijhouden: aanvraagnaam, beoordelingsdatum, geuite zorgen, risicobeperkingsvereisten en goedkeuringsvoorwaarden.

Eerlijkheidsbewaking is een doorlopend proces dat continue aandacht vereist om vertekening te detecteren naarmate gegevensverdelingen veranderen en gebruikerspopulaties veranderen.

  • Maak CRM Analytics-eerlijkheidsdashboards. Stel dashboards samen die meetgegevens over eerlijkheid bijhouden met behulp van de beslissingsgegevens van het voorspellingsmodel die u vastlegt. Bewaak demografische gelijkheid, gelijke kansen, ongelijksoortige impactverhoudingen en meetgegevens over voorspellingskwaliteit op klantsegmenten. Configureer CRM Analytics-waarschuwingen die via een trigger worden geactiveerd wanneer meetgegevens over eerlijkheid gedefinieerde drempelwaarden overschrijden en een onderzoek vereisen.
  • Schakel aangepaste bewaking in voor eerlijkheidssignalen. Stel aangepaste fairness monitoring samen om signalen te detecteren (bijvoorbeeld plotselinge veranderingen in beslissingsverdelingen op demografische groep, pieken in aan vertekening gerelateerde caserecords of achteruitgang in modelprestaties voor specifieke populaties).
  • Plan fairness audits. Voer uitgebreide, driemaandelijkse fairness audits uit voor AI-systemen met een hoge inzet (bijvoorbeeld krediet, werkgelegenheid en gezondheidszorg) en halfjaarlijkse audits voor systemen met een lage inzet (bijvoorbeeld aanbevelingen en personalisering). Audits moeten actuele meetgegevens over eerlijkheid onderzoeken, overschrijvingspatronen in de goedkeuringshistorie beoordelen, feedback van gebruikers en vertekeningsrapporten analyseren en valideren dat governance-controles effectief blijven.
  • Implementeer incidentrespons voor mislukte eerlijkheid. Stel duidelijke processen op die worden gedocumenteerd in Salesforce Knowledge en waarin wordt beschreven hoe te reageren wanneer vertekening wordt gedetecteerd:
  • Onmiddellijk: Beoordeel de ernst en het bereik door een query uit te voeren op de beslissingsgegevens van het voorspellingsmodel in CRM Analytics. Als het incident ernstig is, schort u alle geautomatiseerde besluitvorming op in afwachting van een onderzoek.
  • Korte termijn: Implementeer tijdelijke verminderingsstrategieën (bijvoorbeeld meer menselijk toezicht via aangepaste drempelwaarden voor vertrouwen, uitschakeling van voorzieningen of volledige schorsing van agenten).
  • Onderzoek: Voer een analyse van de hoofdoorzaak (RCA) uit om te bepalen hoe de vertekening het systeem is binnengekomen of zich heeft ontwikkeld. Analyseer tijdens de RCA trainingsgegevens, modelversies en configuratiewijzigingen via de Field Audit Trail.
  • Herstel: Implementeer een permanente oplossing via gegevenscorrectie, modelhertraining of proceswijzigingen.
  • Mededeling: Informeer betroffen gebruikers via cases, e-mail of Experience Cloud-aankondigingen.
  • Preventie: Verwerk wijzigingen om herhaling te voorkomen en documenteer de preventiemethoden in runbooks.

Gebruik deze controlelijst tijdens architectuurbeoordelingen, vóór productie-implementatie en periodiek voor doorlopende beoordeling.

Gegevenskwaliteit en representativiteit

  • Maak velden optioneel waar een proces kan functioneren zonder de gegevens, en ontwerp processen verderop in de stroom om ontbrekende waarden af te handelen, zodat gebruikers die geen informatie kunnen verstrekken (e-mail, SSN, adres) niet worden uitgesloten.
  • Velden voor Naam van architect als één veld met volledige naam of flexibele structuur met meerdere delen, dat mononiemen, niet-Latijnse schriften, diakritische tekens en lange namen accepteert, in plaats van uit te gaan van westerse voor-/achternamen.
  • Implementeer toegestane adresvalidatie die vrije-vorm- en internationale notaties accepteert, waarbij adressen worden opgeslagen zoals ze zijn ingevoerd, in plaats van het maken van records te blokkeren bij een notatiefout.
  • Sla communicatiekanaalvoorkeuren op in contactpersoonsrecords en ondersteun alternatieven voor omnikanalen (e-mail, sms, telefoon, post, chat, spraak) in plaats van aan te nemen dat één kanaal alle gebruikers bereikt.
  • Verzamel demografische gegevens door middel van vrijwillige zelfidentificatie met een optie “Geef er de voorkeur aan niet te antwoorden”, die afzonderlijk wordt opgeslagen onder Privé-OWD met FLS, wordt geaggregeerd voor rapportage en wordt bewaakt via Shield Event Monitoring.
  • Controleer externe verrijkingsleveranciers op eerlijkheidstests, demografische dekking en gevolgtrekkingsmethodologie voordat u demografische of gedragsgegevens toevoegt aan records.

Toegankelijkheid en inclusief ontwerp

  • Gebruik Lightning Design System-componenten, die zijn ontworpen om WCAG 2.2 AA-toegankelijkheid te ondersteunen. Houd er rekening mee dat Salesforce streeft naar conformiteit, maar dat componenten nog steeds correct moeten worden gebruikt.
  • Valideer aangepaste Lightning webcomponenten met behulp van schermlezertests (bijvoorbeeld JAWS, NVDA en VoiceOver).
  • Zorg ervoor dat volledige toetsenbordnavigatie aanwezig is op Lightning pagina’s en Experience Cloud-sites zonder muisafhankelijkheid.
  • Controleer of contrastverhoudingen voldoen aan 4.5:1 voor normale tekst met behulp van tools voor browserontwikkeling of contrastcontrole.
  • Integreer scannen van sa11y- of Lighthouse-toegankelijkheid in CI/CD-pijplijnen die mislukken, bouwt voort op kritieke problemen.
  • Test Experience Cloud-sites met behulp van ondersteunende technologie voordat ze openbaar worden gelanceerd.
  • Controleer auditieve feedback door te bevestigen dat alle dynamische wijzigingen (bijvoorbeeld foutstatussen, het laden van spinners of het uitvouwen van menu’s) duidelijk worden aangekondigd en dat de gesproken inhoud overeenkomt met de visuele bedoeling van de UI.

Eerlijkheid in Salesforce Automation

  • Controleer toewijzings- en routeringsregels op correlatie met beschermde kenmerken die gunstige of ongunstige uitkomsten kunnen concentreren in specifieke demografische groepen.
  • Controlestroom en procesautomatiseringsbeslissingslogica voor vertekening, waarbij bedrijfsregels en -criteria worden gedocumenteerd in Salesforce Knowledge of architectuurbeslissingsrecords.
  • Evalueer validatieregels voor afwijzingsscores die onevenredig veel invloed hebben op specifieke gegevenspatronen of populaties.
  • Analyseer territorium- en segmenteringsontwerpen voor demografische correlatie, documenteer expliciete zakelijke rechtvaardiging en bewaak territoria die te weinig worden bediend op billijke resourcetoewijzing.
  • Stel stromen en toewijzingsregels (arbeid, krediet, toegang tot diensten) aan hetzelfde proces van ethische beoordeling onderwerpen als AI-systemen en plan driemaandelijkse audits van automatiseringsuitkomsten gestratificeerd op demografische gegevens.

AI Fairness en vertekening detectie

  • Controleer Salesforce CRM-gegevens op demografische representatiehiaten voorafgaand aan de training van het voorspellingsmodel.
  • Bereken demografische pariteit, gelijke kansen en ongelijksoortige impactverhoudingen per demografische groep vóór implementatie.
  • Implementeer eerlijkheidsevaluaties als een verplichte implementatiepoort (zie dit als gelijkwaardig aan een beveiligingsbeoordeling).
  • Stel CRM Analytics-dashboards samen die meetgegevens over eerlijkheid bijhouden met behulp van beslissingsgegevens van voorspellingsmodellen die zijn vastgelegd met het Veldcontroletraject.
  • Analyseer voorspellingsmodelvoorzieningen voor proxycorrelatie met beschermde kenmerken (bijvoorbeeld territorium- en accountnaampatronen).
  • Plan uitgebreide, driemaandelijkse eerlijkheidsaudits voor alle AI-systemen met een hoge inzet.

Transparantie en controleerbaarheid

  • Maak Einstein Discovery voorspellingsverklaringen zichtbaar op beslissingspunten in Lightning componenten.
  • Configureer Einstein Trust Layer-auditopnamen met behulp van bewaarmethoden die voldoen aan wettelijke vereisten.
  • Schakel Veldcontroletraject in voor alle aangepaste objecten waarin AI-beslissingsgegevens worden opgeslagen voor langdurige bewaring.
  • Exporteer Event Monitoring-gegevens naar een externe SIEM (Event Log File-gegevens via de API en Real-time Event Monitoring-events via Platform-events) voor opslag die native retentie overschrijdt, met write-once-besturingselementen aan de SIEM-zijde voor manipulatiebewijs.
  • Zorg voor op de gebruiker afgestemde vertrouwenscommunicatie (bijvoorbeeld Hoog, Normaal en Laag) in plaats van ruwe waarschijnlijkheden.

Menselijk toezicht met Salesforce Automation

  • Configureer op vertrouwen gebaseerde escalatiedrempelwaarden in Flow en routeer voorspellingen met weinig vertrouwen naar menselijke beoordeling.
  • Gebruik Salesforce-goedkeuringsprocessen voor beslissingen met grote belangen die beoordelingsketens in meerdere fasen vereisen.
  • Agentforce en Omni-Channel-routering integreren om naadloze escalatie naar menselijke agenten mogelijk te maken.
  • Zorg voor een consistente optie “Verbinden met menselijke agent” in Agentforce interfaces om gebruikers te respecteren.
  • Vereist gedocumenteerde motivering en bijhouden van goedkeuringshistorie voor Agentforce overschrijvingen die worden vastgelegd in aangepaste velden.

Niet-discriminatie met besturingselementen voor gegevenstoegang

  • Schakel Privé-OWD in en verleen vervolgens extra toegang via rollenhiërarchie en regels voor delen.
  • Configureer beveiliging op veldniveau om gevoelige demografische velden te verbergen voor gebruikers die geen toegang nodig hebben.
  • Bewaak toegangsevents op objectniveau (rapportexports en API-query’s) voor gevoelige gegevens via Shield Event Monitoring en analyseer deze op abnormale toegangspatronen.
  • Stel rapporten samen die distributies van regels voor delen analyseren om te zorgen voor een eerlijke recordtoewijzing binnen territoria.
  • Controleer Set-up controletraject op ongeoorloofde wijzigingen in OWD, regels voor delen of FLS-configuratie.

Gebruikersagentschap en instemming

  • Ontwerp aangepaste instemmingsobjecten met behulp van Veldcontroletraject voor het bijhouden van fijnmazige AI-instemming per gebruik.
  • Instemming van Data 360 of Marketing Cloud integreren met Einstein Personalisering en Agentforce voorzieningen.
  • Sla AI-voorkeuren op in gebruikers- of contactpersoonsrecords om consistentie te waarborgen binnen kanalen (bijvoorbeeld web, mobiel en telefoon).
  • Bied toegankelijke afmeldingen in profielinstellingen en menselijke alternatieven via Omni-Channel-routering.
  • Voer een query uit op instemmingsrecords in Flow voordat Einstein voorspellingen of Agentforce betrokkenheid van invloed zijn op gebruikers.

Ethische AI-governance

  • Documenteer alle productievoorspellingsmodellen, inclusief meetgegevens over eerlijkheid en verminderingsstrategieën; documenteer voor door de klant getrainde voorspellingsmodellen (zoals Einstein Discovery en Voorspellingensamensteller) ook demografische gegevens over trainingen.
  • Stel verplichte fairnessgates vóór de implementatie vast die implementatie blokkeren totdat aan alle fairnesscriteria is voldaan.
  • Maak een AI Ethics Review Board als afdwingende autoriteit voor alle AI-toepassingen met een hoge inzet.
  • Stel CRM Analytics-dashboards samen om eerlijkheidsmeetgegevens te bewaken op een geplande cadans via CRM Analytics-waarschuwingen.
  • Definieer incidentresponsprocedures voor mislukte eerlijkheid en documenteer het proces in Salesforce Knowledge.
  • Plan driemaandelijkse fairness-audits die overschrijvingspatronen en feedback van gebruikers analyseren voor alle systemen met een hoge inzet.

Deel uw feedback over het Goed Architectuurde Framework.