Rimelig

Rimelig

I Salesforce-arkitekturer betyder rimelighed opbygning af løsninger, der tjener brugere på en rimelig måde gennem tilgængelige grænseflader, biasregistrering og -reduktion, gennemsigtige beslutninger og etisk ledelse. Einsteins forudsigelser påvirker resultater, der påvirker kunder og medarbejdere, hvilket betyder, at arkitekter skal designe systemer, der producerer rimelige resultater på tværs af demografiske grupper, samtidig med at de forbliver tilgængelige for brugere med handicap.

Salesforce leverer platformsfunktioner, der er designet til fairness, og vi stræber efter at overholde WCAG 2.2 AA. Når det bruges korrekt, leverer Salesforce Lightning Design System (SLDS) komponenter, der er designet til at understøtte dette mål. Lad os se nærmere på hver komponent.

  • Shield Platform Encryption beskytter følsomme attributter som demografiske data, og Begivenhedsovervågning giver de revisionsspor, der understøtter gennemsigtig datahåndtering.
  • Einstein Trust Layer (ETL) registrerer et sikkert revisionsspor for generative AI-meddelelser og -svar til overvågnings- og compliancemål.
  • Experience Cloud indeholder tilgængelighedskontroller.
  • Feltrevisionssporet leverer langsigtet bevarelse af dataændringshistorik på feltniveau, hvilket understøtter algoritmisk ansvarlighed, når AI-beslutningsdata lagres i sporede felter.

Disse funktioner hjælper med til at sænke de driftsmæssige omkostninger for Salesforce Fairness-praksisser.

I Salesforce fungerer rimelighed på tværs af tre dimensioner for at levere løsninger. Inkluderende design hjælper med at gøre Lightning (LWC), Visualforce og Experience Cloud-lokaliteter fuldt tilgængelige – med problemfri tastaturnavigation, skærmlæserkompatibilitet og indstillinger for kognitiv design. AI-fairnesspraksisser hjælper Einstein med at oprette rimelige resultater ved brug af biasregistrering, forskellige træningsdata og kontinuerlig overvågning. Styring leverer processer og kontroller til at opretholde rimelighed, efterhånden som modeller udvikles og anvendelsessituationer udvides.

Forsinkelse af rimelighed skaber sammensætningsrisiko. Ikke tilgængelige Experience Cloud-lokaliteter kan udsætte organisationer for retssager vedrørende American Disability Act (ADA) og, for føderale myndigheder og deres leverandører, overtrædelser af overholdelse af afsnit 508. Afhængig af systemets risikoklassificering og nye algoritmiske ansvarsregler kan Einstein-forudsigelser være i strid med kravene i EU AI Act. Kun automatiserede AI-drevne beslutninger med juridiske eller tilsvarende væsentlige virkninger, der mangler meningsfuld information om beslutningslogikken, kan krænke GDPR-artikel 22 og artikel 15, stk. 1, litra h).

Organisationer, der er arkitekter af retfærdighed, har en tendens til at reducere forudsigelig skade for de kunder, medarbejdere og fællesskaber, der påvirkes af deres systemer. Fejl i retfærdighed kan forårsage materiel skade for påvirkede enkeltpersoner – herunder økonomisk skade, afviste salgsmuligheder, følelsesmæssig nød og styrkelse af systemisk diskrimination. Bestemmelsesjustering har en tendens til at følge efter at betjene påvirkede enkeltpersoner korrekt.

Brug disse principper til at guide dine arkitektoniske beslutninger for fairness på platformen.

  • Design til Lightning-tilgængelighedsmønstre. Når du bygger, skal du bruge Lightning Design System og Lightning Web-standardkomponenter, der er designet til at understøtte WCAG 2.2 AA-tilgængelighed, når det er muligt. Når du bygger med SLDS, bruger du et bibliotek, hvor tilgængelighed er et kernet designprincip. SLDS kontrolleres for tastaturtilgængelighed og kompatibilitet med støttende teknologi, og mange inkluderer et tilgængelighedsafsnit med udviklertips. Hvis der kræves en tilpasset komponent, skal eksplicit implementering af Accessible Rich Internet Applications (WAI-ARIA), semantisk HTML og tastaturnavigationsmønstre valideres gennem støttende teknologitest.
  • Reducer og overvåg bias med de rigtige værktøjer til hver modeltype. Valider AI-output for rimelige resultater på tværs af demografiske grupper før implementering og kontinuerligt i produktion. For forudsigelsesmodeller skal du registrere beslutningsdata gennem Einstein Discovery og tilpasset instrumentering og analysere dem i CRM Analytics for at måle rimelighedsmetrikker. For generative AI- og Agentforce skal du bruge Einstein Trust Layer-revisionssporet (ETL) for meddelelser og svar. Dokumenter beslutninger for at opfylde krav til regulerende gennemsigtighed.
  • Bruge Shield Platform Encryption til databeskyttelseskontroller. Brug Shield Platform Encryption med deterministiske ordninger til følsomme attributter, der kræver exact-match-forespørgsler, samtidig med at personlige data beskyttes. Distribuer begivenhedsovervågning logges til et eksternt SIEM-system (Security Information and Event Management) for at understøtte revisionsspor, der viser, at der er fejl – når SIEM håndhæver skrivebeskyttet lagring og adgangssegregering, der overskrider Salesforce-oprindelige bevarelsesvinduer for krævede bestemmelser.
  • Design gennemgangsarbejdsflows for forudsigelser med høje satser. Konfigurer godkendelsesprocesser og gennemgangsmekanismer i Salesforce-forløb for at sikre, at Einstein, der påvirker konsekvensmæssige beslutninger, modtager relevant menneskelig gennemgang. Brug konfidenstærskler og forretningsregler til at bestemme, hvornår forudsigelser kræver validering, før der handles.
  • Anvend organisationsstandarder (OWD) og sikkerhed på feltniveau (FLS) for ikke at diskriminere. Arkitekter dataadgangsmønstre ved brug af OWD og FLS for at begrænse adgang som standard, og tildel kun den yderligere adgang, som hver rolle har brug for, ved brug af delingsregler. Undgå at tildele profiler overdreven adgang, der kan vise følsomme attributter og aktivere diskriminerende beslutningstagning.
  • Aktiver brugerbureau gennem platformssamtykke. Brug samtykkestyringsfunktioner i Data 360 eller tilpassede samtykkeobjekter med feltrevisionsspor til at spore detaljeret AI-samtykke pr. anvendelsessituation. Gør det muligt for brugere at framelde sig AI-styrede funktioner og levere menneskelige alternativer (når det er muligt).

Beslutninger i dataarkitekturen bestemmer, hvilke populationer der bliver synlige – og usynlige – i Salesforce-systemer. Dårlig datakvalitet er ikke kun et teknisk problem. Det bliver et rimelighedsproblem, når datamangler systematisk nedsætter specifikke demografiske grupper.

  • Gennemse påkrævede felter for datatilgængelighed. Når påkrævede felter forudsætter tilgængelighed af oplysninger, der varierer på tværs af demografier, bliver datafuldstændighed diskriminerende. Brugere, der ikke kan angive de krævede oplysninger, bliver usynlige i systemer, der afviser ufuldstændige registreringer.
    • Krævning af mailadresser udelader udfyldninger, der ikke har pålidelig internetadgang eller personlige mailadresser.
    • Krævning af amerikanske SSN (Social Security Numbers) udelader internationale kunder og nyligt indvandrede, der endnu ikke har fået udstedt et SSN.
    • Krævning af gadeadresser udelader hjemløse og brugere med ikke-traditionelle adresser.
  • Gennemse forretningsjusteringer for påkrævede felter. For hvert påkrævet felt er det vigtigt at dokumentere, hvorfor oplysningerne er obligatoriske i modsætning til valgfri. Hvis processer kan fungere uden bestemte data via alternative tilgange, skal du gøre disse felter valgfri og designe systemer til at håndtere manglende værdier på en god måde. Dette hjælper med til at sikre, at brugere, der ikke kan angive sådanne data, ikke udelades.

Navnefelter, der følger vestlige navngivningskonventioner (fornavn, efternavn), kan ekskludere kulturer med forskellige navngivningspraksisser.

Mange kulturer bruger:

  • Enkeltnavne – eller mononymer – uden efternavne
  • Patronymiske systemer, hvor “efternavn” ændres generelt
  • Flere navne eller familiens navne
  • Navne, der ændres baseret på livsbegivenheder eller social kontekst
  • Navne, hvor “første” og “sidste” er kulturelt meningsløse forskelle

Design navnearkitektur ved brug af et enkelt felt med fuldt navn eller en fleksibel struktur med flere dele, der tager højde for almindelige navnekonventioner. Undgå antagelser om navnearrangering, overtagelsesmønstre eller kulturelle normer.

Test navnearkitektur ved brug af forskellige internationale navne for at sikre, at navnefelter accepterer:

  • Navne på enkelt ord (f.eks. Sukarno, Cher og Teller)
  • Lange navne, der overskrider grænserne for almindelig feltlængde
  • Navne med diakritikker, apostrofer, bindestreger og mellemrum
  • Navne med ikke-latinske scripts (f.eks. arabisk, kinesisk, cyrillisk og Devanagari)

Når navnevalidering afviser en brugers gyldige navn, oplever de systemafvisning, der er baseret på deres kulturelle identitet.

Adressevalideringstjenester optimeres ofte for amerikanske og vesteuropæiske formater og genkender ofte ikke:

  • Internationale adresseformater med forskellig feltrækkefølge
  • Landdistrikter uden gadenavne
  • Militære adresser (f.eks. APO og FPO)
  • PO-bokse og alternative leveringsplaceringer
  • Stammeområder med entydige adressesystemer
  • Lande med ikke-latinske scripts for adressekomponenter

Når adressevalideringer afviser ikke-traditionelle adresseformater, forhindrer det kontooprettelse, forsendelse og servicelevering for brugere, hvis adresser ikke matcher forventningerne til valideringsdatabasen.

Her er nogle få måder, hvorpå du kan designe adressevalideringer med tanke på tilgængelighed:

  • Implementer validering af tilladelsesadresse.
  • Accepter adresseindtastning i frit format, når strukturerede valideringer mislykkes.
  • Gem adresser, som de indtastes af brugere, i stedet for at tvinge brugere til at foretage ugyldige rettelser.
  • Brug adressevalidering til databerigelse og dubletregistrering, ikke til at validere adresseformatering.

I stedet for at blokere dataregistreringer på forhånd, kan du opbygge adressebekræftelse i fuldførelsesprocesser, hvor nøjagtigheden af adressen betyder noget operativt.

Universelle adgangsforudsætninger for specifikke kommunikationskanaler udelader populationer med forskellig teknologiadgang eller præferencer.

Kun mail-kommunikation udelader:

  • Brugere uden pålidelig internetadgang
  • Ældre populationer, der er mindre trygge ved brug af mail
  • Brugere i områder, hvor SMS- eller meddelelsesapps er den primære kommunikationsmetode

Kun telefonkommunikation udelader:

  • Brugere, der er døve og dårlige til at høre
  • Brugere uden telefonadgang, eller dem, der bruger delte telefoner

Design omnichannel-kommunikationsarkitektur, der tillader brugere at kontrollere kanalpræferencer. Gem foretrukne kommunikationsmetoder i kontaktregistreringer, og respekter ensartede præferencer på tværs af alle udgående kommunikationssystemer. Angiv en række kommunikationsalternativer i stedet for at antage, at single-channel-metoder fungerer universelt.

Indsamling af demografiske data til fairnessovervågning kræver omhyggelig arkitektur for at forhindre misbrug.

Indsamling og behandling af demografiske data er juridisk afhængig og juridisk begrænset (i EU behandler artikel 9 GDPR dem som særlige kategorier af data, der kræver et specifikt retsgrundlag; i USA er biasovervågning typisk baseret på frivillig EEO-selvidentifikation). Hvor der findes et lovligt grundlag, bruger organisationer demografiske data til at:

  • Overvåg rimelighedsmetrikker, der er stratificeret efter beskyttede grupper
  • Registrer bias i automatisering og AI-systemer
  • Demonstrere overholdelse af bestemmelser med anti-diskriminationskrav

Indsamling af demografiske data skaber visse risici:

  • Data kan bruges til diskriminerende formål, hvis adgangskontroller mislykkes
  • Brugere kan have mistillid til indsamlingsmetoder og angive unøjagtige data
  • Samling kan føles invasiv eller diskriminerende

Opbyg frivillig selvidentifikation, og design demografisk datasamling ved brug af oplysninger, der er:

  • Klart forklaret med et gennemsigtigt formål (f.eks. fairnessovervågning eller overensstemmelsesrapportering)
  • Frivilligt og inkluderer en “Præferer ikke at svare”-indstilling, der altid er tilgængelig
  • Adskilt fra driftsmæssige data med streng FLS for at forhindre upassende adgang
  • Aggregeres til rapportering og analyser og er ikke linket til individuelle beslutninger
  • Overvåget via Shield-begivenhedsovervågning for adgangsmønsterrevision

Det er vigtigt at dokumentere i politikker for beskyttelse af personlige oplysninger præcis, hvordan demografiske data bruges og ikke bruges. Overtrædelse af bruger Trust gennem uafsløret brug af data kan alvorligt skade troværdigheden, som kan være vanskeligt at komme tilbage fra.

Databerigelse fra tredjepart, der føjer demografiske, firmografiske eller adfærdsmæssige data til Salesforce-registreringer, kan introducere bias gennem:

  • Ukorrekte konklusioner, der er baseret på stereotyper
  • Ufuldstændig dækning med mangler, der er forbundet med demografi
  • Egnede algoritmer, der bruger ukendte fairness-egenskaber
  • Data, der stammer fra delvise historiske registreringer

Før du implementerer databerigelsestjenester, er det vigtigt at overvåge:

  • Praksisser for udbyderens fairness-test og biasbegrænsning
  • Datadækning og nøjagtighed på tværs af demografiske grupper
  • Hent metoder og funktioner, der bruges til at oprette forudsigelser
  • Begrænsninger for kontraktmæssig dataanvendelse og bevarelsespolitikker

Husk på, at når tredjepartsdata kommer ind i din Salesforce-organisation, kan det påvirke beslutninger og skabe leverandørintroduceret bias, der også afspejles som en bias i din organisation.

I Salesforce-kontekster henviser tilgængelighed til arkitektur af Lightning, Visualforce og Experience Cloud-lokaliteter, der fungerer for brugere med handicap. Lightning giver basistilgængelighed, når de bruges korrekt. Men tilpasset udvikling og Experience Cloud-konfiguration kræver eksplicit tilgængelighedsimplementering.

Lightning Design System-komponenter er designet til at understøtte WCAG 2.2 AA-overensstemmelse, når de bruges som designet. Salesforce stræber efter – men certificerer ikke – fuld overensstemmelse. Afvigelse fra SLDS eller opbygning af tilpassede komponenter uden tilgængelighedsovervejelser opretter hindringer for brugere med handicap.

Lightning giver indbygget tilgængelighed. Komponenter som Lightning, Lightning, Lightning og Lightning inkluderer automatisk korrekte ARIA-attributter, betegnelsestilknytninger, tastaturnavigation og fokusstyring. Når det er muligt, skal du bruge standardkomponenter i stedet for at opbygge tilpassede alternativer, der ligner hinanden, men som mangler den relevante tilgængelighedsinfrastruktur.

  • Brug semantisk HTML i tilpassede Lightning-webkomponenter. Når du opbygger tilpassede komponenter, skal du bruge semantiske HTML-elementer (
    ,
  • Implementer ARIA i tilpassede komponenter. Anvend ARIA-mærker, roller og egenskaber, når semantisk HTML ikke kan formidle grænsefladeadfærd. Dynamiske indholdsopdateringer kræver aria-live-områder, der annoncerer ændringer til skærmlæsere. Tilpassede interaktive komponenter skal have eksplicitte rolledefinitioner, der matcher deres adfærd. Lightning håndterer ARIA automatisk. Men tilpassede komponenter kræver manuel ARIA-validering via skærmlæsertest.
  • Test med støttende teknologi: Valider Lightning ved brug af faktiske skærmlæsere (f.eks. JAWS og NVDA til Windows, VoiceOver til macOS og iOS og TalkBack til Android). Baseret på Deques storskalaundersøgelse fanger automatiserede værktøjer som axe-core ca. 57 % af tilgængelighedsproblemer efter mængde. De resterende problemer kræver manuel test med støttende teknologi af personer, der forstår navigationsmønstre for skærmlæsere.
  • Brug fokusstyring i Lightning-forløb. Når modaler åbnes, dynamisk indhold indlæses, eller brugere fuldfører forløb med flere trin, skal du programmeringsmæssigt administrere fokus for at guide tastaturbrugere til nyt indhold. Lightning og pop over-komponenter giver grundlæggende fokusstyring, men komplekse forløb skal have eksplicit fokuslogik for at flytte fokus korrekt, efterhånden som indholdet ændres.

Experience Cloud-lokaliteter tjener eksterne brugere – herunder kunder, partnere og offentlige målgrupper – der kræver tilgængeligt design, der muligvis skal opfylde kravene i ADA, Section 508 og/eller European Accessibility Act (afhængigt af jurisdiktion, målgruppe og organisationstype).

  • Brug tilgængelige skabeloner. Experience Cloud-skabeloner, der er opbygget ved brug af Lightning Web Runtime (LWR), inkluderer basistilgængelighed. Standardskabeloner som Kundekontoportal og hjælpecenter giver WCAG 2.2 AA-grundlag, når de er konfigureret korrekt. Tilpassede skabeloner kræver eksplicit tilgængelighedsimplementering, herunder semantisk kodning, tastaturnavigation og skærmlæserkompatibilitet.
  • Bekræft WCAG-overensstemmelse i temaer. Tilpassede temaer og brandede lokaliteter kræver validering af farvekontrast. Indstillinger for Oplevelseskonstruktør-tema kontrollerer farver, typografi og afstand. Sørg for, at al tekst opfylder 4,5:1 kontrast for normal tekst (under 18pt for almindelig eller under 14pt for fed) og 3:1 for stor tekst (18pt eller større for almindelig eller 14pt eller større for fed) og brugergrænsefladekomponenter. Brug browserudviklerværktøjer eller onlinekontrolprogrammer til at validere for overensstemmelse. Test med browserzoom til 200 % for at sikre, at teksten skaleres uden at miste indhold eller funktionalitet.
  • Brug tastaturnavigation i navigationsmenuer. Experience Cloud-navigationskomponenter skal understøtte kun tastaturhandling uden muselafhængighed. Brugere skal navigere ind og ud af rullemenuer, megamenuer og udløbsnavigation ved brug af Tab, Enter, Escape og Pil-taster uden fokusfælder. Test alle navigationsstier ved brug af kun tastaturet for at validere tilgængelighed.
  • Aktiver formulartilgængelighed i Experience Cloud. Tilknyt betegnelser eksplicit til alle formularinput ved brug af korrekte betegnelseselementer eller aria-labelledby. Pladsholdertekst i sig selv mislykkes tilgængelighedskravene, fordi teksten forsvinder, så snart dataindtastningen begynder, hvilket efterlader skærmlæserbrugere uden tilstrækkelig, vedvarende kontekst. Lightning leverer indbygget betegnelsestilknytning, når de konfigureres ved brug af de krævede betegnelsesattributter. Tilpassede Visualforce kræver eksplicit betegnelsesinputtilknytning.
  • Test Experience Cloud-lokaliteter ved brug af støttende teknologi. Før du starter offentlige Experience Cloud-lokaliteter, skal du udføre omfattende tilgængelighedstest ved brug af skærmlæsere, kun tastaturnavigation og browserzoom. Det er vigtigt at inkludere brugere med handicap i anvendelighedstest for at afsløre praktiske, oplevelsesmæssige hindringer, som ekspertanmeldelser ofte kan overse. Hvis du kun tester interne Lightning uden at validere ekstern Experience Cloud-tilgængelighed, efterlades offentlige lokaliteter sårbare over for tilgængelighedskrav og retssager.
  • Brug alternativ tekst til billeder og ikoner. Alle informative billeder, ikoner og grafisk indhold i Experience Cloud kræver alternativ tekst. Dekorative billeder bruger tom alternativ tekst (alt=”), hvilket gør det muligt for skærmlæsere at springe over dem. Informative billeder giver meningsfuld alternativ tekst, der beskriver indhold og funktion. Når du skriver alternativ tekst for ikoner, skal du fokusere på ikonets handling eller formål i stedet for dets visuelle udseende (i stedet for at beskrive et forstørrelsesglasikon som “forstørrelsesglas” skal alternativteksten angive dets funktionelle hjælpeprogram, f.eks. “Søgelokalitet”). Når CMS administrerer billeder, skal det bede indholdsforfattere om at angive alternativ tekst eller eksplicit markere billedet som dekorativt (hvilket angiver alt=""). Dette sikrer tilgængelighed ved at forhindre manglende alternativ tekst og tvungne beskrivelser for æstetiske billeder.

Komplet tastaturtilgængelighed betyder, at brugere kan få adgang til al funktionalitet ved brug af deres tastatur uden at kræve mus- eller touchinteraktion på noget tidspunkt.

  • Brug logisk fokusrækkefølge på Lightning-sider. Sørg for, at fokusrækkefølgen følger det visuelle layout og interaktionsforløbet. Når brugerne trykker på Fane, skal det visuelle fokus flytte gennem interaktive elementer i den rækkefølge, som brugerne forventer baseret på det visuelle design. Lightning App-konstruktør og Oplevelseskonstruktør etablerer fokusrækkefølge baseret på komponentplacering. Tilpassede komponenter kræver eksplicit fanindexstyring for at sikre logisk fokusstatus.
  • Brug synlige fokusindikatorer for at opfylde kontrastkrav. Lightning Design System leverer fokustypografier, der opfylder WCAG-kravene for de fleste komponenter. Tilpassede komponenter skal muligvis have forbedrede fokusindikatorer for at opfylde 3:1-kontrastkravet mod omgivende indhold. Fokusindikatorer skal være tydeligt synlige for at tillade brugere med lavt syn at navigere via tastaturet. Fjern aldrig fokusindikatorer med CSS (oversigt: ingen) uden at angive alternativ synlig fokus-typografi.
  • Brug tastaturfælde-reduktioner i modaler og overlejringer. Modaldialogbokse skal fange fokus i modaldialogboksen, mens den er åben, hvilket forhindrer tastaturbrugere i at nå til skjult baggrundsindhold. Fokusfælden skal frigives ved modaldialogboks lukning og returnere fokus til udløserelementet. Integreret indhold – herunder iframes og tredjepartswidgets – må ikke registrere tastaturfokus permanent uden en escape-mekanisme.
  • Brug genveje uden konflikter. Lightning leverer tastaturgenveje, der er dokumenteret i Hjælp til Salesforce. Tilpassede tastaturgenveje skal være designet til at forhindre konflikter med standardbrowserkontrolelementer og skærmlæsernavigationskommandoer. I overensstemmelse med WCAG-succeskriterier må genveje med et enkelt tegn (f.eks. tryk på et enkelt bogstav eller tegnsætningstegn) ikke udløse globale handlinger. De skal enten begrænse aktiveringen til, når en specifik komponent har aktivt fokus, eller give brugere en måde til at deaktivere eller omformulere genvejen fuldstændigt.

Opbyg validering af tilgængelighed i CI/CD-pipelines for at finde strukturelle problemer automatisk på hver implementering i stedet for at behandle tilgængelighed som periodiske manuelle revisioner.

  • Brug sa11y til Lightning Web Component-tilgængelighedstest. Salesforces sa11y-biblioteker (pakken @sa11y/jest) pakker aksekerne-tilgængelighedssystemet for at tilføje en toBeAccessible()-match til Jest-enhedstest. Skriv tilgængelighedstest, der validerer korrekt ARIA-anvendelse, betegnelsestilknytninger, kontrastforhold og semantisk kodning automatisk som en del af enhedstest. Konfigurer opbygninger til at mislykkes, når der registreres problemer med kritisk tilgængelighed.
  • Brug Lighthouse CI til Experience Cloud. Google Lighthouse overvåger websidetilgængelighed, herunder Experience Cloud-lokaliteter. Integrer Lighthouse CI i implementeringspipelines for at scanne offentlige sider for tilgængelighedsproblemer. Konfigurer score tærskler til at kræve mindste tilgængelighedsscores før implementeringsgodkendelser.
  • Brug Tilgængelighedsagenten, der er tilgængelig via Salesforce DX MCP-pakken. I MCP-kompatible miljøer eller i Agentforce Vibes gennemser det kode i forhold til WCAG-standarder, viser målrettede rettelser og kan generere en pull-anmodning, som en tekniker kan gennemse, validere og flette.

Bias har eksisteret i deterministisk Salesforce-automatisering længe, før AI kom på billedet. Tildelingsregler, forløbsbeslutninger, valideringsregler og områdedesign koder menneskelig dom, der kan forlænge diskriminering. I modsætning til AI-bias – som arkitekter undersøger omhyggeligt – går automatiseringsbias ofte gennem uundersøgt, fordi deterministisk logik føles objektiv.

  • Følg emne- og sagstildelingsregler. Distribuer arbejde på tværs af salgs- og serviceteams. Når tildelingslogik bruger kriterier, der er forbundet med beskyttede egenskaber, opretter automatisering systematiske forskelle i servicekvalitet og salgsmulighedsadgang.
  • Tildelingsregler, der bruger område-, postnummer- eller kontokarakteristika, kan distribuere salgsmuligheder med høj værdi uforholdsmæssigt til specifikke teams, mens der distribueres arbejde med lavere værdi andre steder. Hvis områdegrænser er forbundet med kundedemografi og kompensationsstrukturer, der er forskellige på tværs af områder, opretter tildelingsautomatisering økonomisk diskrimination.
  • Overvåg resultaterne af tildelingsregler regelmæssigt. Beregn tildelingsdistributioner på tværs af områder og teams, der er inddelt efter kundedemografi. Hvis Virksomhedskonti er koncentreret i specifikke områder, mens SMB-konti distribueres andre steder – og hvis Virksomhedsområder modtager bedre kompensation eller ressourcer – kan tildelingsregler producere urimelige resultater, der garanterer rimelig gennemgang.
  • Gennemse Omni-Channel-færdighedsbaseret distribution. Dette kan påvirke servicekvaliteten på tværs af kundepopulationer. Hvis distributionslogik implicit antager, at visse færdigheder er forbundet med kundeværdi eller problemkompleksitet, kan kunder modtage forskellige serviceresultater baseret på demografiske proxyer.

Det er vigtigt at overvåge den gennemsnitlige tid til håndtering, første kontakt-løsninger og kundetilfredshed på tværs af distributionsstier. Uoverensstemmelser kan angive, om visse kundesegmenter systematisk modtager mindre erfarne agenter eller færre distributionsindstillinger.

  • Gennemse Salesforce Flow-automatiseringer. Vedtagelse af godkendelsesbeslutninger, berettigelsesbestemmelser eller adgangstildelinger kan kode diskriminerende logik gennem tilsyneladende harmløse forretningsregler. Visse forløb opretter indirekte diskrimination, når kriteriet korrelerer med beskyttede egenskaber.
  • Gennemse forløbsbeslutninger med tanke på fairness. For hvert forløb, der træffer konsekvensmæssige beslutninger, der påvirker brugere, er det vigtigt at spørge:
  • Hvad sker der med brugere, der ikke passer til den typiske kundeprofil?
  • Er beslutningskriterier forbundet med demografiske karakteristika?
  • Håndteres undtagelser og kantsager på en rimelig måde, eller nedsætter de systematisk specifikke grupper?

Det er vigtigt at dokumentere forløbsbeslutningslogik og rimelighedsovervejelser i arkitekturbeslutningsregistreringer og underlægge forløb med høje satser de samme etiske gennemgangspolitikker som AI-systemer.

  • Gennemse valideringsregler. Forhindring af dataindtastning kan ekskludere gyldige data fra brugere, hvis oplysninger ikke matcher systemantagelser. Valideringsregler, der afviser lovlige data, opretter usynlige udfyldninger. Brugere, hvis data ikke passer til valideringsmønstre, kan ikke engagere sig i bestemte systemer. Valideringsfejl bliver ofte ikke rapporteret, fordi brugere afbryder deres anmodninger i stedet for at rapportere tekniske fejl. Her er flere almindelige valideringsbiasmønstre:
  • Navnevurderinger, der kræver latinske tegn, kan ekskludere navne med diakritiske og ikke-latinske scripts.
  • Telefonnummervalideringer bruger ofte amerikanske/vestlige formater, hvilket udelukker internationale numre og alternative kommunikationsmetoder.
  • Adressevalideringer genkender ikke ikke-standardadresser (f.eks. PO-bokse, landdistrikter, stammelande og internationale formater).
  • Mailvalideringer, der kræver personlige mailadresser, kan skabe en ulempe for brugere, der ikke har personlig mailadgang.
  • Test valideringsregler ved hjælp af forskellige data. Inkluder internationale adresser, ikke-vestlige navne og alternative telefonformater i valideringstest. Når valideringen afviser gyldige data, skal du udvide valideringslogikken for at undgå at ekskludere gyldige brugere.
  • Gennemse designs for salgsområder. Kundesegmenteringsstrategier og salgsområdedesign bestemmer ressourcetildeling på tværs af kundepopulationer. Når områdegrænser eller segmenteringskriterier er forbundet med demografi, der resulterer i uensartet ressourcetildeling, kan denne tildeling oprette diskriminerende resultater. Områdedesign, der bruger geografiske grænser, er ofte forbundet med racemæssig, etnisk og økonomisk demografi på grund af bopælssegregeringsmønstre. Hvis kompensation, personaletiveauer eller ressourceinvesteringer varierer på tværs af områder, kan geografi blive en mekanisme for diskriminerende ressourcetildeling.
  • Analyser områdets demografi, før du afslutter design. Tilknyt kundedemo på tværs af foreslåede områdegrænser. Når der opstår demografiske koncentrationer, skal du evaluere, om ressourcetildelingen er rimelig på tværs af alle områder, uanset demografisk sammensætning. Hvis forretningsjusteringen kræver forskellige ressourceniveauer på tværs af områder (f.eks. markedsmodenhed, konkurrenceintensitet og vækstpotentiale), skal du dokumentere denne begrundelse eksplicit og overvåge resultaterne for at sikre, at underbetjente områder modtager tilstrækkelige investeringsmuligheder for at forhindre indbyggede forskelle.
  • Bevar gennemsigtighed i automatiseringslogik. Dokumenter forretningsregler, tildelingskriterier og forløbsbeslutningslogik i Salesforce Knowledge eller arkitekturbeslutningsregistreringer. Gennemsigtig automatisering gør det muligt at gennemgå rimelighed på en måde, som skjult logik forhindrer.
  • Regelmæssig revision af resultater. Planlæg kvartalsvise revisioner for at analysere automatiseringsresultater, der kan være inddelt efter kundedemografi. Husk på, at uoverensstemmelser udløser undersøgelser og potentiel rettelse.
  • Det er vigtigt at spore:
  • Tildelingsdistributioner på tværs af teams og områder
  • Godkendelsesfrekvenser for forløb, der træffer beslutninger om berettigelse
  • Afvisningsfrekvenser for valideringsregel efter datamønster
  • Områdeydeevne og ressourcetildeling
  • Gennemse automatisering med høje satser gennem en etisk linse. Emneforløb og tildelingsregler, der påvirker beskæftigelse, kredit, adgang til service eller andre konsekvenser af den samme etiske gennemgangsproces som AI-systemer. Automatiseringsbias kræver det samme niveau af gennemgang som algoritmisk bias.

I Salesforce fokuserer AI fairness på at bruge Einstein til at validere, at forudsigelser giver rimelige resultater på tværs af alle demografiske grupper. Einstein Discovery og tilpasset instrumentering registrerer forudsigelsesmodelbeslutningsdata, der aktiverer biasregistrering. CRM Analytics-dashboards sporer rimelighedsmetrikker. Feltrevisionsspor og Begivenhedsovervågning registrerer beslutningsdata for algoritmisk ansvarlighed.

Einstein, der påvirker følsomme beslutninger (f.eks. emnescoring, salgsmulighedsprognoser og kundesegmentering), kræver evalueringer af rimelighed før implementering, der fungerer som et obligatorisk ækvivalent trin (ligner sikkerhedsgennemgange).

Analyser alle forudsigelsesmodelfunktioner for korrelation med beskyttede egenskaber ved brug af statistiske metoder. Fjern eller transformer proxyfunktioner efter evaluering af, om deres forudsigelsesværdi retfærdiggør inkludering på trods af proxyfunktioner.

  • Auditer Salesforce CRM-data før uddannelse. Salesforce-organisationer indeholder årtier med menneskelige beslutninger, der er baseret på historiske fremgangsmåder. Hvis tidligere salgsteams prioriterede bestemte demografier, lærer Einstein disse mønstre og bevarer dem. Før du træner forudsigelsesmodeller på historiske data, er det vigtigt at overvåge disse data for demografiske repræsentation huller og måle inkonsekvenser på tværs af kundesegmenter.
  • Beregn fairness-metrikker på tværs af demografiske grupper. Før du implementerer forudsigelsesmodeller, er det vigtigt at beregne demografisk paritet, lige salgsmuligheder og uensartede påvirkningsforhold på tværs af beskyttede grupper, hvor du har et lovligt grundlag for at indsamle og behandle de krævede demografiske data. Hvis Einstein-emnescoring tildeler høje scores til Segment A 50 % af tiden, men kun 30 % af tiden til Segment B, vil et forhold på 60 % ikke overholde fire femtedelsreglen (80 %) og kræve undersøgelse og reduktion. Antallet på 80 % er en screeningudløser, ikke en lovlig gennemgang/fejllinje: fire-femters reglen er en amerikansk føderal tommelfingerregel for beskæftigelsesvalg, og rydning det er ikke en sikker havn — en statistisk signifikant forskel kan berettige kontrol ved højere forhold, og andre regimer måle negativ påvirkning anderledes (EU indirekte-diskrimination lov, for eksempel, slår på, om en praksis skaber en “særlig ulempe”, uden nogen fast tærskel). Kalibrer undersøgelsestærskler til de jurisdiktioner, og brug sager, du arbejder i.
  • ** Registrer forudsigelsesmodelbeslutningsdata til biasregistrering.** Hvis du vil registrere bias i forudsigelsesmodeller som emnescoring og salgsmulighedsscoring, skal du registrere beslutningsdata gennem Einstein Discovery og tilpasset instrumentering: gem forudsigelsesinputs, -output og -modelversioner i sporede felter, og aktiver Feltrevisionsspor. Analyser disse data i CRM Analytics for at spore beslutningsmønstre på tværs af demografiske grupper over tid, og opbyg dashboards, der advarer, når demografiske paritets- eller ligestillingsmetrikker flytter sig ud over acceptable tærskler.
  • Find proxyfunktioner i forudsigelsesmodeller. Funktioner, der er forbundet med beskyttede egenskaber, aktiverer indirekte forskelsbehandling, selv når beskyttede egenskaber udelades fra modellerne.
    • Salesforce-data indeholder sædvanligvis proxyfunktioner:
  • Område eller postnummer (proxys for race, etnicitet og indkomst)
  • Kontonavnemønstre (proxys for organisationsstørrelse og branchdemografi)
  • Tidspunkter for kommunikationsaktivitet (proxys for tidszoner, religion og behandlingsansvar)
  • Enhedstype eller browser fra aktivitetsdata (proxier for indtjeningsniveau)

Når bias registreres i Einstein, skal du anvende reducering på den relevante pipelinefase (baseret på grundlæggende årsag og tekniske begrænsninger).

  • Balancedata før modeltræning. Genbalancer Salesforce CRM-data ved at overprøve underrepræsenterede kundesegmenter eller underprøve overrepræsenterede segmenter, før du træner forudsigelsesmodeller. Brug Data 360 til at aggregere data på tværs af flere organisationer for at sikre forskellige uddannelsessæt. Syntetisk datagenerering kan supplere sjældne segmenter, mens fortrolighed bevares gennem differentierede fortrolighedsteknikker.
  • Fjern proxyer i funktionsteknik. Når proxyfunktioner identificeres, skal du erstatte dem med alternative funktioner, der giver forudsigende styrke uden demografisk korrelation. Hvis område fungerer som demografisk proxy, kan du overveje brancheklassificering eller firmastørrelse som alternativer. Hvis kontonavnemønstre er forbundet med demografi, skal du bruge firmografiske attributter i stedet for.
  • Juster tærsklerne under efterbehandling. Juster beslutningstærsklerne pr. demografisk segment for at ligestille resultatfrekvenser efter træningsmodeller. For beskæftigelsesrelaterede beslutninger er dette strengt forbudt: Afsnit VII (Loven om borgerrettigheder fra 1991) forbyder justering af scores eller brug af forskellige udskæringsscores efter beskyttet klasse, og ingen dokumenteret begrundelse gør denne praksis lovlig. Hvor det ikke er forbudt, skal du dokumentere tærskeljusteringer med forretningsjustering for forskellig behandling, når forudsigelser informerer automatiserede beslutninger.
  • Opdater modeller regelmæssigt ved brug af opdaterede data. Planlæg modeltræning kvartalsvis (eller når der forekommer væsentlige datadistributionsvagter). Gentræning af nye data fanger nye biasmønstre og retter ethvert afvigelse fra de oprindelige fairness-basislinjer. Valider rimelighedsmetrikker igen på hver modelversion før produktionsimplementering for at sikre, at træning ikke introducerede nye bias.

Trusteddelelser, svar og Trust for genererende AI og Agentforce og understøtter gennemsigtighed og overholdelse af bestemmelser for genererende AI. For forudsigelsesmodeller kommer gennemsigtighed og beslutningsforløb fra Einstein Discovery og Model Manager, som kræver tilpasset instrumentering for at bevare revisionsdata.

Opbyg forklarbarhed i Einstein fra den indledende arkitektur i stedet for at justere forklaringerne på uigennemsigtige systemer efter implementering.

  • Oversigt Einstein Discovery forklaringer på beslutningspunkter. Einstein Discovery leverer forudsigelsesfaktorforklaringer, der viser, hvilke variabler der påvirkede specifikke forudsigelser mest med retningsmæssig påvirkning. Architect Lightning, der viser disse forklaringer for brugere på beslutningstidspunktet i stedet for at kræve navigation for at adskille CRM Analytics-dashboards. Når beslutninger påvirker brugere, har de brug for gennemsigtighed, ikke abstrakte modelydeevnemetrikker.
  • Layer forklaringer til forskellige målgrupper. Angiv forklaringsdybde, der er relevant for hver målgruppe:
  • Forretningsbrugere: “Dette emne scorer højt, fordi den årlige omsætning overstiger $1M, og engagementsscoren er i de øverste 10 %”.
  • Tekniske brugere: Angiv et Einstein Discovery med funktionsvægt, træningsdatakarakteristika og valideringsmetrikker.
  • Kunder: “Denne anbefaling er baseret på dine seneste køb og kunder med lignende præferencer”.
  • Revisorer: Angiv beslutningsforløbet fra Einstein Discovery og Model Manager – modelversion, inputværdier og de faktorer, der skabte forudsigelsen – registreret gennem tilpasset instrumentering.
  • Kommunikere tillid korrekt. Vis forudsigelseskonfidens i brugervenlige termer, og undgå rå sandsynlighedsscores, som brugere kan fortolke forkert. I stedet for at vise “73% konfidens” skal du kommunikere dette ved brug af kategorier (f.eks. Høj konfidens, Moderer konfidens og Kræver gennemgang) med forklaringer på, hvad hvert konfidensniveau betyder for beslutningers pålidelighed, samt hvilke yderligere gennemgange der vil forekomme.

Vedligehold omfattende, uforanderlige revisionsspor, der understøtter ansvarlighed, fejlfinding og overholdelse af bestemmelser for alle AI-styrede beslutninger, der påvirker brugere.

  • Få forudsigende revisionsdata med de rigtige værktøjer. Gem forudsigelsesmodelrevisionsdata – forudsigelsesinput, output og modelversioner – i sporede felter med feltrevisionsspor aktiveret. Arkitekter databevarelsespolitikker, så de opfylder bestemmelseskrav, som varierer efter branche og jurisdiktion:
    • Reglerne for finansielle tjenesteydelser fastsætter bevarelse pr. forordning (f.eks. fastsætter FINRA-reglen 4511(b) en standardbevarelsesperiode på seks år for registreringer, der ellers ikke har en bestemt bevarelsesperiode i henhold til FINRA-reglerne eller SEA-reglen 17a-4).
    • Bevarelse af sundhedspleje er også reguleret af specifikke regler (f.eks. kræver HIPAA mindst seks år for overholdelsesdokumentation; bevarelse af medicinsk optegnelse er fastsat af individuelle statslige love) snarere end generelle mandater for ubestemt opbevaring.
  • Analyser forudsigelsesmodelbeslutningsdata med CRM Analytics. Opbyg CRM Analytics-dashboards på de forudsigelsesmodelbeslutningsdata, du registrerer (forudsigelsesinput, output og modelversioner i sporede felter) for at analysere beslutningsmønstre, rimelighedsmetrikker og modelydeevne over tid. Opret linser, der viser forudsigelsesdistributioner efter konfidensniveau, demografisk segment og resultattype. Konfigurer Einstein Discovery, der identificerer afvigelser, der kræver yderligere undersøgelse.
  • Brug feltrevisionsspor til langsigtet bevarelse. Standardfelthistorik sporer ændringer for 18 måneder i brugergrænsefladen og op til 24 måneder via API. Feltrevisionsspor giver dig mulighed for at bevare felthistorik uendeligt for tilpassede objekter, der lagrer AI-beslutningsdata. Den arkiverer som standard historikken efter op til 18 måneder og bevarer derefter de arkiverede data, indtil du sletter dem. Aktiver Feltrevisionsspor på objekter, der indeholder samtykkeregistreringer, tilsidesætte beslutninger og biasrapporter for at opfylde krav til regulerende bevarelse.
  • Brug Begivenhedsovervågning til Agentforce-interaktioner. Begivenhedsovervågning registrerer begivenheder på kaldeniveau for Agentforce, f.eks. når handlinger og forløb køres. Eksporter begivenhedsovervågningsdata til et eksternt SIEM – standardbegivenhedslogfildata via API og undersættet Begivenhedsovervågning i realtid for begivenheder via platformsbegivenheder – til lagring, der overskrider Salesforce-oprindelige bevarelsesvindue. Tilsidesættelsesbevis afhænger af specifik SIEM-adfærd, der håndhæver skrivebeskyttet lagring og adgangssegregering. Konfigurer SIEM-forespørgsler for at registrere biasmønstre på tværs af store mængder Agentforce.
  • Overvåg Agentforce-samtaler med Einstein Trust-laget. Trustevisionssporet for Agentforce og -svar, der er lagret i Data 360, og leverer registreringen på afskriftsniveau til gennemsigtighed og overholdelse af bestemmelser.

Lad os se nærmere på arkitektgennemsigtighedsfunktioner, der er placeret til overholdelse af aktuelle og nye AI-bestemmelser på tværs af flere jurisdiktioner.

  • Krav til gennemsigtighed i EU AI Act. Højrisikose AI-systemer i henhold til EU AI Act kræver dokumentation for gennemsigtighed, teknisk dokumentation, menneskelig tilsyn og nøjagtigheds-/retfærdighedsmetrikker. Einstein Trust Layer-revisionssporene og Einstein Discovery giver grundlag for disse krav. Dokumentmodeltræning af demografiske data, valideringsmetoder og kendte begrænsninger i arkitektoniske beslutningsregistreringer.
  • GDPR ret til forklaring. GDPR giver EU-datasubjekter ret til meningsfulde oplysninger om beslutningens logik, når beslutningen udelukkende er baseret på automatiseret behandling og producerer juridiske eller tilsvarende betydningsfulde virkninger. Denne rettighed stammer fra artikel 15, stk. 1, litra h), og artikel 22, stk. 3, i betragtning 71, og blev præciseret af Domstolen i sagen Dun & Bradstreet (2025). Design systemer, der genererer kohærente forklaringer på efterspørgsel for enhver historisk beslutning inden for anmodningstidsrammer for registreret adgang, som varierer (afhængigt af jurisdiktion) mellem 15 og 45 dage. De forudsigelsesmodelbeslutningsdata, du registrerer – forudsigelsesinput, output, modelversioner og Einstein Discovery – gør det muligt at rekonstruere forklaringer, når de lagres med tilstrækkelig bevarelse.
  • Algoritmisk ansvarsregler. Amerikanske algoritmiske ansvarsregler på statsniveau kræver i stigende grad påvirkningsvurderinger og gennemsigtighedsrapportering for automatiserede beslutningssystemer. De forudsigelsesmodelbeslutningsdata, du registrerer, og CRM Analytics-fairnessovervågningsdashboards giver databasen for disse rapporter. Udfør algoritmiske påvirkningsvurderinger, før du implementerer konsekvent AI som proaktiv overholdelse snarere end som et reaktivt svar på reguleringsforespørgsler.

OWD’er, delingsregler og sikkerhed på feltniveau (FLS) formaterer de datadgangsmønstre, der bestemmer, hvilke oplysninger brugerne kan gennemse og bruge til at træffe beslutninger. Korrekt konfiguration forhindrer diskriminerende adgang til følsomme attributter, mens du også sikrer rimelig service.

Design OWD’er og sikkerhed på feltniveau for at begrænse adgang som standard. For delingsregler skal du bruge PoLP-princippen til kun at tildele den yderligere adgang, som hver rolle har brug for, hvilket forhindrer diskriminerende beslutningstagning baseret på beskyttede egenskaber.

  • Aktiver restriktiv OWD som standard. Brug private OWD’er til objekter, der indeholder følsomme kundedata, og tildel adgang efter rollehierarki og delingsregler. Offentlige OWD’er Læs/Skriv gør begrænsning af adgang senere forstyrrende – indsnævring af standarden udløser en delingsgenberegning og træder kun i kraft, når den er fuldført – snarere end umuligt. Private OWD’er med eksplicitte delingstildelinger opretter reviserbare adgangsmønstre, der understøtter ikke-diskrimineringsoverholdelse.
  • Anvend Sikkerhed på feltniveau for følsomme attributter. Skjul følsomme felter, der indeholder beskyttede egenskaber (f.eks. etnicitet, religion og handicapstatus), fra brugere, der ikke kræver adgang til lovlige forretningsformål. Konfigurer FLS til at fjerne læseadgang for følsomme felter i de fleste profiler. Når disse felter er påkrævede til specifikke formål (f.eks. diversitetsrapportering og rimelig tilpasning), skal du tildele minimal adgang ved brug af tilladelsessæt med dokumenteret forretningsjustering.
  • Udformning af tildelings- og delingsregler for retfærdige resultater. Brug tildelingsregler, køer og Omni-Channel-distribution til at distribuere arbejde ligeligt på tværs af områder, teams og serviceagenter. Undgå manuel deling, der koncentrerer salgsmuligheder af høj værdi eller kunder med specifikke brugergrupper uden dokumenteret forretningsjustering. Konfigurer automatiske delingsregler baseret på målsætningskriterier (f.eks. branche, geografi og produktlinje) i stedet for subjektiv managerdiskretion, hvilket kan aktivere bias.
  • Angiv tilladelsessæt til midlertidig adgang. Tildel midlertidig adgang til følsomme data via tilladelsessæt i stedet for at redigere profiler, hvilket påvirker alle brugere permanent. Når brugere har brug for adgang til demografiske data for specifikke projekter (f.eks. diversitetsanalyser og anmodninger om indkvartering), skal du tildele tilladelsessæt med dokumenterede udløbsdatoer. Planlagte forløb kan tilbagekalde tilladelsessæt automatisk efter definerede perioder.

Brug Shield-begivenhedsovervågning og rapporter til at registrere dataadgangsmønstre, der angiver potentiel forskelsbehandling eller bias i dataanvendelse.

  • Brug Shield-begivenhedsovervågning til at overvåge adgang til følsomme data. Brug Begivenhedsovervågning til at registrere adgangsbegivenheder på objektniveau (rapporteksporter, API-forespørgsler og sidevisninger) på objekter, der indeholder beskyttede egenskaber eller følsomme attributter. Konfigurer forespørgsler over disse begivenheder for at vise, hvem der åbnede objektet, hvornår og i hvilken kontekst, og behandl afvigelser (f.eks. pludselige spidser og adgang fra uventede brugere) som udløsere til undersøgelse.
  • Rapporter om delingsregeldistributioner. Opbyg rapporter, der analyserer, hvordan registreringer distribueres på tværs af brugere, teams og områder. Beregn distributionsstatistikker efter kundedemo for at sikre, at konti og salgsmuligheder af høj værdi distribueres ligeligt. Identificer koncentrationer, hvor specifikke brugergrupper modtager uforholdsmæssig adgang til værdifulde registreringer uden dokumenteret forretningsjustering.
  • Auditer CRUD- og FLS-overtrædelser. Gennemse revisionssporet for opsætning for ændringer af OWD-indstillinger, delingsregler, FLS-konfigurationer og tilladelsessæt. Uautoriserede ændringer af dataadgangskontroller kan angive forsøg på at få adgang til følsomme data upassende. Brug transaktionssikkerhedspolitikker til at reagere på begivenheder med høj risiko i Begivenhedsovervågning i realtid (f.eks. uregelmæssig API-aktivitet, mistænkelige logins og eksport af store rapporter eller listevisninger af følsomme data). Da transaktionssikkerhed kun fungerer på disse kørselsbegivenheder i stedet for DML- eller FLS-ændringer på registreringsniveau, skal du være afhængig af revisionssporet for opsætning og dokumenterede ændringsstyringsgodkendelser for FLS og delingsændringer.

I Salesforce betyder brugerbureauer, at kunder og medarbejdere bevarer meningsfuld kontrol over, hvordan AI påvirker deres oplevelse. Salesforce-samtykkeadministrationsfunktioner, Data 360-samtykke og tilpassede samtykkeobjekter aktiverer detaljeret kontrol over AI-interaktioner.

Design samtykkesporing ved brug af Data 360-samtykkeadministration, Marketing Cloud-samtykke eller tilpassede samtykkeobjekter, der bruger feltrevisionsspor for AI-specifikke samtykkekrav.

  • Aktiver detaljeret samtykke pr. AI-anvendelsessituation. Aktiver samtykke pr. AI-anvendelsessituation i stedet for at bruge et omfattende AI-samtykke. Kunder kan acceptere Einstein, men afvise AI-styrede kreditbeslutninger. Aktiver feltrevisionsspor på samtykkeobjekter for langsigtet bevarelse og opfyldelse af bestemmelseskrav. Design tilpassede samtykkeobjekter med felter, der sporer:
  • Samtykkeformål (f.eks. Einstein, Einstein og Einstein)
  • Samtykketildelingsdato og tildelingsmetode (f.eks. webformular, API, telefon og mail)
  • Samtykketilbagetrækningsdato (hvis relevant)
  • Relateret bruger- eller kontakt-id
  • Brug Data 360-samtykke til personliggørelse. Brug Data 360-samtykkeadministration til Einstein-personalisering. Data 360 overfører og lagrer samtykkepræferencer fra upstream-systemer via forbindelser, der er tilknyttet fortrolighedsdatamodellen, hvilket giver dig mulighed for at bruge disse samtykkeattributter som filterkriterier i segmentering og ved aktivering. Tilknyt samtykkeattributter til specifikke AI-anvendelsessituationer for at gøre det muligt for brugere at framelde sig tilpasning, mens de også vedligeholder kernetjenester
  • Aktiver Marketing Cloud-samtykkeintegration. Integrer Marketing Cloud-samtykke med Einstein Meddelelsesindsigter og AI-drevne marketingfunktioner. Respekter Marketing Cloud-abonnementsstatus og samtykke i al AI-styret kommunikation.

Angiv meningsfulde frameldinger fra AI-styrede funktioner med tilgængelige kontroller, der respekterer brugerpræferencer via menneskelige alternativer af sammenlignelig kvalitet.

  • Angiv tilgængelige frameldinger i profilindstillinger. Gør det muligt for brugere at framelde sig AI-styrede interaktioner via tilgængelige præferencekontroller i Experience Cloud-profilindstillinger eller Mine indstillinger i interne apps. Angiv tydelige beskrivelser af, hvad hver framelding betyder, og den alternative oplevelse, som brugerne vil modtage ved framelding. Gem præferencer i bruger- eller kontaktregistreringer.
  • Angiv vedvarende præferenceindstillinger på tværs af kanaler. Gem AI-præferencer i bruger- eller kontaktregistreringer for at sikre ensartethed på tværs af kanaler (f.eks. web, mobil, telefon og mail). Forespørg på præferencer ensartet i alle interaktionsforløb for at forhindre brugere i at have brug for gentagne gange at bekræfte præferencer i forskellige kanaler.

Etisk AI-styring leverer organisationsstrukturer, der hjælper med til at sikre, at rimelighed bevares, efterhånden som modeller udvikles, datavagter og anvendelsessituationer udvides. Uden styring forværres indledende rimelighedsbestræbelser, efterhånden som organisationens opmærksomhed skifter.

Opret obligatorisk dokumentation, og gennemse kontrolpunkter, før Einstein. Tænk på dette som en gate, der er lige så vigtig som sikkerhedsgennemgange.

  • Angiv modeldokumentation. Gem modeldokumentation i Salesforce ved brug af et tilpasset modelobjekt eller Salesforce-filer, der er vedhæftet til projekter for at aktivere søgbarhed og versionskontrol. Dokumenter hver produktionsforudsigelsesmodel ved brug af:
  • Træning af demografiske data og kendte repræsentation huller (for kundeuddannede forudsigelsesmodeller som Einstein Discovery og Forudsigelseskonstruktør)
  • Fairness-metrikker før implementering, der beregnes efter demografisk gruppe
  • Tilsigtede anvendelsessituationer og kendte upassende anvendelser
  • Bias-begrænsningsstrategier, der anvendes under udvikling
  • Fairness-overvågningstilgang og advarselstærskler
  • Krav til menneskelig tilsyn og godkendelsesarbejdsflows
  • Gennemse tidsplaner og ansvarlige parter
  • Overvejelser i forbindelse med bestemmelser og overensstemmelsesplacering
  • Aktiver Fairness-portaler før implementering. Modeller, der ikke klarer nogen gate-test, må ikke fortsætte til produktion. Behandl fairness-portaler med samme rigor som sikkerhedsportaler. Med andre ord bærer de autoritet til at blokere implementeringer. Før du implementerer Einstein i produktion, skal du:
  • Gennemse revisioner af data om uddannelse. Alle repræsentationmangler skal analyseres og dokumenteres.
  • Gennemgang af retfærdighedsmetrikker (f.eks. demografisk paritet, lige muligheder og uensartet påvirkning skal beregnes og bekræftes for at opfylde tærsklerne).
  • Gennemse konsekvensanalyser. Evaluer potentiel skade på tværs af påvirkede populationer.
  • Design med menneskelig tilsyn. Alle eskaleringsmønstre, godkendelsesarbejdsflows og tilsidesættelsesmekanismer skal designes og testes korrekt.
  • Fuldfør en gennemsigtighedsgennemgang. Forklaringsfunktioner skal valideres for alle beslutningstyper.
  • Komplet dokumentation. Alle påkrævede modeldokumentartikler skal godkendes.

Etabler gennemgangsprocesser for AI-applikationer med stor interesse, der giver krydsfunktionsovervågning og har håndhævelsesmyndighed.

  • Sammensætning af bestyrelsen. Inkluder tekniske eksperter (f.eks. arkitekter og datavidenskabsfolk), forretningsinteresserede (f.eks. produktejere og driftspersonale), juridiske rådgivere, fortrolighedsspecialister og repræsentanter fra påvirkede fællesskaber (hvor det er muligt). Husk, at forskellige perspektiver viser retfærdighedsproblemer, som homogene grupper ofte går glip af.
  • Gennemse alle udløsere, der kræver godkendelse fra etiske råd. Definer, hvilke AI-anvendelsessituationer der kræver etisk gennemgang før implementering:
  • Beslutninger, der påvirker beskæftigelse, kredit, bolig, sundhedspleje eller juridiske rettigheder
  • Automatiserede systemer, der påvirker mere end 10.000 brugere eller transaktioner pr. år
  • AI-applikationer, der bruger følsomme personlige data, herunder helbreds-, økonomiske eller demografiske data
  • Novelle anvendelsessituationer, der ikke har et etableret organisatorisk præcedens
  • Systemer, hvor potentielle bias kan forårsage væsentlig skade på enkeltpersoner eller grupper
  • Gennemse og beslut, hvem der har myndighed til at blokere implementeringer. Etiske gennemgangsråd bør have autoritet til at kræve ændringer, pålægge overvågningsbetingelser eller blokere implementeringer, der ikke overholder etiske standarder. Kun rådgivende gennemgange (uden håndhævelsesmyndighed) kan begrænse effektiviteten af styringsprocessen. Dokumenter alle gennemgange i tilpassede Salesforce-objekter, der sporer: applikationsnavn, gennemgangsdato, bekymringer, reduktionskrav og godkendelsesbetingelser.

Fairness-overvågning er en igangværende proces, der kræver kontinuerlig opmærksomhed for at registrere biasforskydning, når datafordelinger skifter, og brugerpopulationer ændres.

  • Opret CRM Analytics Fairness-dashboards. Opbyg dashboards, der sporer rimelighedsmetrikker ved brug af de forudsigelsesmodelbeslutningsdata, du registrerer. Overvåg demografisk paritet, lige salgsmulighed, uensartede påvirkningsforhold og metrikker for forudsigelseskvalitet efter kundesegmenter. Konfigurer CRM Analytics-advarsler, der udløses, når rimelige metrikker bryder definerede tærskler og kræver en undersøgelse.
  • Aktiver tilpasset overvågning for fairness-signaler. Opbyg tilpasset fairnessovervågning for at registrere signaler (f.eks. pludselige ændringer i beslutningsdistributioner efter demografisk gruppe, spids i biasrelaterede sagsregistreringer eller nedgang i modelydeevne for specifikke populationer).
  • Planlægge revisioner. Udfør omfattende kvartalsvise rimelighedsrevisioner for AI-systemer med høj indsats (f.eks. kredit, beskæftigelse og sundhedspleje) og halvårlige revisioner for systemer med lav indsats (f.eks. anbefalinger og tilpasning). Revisioner skal undersøge aktuelle rimelighedsmetrikker, gennemse tilsidesættelsesmønstre i godkendelseshistorik, analysere brugerfeedback og biasrapporter og validere, at styringskontroller forbliver effektive.
  • Implementer hændelsessvar for fairnessfejl. Opret tydelige processer, der er dokumenteret i Salesforce Knowledge med detaljerede oplysninger om, hvordan du reagerer, når der registreres bias:
  • Øjeblikkelig: Vurder alvorsgraden og omfanget ved at forespørge på forudsigelsesmodelbeslutningsdata i CRM Analytics. Hvis hændelsen er alvorlig, skal du suspendere al automatiseret beslutningstagning i afventning af en undersøgelse.
  • Kortsigtet: Implementer midlertidige reduktionsstrategier (f.eks. øget menneskelig tilsyn via justerede konfidensstærskler, funktionsinaktivering eller fuldstændig agentsuspension).
  • Udforskning: Udfør en RCA (roden cause analysis) for at identificere, hvordan bias indtastede systemet eller udviklede sig. Under RCA skal du analysere træningsdata, modelversioner og konfigurationsændringer via feltrevisionssporet.
  • Reparation: Implementer en permanent løsning via datakorrektion, modeltræning eller procesændringer.
  • Meddelelse: Adviser påvirkede brugere via Sager, mail eller Experience Cloud-bekendtgørelser.
  • Forebyggelse: Behandl ændringer for at forhindre gentagelse, og dokumenter forebyggelsesmetoderne i kørselslister.

Brug denne tjekliste under arkitektoniske gennemgange, før produktionsimplementering og regelmæssigt til løbende vurdering.

Datakvalitet og repræsentativ rimelighed

  • Gør felter valgfri, hvor en proces kan fungere uden dataene, og design downstream-processer til at håndtere manglende værdier, så brugere, der ikke kan angive oplysninger (mail, SSN, gadeadresse), ikke udelades.
  • Architect Name-felter som et enkelt felt med et fuldt navn eller en fleksibel struktur med flere dele, der accepterer mononymer, ikke-latinske scripts, diakritikker og lange navne i stedet for at antage, at de er i den vestlige første/sidste rækkefølge.
  • Implementer validering af tilladelsesadresse, der accepterer frie formater og internationale formater, og lagrer adresser som angivet i stedet for at blokere registreringsoprettelse på et format, der ikke matcher.
  • Gem kommunikationskanalpræferencer i kontaktregistreringer, og understøt omnichannel-alternativer (mail, sms, telefon, post, chat, voice) i stedet for at antage, at en enkelt kanal når alle brugere.
  • Indsaml demografiske data gennem frivillig selvidentifikation med en “Foretræk ikke at svare”-indstilling, gemmes separat under Privat OWD med FLS, aggregeres til rapportering og overvåges via Shield-begivenhedsovervågning.
  • Overvåg tredjeparts berigelsesleverandører for fairness-test, demografisk dækning og udledningsmetodologi, før du føjer demografiske eller adfærdsmæssige data til registreringer.

Tilgængelighed og inkluderende design

  • Brug Lightning Design System-komponenter, der er designet til at understøtte WCAG 2.2 AA-tilgængelighed. Husk på, at Salesforce stræber efter overensstemmelse, men komponenter kræver stadig korrekt brug.
  • Valider tilpassede Lightning med skærmlæsertest (f.eks. JAWS, NVDA og VoiceOver).
  • Sørg for, at komplet tastaturnavigation findes på Lightning og på Experience Cloud-lokaliteter uden muselafhængighed.
  • Bekræft, at kontrastforhold opfylder 4,5:1 for normal tekst ved brug af browserudviklingsværktøjer eller kontrastkontrolprogrammer.
  • Integrer sa11y- eller Lighthouse-tilgængelighedsscanning i CI/CD-pipelines, der bygger på kritiske problemer.
  • Test Experience Cloud-lokaliteter ved brug af støttende teknologi før offentlig lancering.
  • Bekræft auditiv feedback ved at bekræfte, at alle dynamiske ændringer (f.eks. fejltilstande, indlæsning af spinners eller udvidede menuer) er tydeligt annonceret, og det talte indhold matcher brugergrænsefladens visuelle hensigt.

Retfærd i Salesforce Automation

  • Gennemse tildelings- og distributionsregler for korrelation med beskyttede egenskaber, der kan koncentrere gunstige eller ugunstige resultater i specifikke demografiske grupper.
  • Overvåg forløbs- og procesautomatiseringsbeslutningslogik for bias, dokumenter forretningsregler og kriterier i Salesforce Knowledge eller arkitekturbeslutningsregistreringer.
  • Evaluer valideringsregler for afvisningsfrekvenser, der påvirker specifikke datamønstre eller -populationer i uforholdsmæssig høj grad.
  • Analyser område- og segmenteringsdesign for demografisk korrelation, dokumenter eksplicit forretningsjustering og overvåg underbetjente områder for rimelig ressourcetildeling.
  • Underlæg forløb og tildelingsregler (ansættelse, kredit, adgang til service) med høje satser til den samme etiske gennemgangsproces som AI-systemer, og planlæg kvartalsvise revisioner af automatiseringsresultater stratificeret efter demografi.

AI Fairness og bias registrering

  • Overvåg Salesforce CRM-data for demografiske repræsentationsmangel før forudsigende modeluddannelse.
  • Beregn demografisk paritet, lige salgsmulighed og uensartede påvirkningsforhold pr. demografisk gruppe før implementering.
  • Implementer rimelige evalueringer som en obligatorisk implementeringsgate (tænk på dette som at være ækvivalent til en sikkerhedsgennemgang).
  • Opbyg CRM Analytics-dashboards, der sporer rimelighedsmetrikker ved brug af forudsigelsesmodelbeslutningsdata, der er registreret med feltrevisionssporet.
  • Analyser forudsigelsesmodelfunktioner for proxy-korrelation med beskyttede egenskaber (f.eks. område- og kontonavnemønstre).
  • Planlæg omfattende kvartalsvise rimelighedsrevisioner for alle AI-systemer med stor interesse.

Gennemsigtighed og revision

  • Vis Einstein Discovery på beslutningspunkter i Lightning.
  • Konfigurer Einstein Trust Layer-revisionsregistreringer ved brug af bevarelsesmetoder, der opfylder bestemmelseskravene.
  • Aktiver Feltrevisionsspor på alle tilpassede objekter, der lagrer AI-beslutningsdata til langsigtet bevarelse.
  • Eksporter begivenhedsovervågningsdata til et eksternt SIEM – begivenhedslogfildata via API og begivenhedsovervågning i realtid via platformsbegivenheder – til lagring, der overskrider den oprindelige bevarelse, med SIEM-siders skrivebeskyttede kontrolelementer for manipulationsbevis.
  • Angiv brugervenlig konfidenskommunikation (f.eks. Høj, Moderer og Lav) i stedet for rå sandsynligheder.

Menneskelig tilsyn med Salesforce Automation

  • Konfigurer konfidensbaserede eskaleringstærskler i forløb, og distribuer forudsigelser med lav konfidens til human gennemgang.
  • Brug Salesforce-godkendelsesprocesser til beslutninger med stor interesse, der kræver gennemgangskæder med flere faser.
  • Integrer Agentforce og Omni-Channel-distribution for at muliggøre problemfri eskalering til menneskelige agenter.
  • Angiv en vedvarende “Opret forbindelse til menneskelig agent”-indstilling i Agentforce for at respektere brugerbureauet.
  • Kræv dokumenteret grundlæggende og godkendelseshistoriksporing for Agentforce, der registreres i tilpassede felter.

Ikke-diskrimination med dataadgangskontroller

  • Aktiver Privat OWD, og tildel derefter yderligere adgang via rollehierarki og delingsregler.
  • Konfigurer sikkerhed på feltniveau for at skjule følsomme demografiske felter for brugere, der ikke kræver adgang.
  • Overvåg adgangsbegivenheder på objektniveau (rapporteksporter og API-forespørgsler) for følsomme data via Shield-begivenhedsovervågning, og analyser dem for uregelmæssige adgangsmønstre.
  • Opbyg rapporter, der analyserer delingsregeldistributioner for at sikre rimelig registreringstildeling på tværs af områder.
  • Gennemse revisionsspor for opsætning for uautoriserede ændringer af OWD, delingsregel eller FLS-konfiguration.

Brugeragentur og samtykke

  • Design tilpassede samtykkeobjekter ved brug af feltrevisionsspor til at spore detaljeret samtykke til AI pr. anvendelsessituation.
  • Integrer Data 360- eller Marketing Cloud-samtykke med Einstein-personalisering og Agentforce.
  • Gem AI-præferencer i bruger- eller kontaktregistreringer for at sikre ensartethed på tværs af kanaler (f.eks. web, mobil og telefon).
  • Angiv tilgængelige frameldinger i profilindstillinger og personlige alternativer via Omni-Channel-distribution.
  • Forespørg på samtykkeregistreringer i forløbet, før Einstein eller Agentforce påvirker brugere.

Etisk AI-styring

  • Dokumenter alle produktionsforudsigelsesmodeller, herunder fairness-metrikker og reduktionsstrategier. For kundetrænede forudsigelsesmodeller (f.eks. Einstein Discovery og Forudsigelseskonstruktør) skal du også dokumentere træningsdatademografier.
  • Etabler obligatoriske før implementering fairness-portaler, der blokerer implementering, indtil alle fairness-kriterier er opfyldt.
  • Opret et AI-etisk gennemgangspanel som håndhævelsesmyndighed for alle AI-applikationer med stor interesse.
  • Opbyg CRM Analytics-dashboards for at overvåge rimelighedsmetrikker på en planlagt kadence via CRM Analytics-advarsler.
  • Definer hændelsessvarprocedurer for fairnessfejl, og dokumenter processen i Salesforce Knowledge.
  • Planlæg kvartalsvise rimelighedsrevisioner, der analyserer tilsidesættelsesmønstre og brugerfeedback for alle systemer med høje satser.

Del din feedback om den veludformede ramme.