Rettferdighet

Rettferdighet

I Salesforce-arkitekturer betyr rettferdighet å bygge løsninger som tjener brukerne på en rettferdig måte gjennom tilgjengelige grensesnitt, deteksjon og avverging av systematiske avvik, transparente beslutninger og etisk styring. Einsteins forutsigelser påvirker utfall som påvirker kunder og ansatte, noe som betyr at arkitekter skal utforme systemer som gir rettferdige resultater på tvers av demografiske grupper, samtidig som de forblir tilgjengelige for brukere med funksjonshemming.

Salesforce leverer plattformfunksjoner som er skreddersydd for rettferdighet, og vi streber etter å overholde WCAG 2.2 AA. Når det brukes riktig, leverer Salesforce Lightning Design System (SLDS) komponenter som er utformet for å støtte dette målet. La oss ta en nærmere titt på hver komponent.

  • Shield Platform Encryption beskytter sensitive attributter som demografiske data, og Event Monitoring gir revisjonsspor som støtter gjennomsiktig databehandling.
  • Einstein Trust Layer (ETL) fanger opp et sikkert revisjonsspor for generative AI-ledetekster og -svar for overvåkings- og samsvarsformål.
  • Experience Cloud inkluderer tilgjengelighetskontroller.
  • Feltrevisjonssporet sørger for langsiktig oppbevaring av endringshistorikk for data på feltnivå, som støtter algoritmisk ansvarlighet når AI-beslutningsdata lagres i sporede felt.

Disse funksjonene bidrar til å redusere driftskostnadene for Salesforces rettferdighetsrutiner.

I Salesforce opererer rettferdighet på tvers av tre dimensjoner for å gi løsninger. Inkludert design bidrar til å gjøre Lightning (LWC), Visualforce og Experience Cloud-nettsteder fullt tilgjengelig – med sømløs tastaturnavigering, skjermleserkompatibilitet og tilpassinger av kognitiv design. AI-rettferdighetsrutiner hjelper Einstein med å produsere rettferdige utfall ved bruk av systematiske avvik, varierte opplæringsdata og kontinuerlig overvåking. Styring sørger for prosesser og kontroller for å opprettholde rettferdighet etter hvert som modeller utvikles og brukstilfeller utvides.

Forsømmelse av rettferdighet skaper sammensatt risiko. Ikke-tilgjengelige Experience Cloud-nettsteder kan utsette organisasjoner for Americans with Disabilities Act (ADA)-prosesser og, for føderale organer og deres kontraktører, overtredelser av overholdelse av § 508. Avhengig av systemets risikoklassifisering og nye algoritmiske ansvarsregler, kan systematiske Einstein-forutsigelser bryte kravene i EU AI Act. Bare automatiserte AI-drevne beslutninger med juridiske eller tilsvarende betydelige virkninger som mangler meningsfylt informasjon om beslutningslogikken, kan være i strid med artikkel 22 og artikkel 15(1)(h).

Organisasjoner som bygger opp rettferdighet, har en tendens til å redusere forutsigbar skade for kundene, de ansatte og fellesskapene som påvirkes av systemene deres. Feil i rettferdighet kan forårsake materiell skade for berørte enkeltpersoner – inkludert økonomisk skade, avslåtte salgsmuligheter, følelsesmessig nød og forsterkning av systemisk diskriminering. Regulatorisk justering har en tendens til å følge med godt betjening av berørte enkeltpersoner.

Bruk disse prinsippene til å lede dine arkitektoniske beslutninger om rettferdighet på plattformen.

  • Design for Lightning tilgjengelighetsmønstre. Når du bygger, må du bruke Lightning Design System og standard Lightning Web-komponenter som er utformet for å støtte WCAG 2.2 AA tilgjengelighet når det er mulig. Når du bygger med SLDS, bruker du et bibliotek der tilgjengelighet er et kjernedesignprinsipp. SLDS kontrolleres for tastaturtilgjengelighet og kompatibilitet med hjelpeteknologi, og mange inkluderer en tilgjengelighetsdel med utviklertips. Hvis en tilpasset komponent kreves, må eksplisitt implementering av Accessible Rich Internet Applications (WAI-ARIA), semantisk HTML og tastaturnavigeringsmønstre valideres gjennom testing av hjelpeteknologi.
  • Reduser og overvåk systematiske avvik med de riktige verktøyene for hver modelltype. Valider AI-utdata for å få rettferdige utfall på tvers av demografiske grupper før distribusjon og kontinuerlig i produksjonsorganisasjonen. For forutsigelsesmodeller kan du fange opp beslutningsdata via Einstein Discovery og tilpasset instrumentering og analysere dem i CRM Analytics for å måle rettferdighetsmålinger. For generative AI- og Agentforce bruker du revisjonssporet Einstein Trust Layer (ETL) for ledetekster og svar. Dokumenter beslutninger for å oppfylle krav til regulatorisk gjennomsiktighet.
  • Leverage Shield Platform Encryption for datasikringsregler. Bruk Shield Platform Encryption med deterministiske skjemaer for sensitive attributter som krever spørringer med nøyaktig samsvar, samtidig som du beskytter personlige data. Rut hendelsesovervåking logger til et eksternt system for sikkerhetsinformasjon og hendelsesbehandling (SIEM) for å støtte revisjonsspor som viser manipulering – når SIEM håndhever skrivebeskyttet lagring og tilgangssegregering som overskrider Salesforce-innebygde oppbevaringsvinduer for nødvendige forskrifter.
  • Utform arbeidsflyter for gjennomgang for forutsigelser med høy innsats. Konfigurer godkjenningsprosesser og gennemse mekanismer i Salesforce-forløb for at sikre, at Einstein, der påvirker konsekvensbeslutninger, modtager passende menneskelig gennemgang. Bruk konfidens terskler og forretningsregler til å finne ut når forutsigelser må valideres før handling utføres.
  • Bruk organisasjonsomfattende standarder (OWD) og feltnivåsikkerhet (FLS) for å unngå diskriminering. Arkitekter datatilgangsmønstre ved bruk av OWD og FLS for å begrense tilgang som standard, og gi bare den ekstra tilgangen hver rolle trenger ved bruk av delingsregler. Unngå å gi profiler overdreven tilgang som kan vise sensitive attributter og aktivere diskriminerende beslutningstaking.
  • Aktiver brukeragentur via plattformsamtykke. Bruk samtykkebehandlingsfunksjonaliteten i Data 360- eller tilpassede samtykkeobjekter med Feltrevisjonsspor til å spore detaljert AI-samtykke per bruksområde. Gi brukere mulighet til å velge bort AI-drevne funksjoner og tilby alternativer for brukere (når det er mulig).

Datarkitekturbeslutninger bestemmer hvilke populasjoner som blir synlige – og usynlige – i Salesforce-systemer. Dårlig datakvalitet er ikke bare et teknisk problem. Det blir et rettferdighetsproblem når gap i data systematisk skader bestemte demografiske grupper.

  • Se gjennom nødvendige felt for datatilgjengelighet. Når nødvendige felt forutsetter tilgjengelighet av informasjon som varierer på tvers av demografi, blir fullstendighet av data diskriminerende. Brukere som ikke kan oppgi nødvendig informasjon, blir usynlige i systemer som avviser ufullstendige poster.
    • Kreving av e-postadresser utelukker populasjoner som ikke har pålitelig internettilgang eller personlige e-postadresser.
    • Krevelse av amerikanske SSN-er (Social Security Numbers) utelukker internasjonale kunder og nylig innvandrere som ennå ikke har fått utstedt et SSN.
    • Å kreve gateadresser utelukker hjemløse populasjoner og brukere med ikke-tradisjonelle adresser.
  • Revider forretningsmessige begrunnelser for nødvendige felt. For hvert nødvendige felt er det viktig å dokumentere hvorfor informasjonen er obligatorisk i motsetning til valgfri. Hvis prosesser kan fungere uten bestemte data via alternative tilnærminger, gjør du disse feltene valgfrie og utformer systemer for å håndtere manglende verdier på en behagelig måte. Dette bidrar til å sikre at brukere som ikke kan oppgi slike data, ikke utelukkes.

Navnefelt som følger vestlige navnekonvensjoner (Fornavn, Etternavn), kan utelukke kulturer med forskjellige navnekonvensjoner.

Mange kulturer bruker:

  • Enkeltnavn – eller mononymer – uten etternavn
  • Patronymiske systemer der etternavn endres generelt
  • Flere gitte navn eller etternavn
  • Navn som endres basert på livshendelser eller sosial kontekst
  • Navn der "første" og "siste" er kulturelt meningsløse forskjeller

Utform navnearkitektur ved å bruke et enkelt felt med fullt navn eller en fleksibel, flerdelig struktur som tar hensyn til vanlige navnekonvensjoner. Unngå å lage forutsigelser om navnesortering, arvsmønstre eller kulturelle normer.

Test navnearkitektur med forskjellige internasjonale navn for å sikre at navnefelt godtar:

  • Navn på ett ord (for eksempel Sukarno, Cher og Teller)
  • lange navn som overskrider vanlige feltlengdegrenser
  • Navn med diakritikk, apostrofer, bindestreker og mellomrom
  • Navn med ikke-latinske skript (for eksempel arabisk, kinesisk, cyrillisk og Devanagari)

Når navnevalidering avviser en brukers legitime navn, opplever brukeren systemavvisning som er basert på brukerens kulturelle identitet.

Adressevalideringstjenester er ofte optimalisert for amerikanske og vesteuropeiske formater og klarer ofte ikke å gjenkjenne:

  • Internasjonale adresseformater med forskjellig feltrekkefølge
  • Landlige adresser uten gatenavn
  • Militære adresser (for eksempel APO og FPO)
  • PO-bokser og alternative leveringssteder
  • Triballand med unike adressesystemer
  • Land med ikke-latinske skript for adressekomponenter

Når adressevalideringer avviser ikke-tradisjonelle adresseformater, hindrer det opprettelse av kontoer, forsendelse og levering av tjenester for brukere der adressene ikke samsvarer med forventningene i valideringsdatabasen.

Her er noen få måter å utforme adressevalideringer på med tanke på tilgjengelighet på:

  • Implementer validering av tillatte adresser.
  • Godta fritekstadresseoppføring når strukturerte valideringer mislykkes.
  • Lagre adresser slik de skrives inn av brukere i stedet for å tvinge brukere til å gjøre ugyldige korrigeringer.
  • Bruk adressevalidering til dataforbedring og duplikatoppdagelse, ikke til å validere adresseformatering.

I stedet for å blokkere datafangst på forhånd bygger du adressebekreftelse i innfrielsesprosesser der nøyaktigheten av adressen er operasjonelt viktig.

Universelle tilgangsforutsetninger for bestemte kommunikasjonskanaler utelukker populasjoner med forskjellig teknologitilgang eller preferanser.

Kommunikasjon bare med e-post ekskluderer:

  • Brukere uten pålitelig internettilgang
  • Eldre populasjoner som er mindre komfortable med å bruke e-post
  • Brukere i områder der SMS- eller meldingsapper er den primære kommunikasjonsmetoden

Kommunikasjon bare for telefon utelukker

  • Brukere som er døve og har problemer med å høre
  • Brukere uten telefontilgang eller brukere som bruker delte telefoner

Utform omnikanal-kommunikasjonsarkitektur som lar brukere kontrollere kanalpreferanser. Lagre foretrukne kommunikasjonsmetoder i Kontakt-poster, og respekter konsistent preferanser på tvers av alle utgående kommunikasjonssystemer. Tilby en rekke kommunikasjonsalternativer i stedet for å anta at metoder med én kanal fungerer universelt.

Innsamling av demografiske data for overvåking av rettferdighet krever nøye arkitektur for å hindre misbruk.

Innsamling og behandling av demografiske data er jurisdiksjonsavhengig og juridisk begrenset (i EU behandler artikkel 9 i GDPR dem som data av spesiell kategori som krever en spesifikk juridisk grunnlag, i USA er skjevhetsovervåking vanligvis basert på frivillig EEO-egenidentifikasjon). Når det finnes et juridisk grunnlag, bruker organisasjoner demografiske data til å

  • Overvåk rettferdighetsmålinger som er lagd etter beskyttede grupper
  • Oppdage systematiske avvik i automatisering og AI-systemer
  • Demonstrere etterlevelse av forskriftskrav for å hindre diskriminering

Indsamling af demografiske data opretter visse risici:

  • Data kan brukes til diskriminerende formål hvis tilgangskontroller mislykkes
  • Brukere kan ikke stole på samlingsmetoder og oppgi unøyaktige data
  • Samling kan virke invasiv eller diskriminerende

Arkitekter frivillig selvidentifikasjon og utform samlingen av demografiske data ved å bruke informasjon som er:

  • Klart forklart med et transparent formål (for eksempel overvåking av rettferdighet eller rapportering av samsvar)
  • Frivillig og inkluderer alternativet "Foretruk ikke å svare" som alltid er tilgjengelig
  • Skillet fra driftsdata med streng FLS for å hindre upassende tilgang
  • Aggregeres for rapportering og analyse og er ikke knyttet til individuelle beslutninger
  • Overvåkes via Shield-hendelsesovervåking for tilgangsmønsterrevisjon

Det er viktig å dokumentere nøyaktig hvordan demografiske data vil og ikke vil bli brukt, i personvernpolicyer. Brudd på bruker Trust ved bruk av upubliserte data kan alvorlig skade troverdigheten, noe som kan være vanskelig å gjenopprette fra.

Tredjeparts dataforbedring som føyer til demografiske, firmagrafiske eller atferdsdata i Salesforce-poster, kan introdusere systematiske avvik ved å

  • Upresise utledninger som er basert på stereotyper
  • Ufullstendig dekning med hull som er korrelert med demografi
  • Proprietære algoritmer som bruker ukjente rettferdighetsegenskaper
  • Data som hentes fra systematiske historiske poster

Før du implementerer dataforbedringstjenester er det viktig å revidere:

  • Praksis for å teste leverandørens rettferdighet og avhjelpe systematiske avvik
  • Datadekning og nøyaktighet på tvers av demografiske grupper
  • Utledingsmetodologier og -funksjoner som brukes til å opprette forutsigelser
  • Restriksjoner og oppbevaringspolicyer for bruk av kontraktsdata

Husk at når tredjeparts data kommer inn i Salesforce-organisasjonen, kan det påvirke beslutninger og opprette leverandøroppgitte systematiske avvik som også gjenspeiles som systematiske avvik i organisasjonen.

I Salesforce-kontekster refererer tilgjengelighet til å arkitektere Lightning, Visualforce og Experience Cloud-nettsteder som fungerer for brukere med funksjonshemming. Standard Lightning gir grunnleggende tilgjengelighet når de brukes riktig, men tilpasset utvikling og Experience Cloud-konfigurasjon krever eksplisitt implementering av tilgjengelighet.

Lightning Design System-komponenter er utformet for å støtte WCAG 2.2 AA-samsvar når de brukes slik de er utformet. Salesforce arbeider for – men sertifiserer ikke – full samsvar. Å avvike fra SLDS eller bygge tilpassede komponenter uten hensyn til tilgjengelighet skaper barrierer for brukere med funksjonshemming.

Standard Lightning gir innebygd tilgjengelighet. Komponenter som Lightning, Lightning, Lightning og Lightning inkluderer automatisk riktige ARIA-attributter, etiketttilknytninger, tastaturnavigering og fokusbehandling. Bruk standardkomponenter når det er mulig i stedet for å bygge tilpassede alternativer som ser likt ut, men kan mangle den riktige tilgjengelighetsinfrastrukturen.

  • Bruk semantisk HTML i tilpassede Lightning-nettkomponenter. Når du bygger tilpassede komponenter, bruker du semantiske HTML-elementer (,
  • Implementer ARIA i tilpassede komponenter. Bruk ARIA-landemerker, -roller og -egenskaper når semantisk HTML ikke kan formidle grensesnittvirkemåte. Dynamiske innholdsoppdateringer krever aria-live-områder som kunngjør endringer til skjermlesere. Tilpassede interaktive komponenter trenger eksplisitte rolledefinisjoner som samsvarer med virkemåten deres. Lightning håndterer ARIA automatisk, men tilpassede komponenter krever manuell ARIA-validering via skjermlesertesting.
  • Test med hjelpeteknologi: Valider Lightning med faktiske skjermlesere (for eksempel JAWS og NVDA for Windows, VoiceOver for macOS og iOS og TalkBack for Android). Basert på Deques omfattende studie fanger automatiserte verktøy som ax-core opp omtrent 57 % av tilgjengelighetsproblemer etter volum. De gjenstående problemene krever manuell testing med hjelpeteknologi av personer som forstår skjermlesernavigeringsmønstre.
  • Bruk fokusbehandling i Lightning-flyter. Når modaler åpnes, dynamisk innhold lastes inn eller brukere fullfører flertrinns flyter, bør du programmatisk behandle fokus for å veilede tastaturbrukere til nytt innhold. Lightning og popup-komponenter sørger for grunnleggende fokusbehandling, men komplekse flyter trenger eksplisitt fokuslogikk for å flytte fokuset riktig etter hvert som innhold endres.

Experience Cloud-nettsteder betjener eksterne brukere – inkludert kunder, partnere og offentlig målgruppe – som krever tilgjengelig design som kanskje må oppfylle kravene i ADA, artikkel 508 og/eller European Accessibility Act (avhengig av jurisdiksjon, målgruppe og organisasjonstype).

  • Bruk tilgjengelige maler. Experience Cloud-maler som er bygd med Lightning Web Runtime (LWR), inkluderer standard tilgjengelighet. Standardmaler som Kundekontoportal og Hjelpesenter gir WCAG 2.2 AA-grunnlaget når de er riktig konfigurert. Tilpassede maler krever implementering av eksplisitt tilgjengelighet, inkludert semantisk kode, tastaturnavigering og skjermleserkompatibilitet.
  • Verifisere WCAG-samsvar i temaer. Tilpassede temaer og merkeprofilerte nettsteder krever fargekontrastvalidering. Tema-innstillingene i Opplevelsesbygger bestemmer farger, typografi og mellomrom. Forsikre deg om at all tekst oppfyller kontrasten 4,5:1 for normal tekst (under 18pt for vanlig tekst eller under 14pt for fet tekst) og 3:1 for stor tekst (18pt eller større for vanlig tekst eller 14pt eller større for fet tekst) og grensesnittkomponenter. Bruk nettleserutviklerverktøy eller nettbaserte kontrastkontrollere til å validere etter samsvar. Test med nettleserzoom til 200 % for å sikre at teksten skaleres uten å miste innhold eller funksjonalitet.
  • Bruk tastaturnavigering i navigeringsmenyer. Experience Cloud-navigeringskomponenter må støtte operasjon bare på tastaturet uten musevennlighet. Brukere må navigere inn og ut av rullegardinmenyer, megamenyer og flytavlogging ved å bruke Tab, Enter, Escape og Pil-tastene uten fokusfeller. Test alle navigasjonsbaner med bare tastaturet for å validere tilgjengelighet.
  • Aktiver skjematilgjengelighet i Experience Cloud. Knytt etiketter eksplisitt til alle skjemainndata ved å bruke riktige etikettelementer eller aria-labelledby. Plassholdertekst i seg selv mislykkes i tilgjengelighetskravene fordi teksten forsvinner så snart dataregistreringen starter, noe som lar skjermleserbrukere uten tilstrekkelig, vedvarende kontekst. Lightning sørger for innebygd etikettilknytning når de er konfigurert med de nødvendige etikettattributtene. Tilpassede Visualforce krever eksplisitt etikettinndatatilknytning.
  • Teste Experience Cloud-nettsteder med hjelpeteknologi. Før du starter offentlig tilgjengelige Experience Cloud-nettsteder, må du utføre omfattende tilgjengelighetstester med skjermlesere, navigering bare for tastatur og nettleserzoom. Det er viktig å inkludere brukere med funksjonshemming i brukertesting for å avdekke praktiske barrierer som ekspertevurderinger ofte kan gå glipp av. Hvis du bare tester interne Lightning uten å validere ekstern Experience Cloud-tilgjengelighet, blir offentlig tilgjengelige nettsteder sårbare for tilgjengelighetsklager og rettssaker.
  • Bruk alternativ tekst til bilder og ikoner. Alle informative bilder, ikoner og grafisk innhold i Experience Cloud krever alternativ tekst. Dekorative bilder bruker tom alternativ tekst (alt=""), som lar skjermlesere hoppe over dem. Informative bilder gir meningsfylt alternativtekst som beskriver innhold og funksjon. Når du skriver alternativ tekst for ikoner, fokuserer du på handlingen eller formålet med ikonet i stedet for dets visuelle utseende (i stedet for å for eksempel beskrive et forstørrelsesglassikon som "forstørrelsesglass", bør alternativteksten angi sin funksjonelle verktøy, som Søk på nettsted). Når du behandler bilder, må CMS be innholdsforfattere om å skrive inn alternativ tekst eller eksplisitt merke bildet som dekorativt (som angir alt="). Dette sikrer tilgjengelighet ved å hindre manglende alternativ tekst og tvungne beskrivelser for estetiske bilder.

Full tastaturtilgjengelighet betyr at brukere kan få tilgang til all funksjonalitet ved bruk av tastaturet uten at det på noe tidspunkt kreves interaksjon med mus eller berøring.

  • Bruk logisk fokusrekkefølge på Lightning-sider. Forsikre deg om at fokusrekkefølgen følger det visuelle oppsettet og flyt for interaksjon. Når brukere trykker på Tab, skal det visuelle fokuset bevege seg gjennom interaktive elementer i den rekkefølgen brukerne forventer basert på visuell utforming. Lightning og Opplevelsesbygger etablerer fokusrekkefølge basert på komponentplassering. Tilpassede komponenter krever eksplisitt faneindeksbehandling for å sikre logisk fokusfremdrift.
  • Bruk synlige fokusindikatorer for å oppfylle kontrastkrav. Lightning Design System tilbyr fokusstiler som oppfyller WCAG-kravene for de fleste komponenter. Tilpassede komponenter kan kreve forbedrede fokusindikatorer for å oppfylle 3:1-kontrastkravet mot omgivende innhold. Fokusindikatorer må være tydelig synlige for å la brukere med lav syn navigere via tastaturet. Fjern aldri fokusindikatorer med CSS (oversikt: ingen) uten å tilby en alternativ stil med synlig fokus.
  • Bruk tastaturfelle-reduksjoner i modaler og overlegg. Modale dialoger bør fange fokus i modalet mens det er åpent, noe som hindrer tastaturbrukere i å nå skjult bakgrunnsinnhold. Fokusfellen bør slippes ved modal avslutning og returnere fokuset til utløserelementet. Innebygd innhold – inkludert iframe-enheter og tredjeparts widgeter – må ikke fange opp tastaturfokus permanent uten en isolasjonsmekanisme.
  • Bruk snarveien uten konflikter. Lightning tilbyr standard tastatursnarveier som er dokumentert i Salesforce Hjelp. Tilpassede tastatursnarveier må utformes for å hindre konflikter med standard nettleserkontroller og skjermlesernavigeringskommandoer. I samsvar med WCAG-kriterier for vellykket utførelse må snarveier med ett tegn (for eksempel å trykke på en enkelt bokstav eller tegnsetting) ikke utløse globale handlinger. De må enten begrense aktiveringen til når en bestemt komponent har aktivt fokus, eller gi brukere en måte å slå av eller tilpasse snarveien helt på.

Bygg tilgjengelighetsvalidering i CI/CD pipelines for å finne strukturelle problemer automatisk på hver distribusjon i stedet for å behandle tilgjengelighet som periodiske manuelle revisjoner.

  • Bruk sa11y til testing av tilgjengelighet for Lightning-nettkomponenter. Salesforces sa11y-biblioteker (@sa11y/jest-pakken) pakker aksjekjernetilgjengelighetsmotoren for å legge til en toBeAccessible()-matcher for Jest-enhetstester. Skriv tilgjengelighetstester som validerer riktig ARIA-bruk, etiketttilknytninger, kontrastforhold og semantisk kode automatisk som en del av enhetstesten. Konfigurer bygninger til å mislykkes når kritiske tilgjengelighetsproblemer oppdages.
  • Bruk Lighthouse CI for Experience Cloud. Google Lighthouse kontrollerer tilgjengeligheten av nettsider, inkludert Experience Cloud-nettsteder. Integrer Lighthouse CI i distribusjonsledninger for å skanne offentlig tilgjengelige sider for tilgjengelighetsproblemer. Konfigurer score terskler til å kreve minimums tilgjengelighetsscore før distribusjonsgodkjenninger.
  • Bruk tilgjengelighetsagenten, som er tilgjengelig via Salesforce DX MCP-pakken. I MCP-kompatible miljøer eller i Agentforce Vibes ser den gjennom kode i forhold til WCAG-standarder, viser målrettede rettelser og kan generere en henteforespørsel som en tekniker kan se gjennom, validere og flette.

Skjevhet eksisterte i deterministisk Salesforce-automatisering lenge før AI kom inn i bildet. Tildelingsregler, Flytbeslutninger, valideringsregler og områdeutforming koder for menneskelig vurdering som kan opprettholde diskriminering. Til forskjell fra AI-skjevhet – som arkitekter undersøker omfattende – går automatiseringsskjevhet ofte gjennom uundersøkt fordi deterministisk logikk føles objektiv.

  • Følg tildelingsregler for salgsemner og saker. Fordel arbeid på tvers av salgs- og serviceteam. Når tildelingslogikk bruker kriterier som korrelerer med beskyttede egenskaper, oppretter automatisering systematiske forskjeller i tjenestenes kvalitet og salgsmulighetstilgang.
  • Tildelingsregler som bruker områdekarakteristikker, postnummer eller kontokarakteristikker, kan rute salgsmuligheter med høy verdi uforholdsmessig til bestemte team mens arbeid med lavere verdi rutes andre steder. Hvis områdegrenser er korrelert med kundedemografi og kompensasjonsstrukturer som varierer mellom områder, skaper tildelingsautomatisering økonomisk diskriminering.
  • Revider regeltildelingsresultatene regelmessig. Beregne tildelingsfordelinger på tvers av områder og team som er lagd opp etter kundedemografi. Hvis Enterprise-kontoer er konsentrert i bestemte områder mens SMB-kontoer er fordelt andre steder – og hvis Enterprise-områder mottar bedre kompensasjon eller ressurser – kan tildelingsregler gi urettferdige utfall som krever rettferdiggjøring.
  • Se gjennom kvalifikasjonsbasert Omnikanal-ruting. Dette kan påvirke tjenesten på tvers av kundepopulasjoner. Hvis rutingslogikk implisitt forutsetter at bestemte kvalifikasjoner er korrelert med kundeverdi eller problemkompleksitet, kan kunder motta forskjellige tjenesteresultater basert på demografiske proxyer.

Det er viktig å overvåke gjennomsnittlig håndteringstid, første kontaktoppløsninger og kundetilfredshet på tvers av rutingsbaner. Ulikheter kan indikere om enkelte kundesegmenter systematisk mottar mindre erfarne agenter eller færre rutingsalternativer.

  • Se gjennom Salesforce Flow-automatiseringer. Det å ta godkjenningsbeslutninger, bestemme berettigelser eller gi tilgangstilskudd kan kode diskriminerende logikk gjennom tilsynelatende harmløse forretningsregler. Enkelte flyter fører til indirekte diskriminering når kriteriene er korrelert med beskyttede egenskaper.
  • Se gjennom flytbeslutninger med tanke på rettferdighet. For hver flyt som tar konsekvensbeslutninger som påvirker brukere, er det viktig å spørre:
  • Hva skjer med brukere som ikke passer til den typiske kundeprofilen?
  • Korrelerer beslutningskriterier med demografiske egenskaper?
  • Håndteres unntak og kanttilfeller likt, eller skader de systematisk bestemte grupper?

Det er viktig å dokumentere viktige punkter om flytbeslutningslogikk og rettferdighet i arkitekturbeslutningsposter, og å underkaste flyter med høy risiko til de samme etiske gjennomgangspolicyene som AI-systemer.

  • Se gjennom valideringsregler. Hindre dataregistrering kan utelukke gyldige data fra brukere som har informasjon som ikke samsvarer med systemforutsetninger. Valideringsregler som avviser legitime data, oppretter usynlige populasjoner. Brukere som har data som ikke passer valideringsmønstre, kan ikke engasjere seg i bestemte systemer. Valideringsfeil blir ofte ikke rapportert fordi brukere avviser forespørslene sine i stedet for å rapportere tekniske feil. Her er flere vanlige valideringsskjevhetsmønstre:
  • Navnevalideringer som krever latinske tegn, kan utelukke navn med diakritikk og ikke-latinske skript.
  • Valideringer av telefonnumre bruker ofte amerikanske/vestlige formater, som utelukker internasjonale numre og alternative kommunikasjonsmetoder.
  • Adressevalideringer kan ikke gjenkjenne ikke-standardadresser (for eksempel PO-bokser, landlige ruter, stammeområder og internasjonale formater).
  • E-postvalideringer som krever personlige e-postadresser, kan skape en ulempe for brukere som ikke har personlig e-posttilgang.
  • Test valideringsregler med forskjellige data. Inkluder internasjonale adresser, ikke-vestlige navn og alternative telefonformater i valideringstester. Når valideringen avviser legitime data, må du utvide valideringslogikken for å unngå å utelukke gyldige brukere.
  • Se gjennom salgsområdedesign. Kundesegmenteringsstrategier og salgsområdedesign bestemmer ressurstildelingen på tvers av kundepopulasjoner. Når områdegrenser eller segmenteringskriterier korrelerer med demografi som fører til ulik ressurstildeling, kan denne tildelingen gi diskriminerende utfall. Områdeutforminger som bruker geografiske grenser, korrelerer ofte med rasistisk, etnisk og økonomisk demografi på grunn av boligsegregeringsmønstre. Hvis kompensasjon, personalnivåer eller ressursinvesteringer varierer mellom områder, kan geografi bli en mekanisme for diskriminerende tildeling av ressurser.
  • Analyser områdedemonstrasjonen før du avslutter utformingen. Tilordne kundedemografi på tvers av foreslåtte områdegrenser. Når det oppstår demografiske konsentrasjoner, evaluerer du om ressurstildelingen er rettferdig på tvers av alle områder uavhengig av demografisk sammensetning. Hvis forretningsbegrunnelsen krever forskjellige ressursnivåer på tvers av områder (for eksempel markedsmodning, konkurranseintensitet og vekstpotensial), dokumenterer du denne begrunnelsen eksplisitt og overvåker utfallet for å sikre at underbetjente områder får tilstrekkelige investeringsmuligheter for å hindre forankrede forskjeller.
  • Behold gjennomsiktighet i automatiseringslogikk. Dokumenter forretningsregler, tildelingskriterier og flytbeslutningslogikk i Salesforce Knowledge eller arkitekturbeslutningsposter. Gjennomsiktig automatisering gjør det mulig å gjennomgå rettferdighet på en måte som skjult logikk hindrer.
  • Regelmessig revisjon av resultater. Planlegg kvartalsvise revisjoner for å analysere automatiseringsresultater som kan være lagdelt etter kundedemografi. Husk at forskjeller utløser undersøkelser og potensiell rettelse.
  • Det er viktig å spore:
  • Tildelingsfordelinger på tvers av team og områder
  • Godkjenningsgrader for flyter som tar beslutninger om berettigelse
  • Avvisningsgrader for valideringsregler etter datamønster
  • Områdeytelse og ressurstildeling
  • Se gjennom automatisering med høy innsats gjennom en etisk linse. Emneflyter og tildelingsregler som påvirker ansettelse, kreditt, tjenestetilgang eller andre konsekvensutfall i samme etiske gjennomgangsprosess som AI-systemer. Automatiseringsskjevhet krever samme nivå av gjennomgang som algoritmiske skjevheter.

I Salesforce fokuserer AI fairness på å bruke Einstein til å validere at forutsigelser gir rettferdige utfall på tvers av alle demografiske grupper. Einstein Discovery og tilpasset instrumentering fanger opp forutsigelsesmodellbeslutningsdata som muliggjør systematiske avvik. CRM Analytics-kontrollpaneler sporer fairness-målinger. Feltrevisjonsspor og Hendelsesovervåking fanger opp beslutningsdata for algoritmisk ansvarlighet.

Einstein som påvirker konsekvensbeslutninger (for eksempel salgsemnescore, salgsmulighetsprognoser og kundesegmentering), krever vurderinger av rettferdighet før distribusjon som fungerer som et obligatorisk tilsvarende trinn (likner sikkerhetsvurderinger).

Analyser alle prediktive modellfunksjoner for korrelasjon med beskyttede egenskaper ved bruk av statistiske metoder. Fjern eller transformer proxyfunksjoner etter å ha vurdert om deres forutsigelsesverdi berettiger inkludering til tross for proxyfelt.

  • Revider Salesforce CRM-data før opplæring. Salesforce-organisasjoner inneholder flere tiår med menneskelige beslutninger som er basert på historiske fremgangsmåter. Hvis tidligere salgsteam prioriterte bestemte demografiske elementer, lærer Einstein disse mønstrene og opprettholder dem. Før du lærer opp forutsigelsesmodeller på historiske data, er det viktig å revidere disse dataene for gap i demografisk representasjon og målingskonsistens på tvers av kundesegmenter.
  • Beregne rettferdighetsmålinger på tvers av demografiske grupper. Før du distribuerer forutsigelsesmodeller, er det viktig å beregne demografisk paritet, lik salgsmulighet og forskjellige innvirkningsforhold på tvers av beskyttede grupper, der du har et juridisk grunnlag for å innhente og behandle de nødvendige demografiske dataene. Hvis Einstein-salgsemnescore tildeler høye score til segment A 50 % av tiden, men bare 30 % av tiden til segment B, mislykkes et forhold på 60 % med fjerde-femte-regelen (80 %) og krever undersøkelse og avbøyning. 80 %-tallet er en skjermutløser, ikke en juridisk gjennomgang/feil-linje: fire-femte regelen er en amerikansk føderal tommelregel for ansettelsesvalg, og å fjerne den er ikke en trygg havn – en statistisk signifikant forskjell kan berettige gransking i høyere forhold, og andre regimer måler negativ innvirkning annerledes (EU-lov om indirekte diskriminering, for eksempel, slår på om en praksis skaper en "spesiell ulempe", uten noen fast terskel). Kalibrer undersøkelsesterskler til jurisdiksjonene og brukstilfellene du arbeider i.
  • Fang opp forutsigelsesmodellbeslutningsdata for systematiske avvik. For å oppdage systematiske avvik i forutsigelsesmodeller som salgsemnescore og salgsmulighetsscore, kan du fange opp beslutningsdata via Einstein Discovery og tilpasset instrumentering: lagre inndata, utdata og modellversjoner for forutsigelser i sporede felt og aktiver Feltrevisjonsspor. Analyser disse dataene i CRM Analytics for å spore beslutningsmønstre på tvers av demografiske grupper over tid, og bygg kontrollpaneler som varsler når demografisk-paritet- eller likestillingsmålinger avviker utover akseptable terskler.
  • Detekter proxyfunksjoner i prediktive modeller. Funksjoner som er korrelert med beskyttede egenskaper, muliggjør indirekte diskriminering selv om beskyttede egenskaper er utelukket fra modellene.
    • Salesforce-data inneholder vanligvis proxyfunksjoner:
  • Område- eller postnummer (proxyer for rase, etnisitet og inntekt)
  • Kontonavnmønstre (proxyer for organisasjonsstørrelse og bransjedemografi)
  • Tidsplan for kommunikasjonsaktivitet (proxyer for tidssoner, religion og ansvar for behandling)
  • Enhetstype eller nettleser fra aktivitetsdata (proxyer for inntaksnivå)

Når systematiske avvik oppdages i Einstein, må du bruke avbøying i den riktige pipelinefasen (basert på rotårsak og tekniske begrensninger).

  • Balansedata før modellopplæring. Ombalansere Salesforce CRM-data ved å oversamplere underrepresenterte kundesegmenter eller undersamplere overrepresenterte segmenter før du lærer opp forutsigelsesmodeller. Bruk Data 360 til å aggregere data på tvers av flere organisasjoner for å sikre ulike opplæringssett. Generering av syntetiske data kan supplere omfattende segmenter samtidig som personvern bevares gjennom forskjellige personvernteknikker.
  • Fjern proxyer i funksjonsteknikk. Når proxyfunksjoner identifiseres, erstatter du dem med alternative funksjoner som gir forutsigelseskraft uten demografisk korrelasjon. Hvis område fungerer som demografisk proxyer, kan du vurdere bransjeklassifisering eller firmas størrelse som alternativer. Hvis kontonavnmønstre er korrelert med demografi, bruker du i stedet firmografiske attributter.
  • Juster tersklene under etterbehandling. Juster beslutningsterskelene per demografisk segment for å avstemme utfallsgrader etter opplæringsmodeller. For ansettelsesrelaterte beslutninger er dette strengt forbudt: Tittel VII (Civil Rights Act of 1991) forbyr justering av score eller bruk av forskjellige avgrensningsscore etter beskyttet klasse, og ingen dokumentert begrunnelse gjør denne praksisen lovlig. Når det ikke er forbudt, dokumenterer du terskeljusteringer med forretningsbegrunnelse for forskjellig behandling når forutsigelser informerer automatiske beslutninger.
  • Oppdater modeller regelmessig ved bruk av oppdaterte data. Planlegg modellopplæring på nytt kvartalsvis (eller når det skjer betydelige datafordelingsskift). Omlæring på nye data fanger opp nye skjevhetsmønstre og korrigerer eventuell avvik fra opprinnelige grunnleggende rettferdighetslinjer. Valider om rettferdighetsmålinger for hver modellversjon før produksjonsdistribusjon for å sikre at ny opplæring ikke introduserte nye systematiske avvik.

Einstein Trust fanger opp ledetekster, svar og Trust for generativ AI og Agentforce, og støtter gjennomsiktighet og forskriftssamsvar for generativ AI. For forutsigelsesmodeller kommer gjennomsiktighet og beslutningstrinn fra Einstein Discovery og Modellbehandling, som krever tilpasset instrumentering for å beholde revisjonsdata.

Bygg forklarbarhet i Einstein fra den første arkitekturen i stedet for å tilpasse forklaringer på nytt til opake systemer etter distribusjon.

  • Surface Einstein Discovery-forklaringer ved beslutningspunkter. Einstein Discovery gir forutsigelsesfaktorforklaringer som viser hvilke variabler som påvirket spesifikke forutsigelser mest med retningsinnvirkning. Arkitekter Lightning som viser disse forklaringene til brukere ved beslutningstidspunktet i stedet for å kreve navigering for å skille CRM Analytics-kontrollpaneler. Når beslutninger påvirker brukere, trenger de gjennomsiktighet, ikke abstrakte målinger av modellytelsen.
  • Lagforklaringer for ulike målgrupper. Gi forklaringsdybde som er riktig for hver målgruppe:
  • Forretningsbrukere: "Dette salgsemnet scoret høyt fordi årlig omsetning overskrider USD 1 000, og engasjementsscoren er i topp 10 %."
  • Tekniske brukere: Lever et Einstein Discovery med funksjonsvekter, opplæringsdataegenskaper og valideringsmålinger.
  • Kunder: "Denne anbefalingen er basert på dine siste kjøp og kunder med lignende preferanser."
  • Revisorer: Tilby beslutningslinje fra Einstein Discovery og Modellbehandling – modellversjon, inndataverdier og faktorene som drev forutsigelsen – registrert via tilpasset instrumentering.
  • Kommuniser tillit riktig. Vis forutsigelseskonfidens i brukervennlige termer, og unngå rå sannsynlighetsscore som brukere kan feiltolke. I stedet for å vise "73% konfidens" kommuniserer du dette ved å bruke kategorier (for eksempel Høy konfidens, Moderert konfidens og Gjennomgang av behov) med forklaringer på hva hvert konfidensnivå betyr for beslutningspålitelighet, i tillegg til hvilke andre gjennomganger som skal skje.

Oppretthold omfattende, uforanderlige revisjonsspor som støtter ansvarlighet, feilsøking og etterlevelse av forskrifter for alle AI-drevne beslutninger som påvirker brukere.

  • Fang opp forutsigelsesrevisjonsdata med de riktige verktøyene. Lagre forutsigelsesmodellrevisjonsdata – forutsigelsesinndata, utdata og modellversjoner – i sporede felt med Feltrevisjonsspor aktivert. Arkitekter dataoppbevaringspolicyer for å oppfylle lovpålagte krav, som varierer etter bransje og jurisdiksjon:
    • Reglene for finansielle tjenester fastsetter oppbevaring per forskrift (for eksempel fastsetter FINRA-regelen 4511(b) en standard oppbevaringsperiode på seks år for poster som ellers ikke har en spesifisert oppbevaringsperiode i henhold til FINRA-reglene eller SEA-regelen 17a-4).
    • Oppbevaring av helsetjenester styres også av spesifikke regler (for eksempel krever HIPAA minst seks år for samsvarsdokumentasjon; oppbevaring av medisinsk post fastsettes av individuelle delstatlige lover) i stedet for omfattende ubestemte oppbevaringskrav.
  • Analyser forutsigelsesmodellbeslutningsdata med CRM Analytics. Bygg CRM Analytics-kontrollpaneler på forutsigelsesmodellbeslutningsdataene du fanger opp (forutsigelsesinndata, utdata og modellversjoner i sporede felt) for å analysere beslutningsmønstre, fairness-målinger og modellytelse over tid. Opprett linser som viser forutsigelsesfordelinger etter konfidensnivå, demografisk segment og utfallstype. Konfigurer Einstein Discovery som identifiserer avvikende mønstre som krever ytterligere undersøkelse.
  • Bruk Feltrevisjonsspor til langsiktig oppbevaring. Standardfelthistorikk sporer endringer for 18 måneder i grensesnittet og opptil 24 måneder via API-et. Med Feltrevisjonsspor kan du beholde felthistorikk på ubestemt tid for tilpassede objekter som lagrer AI-beslutningsdata. Den arkiverer historikk etter opptil 18 måneder som standard, og beholder deretter de arkiverte dataene til du sletter dem. Aktiver Feltrevisjonsspor for objekter som inneholder samtykkeposter, overstyr beslutninger og systematiske rapporter, for å oppfylle krav til lovpålagte oppbevaringskrav.
  • Bruk Hendelsesovervåking til Agentforce-interaksjoner. Hendelsesovervåking fanger opp hendelser på kallnivå for Agentforce, som når handlinger og flyter kjøres. Eksporter hendelsesovervåking-data til et eksternt SIEM – standard hendelsesloggfildata via APIen og delsettet Sanntids hendelsesovervåking av hendelser via plattformhendelser – for lagring som overskrider det innebygde oppbevaringsvinduet i Salesforce. Tamper-bevis avhenger av bestemt SIEM-virkemåte som håndhever skrivebeskyttet lagring og tilgangssegregering. Konfigurer SIEM-spørringer for å oppdage skjevhetsmønstre på tvers av store volumer av Agentforce.
  • Revider Agentforce-samtaler med Einstein Trust-laget. Einstein Trust fanger opp revisjonssporet for Agentforce og -svar, lagret i Data 360, som gir posten på avskriftsnivå for gjennomsiktighet og etterlevelse av forskrifter.

La oss se nærmere på arkitektgjennomsiktighetsfunksjonene som er plassert for å overholde gjeldende og nye AI-forskrifter på tvers av flere jurisdiksjoner.

  • Krav til gjennomsiktighet i EU AI Act. Høyrisiko AI-systemer i henhold til EU AI Act krever transparensdokumentasjon, teknisk dokumentasjon, menneskelig overvåkingsfunksjonalitet og nøyaktighet/rettferdighetsmålinger. Revisjonssporene for Einstein Trust og Einstein Discovery gir grunnlaget for disse kravene. Dokumenter datademografi, valideringstilnærminger og kjente begrensninger i arkitekturbeslutningsposter.
  • Rett til informasjon. GDPR gir registrerte i EU rett til meningsfylt informasjon om logikken i en beslutning når denne beslutningen bare er basert på automatisert behandling og gir juridiske eller tilsvarende betydelige virkninger. Denne retten stammer fra artikkel 15 nr. 1 bokstav h) og artikkel 22 nr. 3 sammen med betragtning 71 og ble klargjort av EU-domstolen i saken Dun & Bradstreet (2025). Utform systemer som genererer konsistente forklaringer på forespørsel for historiske beslutninger innenfor tidsrammer for forespørsler om datasubjektets tilgang, som varierer (avhengig av jurisdiksjon) mellom 15 og 45 dager. Forutsigelsesmodellbeslutningsdataene du fanger opp – forutsigelsesinndata, utdata, modellversjoner og Einstein Discovery – lar deg rekonstruere forklaringer når de lagres med tilstrekkelig oppbevaring.
  • Algorithmic accountability laws. Statlige algoritmiske ansvarsforskrifter i USA krever i økende grad innvirkningsvurderinger og gjennomsiktighetsrapportering for automatiske beslutningssystemer. Forutsigelsesmodellbeslutningsdataene du fanger opp, og CRM Analytics-kontrollpanelene for overvåking av rettferdighet gir grunnlaget for disse rapportene. Utfør algoritmiske innvirkningsvurderinger før du distribuerer etterfølgende AI som proaktiv overholdelse av krav i stedet for som et reaktivt svar på lovpålagte forespørsler.

OWD-er, delingsregler og feltnivåsikkerhet (FLS) former datatilgangsmønstrene som bestemmer hvilken informasjon brukere kan se gjennom og bruke til å ta beslutninger. Riktig konfigurasjon hindrer diskriminerende tilgang til sensitive attributter samtidig som du sikrer rettferdig service.

Utform OWD-er og feltnivåsikkerhet for å begrense tilgang som standard. Når det gjelder delingsregler, bruker du prinsippet for minst rettigheter (PoLP) til å gi bare den ekstra tilgangen som hver rolle legitimt trenger, noe som hindrer diskriminerende beslutninger basert på beskyttede egenskaper.

  • Aktiver restriktiv OWD som standard. Bruk private OWD-er for objekter som inneholder sensitive kundedata, og gi tilgang etter rollehierarki og delingsregler. Felles lese/skrive-ODD-er gjør begrensning av tilgang forstyrrende senere – innstramming av standard utløser en ny beregning av deling og trer i kraft først etter at den er fullført – i stedet for umulig. Private OWD-er med eksplisitte delingstildelinger oppretter reviderbare tilgangsmønstre som støtter overholdelse av krav om ikke-diskriminering.
  • Bruk feltnivåsikkerhet for sensitive attributter. Skjul sensitive felt som inneholder beskyttede egenskaper (for eksempel etnisitet, religion og funksjonshemmingsstatus) for brukere som ikke trenger tilgang for legitime forretningsformål. Konfigurer FLS til å fjerne lesetilgang for sensitive felt i de fleste profiler. Når disse feltene kreves for bestemte formål (for eksempel rapportering av mangfold og rimelig tilpassing), gir du minimumstilgang ved å bruke tillatelsessett med dokumentert forretningsbegrunnelse.
  • Utform tildelings- og delingsregler for rettferdige utfall. Bruk tildelingsregler, køer og Omnikanal-ruting til å fordele arbeid rettferdig på tvers av områder, team og serviceagenter. Unngå manuell deling som konsentrerer salgsmuligheter med høy verdi eller kunder med bestemte brukergrupper uten dokumentert forretningsbegrunnelse. Konfigurer automatiske delingsregler basert på objektive kriterier (for eksempel bransje, geografi og produktlinje) i stedet for subjektiv lederbeskyttelse, som kan aktivere systematiske avvik.
  • Gi tillatelsessett for midlertidig tilgang. Gi midlertidig tilgang til sensitive data via tillatelsessett i stedet for å endre profiler, som påvirker alle brukere permanent. Når brukere trenger tilgang til demografiske data for bestemte prosjekter (for eksempel mangfoldsanalyse og forespørsler om overnatting), tildeler du tillatelsessett med dokumenterte utløp. Planlagte flyter kan oppheve tillatelsessett automatisk etter definerte perioder.

Bruk Shield-hendelsesovervåking og rapporter til å oppdage datatilgangsmønstre som indikerer potensiell diskriminering eller systematiske avvik i databruk.

  • Bruk Shield Event Monitoring til å kontrollere tilgang til sensitive data. Bruk Hendelsesovervåking til å fange opp tilgangshendelser på objektnivå (rapporteksporter, API-spørringer og sidevisninger) for objekter som inneholder beskyttede egenskaper eller sensitive attributter. Konfigurer spørringer over disse hendelsene for å vise hvem som hadde tilgang til objektet, når og i hvilken kontekst, og behandle unormale mønstre (for eksempel plutselige spikes og tilgang fra uventede brukere) som utløsere for undersøkelse.
  • Rapport om delingsregelfordelinger. Bygg rapporter som analyserer hvordan poster distribueres på tvers av brukere, team og områder. Beregn fordelingstatistikk etter kundedemografi for å sikre at kontoer og salgsmuligheter med høy verdi blir fordelt likt. Identifiser konsentrasjoner der bestemte brukergrupper får uforholdsmessig tilgang til verdifulle poster uten dokumentert forretningsbegrunnelse.
  • Revisjon av CRUD- og FLS-brudd. Se gjennom Revisjonsspor for oppsett for å finne endringer i OWD-innstillinger, delingsregler, FLS-konfigurasjoner og tillatelsessett. Uautoriserte endringer i datatilgangskontroller kan indikere forsøk på å få tilgang til sensitive data på en upassende måte. Bruk policyer for transaksjonssikkerhet til å handle på hendelser med høy risiko og Sanntids hendelsesovervåking (for eksempel avvikende API-aktivitet, mistenkelige pålogginger og eksport av store rapporter eller listevisninger av sensitive data). I og med at Transaksjonssikkerhet bare fungerer på disse kjøretidshendelsene i stedet for DML- eller FLS-endringer på postnivå, må du stole på Revisjonsspor for oppsett og dokumenterte godkjenninger av endringsbehandling for endringer i FLS og deling.

I Salesforce betyr brukeragentur at kunder og ansatte beholder meningsfylt kontroll over hvordan AI påvirker opplevelsen deres. Salesforce-samtykkebehandlingsfunksjoner, Data 360-samtykke og tilpassede samtykkeobjekter gir detaljert kontroll over AI-interaksjoner.

Utform samtykkesporing med Data 360-samtykkebehandling, Marketing Cloud-samtykke eller tilpassede samtykkeobjekter som bruker Feltrevisjonsspor for AI-spesifikke samtykkekrav.

  • Aktiver detaljert samtykke per AI-brukstilfelle. Aktiver samtykke per AI-brukstilfelle i stedet for å bruke et fullstendig AI-samtykke. Kunder kan samtykke til Einstein, men avslå AI-drevne kredittbeslutninger. Aktiver Feltrevisjonsspor for samtykkeobjekter for langsiktig oppbevaring og oppfyllelse av lovpålagte krav. Utform tilpassede Samtykke-objekter med felt som sporer:
  • Samtykkedsformål (for eksempel Einstein, Einstein og Einstein)
  • Tildelingsdato for samtykke og Tildelingsmetode (for eksempel nettskjema, API, telefon og e-post)
  • Dato for tilbakekalling av samtykke (hvis aktuelt)
  • Relatert bruker eller kontakt-ID
  • Bruk Data 360-samtykke til tilpassing. Bruk Data 360-samtykkebehandling for Einstein-tilpassing. Data 360 henter inn og lagrer samtykkepreferanser fra oppstrøms systemer via koblinger som er tilordnet til personverndatamodellen, som lar deg bruke disse samtykkeattributtene som filterkriterier i segmentering og ved aktivering. Tilordne samtykkeattributter til bestemte AI-brukstilfeller for å gi brukere mulighet til å velge bort tilpassing samtidig som de opprettholder kjernetjenester
  • Aktiver Marketing Cloud-samtykkeintegrering. Integrer Marketing Cloud-samtykke med Einstein Messaging-innsikt og AI-drevne markedsføringsfunksjoner. Respekter Marketing Cloud-abonnementstatusen og samtykket i all AI-drevet kommunikasjon.

Gi meningsfylte reservasjoner fra AI-drevne funksjoner med tilgjengelige kontroller som tar hensyn til brukerpreferanser via menneskelige alternativer av sammenlignbar kvalitet.

  • Gi tilgjengelige reservasjoner i profilinnstillinger. Gi brukere mulighet til å velge bort AI-drevne interaksjoner via tilgjengelige preferansekontroller i Experience Cloud-profilinnstillinger eller Mine innstillinger i interne apper. Gi tydelige beskrivelser av hva hver reservasjon betyr og den alternative opplevelsen brukerne vil motta ved reservasjon. Lagre preferanser i Bruker- eller Kontakt-poster.
  • Gi faste preferansealternativer på tvers av kanaler. Lagre AI-preferanser i Bruker- eller Kontakt-poster for å sikre konsistens på tvers av kanaler (for eksempel nett, mobil, telefon og e-post). Spørre preferanser konsistent i alle interaksjonsflyter for å hindre at brukere må deklarere preferanser på nytt gjentatte ganger i forskjellige kanaler.

Etisk AI-styring gir organisasjonsstrukturer som bidrar til å sikre at rettferdighet vedvarer etter hvert som modeller utvikles, data skift og brukstilfeller utvides. Uten styring blir innledende rettferdighetsarbeid dårligere etter hvert som organisasjonens oppmerksomhet skifter.

Opprett obligatorisk dokumentasjon og gjennomgå sjekkpunkter før Einstein distribueres. Tenk på dette som en port som er like viktig som sikkerhetsvurderinger.

  • Gi modelldokumentasjon. Lagre modelldokumentasjon i Salesforce ved bruk av et tilpasset Modell-objekt, eller Salesforce Files som er knyttet til Prosjekter, for å aktivere søkbarhet og versjonskontroll. Dokumenter hver forutsigelsesmodell for produksjon ved å bruke
  • Opplæring av demografiske data og kjente representasjonshull (for kundeopplærte forutsigelsesmodeller som Einstein Discovery og Prediction Builder)
  • Målinger av rettferdighet før distribusjon som beregnes etter demografisk gruppe
  • Tiltenkte brukstilfeller og kjente upassende bruk
  • strategier for avverging av systematiske avvik som brukes under utvikling
  • Fairness-overvåkingstilnærming og varselterskler
  • Krav til personlig tilsyn og godkjenningsarbeidsflyter
  • Se gjennom tidsplaner og ansvarlige parter
  • Viktige punkter om forskrift og samsvar
  • Aktiver fairness-portaler før distribusjon. Modeller som mislykkes i noen porttester, må ikke fortsette til produksjon. Behandle rettferdighetsportaler med samme strenghet som sikkerhetsportaler. Med andre ord har de myndighet til å blokkere distribusjoner. Før du distribuerer Einstein til produksjon må du
  • Se gjennom revisjoner av opplæringsdata. Alle representasjonshull må analyseres og dokumenteres.
  • Gjennomgå rettferdighetsmålinger (for eksempel demografisk paritet, like muligheter og ulik innvirkning må beregnes og bekreftes for å oppfylle terskler).
  • Se gjennom konsekvensvurderinger. Evaluer potensiell skade på tvers av berørte populasjoner.
  • Design med menneskelig oversikt. Alle eskaleringsmønstre, godkjenningsarbeidsflyter og overstyringsmekanismer må være riktig utformet og testet.
  • Fullfør en gjennomsiktighetsgjennomgang. Forklaringsfunksjoner må valideres for alle beslutningstyper.
  • Komplett dokumentasjon. Alle nødvendige modelldokumentartikler må være godkjent.

Opprett gjennomgangsprosesser for AI-programmer med stor interesse som gir overvåkning på tvers av funksjoner og har håndhevingstillatelse.

  • Se gjennom sammensetningen av styret. Inkluder tekniske eksperter (for eksempel arkitekter og datateknikere), forretningsinteressenter (for eksempel produkteiere og driftspersoner), juridiske rådgivere, personvernspesialister og representanter fra berørte fellesskap (hvis det er mulig). Husk at ulike perspektiver viser rettferdighetsproblemer som homogene grupper ofte mangler.
  • Se gjennom alle utløsere som krever godkjenning av etisk råd. Definer hvilke AI-brukstilfeller som krever etisk gjennomgang før distribusjon:
  • Beslutninger som påvirker ansettelse, kreditt, bolig, helsetjenester eller juridiske rettigheter
  • Automatiserte systemer som påvirker mer enn 10 000 brukere eller transaksjoner per år
  • AI-programmer som bruker sensitive personlige data, inkludert helse-, økonomiske eller demografiske data
  • Nye brukstilfeller som ikke har et etablert organisasjonsprecedent
  • Systemer der potensielle systematiske avvik kan føre til betydelig skade for enkeltpersoner eller grupper
  • Gjennomgå og fastslå hvem som har myndighet til å blokkere distribusjoner. Etiske gjennomgangspaneler bør ha myndighet til å kreve endringer, innføre overvåkingsbetingelser eller blokkere distribusjoner som ikke samsvarer med etiske standarder. Gjennomganger bare for rådgivning (uten håndhevelse) kan begrense effektiviteten av styringsprosessen. Dokumenter alle vurderinger i tilpassede Salesforce-objekter som sporer: programnavn, gjennomgangsdato, oppståtte bekymringer, avbøyingskrav og godkjenningsbetingelser.

Overvåking av rettferdighet er en kontinuerlig prosess som krever kontinuerlig oppmerksomhet for å oppdage systematiske avvik etter hvert som datadistribusjoner skifter og brukerpopulasjoner endres.

  • Opprett CRM Analytics-kontrollpaneler for rettferdighet. Bygg kontrollpaneler som sporer rettferdighetsmålinger med forutsigelsesmodellbeslutningsdataene du fanger opp. Overvåk demografisk paritet, lik salgsmulighet, forskjellig innvirkning og målinger av forutsigelseskvalitet etter kundesegmenter. Konfigurer CRM Analytics-varsler som utløses når rettferdighetsmålinger bryter definerte terskler og krever en undersøkelse.
  • Aktiver tilpasset overvåking for rettferdighetssignaler. Bygg tilpasset overvåking av rettferdighet for å oppdage signaler (for eksempel plutselige endringer i beslutningsfordelinger etter demografisk gruppe, økninger i skjevhetsrelaterte saksposter eller nedgang i modellytelsen for bestemte populasjoner).
  • Planlegge rettferdighetsrevisjoner. Utfør omfattende, kvartalsvise rettferdighetsrevisjoner for AI-systemer med høy innsats (for eksempel kreditt, ansettelse og helsetjenester), og halvårsrevisjoner for systemer med lavere innsats (for eksempel anbefalinger og tilpassing). Revisjoner bør undersøke gjeldende rettferdighetsmålinger, se gjennom overstyringsmønstre i godkjenningshistorikk, analysere tilbakemeldinger fra brukere og skjevhetsrapporter, og validere om styringskontroller forblir effektive.
  • Implementer hendelsessvar for manglende rettferdiggjøring. Opprett tydelige prosesser som er dokumentert i Salesforce Knowledge med detaljer om hvordan du skal reagere når systematiske avvik oppdages:
  • Umiddelbart: Vurder alvorlighetsgraden og omfanget ved å spørre beslutningsdataene for forutsigelsesmodellen i CRM Analytics. Hvis hendelsen er alvorlig, suspenderer du all automatisk beslutningstaking i påvente av en undersøkelse.
  • Kortsiktig: Implementer midlertidige avbøyningsstrategier (for eksempel økt oversikt over brukere via justerte konfidens terskler, funksjonsdeaktivering eller fullstendig suspendering av agenter).
  • Utforsking: Utfør en rotårsaksanalyse (RCA) for å identifisere hvordan systematiske avvik kom inn i systemet eller utviklet seg. Under RCA analyserer du opplæringsdata, modellversjoner og konfigurasjonsendringer via Feltrevisjonsspor.
  • Rettelse: Implementer en permanent rettelse via datakorrigering, modellgjennomgang eller prosessendringer.
  • Melding: Varsle berørte brukere via Saker, e-post eller Experience Cloud-kunnskaper.
  • Forebygging: Behandle endringer for å hindre gjentagelse, og dokumenter preventivmetodene i kjørebøker.

Bruk denne sjekklisten under arkitekturgjennomganger, før produksjonsdistribusjon og regelmessig for pågående vurdering.

Datakvalitet og representasjonsrettferdighet

  • Gjør felt valgfrie der en prosess kan fungere uten dataene, og utform nedstrøms prosesser for å håndtere manglende verdier, slik at brukere som ikke kan oppgi informasjon (e-post, SSN, gateadresse), ikke utelukkes.
  • Navn på arkitektfelt som et enkelt felt med fullt navn eller en fleksibel struktur med flere deler som godtar mononymer, ikke-latinske skript, diakritikk og lange navn, i stedet for å anta første/siste rekkefølge i vestlig rekkefølge.
  • Implementer tillatelsesvalidering av adresser som godtar fritekstformater og internasjonale formater, og lagre adresser som oppgitt i stedet for å blokkere postopprettelse i formater som ikke samsvarer.
  • Lagre preferanser for kommunikasjonskanaler i Kontakt-poster og støtt omnikanalternativer (e-post, SMS, telefon, post, chat, tale) i stedet for å anta at en enkelt kanal når alle brukere.
  • Indsaml demografiske data gennem frivillig selvidentifikation med indstillingen "Foretruk ikke at svare", lagret separat under Privat OWD med FLS, aggregeret til rapportering og overvåget via Shield-begivenhedsovervågning.
  • Revider tredjeparts forbedringsleverandører for rettferdighetstesting, demografisk dekning og utledningsmetodologi før du føyer til demografiske eller atferdsdata i poster.

Tilgjengelighet og inkluderende design

  • Bruk Lightning Design System-komponenter som er utformet for å støtte WCAG 2.2 AA tilgjengelighet. Husk at Salesforce arbeider for å oppnå samsvar, men komponenter må fremdeles brukes riktig.
  • Valider tilpassede Lightning med skjermlesertesting (for eksempel JAWS, NVDA og VoiceOver).
  • Forsikre deg om at fullstendig tastaturnavigering finnes på Lightning og Experience Cloud-nettsteder uten musevennlighet.
  • Kontroller at kontrastforhold oppfyller 4,5:1 for normal tekst ved å bruke nettleserutviklingsverktøy eller kontrastkontrollere.
  • Integrer Sa11y- eller Lighthouse-tilgjengelighetsskanning i CI/CD pipelines som mislykkes, bygger på kritiske problemer.
  • Test Experience Cloud-nettsteder med hjelpeteknologi før offentlig oppstart.
  • Bekreft tilbakemeldinger fra hørsel ved å bekrefte at alle dynamiske endringer (for eksempel feilstatuser, innlasting av spinner eller utvidede menyer) er klart annonsert, og at det tales innhold samsvarer med den visuelle hensikten i grensesnittet.

Rettferdighet i Salesforce Automation

  • Se gjennom tildelings- og rutingsregler for korrelasjon med beskyttede egenskaper som kan konsentrere positive eller ugunstige utfall i bestemte demografiske grupper.
  • Revider Flyt- og prosessautomatiseringsbeslutningslogikk for systematiske avvik, dokumentere forretningsregler og kriterier i Salesforce Knowledge eller arkitekturbeslutningsposter.
  • Evaluer valideringsregler for avvisningsfrekvenser som har en uforholdsmessig innvirkning på bestemte datamønstre eller -populasjoner.
  • Analyser område- og segmenteringsutforminger for demografisk korrelasjon, dokumenter eksplisitt forretningsbegrunnelse og overvåk underbetjente områder for rettferdig ressurstildeling.
  • Subject high-stakes Flyter og tildelingsregler (ansettelse, kreditt, tjenestetilgang) til den samme etikkgjennomgangsprosessen som AI-systemer, og planlegg kvartalsvise revisjoner av automatiseringsresultater stratifisert etter demografi.

AI Fairness and Bias Detection

  • Revider Salesforce CRM-data for å finne gap i demografisk representasjon før forutsigelsesmodellopplæring.
  • Beregn demografisk paritet, lik salgsmulighet og forskjellige innvirkningsforhold per demografisk gruppe før distribusjon.
  • Implementer rettferdighetsvurderinger som en obligatorisk distribusjonsgate (tenk på dette som å være lik en sikkerhetsgjennomgang).
  • Bygg CRM Analytics-kontrollpaneler som sporer rettferdighetsmålinger ved bruk av forutsigelsesmodellbeslutningsdata som fanges opp med Feltrevisjonsspor.
  • Analyser prediktive modellfunksjoner for proxykorrelasjon med beskyttede egenskaper (for eksempel områdenavn- og kontonavnmønstre).
  • Planlegg omfattende, kvartalsvise rettferdighetsrevisjoner for alle AI-systemer med høy risiko.

Transparanse og revisjonskapasitet

  • Forklaringer av Surface Einstein Discovery på beslutningspunkter i Lightning.
  • Konfigurer Einstein Trust Layer-revisjonsfangst ved bruk av oppbevaringsmetoder som oppfyller lovpålagte krav.
  • Aktiver Feltrevisjonsspor i alle tilpassede objekter som lagrer AI-beslutningsdata for langsiktig oppbevaring.
  • Eksporter hendelsesovervåkingsdata til et eksternt SIEM – hendelsesloggfildata via API-et og hendelsesovervåkingshendelser i sanntid via plattformhendelser – for lagring som overskrider innebygd oppbevaring, med skrivetidskontroller på SIEM-siden for manipulasjonsbevis.
  • Gi brukervennlig konfidenskommunikasjon (for eksempel Høy, Moderert og Lavt) i stedet for rå sannsynligheter.

Menneskelig overvåking med Salesforce Automation

  • Konfigurer konfidensbaserte eskaleringsterskeler i Flyt, og ruter forutsigelser med lite konfidens til gjennomgang for brukere.
  • Bruk Salesforce-godkjenningsprosesser til viktige beslutninger som krever kjeder for gjennomgang med flere faser.
  • Integrer Agentforce og Omnikanal-ruting for å muliggjøre sømløs eskalering til agenter.
  • Oppgi et fast alternativ for Koble til personlig agent i Agentforce for å respektere brukerorganisasjonen.
  • Krev dokumentert logikk og sporing av godkjenningshistorikk for Agentforce som fanges opp i tilpassede felt.

Ikke-diskriminering med datatilgangskontroller

  • Aktiver Privat OWD, og gi deretter ekstra tilgang via rollehierarki og delingsregler.
  • Konfigurer feltnivåsikkerhet for å skjule sensitive demografiske felt for brukere som ikke trenger tilgang.
  • Overvåk tilgangshendelser på objektnivå (rapporteksporter og API-spørringer) for sensitive data via Shield-hendelsesovervåking, og analyser dem for unormale tilgangsmønstre.
  • Bygg rapporter som analyserer fordelinger av delingsregler for å sikre rettferdig posttildeling på tvers av områder.
  • Se gjennom Revisjonsspor for oppsett for uautoriserte endringer i OWD-, delingsregel- eller FLS-konfigurasjon.

Brukeragentur og samtykke

  • Utform tilpassede Samtykke-objekter ved å bruke Feltrevisjonsspor til å spore detaljert samtykke fra AI per bruksområde.
  • Integrer Data 360- eller Marketing Cloud-samtykke med Einstein-tilpassing og Agentforce.
  • Lagre AI-preferanser i Bruker- eller Kontakt-poster for å sikre konsistens på tvers av kanaler (for eksempel nett, mobil og telefon).
  • Gi tilgjengelige reservasjoner i profilinnstillinger og alternativer for brukere via Omnikanal-ruting.
  • Spør samtykkeposter i Flyt før Einstein eller Agentforce påvirker brukere.

Etisk AI-styring

  • Dokumenter alle produksjonsforutsigelsesmodeller, inkludert fairness-målinger og avbøyningsstrategier. For kundeopplærte forutsigelsesmodeller (som Einstein Discovery og Prediction Builder) dokumenterer du også opplæringsdata-demografi.
  • Opprett obligatoriske rettferdighetsportaler før distribusjon som blokkerer distribusjon til alle rettferdighetskriteriene er oppfylt.
  • Opprett et AI Ethics Review Board som håndhevingsenhet for alle AI-programmer med høy interesse.
  • Bygg CRM Analytics-kontrollpaneler for å overvåke rettferdighetsmålinger i en planlagt kadens via CRM Analytics-varsler.
  • Definer hendelsessvarprosedyrer for rettferdighetsfeil og dokumenter prosessen i Salesforce Knowledge.
  • Planlegg kvartalsvise rettferdighetsrevisjoner som analyserer overstyringsmønstre og tilbakemeldinger fra brukere for alle systemer med høy risiko.

Dele tilbakemeldingene dine om det velbygde rammeverket.