Rättvisa

Rättvisa

I Salesforce-arkitekturer innebär rättvisa att bygga lösningar som servar användare rättvist genom tillgängliga gränssnitt, upptäckt och begränsning av biasering, transparenta beslut och etisk styrning. Einsteins förutsägelser påverkar resultat som påverkar kunder och anställda, vilket innebär att arkitekter bör utforma system som ger rättvisa resultat över demografiska grupper samtidigt som de är tillgängliga för användare med funktionshinder.

Salesforce tillhandahåller plattformsfunktioner som är specialbyggda för rättvisa och vi strävar efter att uppfylla WCAG 2.2 AA. När det används korrekt tillhandahåller Salesforce Lightning Design System (SLDS) komponenter som är utformade för att stödja detta mål. Låt oss ta en närmare titt på varje komponent.

  • Shield Platform Encryption skyddar känsliga attribut som demografiska data, och händelseövervakning tillhandahåller granskningsloggar som har stöd för transparent datahantering.
  • Einstein Trust Layer (ETL) samlar in en säker verifieringskedja för uppmaningar och svar om genererande AI för övervakning och efterlevnad.
  • Experience Cloud inkluderar tillgänglighetskontroller.
  • Fältgranskningsloggen ger långsiktig lagring av dataändringshistorik på fältnivå, vilket stöder algoritmisk ansvarighet när AI-beslutsdata lagras i spårade fält.

Dessa kapaciteter hjälper till att sänka driftskostnaderna för Salesforces rättviserutiner.

På Salesforce arbetar rättvisa över tre dimensioner för att tillhandahålla lösningar. Inkluderande design hjälper till att göra Lightning (LWC), Visualforce och Experience Cloud-webbplatser fullständigt tillgängliga—med sömlös tangentbordsnavigering, skärmläsarkompatibilitet och kognitiv design. Rättvisa metoder för AI hjälper Einstein förutsägelser att skapa rättvisa resultat med hjälp av biasdetektering, olika utbildningsdata och kontinuerlig övervakning. Styrning tillhandahåller processer och kontroller för att upprätthålla rättvisa när modeller utvecklas och användningsfall utökas.

Försummelse av rättvisa skapar ökad risk. Experience Cloud-webbplatser som inte är tillgängliga kan utsätta organisationer för rättstvister enligt Americans with Disabilities Act (ADA) och, för federala myndigheter och deras leverantörer, överträdelser av avsnitt 508. Beroende på systemets riskklassificering och nya algoritmiska ansvarslagar kan partiska Einstein-förutsägelser strida mot kraven i EU:s AI-lag. Endast automatiserade AI-drivna beslut med juridiska eller liknande betydande effekter som saknar meningsfull information om beslutslogiken kan bryta mot GDPR artikel 22 och artikel 15.1 h informationsrättigheter.

Organisationer som skapar rättvisa tenderar att minska förutsebar skada för kunder, anställda och diskussionsgrupper som påverkas av deras system. Misslyckanden i rättvisa kan orsaka påtaglig, materiell skada för drabbade individer—inklusive ekonomisk skada, nekade möjligheter, känslomässigt lidande och förstärkning av systemisk diskriminering. Anpassning av regelverk tenderar att följa av att tjäna påverkade individer väl.

Använd dessa principer för att guida dina arkitektoniska beslut för rättvisa på plattformen.

  • Utforma tillgänglighetsmönster för Lightning. När du bygger, använd Lightning Design System och standardwebbkomponenter i Lightning som är utformade för att stödja tillgänglighet för WCAG 2.2 AA när så är möjligt. När du bygger med SLDS använder du ett bibliotek där tillgänglighet är en central designprincip. SLDS komponenter kontrolleras för tangentbordsåtkomst och kompatibilitet med hjälpmedelsteknik, och många innehåller en tillgänglighetssektion med utvecklartips. Om en egen komponent krävs måste explicit implementering av WAI-ARIA (Accessible Rich Internet Applications), semantisk HTML och tangentbordsnavigering valideras genom hjälpmedelstester.
  • Minska och övervaka biasering med rätt verktyg för varje modelltyp. Validera AI-resultat för rättvisa resultat över demografiska grupper innan distribuering och kontinuerligt i produktion. För prediktiva modeller, samla in beslutsdata genom Einstein Discovery och egen instrumentering och analysera dem i CRM Analytics för att mäta rättvisa. För funktioner för generativ AI och Agentforce, använd granskningsloggen för uppmaningar och svar från Einstein Trust Layer (ETL). Dokumentera beslut för att uppfylla kraven på transparens.
  • Leverage Shield Platform Encryption för dataskyddskontroller. Använd Shield Platform Encryption med deterministiska scheman för känsliga attribut som kräver sökfrågor med exakt matchning och samtidigt skyddar personuppgifter. Dirigera händelseövervakningsloggar till ett externt system för säkerhetsinformation och händelsehantering (SIEM) för att stödja manipulationssäkra granskningskedjor—när SIEM tillämpar lagring en gång och åtkomstsegregation som överskrider Salesforces inbyggda lagringsfönster för obligatoriska föreskrifter.
  • Utforma granskningsflöden för förutsägelser med höga insatser. Konfigurera godkännandeprocesser och granskningsmekanismer i Salesforce-flöden för att säkerställa att Einstein förutsägelser som påverkar följdbeslut granskas av personal. Använd förtroendetrösklar och verksamhetsregler för att avgöra när förutsägelser behöver valideras innan åtgärder vidtas.
  • Tillämpa organisationsomfattande standarder (OWD) och fältnivåsäkerhet (FLS) för icke-diskriminering. Arkitektdataåtkomstmönster som använder OWD och FLS för att begränsa åtkomst som standard och endast bevilja den ytterligare åtkomst som varje roll behöver med delningsregler. Undvik att bevilja profiler överdriven åtkomst som kan exponera känsliga attribut och möjliggöra diskriminerande beslutsfattande.
  • Aktivera användaragentur genom plattformssamtycke. Använd kapaciteten för samtyckeshantering i Data 360 eller egna samtyckesobjekt med Fältgranskningslogg för att följa detaljerat AI-samtycke per användningsfall. Låt användare avböja AI-drivna funktioner och tillhandahålla mänskliga alternativ (när så är möjligt).

Beslut om dataarkitektur avgör vilka populationer som blir synliga—och osynliga—i Salesforce-system. Dålig datakvalitet är inte bara ett tekniskt problem. Det blir ett rättviseproblem när dataluckor systematiskt missgynnar specifika demografiska grupper.

  • Gå igenom obligatoriska fält för att se datatillgänglighet. När obligatoriska fält antar informationstillgänglighet som varierar över demografi blir datakompletthet diskriminerande. Användare som inte kan tillhandahålla den information som behövs blir dolda i system som avvisar ofullständiga poster.
    • Att kräva e-postadresser utesluter populationer som inte har pålitlig internetåtkomst eller personliga e-postadresser.
    • Att kräva amerikanska personnummer (SSN) utesluter internationella kunder och nya invandrare som ännu inte har fått ett SSN.
    • Att kräva gatuadresser utesluter hemlösa och användare med icke-traditionella adresser.
  • Granska verksamhetsmotiveringar för obligatoriska fält. För varje obligatoriskt fält är det viktigt att dokumentera varför informationen är obligatorisk och inte valfri. Om processer kan fungera utan vissa data via alternativa metoder, gör dessa fält valfria och designsystem för att hantera saknade värden smidigt. Detta hjälper till att säkerställa att användare som inte kan tillhandahålla sådana data inte utesluts.

Namnfält som följer västerländska namnkonventioner (Förnamn, Efternamn) kan utesluta kulturer med olika namngivningsmetoder.

Många kulturer använder:

  • Enskilda namn—eller mononymer—utan familjenamn
  • Patronymiska system där “efternamn” ändras generationellt
  • Flera förnamn eller familjenamn
  • Namn som ändras baserat på livshändelser eller socialt sammanhang
  • Namn där “för” och “sista” är kulturellt meningslösa skillnader

Utforma namnarkitektur med ett enskilt fält med fullständiga namn eller en flexibel struktur med flera delar som uppfyller vanliga namnkonventioner. Undvik att göra antaganden om namnordning, arvsmönster eller kulturella normer.

Testa namnarkitektur med olika internationella namn för att säkerställa att namnfält accepterar:

  • Namn på enskilda ord (till exempel Sukarno, Cher och Teller)
  • Långa namn som överskrider vanliga fältlängdgränser
  • Namn med diakritiska tecken, apostrofer, bindestreck och blanksteg
  • Namn med icke-latinska skrivtecken (till exempel arabiska, kinesiska, kyrilliska och devanagari)

När namnvalidering avvisar en användares legitima namn upplever de systemavvisande som baseras på deras kulturella identitet.

Adressvalideringstjänster är ofta optimerade för amerikanska och västeuropeiska format och känner ofta inte igen:

  • Internationella adressformat med olika fältordning
  • Landsbygdsadresser utan gatunamn
  • Militära adresser (till exempel APO och FPO)
  • PO-boxar och alternativa leveransplatser
  • Stammarker med unika adresssystem
  • Länder med icke-latinska skript för adresskomponenter

När adressvalideringar avvisar icke-traditionella adressformat förhindrar det att konton skapas, skickas och levereras för användare vars adresser inte uppfyller förväntningarna för valideringsdatabasen.

Här är några sätt att utforma adressvalideringar med tanke på tillgänglighet:

  • Implementera tillåtande adressvalidering.
  • Acceptera friformadressinmatning om strukturerade valideringar misslyckas.
  • Lagra adresser när de anges av användare istället för att tvinga användare att göra ogiltiga korrigeringar.
  • Använd adressvalidering för att förbättra data och upptäcka dubbletter, inte för att validera adressformatering.

Istället för att blockera datainsamling direkt kan du bygga in adressverifiering i uppfyllandeprocesser där adressens precision är viktig operativt.

Antaganden om universell åtkomst för specifika kommunikationskanaler utesluter populationer med olika teknikåtkomst eller inställningar.

E-postkommunikation omfattar inte:

  • Användare utan pålitlig internetåtkomst
  • Äldre befolkningsgrupper som är mindre bekväma med att använda e-post
  • Användare i regioner där SMS eller meddelandeappar är den primära kommunikationsmetoden

Kommunikation endast för telefon utesluter:

  • Användare som är döva och har nedsatt hörsel
  • Användare utan telefonåtkomst eller de som använder delade telefoner

Utforma en omnikanalkommunikationsarkitektur som låter användare styra kanalpreferenser. Lagra föredragna kommunikationsmetoder i kontaktposter och respektera konsekvent preferenser i alla utgående kommunikationssystem. Tillhandahåll en mängd olika kommunikationsalternativ istället för att anta att enkanalsmetoder fungerar universellt.

Att samla in demografiska data för rättviseövervakning kräver noggrann arkitektur för att förhindra missbruk.

Insamling och bearbetning av demografiska data är beroende av jurisdiktion och rättsligt begränsad (i EU behandlas de i artikel 9 i GDPR som data av särskild kategori som kräver en specifik rättslig grund; i USA bygger övervakning av biasering vanligtvis på frivillig självidentifiering av EEO). Där det finns en laglig grund använder organisationer demografiska data för att:

  • Bevaka rättvisemått som är stratifierade efter skyddade grupper
  • Upptäck biasering i automatiserings- och AI-system
  • Visa efterlevnad av bestämmelser om antidiskriminering

Att samla in demografiska data skapar vissa risker:

  • Data kan användas i diskriminerande syften om åtkomstkontroller misslyckas
  • Användare kan misstro insamlingsmetoder och tillhandahålla felaktiga data
  • Insamlingen kan kännas invasiv eller diskriminerande

Arkitekt frivillig självidentifiering och utforma demografisk datainsamling med hjälp av information som är:

  • Tydligt förklarat med ett transparent syfte (till exempel rättviseövervakning eller efterlevnadsrapportering)
  • Frivilligt och innehåller alternativet “Föredra att inte svara” som alltid är tillgängligt
  • Separerad från operativa data med strikt FLS för att förhindra olämplig åtkomst
  • Aggregerad för rapportering och analys och inte kopplad till individuella beslut
  • Övervakas via Shield Event Monitoring för åtkomstmönstergranskning

Det är viktigt att dokumentera i sekretesspolicyer exakt hur demografiska data kommer att användas och inte kommer att användas. Att bryta mot user Trust genom hemlig dataanvändning kan allvarligt skada trovärdigheten, vilket kan vara svårt att återställa från.

Dataförbättring från tredje part som lägger till demografiska, firmografiska eller beteendemässiga data i Salesforce-poster kan introducera biasering genom:

  • Felaktiga slutsatser som baseras på stereotyper
  • Ofullständig täckning med luckor som korrelerar med demografi
  • Egenutvecklade algoritmer som använder okända rättviseegenskaper
  • Data som hämtas från felaktiga historiska poster

Innan du implementerar dataförbättringstjänster är det viktigt att granska:

  • Tester av leverantörers rättvisa och metoder för begränsning av biasering
  • Datatäckning och precision i demografiska grupper
  • Slutsatssmetoder och funktioner som används för att skapa förutsägelser
  • Kontraktsbegränsningar och lagringspolicyer för dataanvändning

Kom ihåg att när data från tredje part väl kommer in i din Salesforce-organisation kan det påverka beslut och skapa leverantörsintroducerad biasering som även återspeglas som en biasering i din organisation.

I Salesforce-sammanhang refererar tillgänglighet till att skapa Lightning, Visualforce och Experience Cloud-webbplatser som fungerar för användare med funktionshinder. Standardkomponenter i Lightning ger grundläggande tillgänglighet när de används korrekt. Egen utveckling och Experience Cloud-konfiguration kräver dock uttrycklig tillgänglighetsimplementering.

Lightning Design System-komponenter är utformade för att stödja WCAG 2.2 AA-efterlevnad när de används som de ska. Salesforce strävar efter—men certifierar inte—fullständig efterlevnad. Att avvika från SLDS mönster eller bygga egna komponenter utan tillgänglighetsöverväganden skapar hinder för användare med funktionshinder.

Standardkomponenter för Lightning ger inbyggd tillgänglighet. Komponenter som Lightning, Lightning, Lightning och Lightning inkluderar automatiskt rätt ARIA-attribut, etikettassociationer, tangentbordsnavigering och fokushantering. När det är möjligt, använd standardkomponenter istället för att bygga egna alternativ som ser liknande ut men kanske inte har rätt tillgänglighetsinfrastruktur.

  • Använd semantisk HTML i egna Lightning-webbkomponenter. När du bygger egna komponenter, använd semantiska HTML-element (
    ,
  • Implementera ARIA i egna komponenter. Tillämpa ARIA-landmärken, -roller och -egenskaper när semantisk HTML inte kan förmedla gränssnittsbeteende. Uppdateringar av dynamiskt innehåll kräver aria-liveregioner som meddelar ändringar av skärmläsare. Egna interaktiva komponenter behöver uttryckliga rolldefinitioner som matchar deras beteende. Lightning hanterar ARIA automatiskt. Egna komponenter kräver dock manuell ARIA-validering via skärmläsartest.
  • Test med hjälpmedelsteknik: Validera Lightning med faktiska skärmläsare (till exempel JAWS och NVDA för Windows, VoiceOver för macOS och iOS och TalkBack för Android). Baserat på Deques storskaliga studie fångar automatiserade verktyg som yxkärna upp ungefär 57 % av tillgänglighetsproblemen efter volym. De återstående problemen kräver manuella tester med hjälpmedelsteknik av personer som förstår skärmläsares navigeringsmönster.
  • Använd fokushantering i Lightning flöden. När moduler öppnas, dynamiskt innehåll läses in eller användare slutför flerstegsflöden bör du programmatiskt hantera fokus för att guida tangentbordsanvändare till nytt innehåll. Lightning och överflyttningskomponenter ger grundläggande fokushantering, men komplexa flöden behöver uttrycklig fokuslogik för att flytta fokus korrekt när innehållet ändras.

Experience Cloud-webbplatser servar externa användare—inklusive kunder, partners och offentliga målgrupper—som behöver tillgänglig design som kan behöva uppfylla kraven i ADA, Avsnitt 508 och/eller Europeiska tillgänglighetslagen (beroende på jurisdiktion, målgrupp och organisationstyp).

  • Använd tillgängliga mallar. Experience Cloud-mallar som byggts med Lightning Web Runtime (LWR) inkluderar grundläggande tillgänglighet. Standardmallar som Kundkontoportal och Hjälpcenter tillhandahåller WCAG 2.2 AA-grunder när de är korrekt konfigurerade. Egna mallar kräver uttrycklig implementering av tillgänglighet, inklusive semantisk kod, tangentbordsnavigering och skärmläsarkompatibilitet.
  • Bekräfta WCAG-efterlevnad i teman. Egna teman och varumärkta webbplatser kräver validering av färgkontrast. Upplevelsebyggarens inställningar för Tema styr färger, typografi och mellanrum. Se till att all text uppfyller 4,5:1 kontrast för normal text (under 18pt för vanlig eller under 14pt för fetstil), och 3:1 för stor text (18pt eller större för vanlig eller 14pt eller större för fetstil) och gränssnittskomponenter. Använd utvecklarverktyg för webbläsare eller kontrastkontroller online för att validera efterlevnad. Testa med webbläsarens zoom till 200% för att säkerställa att texten skalas upp utan att förlora innehåll eller funktionalitet.
  • Använd tangentbordsnavigering i navigeringsmenyer. Experience Cloud-navigeringskomponenter måste ha stöd för endast tangentbordsanvändning utan musberoende. Användare måste navigera in i och ut ur rullmenyer, megamenyer och flyout-navigering med hjälp av knapparna Tab, Enter, Escape och Arrow utan fokusfällor. Testa alla navigeringsvägar med endast tangentbordet för att validera tillgänglighet.
  • Aktivera formuläråtkomst i Experience Cloud. Associera etiketter uttryckligen med alla formulärinmatningar med rätt label-element eller aria-labelby. Enbart platshållartexten uppfyller inte tillgänglighetskraven eftersom texten försvinner så fort datainmatningen påbörjas, vilket gör att skärmläsaranvändare inte har tillräckligt, bestående sammanhang. Lightning ger inbyggd etikettassociation när de konfigureras med de etikettattribut som behövs. Egna Visualforce kräver uttrycklig association mellan etikett och indata.
  • Testa Experience Cloud-webbplatser med hjälpmedelsteknik. Innan du startar Experience Cloud-webbplatser som visas offentligt måste du utföra omfattande tillgänglighetstester med skärmläsare, endast-tangentbord-navigering och webbläsarzoom. Det är viktigt att inkludera användare med funktionshinder i användbarhetstester för att upptäcka praktiska hinder som experter ofta kan missa. Att endast testa interna Lightning utan att validera extern Experience Cloud-tillgänglighet lämnar offentliga webbplatser sårbara för tillgänglighetsklagomål och rättstvister.
  • Använd alternativ text för bilder och ikoner. Alla informativa bilder, ikoner och grafiskt innehåll i Experience Cloud kräver alt-text. Dekorativa bilder använder tom alt-text (alt=”), vilket låter skärmläsare hoppa över dem. Informativa bilder ger meningsfull alt-text som beskriver innehåll och funktion. När du skriver alt-text för ikoner, fokusera på åtgärden eller syftet med ikonen snarare än dess visuella utseende (till exempel, istället för att beskriva en förstoringsglasikon som “förstoringsglas” ska alt-texten ange sitt funktionella verktyg, som “Sök webbplats”). Vid hantering av bilder måste CMS uppmana innehållsförfattare att ange alt-text eller uttryckligen markera bilden som dekorativ (vilket anger alt=”). Detta säkerställer tillgänglighet genom att förhindra att alt-text saknas och tvingade beskrivningar för estetiska bilder.

Fullständig tangentbordsåtkomst innebär att användare kan komma åt all funktionalitet med sitt tangentbord utan att behöva använda musen eller touch-interaktion.

  • Använd logisk fokusordning på Lightning-sidor. Se till att fokusordningen följer visuell layout och interaktionsflöde. När användare trycker på Flik ska det visuella fokus flyttas genom interaktiva element i den ordning som användare förväntar sig baserat på visuell design. Lightning och Upplevelsebyggaren etablerar fokusordning baserat på komponentplacering. Egna komponenter kräver uttrycklig tabindexhantering för att säkerställa logisk fokusförlopp.
  • Använd synliga fokusindikatorer för att uppfylla kontrastkraven. Lightning Design System tillhandahåller fokusstilar för att uppfylla WCAG-kraven för de flesta komponenter. Egna komponenter kan behöva utökade fokusindikatorer för att uppfylla kontrastkravet 3:1 mot omgivande innehåll. Fokusindikatorer måste vara tydligt synliga för att låta användare med nedsatt syn navigera via tangentbordet. Ta aldrig bort fokusindikatorer med CSS (kontur: inga) utan att tillhandahålla alternativ styling med synligt fokus.
  • Använd begränsning av tangentbordsfällor i moduler och överlägg. Modella dialoger ska fånga fokus inom modulen medan den är öppen, vilket förhindrar tangentbordsanvändare från att nå dolt bakgrundsinnehåll. Fokusfällan ska släppa vid stängning av modul och returnera fokus till utlösarelementet. Inbäddat innehåll—inklusive iframes och tredjepartswidgets—får inte fånga tangentbordsfokus permanent utan en escape-mekanism.
  • Använd kortkommandon utan konflikter. Lightning tillhandahåller standardkortkommandon som dokumenteras i Salesforce-hjälpen. Egna kortkommandon måste utformas för att förhindra konflikter med standardwebbläsarkontroller och skärmläsares navigeringskommandon. I enlighet med WCAG:s framgångskriterier får kortkommandon med endast ett tecken (till exempel att trycka på en bokstav eller ett skiljetecken) inte utlösa globala åtgärder. De måste antingen begränsa aktiveringen till när en specifik komponent har aktivt fokus, eller ge användare ett sätt att stänga av eller mappa om genvägen helt.

Bygg in tillgänglighetsvalidering i CI/CD-pipelines för att hitta strukturella problem automatiskt vid varje distribuering istället för att behandla tillgänglighet som regelbundna manuella granskningar.

  • Använd sa11y för tillgänglighetstest av Lightning-webbkomponenter. Salesforces sa11y-bibliotek (@sa11y/jest-paketet) omger tillgänglighetsmotorn med axlar för att lägga till en toBeAccessible()-matchning för Jest-enhetstester. Skriv tillgänglighetstester som validerar korrekt ARIA-användning, etikettassociationer, kontrastförhållanden och semantisk kod automatiskt som en del av enhetstester. Konfigurera byggen att misslyckas när viktiga tillgänglighetsproblem upptäcks.
  • Använd Lighthouse CI för Experience Cloud. Google Lighthouse granskar webbsidors tillgänglighet, inklusive Experience Cloud-webbplatser. Integrera Lighthouse CI i distributionspipelines för att söka igenom offentliga sidor efter tillgänglighetsproblem. Konfigurera betygströsklar för att kräva lägsta tillgänglighetsbetyg innan distributionsgodkännanden.
  • Använd tillgänglighetsagenten, som är tillgänglig via Salesforce DX MCP-paketet. I MCP-kompatibla miljöer eller inom Agentforce Vibes granskar den kod mot WCAG-standarder, lyfter fram målfixar och kan skapa en hämtningsbegäran för en tekniker att granska, validera och koppla.

Biasering har funnits i deterministisk Salesforce-automatisering långt innan AI kom in i bilden. Tilldelningsregler, flödesbeslut, valideringsregler och områdesdesign kodar mänskligt omdöme som kan vidmakthålla diskriminering. Till skillnad från AI-biasering—som arkitekter granskar mycket—går automatiseringsbiasering ofta igenom ogranskad eftersom deterministisk logik känns objektiv.

  • Följ tilldelningsregler för leads och kundcase. Fördela arbetet mellan försäljnings- och serviceteam. När tilldelningslogik använder kriterier som korrelerar med skyddade egenskaper skapar automatisering systematiska skillnader i servicekvalitet och säljprojektåtkomst.
  • Tilldelningsregler som använder områdes-, postnummer- eller kontoegenskaper kan dirigera säljprojekt med högt värde oproportionerligt till specifika team medan arbete med lägre värde dirigeras någon annanstans. Om områdesgränser korrelerar med kunders demografi och kompensationsstrukturer som skiljer sig åt mellan områden skapar tilldelningsautomatisering ekonomisk diskriminering.
  • Resultat av granskningstilldelningsregler regelbundet. Beräkna tilldelningsfördelningar över områden och team som är stratifierade efter kunddemografi. Om Enterprise-konton koncentreras till specifika områden medan SMB-konton distribueras någon annanstans—och om Enterprise-områden får bättre kompensation eller resurser—kan tilldelningsregler ge orättvisa resultat som motiverar rättvisegranskning.
  • Gå igenom kompetensbaserad dirigering i flera kanaler. Detta kan påverka servicekvaliteten i alla kundpopulationer. Om dirigeringslogik underförstått förutsätter att vissa kompetenser korrelerar med kundvärde eller problemkomplexitet kan kunder få olika serviceresultat baserat på demografiska proxyvärden.

Det är viktigt att bevaka den genomsnittliga tiden det tar att hantera, lösningar vid första kontakt och kundnöjdhet över dirigeringsvägar. Skillnader kan indikera om vissa kundsegment systematiskt får mindre erfarna agenter eller färre dirigeringsalternativ.

  • Gå igenom Salesforce-flödesautomatiseringar. Att fatta beslut om godkännanden, beslut om berättigande eller beviljande av åtkomst kan koda diskriminerande logik genom till synes harmlösa verksamhetsregler. Vissa flöden skapar indirekt diskriminering när kriterierna korrelerar med skyddade egenskaper.
  • Gå igenom flödesbeslut med rättvisa i åtanke. För varje flöde som fattar följdbeslut som påverkar användare är det viktigt att fråga:
  • Vad händer med användare som inte passar den vanliga kundprofilen?
  • Korrelerar beslutskriterier med demografiska egenskaper?
  • Hanteras undantag och edge-kundcase rättvist eller missgynnar de systematiskt specifika grupper?

Det är viktigt att dokumentera logik för flödesbeslut och överväganden om rättvisa i poster för arkitekturbeslut, och låta flöden med höga insatser genomgå samma etikgranskningspolicyer som AI-system.

  • Gå igenom valideringsregler. Att förhindra datainmatning kan utesluta giltiga data från användare vars information inte matchar systemantaganden. Valideringsregler som avvisar legitima data skapar osynliga populationer. Användare vars data inte passar valideringsmönster kan inte interagera med vissa system. Valideringsfel rapporteras ofta inte eftersom användare överger sina begäranden istället för att rapportera tekniska fel. Här är flera vanliga mönster för valideringsbiasering:
  • Namnvalideringar som kräver latinska tecken kan utesluta namn med diakritiska och icke-latinska tecken.
  • Valideringar av telefonnummer använder ofta formatet USA/Väst, vilket utesluter internationella nummer och alternativa kommunikationsmetoder.
  • Adressvalideringar känner inte igen icke-standardadresser (till exempel postboxar, landsbygdsrutter, stammarker och internationella format).
  • E-postvalideringar som kräver personliga e-postadresser kan skapa en nackdel för användare som inte har personlig e-poståtkomst.
  • Testa valideringsregler med hjälp av olika data. Inkludera internationella adresser, icke-västerländska namn och alternativa telefonformat i valideringstest. Om valideringen avvisar legitima data måste du utöka valideringslogiken för att undvika att utesluta giltiga användare.
  • Gå igenom utformningen av säljområden. Kundsegmenteringsstrategier och utformningar av säljområden avgör resursallokeringen i alla kundpopulationer. När områdesgränser eller segmenteringskriterier korrelerar med demografi som resulterar i ojämlik resursallokering kan denna allokering ge diskriminerande resultat. Områdesdesigner som använder geografiska gränser korrelerar ofta med ras-, etnisk- och ekonomisk demografi på grund av bostadssegregationsmönster. Om kompensation, personalnivåer eller resursinvesteringar skiljer sig åt mellan områden kan geografi bli en mekanism för diskriminerande resursallokering.
  • Analysera områdesdemografi innan du slutför designen. Mappa kunders demografi över föreslagna områdesgränser. När demografiska koncentrationer uppstår, utvärdera om resursallokeringen är rättvis i alla områden oavsett demografisk sammansättning. Om verksamhetsmotiveringen kräver olika resursnivåer mellan områden (till exempel marknadsmognad, konkurrensintensitet och tillväxtpotential), dokumentera denna motivering uttryckligen och övervaka resultaten för att säkerställa att underförsörjda områden får lämpliga investeringsmöjligheter för att förhindra bestående skillnader.
  • Upprätthåll transparens i automatiseringslogik. Dokumentera verksamhetsregler, tilldelningskriterier och beslutslogik för flöden i beslutsposter i Salesforce Knowledge eller arkitektur. Transparent automatisering gör att rättvisa kan granskas på ett sätt som dold logik förhindrar.
  • Regelbundna granskningsresultat. Schemalägg kvartalsvisa granskningar för att analysera automatiseringsresultat som kan stratifieras efter kunders demografi. Kom ihåg att skillnader utlöser undersökningar och potentiell korrigering.
  • Det är viktigt att följa:
  • Tilldelningsfördelningar över team och områden
  • Godkännanderesultat för flöden som fattar beslut om rätt till stöd
  • Valideringsregelns avvisandefrekvens efter datamönster
  • Områdesresultat och resurstilldelning
  • Se automatisering med höga insatser ur ett etiskt perspektiv. Ämnesflöden och tilldelningsregler som påverkar anställning, kredit, serviceåtkomst eller andra följdresultat till samma etikgranskningsprocess som AI-system. Automatiseringsbiasering behöver samma nivå av granskning som algoritmisk biasering.

På Salesforce fokuserar AI-rättvisa på att använda Einstein för att validera att förutsägelser ger rättvisa resultat i alla demografiska grupper. Einstein Discovery och egen instrumentering samlar in beslutsdata med prediktiva modeller som möjliggör upptäckt av biasering. CRM Analytics-instrumentpaneler följer rättvisemått. Fältgranskningslogg och händelseövervakning samlar in beslutsdata för algoritmisk ansvarighet.

Einstein förutsägelser som påverkar följdbeslut (till exempel leadbetyg, säljprojektprognoser och kundsegmentering) kräver rättviseutvärderingar före distribution som fungerar som ett obligatoriskt motsvarande steg (liknande säkerhetsgranskningar).

Analysera alla prediktiva modellfunktioner för korrelation med skyddade egenskaper med hjälp av statistiska metoder. Ta bort eller transformera proxyfunktioner efter utvärdering av om deras prediktiva värde motiverar inkludering trots proxyeffekter.

  • Granska Salesforce CRM-data innan utbildning. Salesforce-organisationer innehåller årtionden av mänskliga beslut som baseras på historiska metoder. Om tidigare säljteam har prioriterat viss demografi lär sig Einstein Leadbetyg dessa mönster och upprätthåller dem. Innan du utbildar prediktiva modeller för historiska data är det viktigt att granska dessa data för demografiska representationsluckor och inkonsekvenser i mätningar över kundsegment.
  • Beräkna rättvisemått över demografiska grupper. Innan du distribuerar prediktiva modeller är det viktigt att beräkna demografisk paritet, lika möjligheter och olika påverkanförhållanden mellan skyddade grupper, där du har en laglig grund för att samla in och bearbeta de demografiska data som behövs. Om Einstein Leadbetyg tilldelar höga betyg till segment A 50 % av gångerna men endast 30 % av gångerna till segment B misslyckas fyra femtedelsregeln (80 %) med ett förhållande på 60 % och kräver utredning och begränsning. 80 %-siffran är en screeningutlösare, inte en laglig passning/fellinje: Fyra femtedelsregeln är en federal regel i USA för urval av anställning, och att rensa den är inte en säker hamn – en statistiskt signifikant skillnad kan motivera granskning vid högre proportioner, och andra system mäter negativa effekter annorlunda (EU:s indirekta diskrimineringslag slår till exempel på om en praxis skapar en ”särskild nackdel” utan någon fast tröskel). Kalibrera undersökningströsklar till de jurisdiktioner och användningsfall du är verksam i.
  • Samla in beslutsdata med prediktiva modeller för att upptäcka biasering. För att upptäcka biasering i prediktiva modeller som Leadbetyg och Säljprojektbetyg, samla in beslutsdata via Einstein Discovery och egen instrumentering: lagra förutsägelseinmatningar, utdata och modellversioner i spårade fält och aktivera Fältgranskningslogg. Analysera dessa data i CRM Analytics för att följa beslutsmönster över demografiska grupper över tid, och bygg instrumentpaneler som varnar när demografiska paritets- eller lika-säljprojektmått överskrider acceptabla trösklar.
  • Upptäck proxyfunktioner i prediktiva modeller. Funktioner som korrelerar med skyddade egenskaper möjliggör indirekt diskriminering även om skyddade egenskaper utesluts från modellerna.
    • Salesforce-data innehåller vanligtvis proxyfunktioner:
  • Område eller postnummer (proxy för ras, etnicitet och inkomst)
  • Kontonamnmönster (proxyvärden för organisationsstorlek och branschdemografi)
  • Tidpunkt för kommunikationsaktivitet (proxy för tidszoner, religion och vårdansvar)
  • Enhetstyp eller webbläsare från aktivitetsdata (proxyvärden för inkomstnivå)

När biasering upptäcks i Einsteins förutsägelser måste du tillämpa begränsning i lämpligt pipelinesteg (baserat på grundorsak och tekniska begränsningar).

  • Balansera data innan modellinlärning. Återbalansera Salesforce CRM-data genom översampling av underrepresenterade kundsegment eller undersampling av överrepresenterade segment innan prediktiva modeller tränas. Använd Data 360 för att aggregera data i flera organisationer för att säkerställa olika utbildningsuppsättningar. Skapande av syntetiska data kan komplettera glesa segment samtidigt som sekretess bevaras genom olika sekretesstekniker.
  • Ta bort proxyvärden i funktionsteknik. När proxyfunktioner identifieras, ersätt dem med alternativa funktioner som ger prediktiv kraft utan demografisk korrelation. Om området fungerar som demografisk proxy, överväg branschklassificering eller företagsstorlek som alternativ. Om kontonamnmönster korrelerar med demografi, använd firmografiska attribut istället.
  • Justera trösklar under efterbearbetning. Justera beslutströsklarna per demografiskt segment för att utjämna resultatresultat efter utbildningsmodeller. För sysselsättningsrelaterade beslut är detta direkt förbjudet: Avdelning VII (Civil Rights Act från 1991) anger att betyg ska justeras eller att olika brytpunkter ska användas efter skyddad klass, och ingen dokumenterad motivering gör praxis laglig. Om det inte är förbjudet, dokumentera tröskeljusteringar med affärsmotivering för differentierad behandling när förutsägelser ligger till grund för automatiserade beslut.
  • Återutbilda modeller regelbundet med hjälp av uppdaterade data. Schemalägg omskolning av modell kvartalsvis (eller när betydande datadistributionsskift inträffar). Omskolning på färska data fångar upp nya biasmönster och korrigerar avvikelser från ursprungliga rättvisebaslinjer. Återvalidera rättvisemått för varje modellversion innan produktionsdistribuering för att säkerställa att omskolning inte introducerade nya biaser.

Einstein Trust Layer samlar in uppmaningar, svar och Trust signaler för generativ AI och Agentforce funktioner, med stöd för transparens och regelefterlevnad för generativ AI. För prediktiva modeller kommer transparens och beslutshärkomst från Einstein Discovery och Model Manager, som kräver egen instrumentering för att behålla granskningsdata.

Bygg in förklarlighet i Einstein lösningar från den inledande arkitekturen istället för att eftermontera förklaringar på ogenomskinliga system efter distribuering.

  • Visa förklaringar av Einstein Discovery vid beslutspunkter. Einstein Discovery tillhandahåller förklaringar av förutsägelsefaktorer som visar vilka variabler som mest påverkar specifika förutsägelser med riktningspåverkan. Architect Lightning som visar dessa förklaringar för användare vid tidpunkten för beslutet istället för att kräva navigering för att separera CRM Analytics-instrumentpaneler. När beslut påverkar användare behöver de transparens, inte abstrakta modellprestandamått.
  • Lagerförklaringar för olika målgrupper. Ge förklaringsdjup som passar varje målgrupp:
  • Företagsanvändare: “Detta lead har höga betyg eftersom de årliga intäkterna överstiger 1 miljon dollar och engagemangsbetyget är i topp 10 %.”
  • Tekniska användare: Ge ett modellkort från Einstein Discovery funktionsvikter, egenskaper för inlärningsdata och valideringsmått.
  • Kunder: “Denna rekommendation baseras på dina senaste inköp och kunder med liknande inställningar.”
  • Revisorer: Tillhandahåll beslutshärkomst från Einstein Discovery och Modellhanteraren—modellversion, indatavärden och de faktorer som drev förutsägelsen—som samlats in genom egen instrumentering.
  • Kommunicera förtroende på lämpligt sätt. Visa förutsägelseförtroende i lämpliga termer för användare och undvik råa sannolikhetsbetyg som användare kan misstolka. Istället för att visa “73% förtroende”, kommunicera detta med hjälp av kategorier (till exempel Högt förtroende, Måttligt förtroende och Behöver granskning) med förklaringar av vad varje förtroendenivå innebär för beslutstillförlitlighet, samt vilka ytterligare granskningar som kommer att inträffa.

Upprätthåll omfattande, oföränderliga granskningskedjor som stöder ansvarighet, felsökning och efterlevnad av föreskrifter för alla AI-drivna beslut som påverkar användare.

  • Samla in prediktiva granskningsdata med rätt verktyg. Lagra granskningsdata för prediktiva modeller—förutsägelseinmatningar, utdata och modellversioner—i spårade fält med Fältgranskningslogg aktiverad. Arkitekters datalagringspolicyer för att uppfylla lagstadgade krav, som varierar beroende på bransch och jurisdiktion:
    • Lagring per förordning fastställs i reglerna för finansiella tjänster (till exempel anger FINRA-regel 4511 b en standardlagringsperiod på sex år för poster som annars inte har en specificerad lagringsperiod enligt FINRA-reglerna eller SEA-regel 17a-4).
    • Lagring av vårdjournaler styrs också av specifika regler (till exempel kräver HIPAA minst sex år för dokumentation om efterlevnad, journallagring fastställs av enskilda delstatslagar) snarare än allmänna mandat för obestämd lagring.
  • Analysera beslutsdata för prediktiva modeller med CRM Analytics. Bygg CRM Analytics-instrumentpaneler på de beslutsdata för prediktiva modeller som du samlar in (förutsägelseinmatningar, utdata och modellversioner i spårade fält) för att analysera beslutsmönster, rättvisemått och modellprestanda över tid. Skapa linser som visar förutsägelsefördelningar efter förtroendenivå, demografiskt segment och resultattyp. Konfigurera Einstein Discovery berättelser som identifierar avvikande mönster som kräver ytterligare utredning.
  • Använd fältgranskningsloggen för långsiktig lagring. Standardfälthistorik följer ändringar i 18 månader i användargränssnittet och upp till 24 månader via API. Fältgranskningsloggen låter dig behålla fälthistorik tills vidare för egna objekt som lagrar AI-beslutsdata. Den arkiverar historik efter upp till 18 månader som standard och behåller sedan de arkiverade data tills du tar bort dem. Aktivera Fältgranskningslogg för objekt som innehåller samtyckesposter, åsidosättningsbeslut och biasrapporter för att uppfylla lagstadgade lagringskrav.
  • Använd händelseövervakning för Agentforce interaktioner. Händelseövervakning samlar in åberopningsnivåhändelser för Agentforce, till exempel när åtgärder och flöden körs. Exportera händelseövervakningsdata till ett externt SIEM—standarddata för händelseloggfil via API, och underuppsättningen Händelseövervakning i realtid via plattformshändelser—för lagring som överskrider Salesforces inbyggda lagringsfönster. Bevis för manipulering beror på ett visst SIEM-beteende som tillämpar lagring en gång och åtkomstsegregation. Konfigurera SIEM-frågor för att upptäcka biasmönster i stora volymer Agentforce.
  • Granska Agentforces konversationer med Einstein Trust Layer. Einstein Trust Layer samlar in granskningsloggen för Agentforces konversationsuppmaningar och svar, som lagras i Data 360, och tillhandahåller posten på avskriftsnivå för transparens och efterlevnad av föreskrifter.

Låt oss ta en närmare titt på de möjligheter till transparens för arkitekter som finns för efterlevnad av befintliga och nya AI-föreskrifter i flera jurisdiktioner.

  • Insynskrav för EU AI Act. AI-system med hög risk enligt EU:s AI-lag kräver transparensdokumentation, teknisk dokumentation, kapacitet för mänsklig tillsyn och mått för precision/rättvisa. Granskningsloggarna för Einstein Trust Layer och modellkorten för Einstein Discovery utgör grunden för dessa krav. Dokumentmodell som utbildar datademografi, valideringsmetoder och kända begränsningar i poster för arkitekturbeslut.
  • GDPR rätt till förklaring. Dataskyddsförordningen ger registrerade i EU rätt till meningsfull information om logiken i ett beslut när beslutet endast grundas på automatiserad behandling och har rättsliga eller liknande betydande effekter. Denna rättighet följer av artiklarna 15.1 h och 22.3 i skäl 71 och förtydligades av EU-domstolen i domen i målet Dun & Bradstreet (2025). Utforma system som skapar sammanhängande förklaringar på begäran för historiska beslut inom tidsramar för registrerades åtkomstbegäranden, som varierar (beroende på jurisdiktion) mellan 15 och 45 dagar. De beslutsdata för prediktiva modeller som du samlar in – indata för förutsägelser, utdata, modellversioner och förklaringsfaktorer för Einstein Discovery – låter dig rekonstruera förklaringar när de lagras med tillräcklig lagring.
  • Algoritmiska ansvarslagar. Amerikanska lagar om algoritmisk ansvarighet på delstatsnivå kräver allt oftare konsekvensbedömningar och transparensrapportering för automatiserade beslutssystem. De beslutsdata för prediktiva modeller som du samlar in och instrumentpaneler för rättviseövervakning i CRM Analytics utgör datagrunden för dessa rapporter. Utför algoritmiska konsekvensbedömningar innan du distribuerar efterföljande AI som proaktiv efterlevnad snarare än som ett reaktivt svar på regelfrågor.

OWD, delningsregler och fältnivåsäkerhet (FLS) formar de dataåtkomstmönster som avgör vilken information användare kan granska och använda för att fatta beslut. Korrekt konfiguration förhindrar diskriminerande åtkomst till känsliga attribut och säkerställer samtidigt rättvis service.

Utforma OWDs och fältnivåsäkerhet för att begränsa åtkomst som standard. För delningsregler, använd principen om minsta privilegium (PoLP) för att endast bevilja den ytterligare åtkomst som varje roll behöver, vilket förhindrar diskriminerande beslutsfattande baserat på skyddade egenskaper.

  • Aktivera restriktiv OWD som standard. Använd privata OWD:er för objekt som innehåller känsliga kunddata och bevilja åtkomst efter rollhierarki och delningsregler. Offentliga Läsa/Skriva OWD:er gör det störande att begränsa åtkomsten senare — att skärpa standarden utlöser en omräkning av delningen och börjar gälla först efter att den är klar — snarare än omöjligt. Privata OWD med uttryckliga delningsbidrag skapar granskningsbara åtkomstmönster som stöder efterlevnad av icke-diskriminering.
  • Tillämpa fältnivåsäkerhet för känsliga attribut. Dölj känsliga fält som innehåller skyddade egenskaper (till exempel etnicitet, religion och funktionshinderstatus) från användare som inte behöver åtkomst för legitima affärssyften. Konfigurera FLS för att ta bort läsåtkomst för känsliga fält i de flesta profiler. När dessa fält behövs för specifika ändamål (till exempel mångfaldsrapportering och rimliga anpassningar), bevilja minimal åtkomst med behörighetsuppsättningar med dokumenterad verksamhetsmotivering.
  • Utforma tilldelnings- och delningsregler för rättvisa resultat. Använd tilldelningsregler, köer och Omni-Channel-dirigering för att distribuera arbete jämnt mellan områden, team och serviceagenter. Undvik manuell delning som koncentrerar säljprojekt med högt värde eller kunder med specifika användargrupper utan dokumenterad affärsmotivering. Konfigurera automatiska delningsregler baserat på objektiva kriterier (till exempel bransch, geografi och produktlinje) istället för subjektiv chefsdisposition, vilket kan aktivera biasering.
  • Tillhandahåll behörighetsuppsättningar för tillfällig åtkomst. Bevilja tillfällig åtkomst till känsliga data via behörighetsuppsättningar istället för att ändra profiler, vilket påverkar alla användare permanent. När användare behöver åtkomst till demografiska data för specifika projekt (till exempel mångfaldsanalys och boendebegäranden), tilldela behörighetsuppsättningar med dokumenterade utgångar. Schemalagda flöden kan återkalla behörighetsuppsättningar automatiskt efter definierade perioder.

Använd Shield Event Monitoring och rapporter för att upptäcka dataåtkomstmönster som indikerar potentiell diskriminering eller biasering i dataanvändning.

  • Använd Shield Event Monitoring för att granska åtkomst till känsliga data. Använd Händelseövervakning för att samla in åtkomsthändelser på objektnivå (rapportexporter, API-frågor och sidvisningar) för objekt som innehåller skyddade egenskaper eller känsliga attribut. Konfigurera sökfrågor över dessa händelser för att lyfta fram vem som öppnade objektet, när och i vilket sammanhang, och behandla avvikande mönster (till exempel plötsliga ökningar och åtkomst av oväntade användare) som utlösare för utredning.
  • Rapport om delningsregeldistributioner. Bygg rapporter som analyserar hur poster distribueras över användare, team och områden. Beräkna distributionsstatistik efter kunddemografi för att säkerställa att konton och säljprojekt med högt värde distribueras jämnt. Identifiera koncentrationer där specifika användargrupper får oproportionerlig åtkomst till värdefulla poster utan dokumenterad affärsmotivering.
  • Överträdelser av Audit CRUD och FLS. Granska granskningsloggen för inställningar för ändringar av OWD-inställningar, delningsregler, FLS-konfigurationer och behörighetsuppsättningar. Oauktoriserade ändringar av dataåtkomstkontroller kan indikera försök att komma åt känsliga data på ett olämpligt sätt. Använd transaktionssäkerhetspolicyer för att agera på händelser med hög risk och händelseövervakning i realtid (till exempel avvikande API-aktivitet, misstänkta inloggningar och stora rapport- eller listvyexporter av känsliga data). Eftersom transaktionssäkerhet endast fungerar för dessa runtimehändelser och inte för ändringar av DML eller FLS på postnivå måste du förlita dig på granskningsloggen och dokumenterade godkännanden av ändringshantering för FLS och delningsändringar.

På Salesforce innebär användaragentur att kunder och anställda behåller meningsfull kontroll över hur AI påverkar deras upplevelse. Salesforces kapacitet för samtyckeshantering, Data 360-samtycke och egna samtyckesobjekt möjliggör detaljerad kontroll över AI-interaktioner.

Utforma samtyckesspårning med Data 360-samtyckeshantering, Marketing Cloud-samtycke eller egna samtyckesobjekt som använder Fältgranskningslogg för AI-specifika samtyckeskrav.

  • Aktivera detaljerat samtycke per AI-användningsfall. Aktivera samtycke per AI-användningsfall istället för att använda ett allmänt AI-samtycke. Kunder kan samtycka till Einsteins produktrekommendationer men avböja AI-drivna kreditbeslut. Aktivera fältgranskningslogg för samtyckesobjekt för långsiktig lagring och uppfyllande av lagstadgade krav. Utforma egna samtyckesobjekt med fält som följer:
  • Samtyckessyfte (till exempel Einstein Leadbetyg, Einstein Svarsrekommendationer och Einstein Rekommendationsbyggare)
  • Datum och beviljandemetod för samtycke (till exempel webbformulär, API, telefon och e-post)
  • Datum för återkallande av samtycke (om tillämpligt)
  • Relaterad användare eller kontakt-ID
  • Använd Data 360-samtycke för personanpassning. Använd samtyckeshantering för Data 360 för Einstein Personanpassning. Data 360 tar in och lagrar samtyckespreferenser från system uppströms via anslutare som är mappade till datamodellen för sekretess, vilket låter dig använda dessa samtyckesattribut som filterkriterier i segmentering och vid aktivering. Mappa samtyckesattribut till specifika AI-användningsfall för att låta användare avböja personanpassning samtidigt som de behåller kärntjänsterna
  • Aktivera samtyckesintegrering i Marketing Cloud. Integrera Marketing Cloud-samtycke med Einstein Meddelandeinsikter och AI-drivna marknadsföringsfunktioner. Respektera prenumerationsstatus och samtycke för Marketing Cloud i all AI-driven kommunikation.

Ge meningsfulla avböjanden från AI-drivna funktioner med tillgängliga kontroller som respekterar användarpreferenser via mänskliga alternativ av jämförbar kvalitet.

  • Tillhandahåll tillgängliga avböjanden i profilinställningar. Låt användare avböja AI-drivna interaktioner via tillgängliga inställningskontroller i Experience Cloud-profilinställningar eller Mina inställningar i interna appar. Ge tydliga beskrivningar av vad varje avböjande innebär och den alternativa upplevelse användare kommer att få när de avböjer. Lagra inställningar i poster för Användare eller Kontakt.
  • Tillhandahåll beständiga inställningsalternativ över kanaler. Lagra AI-preferenser i användar- eller kontaktposter för att säkerställa enhetlighet över kanaler (till exempel webb, mobil, telefon och e-post). Sökfrågepreferenser konsekvent i alla interaktionsflöden för att förhindra att användare upprepade gånger måste hävda preferenser i olika kanaler.

Etisk AI-styrning tillhandahåller organisatoriska strukturer som hjälper till att säkerställa att rättvisa kvarstår när modeller utvecklas, dataskift och användningsfall utökas. Utan styrning försämras inledande rättviseinsatser allt eftersom organisationens uppmärksamhet flyttas.

Upprätta obligatorisk dokumentation och gå igenom kontrollpunkter innan Einstein distribueras. Tänk på detta som en grind som är lika viktig som säkerhetsgranskningar.

  • Tillhandahåll modelldokumentation. Lagra modelldokumentation i Salesforce med ett eget modellobjekt, eller Salesforce Files som är bifogade till projekt för att aktivera sökbarhet och versionshantering. Dokumentera varje prediktiv produktionsmodell med hjälp av:
  • Utbildning av datademografi och kända representationsluckor (för kundutbildade prediktiva modeller som Einstein Discovery och Förutsägelsebyggaren)
  • Mått för rättvisa före distribution som beräknas efter demografisk grupp
  • Avsedd användning och känd olämplig användning
  • Strategier för begränsning av biasering som tillämpas under utveckling
  • Trösklar för rättviseövervakning och varning
  • Krav på mänsklig tillsyn och godkännandeflöden
  • Granska scheman och ansvariga parter
  • Regleringsöverväganden och placering av efterlevnad
  • Aktivera rättvisegrindar för fördistribuering. Modeller som misslyckas med något grindtest får inte fortsätta till produktion. Behandla rättvisegrindar med samma noggrannhet som säkerhetsgrindar. Med andra ord har de behörighet att blockera distribueringar. Innan du distribuerar Einstein förutsägelser till produktion måste du:
  • Gå igenom granskningar av utbildningsdata. Alla representationsluckor måste analyseras och dokumenteras.
  • Granska rättvisemått (till exempel demografisk paritet, lika möjligheter och olika påverkan måste beräknas och bekräftas för att uppfylla trösklarna).
  • Gå igenom konsekvensbedömningar. Utvärdera potentiell skada i alla påverkade populationer.
  • Utforma med mänsklig tillsyn. Alla omflyttningsmönster, godkännandeflöden och åsidosättningsmekanismer måste vara korrekt utformade och testade.
  • Slutför en transparensgranskning. Förklaringsmöjligheter måste valideras för alla beslutstyper.
  • Fullständig dokumentation. Alla obligatoriska artefakter för modelldokumentation måste godkännas.

Etablera granskningsprocesser för AI-program med höga insatser som ger korsfunktionell tillsyn och har verkställande befogenheter.

  • Granska styrelsens sammansättning. Inkludera tekniska experter (till exempel arkitekter och dataforskare), affärsintressenter (till exempel produktägare och operativ personal), juridiska rådgivare, sekretessspecialister och representanter från berörda diskussionsgrupper (om möjligt). Kom ihåg att olika perspektiv lyfter fram rättviseproblem som homogena grupper ofta missar.
  • Gå igenom alla utlösare som kräver godkännande av etiknämnden. Definiera vilka AI-användningsfall som kräver etisk granskning innan distribuering:
  • Beslut som påverkar anställning, kredit, bostad, sjukvård eller juridiska rättigheter
  • Automatiserade system som påverkar fler än 10 000 användare eller transaktioner per år
  • AI-program som använder känsliga personuppgifter, inklusive hälsodata, ekonomiska data eller demografiska data
  • Nya användningsfall som inte har ett etablerat organisationsprejudikat
  • System där potentiell biasering kan orsaka betydande skada för individer eller grupper
  • Gå igenom och avgör vem som har behörighet att blockera distribueringar. Etikprövningsnämnder bör ha befogenhet att kräva ändringar, införa övervakningsvillkor eller blockera distribueringar som inte följer etiska standarder. Enbart rådgivande granskningar (utan verkställande myndighet) kan begränsa styrningsprocessens effektivitet. Dokumentera alla granskningar i Salesforces egna objekt som följer: programnamn, granskningsdatum, problem som tagits upp, begränsningskrav och godkännandevillkor.

Rättviseövervakning är en pågående process som kräver kontinuerlig uppmärksamhet för att upptäcka biasdrift när datadistributioner ändras och användarpopulationer ändras.

  • Skapa CRM Analytics-instrumentpaneler för rättvisa. Bygg instrumentpaneler som följer rättvisemått med hjälp av de beslutsdata för prediktiva modeller som du samlar in. Bevaka demografisk paritet, lika möjligheter, förhållanden med disparat påverkan och mått med förutsägelsekvalitet efter kundsegment. Konfigurera CRM Analytics-varningar som utlöses när rättvisemått bryter mot definierade tröskelvärden och kräver en utredning.
  • Aktivera egen övervakning av rättvisesignaler. Bygg egen rättvisebevakning för att upptäcka signaler (till exempel plötsliga ändringar i beslutsfördelningar efter demografisk grupp, ökningar i biasrelaterade kundcaseposter eller försämringar i modellprestanda för specifika populationer).
  • Schemalägg rättvisegranskningar. Utföra omfattande, kvartalsvisa rättviserevisioner för AI-system med höga insatser (till exempel kredit, anställning och hälsovård) och halvårsvisa revisioner för system med lägre insatser (till exempel rekommendationer och personanpassning). Revisioner bör undersöka aktuella rättvisemått, granska åsidosättningsmönster i godkännandehistorik, analysera användarfeedback och biasrapporter och validera att styrningskontroller förblir effektiva.
  • Implementera incidentsvar för rättvisefel. Upprätta tydliga processer som dokumenteras i Salesforce Knowledge med information om hur biasering ska hanteras när det upptäcks:
  • Omedelbart: Bedöm allvarlighetsgraden och omfattningen genom att fråga beslutsdata för prediktiva modeller i CRM Analytics. Om incidenten är allvarlig, avbryt allt automatiserat beslutsfattande i väntan på en utredning.
  • Kortsiktigt: Implementera tillfälliga begränsningsstrategier (till exempel ökad mänsklig tillsyn via justerade förtroendetrösklar, funktionsinaktivering eller fullständig agentavstängning).
  • Undersökning: Slutför en grundorsaksanalys (RCA) för att identifiera hur biaseringen kom in i systemet eller utvecklades. Under RCA, analysera utbildningsdata, modellversioner och konfigurationsändringar via fältgranskningsloggen.
  • Sanering: Implementera en permanent fix via datakorrigering, modellomskolning eller processändringar.
  • Meddelande: Meddela berörda användare via kundcase, e-post eller Experience Cloud-meddelanden.
  • Förebyggande: Processändringar för att förhindra upprepning och dokumentera förebyggande metoder i runbooks.

Använd denna checklista under arkitekturgranskningar, innan produktionsdistribuering och regelbundet för löpande utvärdering.

Datakvalitet och representativ rättvisa

  • Gör fält valfria där en process kan fungera utan dessa data och utforma processer längre ner för att hantera värden som saknas, så att användare som inte kan tillhandahålla information (e-post, SSN, gatuadress) inte utesluts.
  • Arkitektnamnfält som ett enskilt fullständigt namnfält eller en flexibel struktur med flera delar som accepterar mononymer, icke-latinska skrivtecken, diakritiska tecken och långa namn, istället för att anta västerländsk för-/efternamnordning.
  • Implementera tillåtande adressvalidering som accepterar fritt format och internationella format, lagrar adresser som de angetts istället för att blockera postskapande för ett format som inte matchar.
  • Lagra inställningar för kommunikationskanaler i kontaktposter och stödja omnikanalalternativ (e-post, SMS, telefon, post, chatt, röst) istället för att anta att en enskild kanal når alla användare.
  • Samla in demografiska data genom frivillig självidentifiering med alternativet “Föredra att inte svara”, lagrat separat under Privat OWD med FLS, aggregerat för rapportering och bevakat via Shield Event Monitoring.
  • Granska tredjepartsleverantörer för berikning för rättvisetester, demografisk täckning och härledningsmetodik innan du lägger till demografiska eller beteendemässiga data i poster.

Tillgänglighet och inkluderande design

  • Använd Lightning Design System-komponenter som är utformade för att stödja tillgänglighet för WCAG 2.2 AA. Kom ihåg att Salesforce strävar efter efterlevnad, men att komponenter fortfarande kräver korrekt användning.
  • Validera egna Lightning med skärmläsartest (till exempel JAWS, NVDA och VoiceOver).
  • Se till att fullständig tangentbordsnavigering finns på Lightning och Experience Cloud-webbplatser utan musberoende.
  • Kontrollera att kontrastförhållandet uppfyller 4,5:1 för normal text med hjälp av webbläsarens utvecklingsverktyg eller kontrastkontroller.
  • Integrera sa11y- eller Lighthouse-åtkomstskanning i CI/CD-pipeline som misslyckas bygger på viktiga problem.
  • Testa Experience Cloud-webbplatser med hjälpmedelsteknik innan offentlig lansering.
  • Verifiera hörselfeedback genom att bekräfta att alla dynamiska ändringar (till exempel fellägen, läsa in spinnare eller expandera menyer) är tydligt tillkännagivna och det talade innehållet matchar det visuella syftet i användargränssnittet.

Rättvisa i Salesforce Automatisering

  • Gå igenom tilldelnings- och dirigeringsregler för korrelation med skyddade egenskaper som kan koncentrera positiva eller negativa resultat till specifika demografiska grupper.
  • Granskningsflöde och beslutslogik för processautomatisering för biasering, dokumentera verksamhetsregler och kriterier i Salesforce Knowledge eller beslutsposter för arkitektur.
  • Utvärdera valideringsregler för avvisanderesultat som påverkar specifika datamönster eller populationer oproportionerligt.
  • Analysera områdes- och segmenteringsdesigner för demografisk korrelation, dokumentera uttrycklig verksamhetsmotivering och övervaka underförsörjda områden för rättvis resursallokering.
  • Utsätt flöden och tilldelningsregler med höga insatser (anställning, kredit, serviceåtkomst) för samma etikgranskningsprocess som AI-system, och schemalägg kvartalsvisa revisioner av automatiseringsresultat stratifierade efter demografi.

AI-rättvisa och biasdetektering

  • Granska Salesforce CRM-data för demografiska representationsluckor innan utbildning i prediktiva modeller.
  • Beräkna demografisk paritet, lika möjligheter och olika påverkanförhållanden per demografisk grupp innan distribuering.
  • Implementera rättviseutvärderingar som en obligatorisk distributionsgrind (tänk på detta som likvärdigt med en säkerhetsgranskning).
  • Bygg CRM Analytics-instrumentpaneler som följer rättvisemått med hjälp av beslutsdata från prediktiva modeller som samlats in med fältgranskningsloggen.
  • Analysera prediktiva modellfunktioner för proxykorrelation med skyddade egenskaper (till exempel namnmönster för områden och konton).
  • Schemalägg omfattande, kvartalsvisa rättvisegranskningar för alla AI-system med höga insatser.

Insyn och granskningsbarhet

  • Visa förklaringar av Einstein Discovery vid beslutspunkter i Lightning.
  • Konfigurera Einstein Trust Layer-granskningar med lagringsmetoder som uppfyller lagstadgade krav.
  • Aktivera Fältgranskningslogg för alla egna objekt som lagrar AI-beslutsdata för långsiktig lagring.
  • Exportera händelseövervakningsdata till ett externt SIEM – händelseloggfildata via API, och händelser för händelseövervakning i realtid via plattformshändelser – för lagring som överskrider inbyggd lagring, med SIEM-kontroller på skrivsidan för bevis för manipulation.
  • Tillhandahåll användaranpassad förtroendekommunikation (till exempel Hög, Måttlig och Låg) istället för råa sannolikheter.

Mänsklig tillsyn med Salesforce Automatisering

  • Konfigurera förtroendebaserade omflyttningströsklar i flöden och dirigera förutsägelser med lågt förtroende till mänsklig granskning.
  • Använd Salesforces godkännandeprocesser för beslut med höga insatser som kräver granskningskedjor i flera steg.
  • Integrera Agentforce och Omni-Channel-dirigering för att möjliggöra sömlös omflyttning till mänskliga agenter.
  • Tillhandahåll alternativet “Anslut till mänsklig agent” i Agentforces gränssnitt för att respektera användaragentur.
  • Kräv dokumenterad logik och spårning av godkännandehistorik för Agentforce som samlas in i egna fält.

Icke-diskriminering med dataåtkomstkontroller

  • Aktivera Privat OWD och bevilja sedan ytterligare åtkomst via rollhierarki och delningsregler.
  • Konfigurera fältnivåsäkerhet för att dölja känsliga demografiska fält från användare som inte behöver åtkomst.
  • Övervaka åtkomsthändelser på objektnivå (rapportexporter och API-frågor) för känsliga data via Shield Event Monitoring och analysera dem för avvikande åtkomstmönster.
  • Bygg rapporter som analyserar delningsregeldistributioner för att säkerställa rättvis postallokering över områden.
  • Granska granskningsloggen för oauktoriserade ändringar av OWD, delningsregel eller FLS-konfiguration.

Användarorgan och samtycke

  • Utforma egna samtyckesobjekt med Fältgranskningslogg för att följa detaljerat AI-samtycke per användningsfall.
  • Integrera samtycke från Data 360 eller Marketing Cloud med Einstein Personanpassning och Agentforce.
  • Lagra AI-preferenser i användar- eller kontaktposter för att säkerställa enhetlighet över kanaler (till exempel webb, mobil och telefon).
  • Tillhandahåll tillgängliga avböjanden i profilinställningar och mänskliga alternativ via Omni-Channel-dirigering.
  • Fråga samtyckesposter i flöde innan Einstein eller Agentforce påverkar användare.

Etisk AI-styrning

  • Dokumentera alla prediktiva produktionsmodeller, inklusive rättvisemått och begränsningsstrategier. För kundutbildade prediktiva modeller (som Einstein Discovery och Förutsägelsebyggaren), dokumentera även demografi för utbildningsdata.
  • Upprätta obligatoriska grindar för rättvisa innan distribution som blockerar distribution tills alla rättvisekriterier uppfylls.
  • Skapa en AI-etikgranskningsnämnd som verkställande myndighet för alla AI-program med höga insatser.
  • Bygg CRM Analytics-instrumentpaneler för att bevaka rättvisemått i en schemalagd kadens via CRM Analytics-varningar.
  • Definiera incidentsvarsprocesser för rättvisefel och dokumentera processen i Salesforce Knowledge.
  • Schemalägg kvartalsvisa rättvisegranskningar som analyserar åsidosättningsmönster och användarfeedback för alla system med höga insatser.

Dela din feedback om det välarkitektoniska ramverket.