Fairness for the Agentic Enterprise (Rettferdighet for agentforetak)

Rettferdighet for Agentic Enterprise

Når autonome agenter tar beslutninger som påvirker kunder, ansatte og fellesskap, blir rettferdighet den arkitektoniske kvaliteten som skiller ansvarlig automatisering fra skadelig automatisering. Agentforce som opererer med begrenset menneskelig oversikt, opprettholder og forsterker systematiske avvik i en hidtil usett skala, og gjør individuelle diskriminerende mønstre til systemisk ulikhet. Fairness i agentiske systemer er et førsteklasses arkitektonisk problem på Salesforce-plattformen, som kombinerer AI-fairness, tilgjengelighet, menneskelig oversikt, algoritmisk ansvarlighet og etisk styring i en forent arkitektonisk søyle.

Denne siden tar for seg rettferdighetsutfordringer som er unike for agentiske arkitekturer. Kjerneprinsipper for rettferdighet, tilgjengelighetskrav og etiske styringsrammer er dekket av søylen Rettferdighet. Her fokuserer vi på viktige punkter om autonome agenter: Deteksjon av systematiske avvik for agenter som tar konsekvensbeslutninger og overvåkingsmønstre som tar sikte på å gjøre ansvarlighet mer substantiv enn nominell, gjennomsiktighet som tillater berørte brukere å utfordre beslutninger, og plattformfunksjoner som Einstein Trust Layer som støtter ansvarlig AI-praksis gjennom datakontroller og revisjonslogging.

Agentforce agenter lærer mønstre fra opplæringsdata, hentingskilder og interaksjoner i den virkelige verden. Når disse kildene inneholder systematiske avvik som gjenspeiler historisk diskriminering eller demografiske ubalanser, opprettholder agenter disse avvikene med algoritmisk effektivitet som påvirker tusenvis av brukere før mennesker oppdager mønsteret.

  • Grunnmalmodellskjevhet: Store språkmodeller (LLM-er) blir lært opp på data i internettskala som inneholder samfunnsskjevheter rundt rase, kjønn, alder, funksjonshemming og andre beskyttede egenskaper. Disse systematiske avvikene vises i agentsvar selv uten eksplisitte diskrimineringsinstruksjoner, og de vil sannsynligvis ikke bli fullstendig løst gjennom ledetekst eller testing alene. De gjenspeiler mønstre som delvis er iboende i opplæringsdata for internettskalering. En Agentforce kan for eksempel beskrive lederroller med mannlige språkmønstre. Eller en tjenesteagent kan reagere annerledes på kunder hvis navn angir etnisitet eller kjønn som ikke er flertall – et representativt kvalitetsproblem som kan påvirke kundens opplevelse uavhengig av hvilket som helst beslutningsutfall.

Test agenter systematisk for demografiske systematiske avvik ved bruk av forskjellige personaer som representerer beskyttede grupper. Generer identiske forespørsler som varierer bare demografiske signaler som navn, steder eller kommunikasjonsstiler. Sammenlign agentsvar på tvers av personer for kvalitetsforskjeller, tonevariasjoner og utfallsforskjeller.

  • Gap i opplæringsdatarepresentasjon: Hvis organisasjonens historiske CRM-data underrepresenterer bestemte kundesegmenter, vil Agentforce som er opplært eller basert på disse dataene, gjøre det dårlig for disse segmentene. En salgsemnescoringsagent som er opplært på ti års salgsmulighetsdata, undervurderer systematisk prospekter fra geografier som salgsteamet historisk har avprioritert, og oppretter en tilbakemeldingsløyfe der algoritmiske systematiske avvik kombinerer menneskelige systematiske avvik.

Før du bruker Salesforce-data til agentopplæring eller RAG (Retrieval-Augmented Generation) -grunnlegging, må du revidere den demografiske representasjonen. Identifiser underrepresenterte grupper, og vurder om representasjonshull gjenspeiler legitime forretningsforskjeller eller historisk diskriminering. Reduser ubalanser via dataforbedring eller eksplisitt avbøyning av systematiske avvik før du distribuerer agenter. En del gjenværende systematiske avvik har en tendens til å forbli og behandles vanligvis via nedstrøms overvåking og oversikt i stedet for løst før distribusjon.

  • Hentningsforspenning i RAG-systemer: Agentforce som bruker RAG-reaksjoner til lands i Knowledge, Data 360-segmenter og Salesforce-poster. Når disse hentingskildene inneholder skjevt innhold eller varierer i kvalitet på tvers av demografiske grupper, kan den distribuerte agenten bære dette skjevnet inn i opplevelsene til berørte brukere. For å redusere denne risikoen bør du vurdere hentekilder før produksjon som en god fremgangsmåte. En tjenesteagent som henter Knowledge som tilbyr detaljert feilsøking for bedriftskunder, men bare generelle svar for små bedriftskunder, vil opprettholde forskjeller i tjenestenes kvalitet, et rettferdighetsproblem der kundelager korrelerer med beskyttede egenskaper.

Revider Knowledge og hentingskilder for gap i demografisk representasjon og kvalitetsforskjeller. Der det er vanskelig å lukke hull, behandler du disse begrensningene som sikkerhetsklargjøringer for hvor agenten passer godt. Forsikre deg om at dokumentasjonens kvalitet, fullstendighet og nøyaktighet er sammenlignbare på tvers av alle kundesegmenter. Inkluder mangfoldig representasjon i innholdseksempler i stedet for å bruke referanser til majoritetskulturer som fremhever underrepresenterte brukere som standard.

  • Interaksjonsmønster bias: Agenter kan tilpasse virkemåten basert på samtaletips som er korrelert med beskyttede egenskaper. Overvåking av dette mønsteret er en vanlig fremgangsmåte selv etter distribusjon, fordi noen interaksjonsdynamikker kommer fra brukervirkemåte som ikke finnes i opplæringsdata. Kommunikasjonsstil, språkkompleksitet og tidsmønstre kan signalisere demografisk informasjon. En agent som behandler formelle kommunikasjonsstiler annerledes enn tilfeldige stiler, kan utilsiktet diskriminere på grunnlag av kulturell bakgrunn, utdanningsnivå eller status for morsmål.

Overvåk agentinteraksjoner på tvers av demografiske grupper for å oppnå konsistens i virkemåten. Analyser responslengde, detaljnivå, høflighetsmarkører og løsningskvalitet lagd etter brukeregenskaper. Ulikheter antyder interaksjonsskjevhet som krever undersøkelse.

  • Tilbakemeldingsløyfeamplifisering: Agenter som påvirker sine egne fremtidige opplæringsdata, skaper selvforsterkende systematiske avvik. En rutingsagent som for eksempel tildeler færre salgsmuligheter med høy verdi til bestemte salgsområder, genererer for eksempel færre vellykkede data for disse områdene. Det reduserer i sin tur deres forutsagte suksesssannsynlighet, noe som ytterligere reduserer fremtidig ruting av salgsmuligheter til dem. Uten intervensjon vil dette initielle systematiske avviket skje over tid.

Oppdag tilbakemeldingsløyfer ved å overvåke endringer i beslutningsfordeling over tid. Når bestemte demografiske grupper systematisk mottar færre positive utfall, undersøker du om agentbeslutninger skaper ulikhet som berettiger fremtidige negative beslutninger. Bryt sløyfer gjennom menneskelig gjennomgang av kantsaker og periodisk ombalantering.

Når flere Agentforce agenter arbeider sammen i orkestreringskjeder, blir systematiske avvik fra én agent input til nedstrøms agenter, noe som skaper sammenslåingseffekter der små innledende avvik forsterkes til betydelige diskriminerende utfall.

  • Sekvensielle agentkjeder: Når agent As utdata blir agent Bs inndata, er det en risiko for at agent As systematiske beslutninger begrenser agent Bs alternativer på måter som opprettholder eller forsterker diskriminering.

Vurder en salgsemnekvalifikasjonsorkestrering:

  1. Research Agent samler Kundeintelligens fra nettkilder og CRM-historikk.
  2. Scoringsagent tildeler salgsemnescore basert på Finner fra Research Agent.
  3. Rutingsagent tildeler salgsemner til områder basert på score.
  4. Engasjementsagent tilpasser oppfølging basert på alle tidligere agentutdata.

Når Research Agent systematisk henter mindre omfattende data for bestemte kundedemonstrasjoner (på grunn av gap i opplæringsdata eller henteskjevhet), tolker Scoring Agent ufullstendig informasjon som negative signaler. Rutingsagent tildeles deretter til område med lavere prioritet, og Engasjementsagent gir mindre tilpasset oppfølging. Sammenslåingseffekten skaper forskjeller i tjenestekvalitet som langt overskrider eventuelle individuelle agenters systematiske avvik.

  • Parallell agentkonsensus: Mønstre der flere agenter uavhengig analyserer de samme inndataene og resultatene aggregeres, gir muligheter for forsterkning av systematiske avvik når agenter deler opplæringsdata eller grunnmodeller.

Hvis fem agenter uavhengig scorer et salgsemne, men alle deler systematiske opplæringsdata eller grunnmodellskjevheter, korrigerer ikke konsensus systematiske avvik – det validerer dem bare. "Fem agenter avtalt" gir falsk tillit til diskriminerende utfall når alle fem deler samme systematiske systematiske systematiske avvik.

Mitigation strategier for orkestrering bias:

  • Agentutdatarevisjon i hver fase: Logg fullstendige inndata og utdata for hver agent i orkestreringskjeder. Når systematiske avvik oppdages i endelige utfall, sporer du tilbake gjennom kjeden for å identifisere hvilken agent som introduserte systematiske avvik og i hvilken fase amplifisering skjedde.

Bygg CRM Analytics-kontrollpaneler som viser beslutningsfordelinger i hver orkestreringsfase, delt inn etter demografi. Identifiser hvor forskjeller i kjeden dukker opp eller utvides.

  • Diversitet i agentopplæring og - Diversitet reduserer korrelerte feil, noe som reduserer sannsynligheten for systematiske avvik. Maksimer variasjon når du bruker konsensusmønstre for flere agenter:
  • Forskjellige grunnmodeller der det er kommersielt mulig og støttes, som gjennom konfigurasjoner av Bring Your Own LLM (BYOLLM)
  • Forskjellige hentekilder på tvers av agenter
  • Forskjellige fremgangsmåter for ledetekst
  • Kalibrering av forskjellige konfidens terskler
  • Human gjennomgang ved infleksjonspunkter: Identifiser faser i orkestreringen der beslutninger betydelig avgrenser nedstrøms alternativer. Sett inn en menneskelig gjennomgang ved disse omregningspunktene selv om individuell agentkonfidens er høy. Orchestration opretter emergente effekter, som individuelle agentkonfidensscores ikke registrerer.
  • Riktighetsmålinger per orkestreringsfase: Ikke bare måle rettferdighet for sluttresultater. Beregn demografisk paritet, lik salgsmulighet og ulik innvirkning i hver fase i kjeden.

Hvis fase 1 viser 90 % demografisk paritet, fase 2 viser 85 %, fase 3 viser 78 % og fase 4 viser 70 %, vises hver fase akseptabel i isolasjon, men sammensettes til uakseptabelt sluttforskjell. Fasevise målinger fanger opp sammensetting før det produserer diskriminerende utfall.

  • Kretsbrytere for orkestreringsfeil - Konfigurer orkestreringslogikk til å stoppe og eskalere til mennesker når:
  • Eventuell agentkonfidens faller under terskelen selv om nedstrøms agenter er sikre
  • Utdatadistribusjon endres betydelig mellom orkestreringsfaser
  • Beslutningskjede møter data som ikke er representert i opplæring eller valideringssett
  • Brukeren spør eksplisitt om eller utfordrer midlertidige beslutninger

Orkestrering med flere agenter muliggjør avansert resonans, men oppretter ugjennomsiktige beslutningskjeder der ansvarlighet diffunderer og systematiske avvik forekommer. Arkitektonisk oppmerksomhet på overvåking av gradvis rettferdighet og strategisk menneskelig oversikt hindrer orkestrering fra å bli en mekanisme for forsterkning av systematiske avvik.

Før du distribuerer Agentforce som tar konsekvensbeslutninger om brukere, må du beregne rettferdighetsmålinger på tvers av demografiske grupper. Gjør en rettferdighetsvurdering til en obligatorisk distribusjonsgate ekvivalent i autorisasjon til sikkerhetsvurdering.

  • Demografisk paritet: Positive utfallsfrekvenser må være omtrent like på tvers av beskyttede demografiske grupper. Hvis en agent godkjenner tjenesteforespørsler for gruppe A med en frekvens på 60 %, men gruppe B med en frekvens på 40 %, brytes den demografiske pariteten. Demografisk paritet er hensiktsmessig når det ikke er noen legitim årsak til forskjeller mellom utfallsfrekvenser på tvers av grupper.

Beregn demografisk paritet ved å dele opp populasjonen i demografiske segmenter, måle positive utfallsfrekvenser per segment og sammenligne antall på tvers av segmenter. Dokumenter paritetshull med navngitte godkjennere og grunnlag.

  • Lik salgsmulighet: Sann positive verdier forblir sammenlignbare på tvers av grupper. Agenter identifiserer kvalifiserte enkeltpersoner like godt uavhengig av demografiske egenskaper. En forutsigelsesmodell gjenkjenner kreditværdige ansøgere med lignende satser på tværs af beskyttede grupper, når den underliggende kreditværdi er ens.

Lik salgsmulighet er ofte den mer hensiktsmessige målingen enn demografisk paritet for beslutninger om individuelle kvalifikasjoner, der basisgrader kan avvike med rette. Overvåk om agenter systematisk mangler kvalifiserte kandidater fra underrepresenterte grupper. Hvis det fremdeles er forskjeller etter avbøying, er det ikke sikkert at agenten er egnet for dette bruksområdet.

  • Utført odds: Både sanne positive andeler og usanne positive andeler er like på tvers av grupper. Dette er en streng definisjon som begrenser både antall sanne positive og false positive på tvers av demografi. Justert odds forhindrer både manglende salgsmuligheter i å konsentrere seg i bestemte grupper og falske anklager i å konsentrere seg i bestemte grupper.

Oppnåelse av lik odds krever ofte separate beslutningsterskeler per demografisk gruppe. I USA er det i henhold til tittel VII (Civil Rights Act of 1964) for ansettelsesrelaterte beslutninger forbudt å justere scorer eller å fastsette forskjellige avgrensningsscorer etter beskyttet klasse, slik at like odds ikke kan søkes på denne måten ved ansettelse. I andre sammenhenger og i andre jurisdiksjoner reiser det juridiske spørsmål om eksplisitt forskjellig behandling, så rådfør deg med en juridisk rådgiver før du implementerer gruppespespespesifikke terskler.

  • Ulik påvirkning: Fire-femte-regelen gir en screening terskel: Hvis en gruppe mottar positive utfall med mindre enn 80 % i forhold til gruppen med høyest resultat, undersøker du om det er systematiske avvik. Et 75 %-forhold (for eksempel en 45 %-godkjenningsgrad kontra en 60 %-godkjenningsgrad) faller under terskelen på fire femter og angir potensiell diskriminering som krever begrunnelse eller avbøying.

Uensartet innvirkningsanalyse er standard i ansettelsesloven og brukes i økende grad på AI-systemer. Når porsjoner faller under 80 %, dokumenterer du undersøkelsen og utbedringstrinnene. Når utbedring ikke hever forholdet, kan team konkludere med at bruksområdet ikke passer godt.

  • Individual fairness: Lignende enkeltpersoner mottar lignende forutsigelser uavhengig av gruppemedlemskap. To kunder med identisk kredittverdi, kjøpshistorikk og engasjement mottar lignende kredittgrenseanbefalinger uavhengig av demografiske forskjeller.

Individuell rettferdighet er filosofisk viktig, men operasjonelt utfordrende fordi "likhet" er subjektiv og kontekstuelt avhengig. Bruk individuell rettferdighet som et utformingsprinsipp som veileder valg og testing av funksjoner, i stedet for en streng matematisk begrensning.

To plattformfunksjoner fanger opp data for deteksjon av systematiske avvik. Einstein Trust registrerer et generativt AI-revisjonsspor for hver Agentforce: meldingene som sendes til modellen, de returnerte svarene, de brukte jordingskildene og Trust som toksisitetsscore. Agentforce øktsporing registrerer den trinnvise begrunnelsen bak hver beslutning. Sammen gir de data som støtter oppdagelse av systematiske avvik og overvåking av rettferdighet. Tolkningen av disse dataene er menneskelig arbeid, og krever vanligvis opplærte revisorer og dedikert tid.

  • Svarlogging: Trust logger ledetekster, modellsvar og Trust for hver generative interaksjon. Bruk disse dataene til å analysere forutsigelsesfordelinger på tvers av demografiske grupper. Bygg CRM Analytics-kontrollpaneler som sammenligner godkjenningsgrader, anbefalingsmønstre og risikoscorer etter kundesegment.

Spørrings Trust-lag logges regelmessig: Bruk følgende ledetekst: "Vis meg alle forutsigelser for salgsmuligheter med høy verdi de siste 30 dagene gruppert etter kundebransje, område og kontostørrelse. Er forutsigelsesfordelinger konsistente på tvers av segmenter, eller blir visse segmenter systematisk scoret høyere/lavere?"

  • Reasoning sporfangst: For Agentforce registrerer Agentforce hvordan agenten kom til sin beslutning, mens Trust Layer-revisjonssporet fanger opp ledetekster, svar og landingskilder, inkludert hvilke Knowledge og Salesforce-poster som ble hentet. Se gjennom begge når brukere rapporterer systematiske avvik for å forstå hvilke datakilder, hentingsmønstre eller begrunnelsestrinn som kan ha innført systematiske avvik.

Årsaksspor gjør post-hoc fairness-revisjoner mer detaljerte og enklere å utføre enn de var med tradisjonelle systemer. Eksempel på 100 agentbeslutninger lagret etter demografisk gruppe, og få de som vurderer, til å vurdere om vurderingskvaliteten er sammenlignbar på tvers av grupper.

  • Anomaly detection: Konfigurer varsler når agentbeslutningsmønstre avviker betydelig fra standarden. Hvis godkjenningsgraden for et bestemt kundesegment faller 20 % uke for uke, utløses undersøkelse. Plutselig forskyvning av fordelingen kan indikere Datakvalitetsproblemer, modellforskyvning eller nye systematiske avvik som krever umiddelbar oppmerksomhet.

Bygge tilpasset overvåking for å varsle om rettferdighetssignaler: Varsle når gjennomsnittlig samtalevarighet for Agentforce tjenesteagent for et kundesegment overskrider 1,5 ganger det generelle gjennomsnittet i tre påfølgende dager. Lengdeforskjeller kan indikere at enkelte grupper mottar mindre effektiv service.

  • Fairness-kontrollpanelmaler: Bygg gjenbrukbare CRM Analytics-kontrollpanelmaler som sporer rettferdighetsmålinger for vanlige agentbrukstilfeller. Inkluder beregninger av demografisk paritet, lik salgsmulighetsmålinger, ulik innvirkningsforhold og trenddiagrammer som viser målingens utvikling over tid. Del maler på tvers av agentutviklingsteam som standardiserer overvåking av rettferdighet.

Når systematiske avvik oppdages, bruker du avbøying i riktig fase basert på rotårsaken.

  • Forhåndsbehandling av data: Korrigere systematiske avvik på datanivå før agentopplæring eller RAG-indeksering. Eksempel på underrepresenterte demografiske grupper i opplæringsdata som sikrer balansert representasjon. Syntetiser flere data for underrepresenterte grupper ved å bruke teknikker som SMOTE (Synthetic Minority Oversampling Technique) når reelle data er utilstrekkelige. Vær oppmerksom på at SMOTE interpolerer numeriske tabellfunksjoner, så den gjelder for strukturerte CRM-opplæringsdata, ikke den ustrukturerte teksten som brukes til RAG-landing.

Revider Salesforce CRM-data for å finne demografiske hull før du bruker dem til modellopplæring. Hvis historiske salgsmulighetsdata overrepresenterer bestemte kundetyper, må du balansere opplæringssett på nytt eller bruke utvalgsvekt som hindrer agenter i å lære denne overrepresentasjonen som et beslutningssignal.

  • Begrensninger for algoritmer under behandling: Bruk rettferdighetsbegrensninger under modellopplæring som optimaliserer for både nøyaktighet og rettferdighet samtidig. Dette kan redusere rå nøyaktighet med 2-3 % samtidig som det dramatisk forbedrer rettferdigheten på tvers av grupper. Der du kontrollerer modellopplæring, er rettferdighetsbegrenset opplæring ofte den mest effektive tilnærmingen til avbøying.

For Agentforce som bruker grunnmodeller der du ikke kan endre opplæring, begrenser du agentvirkemåten via systemledetekster: "Behandle alle kundedemonstrasjoner med like profesjonalitet og detaljer. Gi forklaringer av sammenlignbar lengde og kvalitet uavhengig av kundekommunikasjonsstil eller bakgrunn."

  • Terskeljustering etter behandling: Når det er lovlig, kan justering av beslutningsterskeler per demografisk gruppe gjøre utfallstall likt etter modellopplæring. En godkjenningsagent kan for eksempel bruke en konfidens terskel på 80 % for én gruppe og en terskel på 75 % for en annen for å forskyve underliggende modellskjevhet. Antidiskrimineringsloven begrenser denne teknikken sterkt, og noen jurisdiksjoner forbyr den direkte for bestemte beslutninger (se nedenfor).

Tærskkeljustering er kontroversiell fordi den eksplisitt behandler grupper forskjellig, og anti-diskrimineringsloven i mange jurisdiksjoner begrenser eller forbyr det. I USA er det strengt forbudt for ansettelsesrelaterte beslutninger: Tittel VII (Civil Rights Act of 1964) hindrer justering av score eller bruk av forskjellige skjæringsscore etter beskyttet klasse, og ingen dokumentert begrunnelse gjør praksisen lovlig. Andre jurisdiksjoner har sine egne begrensninger, så kontroller reglene som gjelder for brukerne. Når praksisen er tillatt, dokumenterer du juridisk begrunnelse når du implementerer gruppespespespesifikke terskler, og kontrollerer at terskler forbedrer rettferdigheten uten å skape andre diskriminerende effekter.

  • Proxy funksjons deteksjon og fjerning: Identifiser funksjoner som er korrelert med beskyttede egenskaper og fungerer som indirekte diskrimineringsmekanismer. Vanlige proxyer inkluderer følgende:
  • ZIP-kodeproxyer for rase, etnisitet og inntektsnivå
  • Navn mønstre proxy for kjønn og etnisitet
  • Kommunikasjonstidsplaner for religion og omsorgsansvar
  • Enhetstype proxyer for inntektnivå
  • Områdetildeling kan bidra til demografisk sammensetning

Beregne korrelasjonskoeffisienter mellom alle modellfunksjoner og beskyttede egenskaper. For høyt korrelerte funksjoner evaluerer du om en legitim forutsigelsesverdi berettiger inkludering eller om alternative funksjoner kan gi lignende forutsigelser uten proxyeffekter.

Agentforce agenter kan operere med menneskelig tilsyn som er utformet for å gjøre gjennomgang mer substantiv enn nominell. Det riktige overvåkingsnivået avhenger av beslutningstakten, reversibilitet og lovpålagte krav.

Rut konsekvensbeslutninger gjennom menneskelig gjennomgang før utførelse. Om en beslutning er høy nok til å kreve gjennomgang fra en person, er en risikobasert vurdering: vekter alvorlighetsgraden av den potensielle skaden og sannsynligheten for at den skaden oppstår. Konsekvensbeslutninger oppstår ofte innenfor regulerte domener som helsetjenester, finansielle tjenester og offentlig sektor, men de oppstår også utenfor dem. Vanlige kontekster med høy innsats inkluderer følgende:

  • Arbeidsbeslutninger - Ansettelse, forfremmelse, oppsigelse, kompensasjon, ytelsesvurdering
  • Kreditt- og finanstjenester - Godkjenning av kreditt, endringer i grenser, avslutning av kontoer, priser
  • Helse - Diagnoseforslag, behandlingsanbefalinger, dekningsbeslutninger
  • Juridiske rettigheter - Tolkning av kontrakter, tvisteløsning, tilgang til tjenester
  • Husing - leietagerundersøkelse, leasinggodkjenninger, anbefalinger om utvisning

Utform Agentforce i disse kontekstene for å analysere, anbefale og klargjøre beslutninger samtidig som det kreves godkjenning fra personer før utførelse. Plasser agenter som beslutningsstøtteverktøy som forbedrer menneskelig dømmekraft, ikke autonome beslutningstagere som erstatter mennesker.

Konfigurer konfidens terskler som utløser vurdering fra person basert på agentusikkerhet:

  • Høy konfidens (>90%) - Agent fortsetter automatisk med full revisjonslogging
  • Målig konfidens (70-90%) - Agent anbefaler med menneskelig gjennomgang før handling
  • Lav konfidens (<70%) - Agent overfører helt til menneske med kontekstsammendrag

Kalibrere terskler ved bruk av produksjonsdata. En 70 % konfidens-forutsigelse lykkes omtrent 70 % av tiden når den valideres. Feilkalibrerte konfidensresultater undergraver Trust i eskaleringsmekanismer.

Test kalibrering ved å prøve agentbeslutninger i hvert konfidensbånd og beregne faktiske suksessfrekvenser. Hvis beslutninger med høy konfidens lykkes bare 75 % av tiden, skal du omkalibrere terskler eller forbedre beregningen av modellkonfidens.

Hvis Agentforce ikke kan løse en forespørsel innenfor definerte grenser, eskalerer du til brukere. Kontroller at eskaleringsmålet har kapasitet til å rute hjelp til overbelastede køer, reduserer ikke skaden.

Angi eskaleringsutløsere:

  • Samtale svinger – Etter 5-7 svinger uten oppløsning, eskalere
  • Utløpt tid – Etter 10 minutter uten oppløsning, eskaler
  • Brukersentiment – Eskaler når brukeren uttrykker frustrasjon
  • Gjentagelsesdeteksjon – Eskaler når agenten gjentar samme respons

Konfigurer Omnikanal til å rute eskalerte saker til riktige kvalifikasjonsbaserte køer med full samtalekontekst. Lær opp menneskelige agenter til å håndtere eskaleringer effektivt uten å kreve at brukere gjentar informasjon som allerede er gitt til agenten.

Gi autoriserte personer mulighet til å overstyre eventuelle Agentforce når som helst med dokumentert grunnlag. Overstyringer har flere formål:

  • Feilkorreksjon: Brukere korrigerer agentfeil som kan skade brukere eller bryte policyen. Overstyringsfunksjonalitet gir en sikkerhetsventil for autonome systemer som opererer i komplekse miljøer der kanttilfeller er uunngåelige.
  • Bias-deteksjon: Hvis mennesker overstyrer Agentforce oftere for bestemte demografiske elementer enn andre, undersøker du begge mulighetene: agenten kan være systematisk ugunstig for gruppen, og brukere kan korrigere den, eller overstyring kan introdusere nye systematiske avvik. Det første mønsteret peker til å gå gjennom agenten, og det andre mønsteret peker til gjennomgangsopplæring.
  • Agentforbedring: Overstyringer med begrunnelse blir opplæringsdata for agentforbedring. Eksempel på overstyrte beslutninger, og analyser hvorfor personer ikke er enige med agenter. Inkorporer overstyringsmønstre i ledetekstforbedring eller modellgjennomgang.
  • Forvaltning: Overstyrer tildeling av ansvar. Den menneskelige overstyringen av en agentbeslutning tar ansvar for denne beslutningens utfall. Tydelig ansvarlighet hindrer spredning av ansvar der alle forutsetter at AI er ansvarlig og ingen tar eierskap.

Tildel ansvar før distribusjon, ikke etter at hendelser oppstår:

  • Modelleier: Datavitenskapsledelsen er ansvarlig for modellens rettferdighet, nøyaktighet og virkemåte. Godkjenner distribusjoner, svarer på rettferdighetsvarsler, godkjenner oppdateringer. Modelleieren er en navngitt person som er dokumentert i arkitekturbeslutningsposter.
  • Beslutningseier: Product owner accountable for choosing to distribute AI for specific use case and for real world impact on customers (Produkteier ansvarlig for valg av å distribuere AI for bestemte bruksområder og for virkelige kunder. Beslutningseieren kan ikke delegere ansvar til AI-systemer.
  • Appelinstans: Etikkvurderingsrådet eller det utpekte teamet håndterer klager fra brukere som mener agentbeslutninger var urettferdige. Appellprosesser må være tilgjengelige, tidsriktige og autoriserte til å reversere agentbeslutninger.
  • Revisjonsmyndighet: Samsvarsteamet som utfører periodiske revisjoner, validerer agenter som arbeider innenfor rettferdighetsparametere, og kan suspendere agenter som mislykkes i standarder, i påvente av rettelse.

Dokumenter alle roller med navn, ikke bare titler, slik at ansvarlighet beholdes gjennom organisasjonsendringer.

Når Agentforce tar beslutninger som påvirker brukere, fortjener disse brukerne forståelige forklaringer som er proporsjonale med beslutningens innvirkning.

Arkitekter flere forklaringslag som betjener forskjellige målgrupper:

  • Brukerrett forklaringer: Rett språk for forståelse uten teknisk ekspertise. "Tjenesteforespørselen krever ledergodkjenning fordi det forespurte beløpet (12 000 USD) overskrider godkjenningsgrensen (10 000 USD). Godkjenning av ledere fullføres vanligvis innen 24 timer, eller innenfor rammen av den avtalte tjenestenivåavtalen (SLA)."
  • Forretningsforklaringer: Driftsbrukere ser viktige beslutningsfaktorer med forretningskontekst. "Salgsemnescore: 73/100. Primære positive faktorer: Firmastørrelse (500 ansatte), Aktivt nettstedsengasjement (12 besøk på 30 dager), Bransjesamsvar (SaaS). Primære negative faktorer: Ingen MQL-engasjement, utenfor målområde."
  • Tekniske forklaringer: Datateknikere ser modelldetaljer: funksjonsvekter, konfidenskalibrering, modellversjon, opplæringsdato, inndatadistribusjoner. Tekniske forklaringer støtter feilsøking og undersøkelser av systematiske avvik.
  • Revisjonsforklaringer: Samsvarsteam ser fullstendige beslutningssporinger: modellversjon, eksakte inndataverdier på beslutningstidspunktet, alle datakilder som er konsultert, vurderingssporing, konfigurasjonsstatus. Revisjonsforklaringer støtter regulatoriske undersøkelser og rettferdighetsrevisjoner som krever nøyaktig rekonstruksjon.

Agentforce registrerer trinnvis resonans bak agentbeslutninger, mens Einstein Trust fanger opp revisjonssporet for ledetekster og svar, inkludert tilordningskilder. Sammen lar de deg gi gjennomsiktighet på riktig detaljnivå:

  • Sanntids gjennomsiktighet: Når Agentforce tar en beslutning, viser du sammendragsgrunnlaget til brukerne: "Jeg anbefalte Produkt A basert på kjøpshistorikken din (3 lignende kjøp), gjeldende promotering (20 % avslag) og tilgjengelighet av lagerbeholdning (på lager, leveres i morgen)."
  • På forespørsel detaljert forklaring: Oppgi "Hvorfor anbefalte du dette?" lenke som gir brukere mulighet til å vise fullstendig resonans, inkludert alle Knowledge hentet, Salesforce-poster konsultert og beslutningslogikk. Detaljerte forklaringer bygger Trust og gir brukere mulighet til å identifisere feil eller systematiske avvik.
  • Historisk gjenoppbygging: Når brukere utfordrer tidligere beslutninger uker eller måneder senere, henter de øktbegrunnelsesspor og Trust Layer-revisjonshistorikken som muliggjør nøyaktig forklaring av historiske beslutninger. Historisk rekonstruksjon støtter klager og forskriftsundersøkelser.
  • Aggregate mønster analyse: Eksempel på vurderingssporing lagd etter demografiske grupper for å analysere om beslutningskvaliteten er konsistent. Se gjennom 100 spor fra hvert kundesegment, og vurder om begrunnelsesdybde, kildekvalitet og logikk er sammenlignbare på tvers av grupper.

Vis forutsigelseskonfidens i brukervennlige termer for å unngå rå sannsynlighetsscore som brukere feiltolker.

I stedet for "73% konfidens" kommuniserer du konfidens som:

  • Høyt tillit – "Jeg er sikker på at denne anbefalingen er hensiktsmessig basert på lignende saker"
  • Målig tillit – "Denne anbefalingen er sannsynligvis hensiktsmessig, men ledergjennomgang anbefales"
  • Lav tillit – "Denne situasjonen er uvanlig. Jeg eskalerer til en spesialist som kan gi bedre veiledning."

Forklar hva konfidensnivået betyr for pålitelighet: "Høye konfidensanbefalinger er riktig omtrent 95 % av tiden basert på historisk validering."

For moderate eller lavkonfidensbeslutninger forklarer du hvilken ekstra gjennomgang som skal skje: "I og med at denne forespørselen faller utenfor standardparameterne våre, vil den bli gjennomgått av en seniorspesialist med godkjenning som vanligvis fullføres innen 24 timer, eller innenfor din avtalte tjenestenivåavtale (SLA)."

Vis brukere om nødvendig hva som kan endre utfallet. Kontrafaktum gir brukere mulighet til å forbedre utfall gjennom bestemte handlinger i stedet for bare å informere dem om beslutninger som allerede er tatt.

For eksempel: "Salgsemnescoren vil øke med bekreftet ansettelsesinformasjon (+8 poeng) og flere kredittreferanser (+5 poeng). Hvis du leverer denne dokumentasjonen, flyttes programmet til køen for prioritetsgjennomgang."

Kontrafaktum er kraftige gjennomsiktighetsmekanismer, men krever nøye utforming. Unngå å oppgi motfakta som oppfordrer til å spille systemet eller som utilsiktet avslører beskyttede egenskaper som beslutningsfaktorer. "Ditt program vil gi høyere score hvis du var 10 år yngre" er ulovlig diskriminering, ikke nyttig gjennomsiktighet.

I enkelte jurisdiksjoner er tydelig offentliggjøring av at brukere samhandler med en robot, et juridisk krav, ikke bare en anbefalte fremgangsmåte for utforming. Angi tydelig når brukere samhandler med Agentforce i stedet for med brukere. Visning må være fremhevet og kontinuerlig, ikke begravet når det gjelder service eller vises bare én gang ved interaksjonsstart.

Vise faste visuelle indikatorer:

  • Agent avatar tydelig merket "AI-assistent"
  • Topptekst som viser "Du chatter med en Agentforce tjenesteagent"
  • Alternativet "Koble til personagent" synlig i løpet av samtalen

Visning respekterer brukerautonomi som aktiverer informert valg om interaksjonsmodus. Brukere som foretrekker menneskelig interaksjon, må ha dette alternativet uten friksjon eller straffer for tjenestenes kvalitet.

Salesforce Platform-funksjoner som Hendelsesovervåking og Feltrevisjonsspor, som er før agentisk AI, utvider algoritmisk ansvarlighet til beslutningene individuelle agenter tar.

  • Event Monitoring for agenthandlinger: Hendelsesovervåking fanger opp agentdatatilgang, API-kall og systemendringer med Salesforce-styrt integritet. Strømhendelsesovervåking logger til ekstern SIEM for langsiktig oppbevaring og manipulering av bevis som oppfyller lovpålagte krav for konsekvensbeslutninger.

Konfigurer hendelsesovervåking for å spore:

  • API-hendelseslogger som viser interaksjoner mellom agentsystemer
  • Påloggingshendelser for agenttjenestekontoer
  • Rapporter eksporteres når agenter får tilgang til gruppedata
  • Feltrevisjonsspor for AI-påvirkede data: Standard felthistorikk beholder dataendringer i 18 måneder (24 måneder via API-et). Med Feltrevisjonsspor kan du beholde felthistorikk på ubestemt tid – arkivere den etter opptil 18 måneder, og deretter beholde de arkiverte dataene til du sletter dem – for å støtte langsiktige rettferdighetsrevisjoner og regulatoriske undersøkelser. Aktiver Feltrevisjonsspor for objekter som lagrer eller påvirkes av agentbeslutninger, ved å velge blant standardobjektene Feltrevisjonsspor støtter pluss eventuelle tilpassede objekter med felthistorikksporing aktivert (opptil 200 felt per objekt).

For kredittbeslutninger, ansettelsesbeslutninger og andre brukstilfeller med høy risiko kan oppbevaring over flere år være et lovpålagt krav. Oppbevaringsperioder varierer etter regime. Bekreft det aktuelle kravet for bruksområdet.

  • Skjoldhendelsesovervåking for høyeste innsats: Shield-hendelsesovervåking gir forbedret revisjonsfunksjonalitet med strukturerte hendelsesfelt og integrasjon med samsvarsrapporteringsverktøy. Hendelsesloggfildata beholdes som standard i ett år for både Hendelsesovervåking- og Shield-kunder. Bruk Shield til agentbeslutninger med størst risiko der revisjonssporintegritet er avgjørende.

Lagre tilstrekkelig informasjon til å rekonstruere eventuelle historiske agentbeslutninger presist:

  • Modelversjon: Registrer hvilken modellversjon (grunnmodell, ledetekstversjon, finjustert modell-ID) som tok hver beslutning. Modellversjoner endres ofte og produserer forskjellige utdata. Presis versjonssporing aktiverer rotårsaksanalyse når systematiske avvik oppdages.
  • Inndatafunksjonsverdier: Lagre nøyaktige inndataverdier på beslutningstidspunktet, ikke gjeldende verdier som kan ha blitt endret. Med inndataøyeblikksbilder kan du teste om en beslutning ville vært annerledes med gjeldende data, eller bekrefte at den opprinnelige beslutningen var riktig gitt informasjon som var tilgjengelig på det tidspunktet.
  • Konfigurasjonsstatus: Registrer terskler, forretningsregler og parameterinnstillinger som er aktive på beslutningstidspunktet. Konfigurasjonsendringer påvirker utfall. Konfigurasjonshistorikk aktiverer å bestemme om beslutningsavvik gjenspeiler modellendringer eller konfigurasjonsendringer.
  • Miljøkontekst: Registrer relevant kontekst: brukeridentitet, tidsstempel, samtalehistorikk, øktkontekst. Kontekst påvirker agentvirkemåten og må beholdes for nøyaktig rekonstruksjon.

Deteksjon av systematiske avvik må være kontinuerlig, ikke engangsvalidering før distribusjon. Agenter utvikles via ledetekstoppdateringer, endringer i grunnmodellversjoner og skift av datadistribusjoner.

  • Fairness-målingskontrollpaneler: Bygg CRM Analytics-kontrollpaneler som sporer rettferdighetsmålinger fra Einstein Trust Layer-logger. Overvåk demografisk paritet, lik salgsmulighet og forskjellige innvirkningsforhold kontinuerlig. Konfigurer varsler når målinger bryter definerte terskler.

Opprett et kontrollpanel som viser følgende:

  • Beslutningsfordeling etter kundedemografiske segmenter (stolpediagrammer)
  • Fairness-målinger over tid (trendlinjer med varselterskler)
  • Uensartet beregning av innvirkningsforhold med indikator med fire femtedeler
  • Fremste forutsigere som bidrar til beslutninger, der den underliggende modellen viser dem
  • Overstyringsgrad etter demografisk gruppe
  • Distribusjonsskiftdeteksjon: Overvåk agentinndistribusjoner for endringer som indikerer potensielle rettferdighetsproblemer. Hvis den demografiske sammensetningen av brukere som mottar agentbeslutninger, skifter betydelig fra opplæringsdatademografien, kan modellens rettferdighet reduseres.

Varsel når inndatadistribusjoner endres: "Kundesegmentfordeling for Agentforce har flyttet med 15 % mot Enterprise de siste 30 dagene. Se gjennom om rutingslogikk forblir rettferdig for SMB-kunder som nå mottar forskjellige tjenestemønstre."

  • Brukertilbakemeldingsintegrering: Gi brukere mulighet til å rapportere oppfattet systematiske avvik via tilgjengelige mekanismer. Brukerrapporter viser kvalitative problemer med kvantitative målinger som mangler.

Legg til alternativet Rapporter bekymring i Agentforce chattegrensesnitt. Rut rapporter til etikettsjennomgangspanelet med fullstendig samtalekontekst. Spor rapporter i et tilpasset objekt med en nødvendig undersøkelsesarbeidsflyt og en dokumentert løsning.

Utform agentarkitekturer som forutsier eksterne revisjoner av regulatorer, organisasjoner for menneskerettigheter eller kunder som krever algoritmiske demonstrasjoner av ansvarlighet.

  • Eksportmuligheter: Bygg eksportfunksjonalitet som gir samsvarsteam mulighet til å trekke ut fullstendige beslutningsdatasett med demografisk stratifisering for gjennomgang av eksterne revisorer. Eksportører må respektere datapersonvernforskrifter samtidig som de gir tilstrekkelig gjennomsiktighet for validering av rettferdighet.
  • Revisjonsdokumentasjon: Vedlikehold gjeldende dokumentasjon:
  • Agentformål og tiltenkte brukstilfeller
  • Opplæringsdatademografi og kjente begrensninger
  • Fairness-målinger beregnet før distribusjon og i produksjon
  • strategier for avverging av systematiske avvik som er brukt
  • konfigurasjoner for menneskelig oversikt
  • Overvåke tilgangs- og varselterskler
  • Tildelinger av ansvar (modelleier, beslutningseier, klageinstans)
  • Algoritmeinnvirkningsvurderinger: Før du distribuerer agenter som tar konsekvensbeslutninger, utfører du innvirkningsvurderinger som evaluerer potensielle positive og negative effekter på tvers av interessentgrupper. Påvirkningsvurderinger viser due diligence og proaktiv risikobehandling som er verdsatt av regulatorer.

Brukere beholder en meningsfylt kontroll over hvordan Agentforce påvirker opplevelsen sin.

  • Opt-in for etterfølgende agenter: Agenter som tar beslutninger som påvirker brukere betydelig, krever eksplisitt påmelding i stedet for å være aktive som standard. Kreditbeslutningsagenter, ansettelsesvurderingsagenter og tjenesteberettigelsesagenter aktiveres bare etter at brukerne har samtykket, med en klar forståelse av hvordan agenten vil påvirke dem.
  • Granular Consent: Aktiver samtykke per agentbrukstilfelle i stedet for totalt AI-samtykke. En kunde kan samtykke til Agentforce ved å avslå Agentforce. Arkitektur som støtter sporing av samtykke på brukssaksnivå, er ett inndata. Testing og periodisk revisjon av håndhevingslogikken bidrar til å bekrefte at samtykkeporter gjelder i praksis.
  • Dynamisk samtykke for nye funksjoner: Når du distribuerer nye Agentforce som påvirker eksisterende brukere, må du proaktivt søke samtykke for nye brukstilfeller i stedet for å basere deg på opprinnelig samtykke som ikke omfattet spesifikke programmer. Hver materielt ny agentfunksjon som påvirker brukere, utløser samtykkekontroll med tydelig forklaring.
  • Tilbakekalling av samtykke med umiddelbar virkning: Gi brukere mulighet til å trekke tilbake samtykke når som helst med umiddelbar opphør av agentbehandling. Det må være så enkelt å trekke tilbake samtykket som å gi det, uten at det kreves kundestøttekontakter eller byråkratisk prosess.
  • Preferansebehandling: Gi brukere mulighet til å konfigurere agentvirkemåte innenfor definerte grenser:
    • Kommunikasjonsstil (sammendrag kontra detaljerte forklaringer)
    • Proaktivitetsnivå (svar bare når det spørres mot å foreslå proaktivt)
    • Eskaleringspreferanse (foretrukket AI-oppløsning i forhold til foretrukket hurtigbruk)

Lagre preferanser i tilpassede felt for brukerposter. Referansepreferanser i agentsystemledetekster: "Bruker foretrekker detaljerte forklaringer. Gi omfattende svar med støttende vurderinger."

  • Menneskelig håndtering på forespørsel: Gi vedvarende alternativet Koble til med en human agent i Agentforce uten å kreve at brukere fullfører agentinteraksjoner eller forklarer hvorfor de foretrekker mennesker.

Konfigurer umiddelbar overføringsruting: Når brukeren velger Brukeragent, ruter du til Omnikanal med full samtalekontekst og prioritetsflagg som angir brukerpreferanse. Ingen nedsatt tjeneste- eller ventetidspenninger gjelder for valg av interaksjon med person.

  • Transparanseindikatorer: Merk agentinteraksjoner tydelig med faste visuelle indikatorer som gir brukere mulighet til å opprettholde bevissthet om interaksjonsmodus. Brukere som glemmer at de samhandler med agenter, kan ha urealistiske forventninger eller oppfatte bedrageri når begrensninger vises.

Utform agenter som produserer rettferdige utfall på tvers av beskyttede demografiske grupper gjennom hensiktsmessige arkitektoniske valg.

Agenter som tar konsekvensbeslutninger, må ikke diskriminere på grunnlag av beskyttede egenskaper (inkludert rase, kjønn, alder, funksjonshemming, religion, nasjonal opprinnelse eller seksuell orientering) med mindre det er juridisk berettiget for bestemte formål som funksjonshemmede.

  • Funksjonsrevisjon: Se gjennom alle datakilder som brukes i agentenes vurderinger, for å finne beskyttet karakteristisk innhold. CRM-data, Data 360-segmenter og Knowledge kan inneholde demografisk informasjon som agenter ikke bør ta hensyn til ved bestemte beslutninger.

Fjern eller masker beskyttede egenskaper fra agentinndata når disse egenskapene ikke er juridisk berettiget for beslutningstypen. I kredittbeslutninger utelukker du funksjonshemming fordi den ikke er relevant. For forespørsler om funksjonshemmede er funksjonshemmedsstatus viktig og må inkluderes.

  • Prompt engineering for ikke-diskriminering: Inkluder eksplisitte ikke-diskrimineringsinstruksjoner i agentsystemledetekster:

"Du er en kundeservice tjenesteagent. Behandle alle kunder med like profesjonalitet uavhengig av navn, plassering, kommunikasjonsstil eller andre egenskaper. Gi anbefalinger av samme kvalitet og detaljer til alle kunder. Gjør aldri forutsigelser om kunder basert på demografiske egenskaper."

  • Testing med demografiske personer: Før produksjonsdistribusjon må du teste agenter med forskjellige personligheter som representerer beskyttede grupper. Generer identiske forespørsler som varierer bare demografiske signaler (inkludert navn som foreslår forskjellige etnisiteter, steder som foreslår forskjellige regioner, og kommunikasjonsstiler som foreslår forskjellige utdanningsnivåer).

Sammenlign agentsvar på tvers av profiler for kvalitet, lengde, profesjonalitet og utfall. Forskjeller angir systematiske avvik som krever avbøying.

Overvåk Service Quality Agentforce på tvers av kundedemografi for å sikre sammenlignbare opplevelser:

  • Løsningsgrad etter segment: Beregne løsningsgrader for første kontakt, lagret etter kundesegment. Hvis Enterprise-kunder oppnår 75 % oppløsning mens SMB-kunder oppnår 55 % oppløsning, undersøker du om Knowledge, agentopplæring eller produktegenskaper varierer etter segment.
  • Svarkvalitet etter segment: Eksempel på agentdiskusjoner på tvers av segmenter, og få de som vurderer, til å vurdere svarkvalitet på konsistente dimensjoner: nøyaktighet, fullstendighet, profesjonalitet, hjelpsomhet. Testing av pålitelighet mellom rangeringer sikrer at de som vurderer, bruker konsistente standarder.
  • Eskaleringsrate etter segment: Spor hvor ofte agenter eskalerer til personer, lagret etter kundedemografi. Høyere eskaleringsgrader for enkelte segmenter indikerer at agenter er mindre effektive for disse brukerne, noe som fører til forskjeller i tjenestenes kvalitet.
  • Tilfredshet etter segment: Undersøk brukere fra alle demografiske grupper, og sammenlign tilfredshetsscore. Generell høy tilfredshet kan maskere dårlige opplevelser for minoritetsgrupper som er druknet av flertalls tilfredshet.

Agentforce-grensesnitt må være tilgjengelig for brukere med funksjonshemming som oppfyller WCAG 2.2 AA-standarder. Referer til komponenten Salesforce Lightning Design System og mønsterbiblioteker for gjenbrukbare, tilgjengelige Agentforce-komponenter og designmønstre. Disse mønstrene gjør agentopplevelser tilgjengelige, konsistente og lærbare.

  • Skjermleserkompatibilitet: Lightning som leverer Agentforce, inkluderer standard tilgjengelighet når de brukes slik de er utformet. Tilpassede chatteimplementasjoner krever manuell tilgjengelighetsimplementering:
  • Semantisk HTML-struktur med riktige landemerker
  • ARIA-direkteområder som kunngjør nye meldinger
  • Tastaturnavigering gjennom meldingshistorikk
  • Fjern fokusindikatorer på interaktive elementer

Test med hjelpeteknologi for JAWS-, NVDA- og VoiceOver-skjermleser i løpet av utviklingen, ikke bare automatisert skanning.

  • Kognitiv tilgjengelighet: Agentsvar bruker ren språk for generelle målgrupper. Unngå jargon og oppgi ordlister for tekniske termer som ikke kan unngås. Strukturer lange svar med overskrifter, og bruk punktlister eller nummererte lister for å gi bedre forståelse der det er aktuelt.
  • Språklig egenkapital: Agentforce støtter flere språk gjennom multispråklig funksjonalitet i grunnmodellen. Valider responskvalitet er sammenlignbar på tvers av språk via evaluering av innebygde høyttalere, ikke bare automatiserte målinger som mangler kulturelle nyanser.

For forretningskritiske brukstilfeller som betjener ulike språkpopulasjoner, konfigurerer du språkspesifikk håndtering (språkvariabler, lokaliserte ledetekster og filtrering av Knowledge etter språk) og validerer kvalitet per språk i stedet for å stole bare på grunnmodellens flerspråklige overføring, noe som kan gi nedgradert kvalitet for språk med lavere ressurser.

Implementer fairness for Agentforce i faser i samsvar med modenhet for agentdistribusjon.

Fase 1: Foundation (før eventuelle produksjonsagenter)

  • Opprette et etikkvurderingskomité med håndhevingstjeneste
  • Dokumenter ansvarstildelinger (modelleier, beslutningseier, klageinstans)
  • Aktivere Einstein Trust Layer-revisjonsfangst
  • Konfigurere hendelsesovervåking for agenthandlinger
  • Opprette kontrollpaneler for overvåking av grunnleggende rettferdighet i CRM Analytics
  • Definer obligatoriske distribusjonsportaler: datarevisjon, fairness-målinger, innvirkningsvurdering

Fase 2: Første produksjonsagent

  • Utføre omfattende innvirkningsvurdering for bruksområde
  • Revidere opplærings- og RAG-data for demografisk representasjon
  • Beregne rettferdighetsmålinger på tvers av demografiske grupper
  • Implementer mønster for menneskelig oversikt (personlig i sløyfe, konfidenseskalering eller tidsbegrenset)
  • Konfigurere rapporteringsmekanisme for systematiske avvik for brukere
  • Tilnærming til dokumentmodellversjon, konfigurasjon og rekonstruksjon av beslutninger

Fase 3: Kontinuerlig overvåking

  • Overvåk fairness-kontrollpaneler ukentlig og undersøk terskelbrudd innen 24 timer (eller organisasjonens avtalte SLA-avtale for svar)
  • Utføre månedlig overstyringsmønsteranalyse som identifiserer systematiske problemer
  • Se gjennom rapporter om systematiske avvik for brukere ukentlig med dokumenterte undersøkelsesresultater
  • Utføre kvartalsvise omfattende rettferdighetsrevisjoner for agenter med stor interesse
  • Oppdater dokumentasjon etter hvert som agenter utvikler seg via ledetekstoppdateringer eller modellendringer

Fase 4: Skalering og styring

  • Opprette gjenbrukbare fairness-kontrollpanelmaler for vanlige agenttyper
  • Bygge verktøy for agentbeslutningsrekonstruksjon som aktiverer selvbetjening for samsvarsteam
  • Standardiser samtykkebehandlingsmønstre på tvers av alle nye agenter
  • Implementer automatisert fairness-regresjonstesting i CI/CD pipelines
  • Planlegge halvårsvise eksterne rettferdighetsrevisjoner av tredjeparter
  • Opprettholde regulatorisk overvåking og tilpasse seg aktive og nye forpliktelser, inkludert EU AI Act (faset inn til 2025-2027), delstatlige lover og sektorforskrifter

Fairness er en kjernearkitektonisk bekymring for agentiske systemer på Salesforce-plattformen. Organisasjoner som utformer Agentforce med rettferdighet som en førsteklasses arkitektonisk bekymring, plasserer seg foran lovpålagte krav, mens de bygger løsninger som alle brukere kan Trust og bruke effektivt. Plattformfunksjonaliteten finnes. Spørsmålet er om arkitekter vil bruke dem.

Dele tilbakemeldingene dine om det velbygde rammeverket.