Fairness for agentvirksomheden

Retfærd for agentvirksomheden

Når autonome agenter træffer beslutninger, der påvirker kunder, medarbejdere og fællesskaber, bliver rimelighed den arkitektoniske kvalitet, der adskiller ansvarlig automatisering fra skadelig automatisering. Agentforce agenter, der opererer med begrænset menneskelig tilsyn, bevarer og forstærker bias på en hidtil uset skala og omdanner individuelle diskriminerende mønstre til systemisk ulighed. Fairness i agentiske systemer er en førsteklasses arkitektonisk bekymring på Salesforce-platformen, som kombinerer AI-fairness, tilgængelighed, menneskelig tilsyn, algoritmisk ansvarlighed og etisk styring i en forenet arkitektonisk søjle.

Denne side håndterer rimelighedsudfordringer, der er unikke for agentarkitekturer. Kerneprincipperne om retfærdighed, krav til tilgængelighed og etiske styringsrammer er omfattet af søjlen om retfærdighed. Her fokuserer vi på overvejelser i forbindelse med autonome agenter: biasregistrering for agenter, der træffer konsekvensmæssige beslutninger og tilsynsmønstre, der har til formål at gøre ansvarlighed mere substantiel end nominel, gennemsigtighed, der giver påvirkede brugere mulighed for at bestride beslutninger, og platformfunktioner som Einstein Trust Layer, der understøtter ansvarlig AI-praksis gennem datakontrol og revisionsregistrering.

Agentforce agenter lærer mønstre fra træningsdata, hentningskilder og interaktioner i den virkelige verden. Når disse kilder indeholder bias, der afspejler historisk diskrimination eller demografiske ubalancer, bevarer agenter denne bias med algoritmeffektivitet, der påvirker tusindvis af brugere, før mennesker registrerer mønsteret.

  • Basismodel bias: Storsprogmodeller trænes på internetskala-data, der indeholder samfundsbias omkring race, køn, alder, handicap og andre beskyttede egenskaber. Disse bias vises i agentsvar, selv uden eksplicitte diskriminerende instruktioner, og vil sandsynligvis ikke blive håndteret fuldstændigt gennem prompt engineering eller test alene. De afspejler mønstre, der delvist er iboende i internet-skaleringsuddannelsesdata. En Agentforce kan f.eks. beskrive lederroller ved brug af mandlige sprogmønstre. Eller en serviceagent kan reagere forskelligt på kunder, hvis navn angiver ikke-flertals etnicitet eller køn – et repræsentativt kvalitetsspørgsmål, der kan påvirke kundens oplevelse uafhængigt af ethvert beslutningsresultat.

Test agenter systematisk for demografisk bias ved brug af forskellige personaer, der repræsenterer beskyttede grupper. Generer identiske anmodninger, der kun varierer demografiske signaler som navne, placeringer eller kommunikationstypografier. Sammenlign agentsvar på tværs af personaer for kvalitetsforskelle, tonevariationer og resultatforskelle.

  • Uddannelsesmangler i datarepræsentation: Hvis din organisations historiske CRM-data (customer relationship management) underrepræsenterer visse kundesegmenter, vil Agentforce-agenter, der er uddannet i eller baseret på disse data, yde dårligt for disse segmenter. En emnescoringsagent, der er trænet på ti års salgsmulighedsdata, undervurderer systematisk kundeemner fra geografier, som dit salgsteam historisk har nedprioriteret, og skaber en feedbackkørsel, hvor algoritmisk bias sammensætter menneskelig bias.

Før du bruger Salesforce-data til agentuddannelse eller RAG (Return-Augmented Generation - hentning - udvidet generering) skal du overvåge demografisk repræsentation. Identificer underrepræsenterede grupper, og vurder, om repræsentationsmangel afspejler legitime forretningsforskelle eller historisk diskrimination. Reducer ubalancer gennem dataforøgelse eller eksplicit biasreduktion, før du implementerer agenter. Nogle restbias har en tendens til at forblive og administreres typisk gennem downstreamovervågning og oversyn snarere end løst før implementering.

  • Findingsbias i RAG-systemer: Agentforce bruger RAG-basissvar i Knowledge, Data 360-segmenter og Salesforce-registreringer. Når disse hentningskilder indeholder partisk indhold eller varierer i kvalitet på tværs af demografiske grupper, kan den implementerede agent overføre partiskheden til oplevelser for påvirkede brugere. Hvis du vil reducere denne risiko, skal du overvåge hentningskilder før produktion som en bedste fremgangsmåde. En serviceagent, der henter Knowledge, der tilbyder detaljeret fejlfinding for virksomhedskunder, men kun generiske svar for små forretningskunder vil forlænge uoverensstemmelser i servicekvalitet, en rimelighedsproblematik, hvor kundeniveauet korrelerer med beskyttede egenskaber.

Overvåg Knowledge og hentningskilder for demografiske repræsentationsmangler og kvalitetsforskelle. Hvor huller er vanskelige at lukke, skal du behandle disse begrænsninger som vagter på de steder, hvor agenten passer godt. Sørg for, at dokumentationskvalitet, fuldstændighed og nøjagtighed er sammenlignelige på tværs af alle kundesegmenter. Inkluder forskellige repræsentationer i indholdseksempler i stedet for som standard referencer til majoritetskultur, der fjerner underrepræsenterede brugere.

  • Interaktionsmønster bias: Agenter kan tilpasse adfærd baseret på konverserende tip, der er forbundet med beskyttede egenskaber. Overvågning for dette mønster er en almindelig fremgangsmåde, selv efter implementering, da nogle interaktionsdynamikker opstår fra brugeradfærd, der ikke findes i træningsdata. Kommunikationstypografi, sprogkompleksitet og tidsmønstre kan signalere demografiske oplysninger. En agent, der behandler formelle kommunikationstypografier anderledes end casual-typografier, kan utilsigtet diskriminere baseret på kulturel baggrund, uddannelsesniveau eller status på modersmål.

Overvåg agentinteraktioner på tværs af demografiske grupper for ensartethed af adfærd. Analyser svarlængde, detaljeniveau, høflighedsmærker og løsningskvalitet stratificeret efter brugeregenskaber. Uensartetheder foreslår interaktionsbias, der berettiger undersøgelse.

  • Feedback-løkkeforstærkning: Agenter, der påvirker deres egne fremtidige træningsdata, skaber selvforstærkende bias. En distributionsagent, der f.eks. tildeler færre salgsmuligheder af høj værdi til bestemte salgsområder, genererer mindre succesdata for disse områder. Dette reducerer deres forudsagte successandsynlighed, hvilket yderligere reducerer fremtidig salgsmulighedsdistribution til dem. Uden intervention forekommer denne indledende bias over tid.

Registrer feedbackløkker ved at overvåge ændringer i beslutningsdistribution over tid. Når visse demografiske grupper systematisk modtager færre positive resultater, kan du undersøge, om agentbeslutninger skaber den uoverensstemmelse, der retfærdiggør fremtidige negative beslutninger. Opdel løkker gennem menneskelig gennemgang af kantsager og regelmæssig genbalancering.

Når flere Agentforce samarbejder i orkestreringskæder, bliver bias fra en agent input til downstream-agenter, hvilket skaber sammensætningseffekter, hvor små indledende bias forstærkes til væsentlige diskriminerende resultater.

  • Sekventielle agentkæder: Når agent A’s output bliver agent B’s input, er der en risiko for, at agent A’s partiske beslutninger begrænser agent B’s indstillinger på måder, der bevarer eller forstærker diskrimination.

Overvej en orkestrering af emnekvalifikation:

  1. Research Agent indsamler Kundeintelligens fra webkilder og CRM-historik.
  2. Scoringsagent tildeler emnescore baseret på undersøgelsesagentresultater.
  3. Distributionsagent tildeler emne til område baseret på score.
  4. Engagementagent personliggør opsøgende baseret på alle tidligere agentresultater.

Når undersøgelsesagent systematisk henter mindre omfattende data for visse kundedemografier (på grund af træningsdatamangler eller hentningsbias), fortolker scoringsagent ufuldstændige oplysninger som negative signaler. Distributionsagent tildeles derefter til område med lavere prioritet, og Engagementagent giver mindre personlig opsøgende. Sammensætningseffekten opretter uoverensstemmelser i servicekvalitet, der langt overstiger enhver individuel agents bias.

  • Parallel agentkonsensus: Mønstre, hvor flere agenter uafhængigt analyserer det samme input, og resultater aggregeres, giver biasforstærkningsmuligheder, når agenter deler træningsdata eller grundlæggende modeller.

Hvis fem agenter uafhængigt scorer et emne, men alle deler partiske træningsdata eller grundlæggende modelbias, retter konsensus ikke bias – det validerer det blot. “Fem agenter enige” tilbyder falsk tillid til diskriminerende resultater, når alle fem deler den samme systematiske bias.

Begrænsningsstrategier for orkestreringsbias:

  • Agentresultatrevision i hver fase: Logfør komplette input og output for hver agent i orkestreringskæder. Når bias registreres i endelige resultater, kan du spore bagud gennem kæden for at identificere, hvilken agent der introducerede bias, og i hvilken fase forstærkning forekom.

Opbyg CRM Analytics-dashboards, der viser beslutningsdistributioner på hver orkestreringsfase opdelt efter demografi. Identificer, hvor i kæden uoverensstemmelser opstår eller udvides.

  • Diversitet i agentuddannelse og -meddelelse - Diversitet reducerer korrelerede fejl, hvilket gør biasforstærkning mindre sandsynlig. Når du bruger konsensusmønstre for flere agenter, skal du maksimere diversitet:
  • Forskellige grundlægningsmodeller, hvor det er kommercielt muligt og understøttet, f.eks. gennem BYOLLM-konfigurationer (Bring Your Own LLM)
  • Forskellige hentningskilder på tværs af agenter
  • Forskellige meddelelsestekniktilgange
  • Forskellige konfidenstærskelkalibreringer
  • Menneskelig gennemgang ved omdrejningspunkter: Identificer faser i orkestrering, hvor beslutninger væsentligt indsnævrer downstream-indstillinger. Indsæt human review på disse omskifterpunkter, selvom den individuelle agentkonfidens er høj. Orkestrering opretter emergente effekter, som individuelle agentkonfidensscores ikke registrerer.
  • Fairness-metrikker pr. orkestreringsfase: Mål ikke blot rimeligheden af endelige resultater. Beregn demografisk paritet, lige salgsmuligheder og uensartet påvirkning i hver fase af kæden.

Hvis Fase 1 viser 90 % demografisk paritet, Fase 2 viser 85 %, Fase 3 viser 78 %, og Fase 4 viser 70 %, vises hver fase acceptabel i isolation, men sammensættes til uacceptabel endelig uoverensstemmelse. Faseinddelte metrikker fanger sammensætning, før de opretter diskriminerende resultater.

  • Kredsløbsafbrydere til orkestreringsfejl - Konfigurer orkestreringslogik til at stoppe og eskalere til mennesker, når:
  • Enhver agentkonfidens falder under tærsklen, selvom downstream-agenter er sikre
  • Outputdistribution ændres væsentligt mellem orkestreringsfaser
  • Beslutningskæde støder på data, der ikke er repræsenteret i trænings- eller valideringssæt
  • Brugeren spørger eksplicit eller udfordrer mellemliggende beslutninger

Orkestrering med flere agenter aktiverer sofistikeret resonnement, men skaber uigennemsigtige beslutningskæder, hvor ansvarsfrihed diffunderer og biasforbindelser opstår. Architektonisk opmærksomhed på faseinddelt fairnessovervågning og strategisk menneskelig tilsyn forhindrer orkestrering i at blive en biasforstærkermaskineri.

Før du implementerer Agentforce, der træffer konsekvensmæssige beslutninger om brugere, skal du beregne rimelige metrikker på tværs af demografiske grupper. Gør rimelig evaluering til en obligatorisk implementeringsgateway ækvivalent i autoritet til sikkerhedsgennemgang.

  • Demografisk paritet: Positive resultatfrekvenser skal være ca. ens på tværs af beskyttede demografiske grupper. Hvis en agent godkender serviceanmodninger for gruppe A ved en sats på 60 %, men gruppe B ved en sats på 40 %, overtrædes demografisk paritet. Demografisk ligestilling er relevant, når der ikke er nogen legitim årsag til forskelle i resultatfrekvens på tværs af grupper.

Beregn demografisk paritet ved at opdele populationen i demografiske segmenter, måle positive resultatfrekvenser pr. segment og sammenligne satser på tværs af segmenter. Dokumentparitet mangler med navngivne godkendere og logik.

  • Lige muligheder: Sande positive satser forbliver sammenlignelige på tværs af grupper. Agenter identificerer kvalificerede enkeltpersoner lige godt, uanset demografiske karakteristika. En forudsigelsesmodel genkender kreditværdige ansøgere med lignende satser på tværs af beskyttede grupper, når den underliggende kreditværdighed er ens.

Lighed med salgsmulighed er ofte den mere relevante metrik end demografisk paritet for beslutninger om individuelle kvalifikationer, hvor basisfrekvenserne kan afvige. Overvåg, om agenter systematisk går glip af kvalificerede kandidater fra underrepræsenterede grupper. Hvis der stadig er uoverensstemmelser efter reduktion, er agenten muligvis ikke egnet til denne anvendelsessituation.

  • Udlignede odds: Både sande positive satser og falske positive satser er ens på tværs af grupper. Dette er en streng definition, der begrænser både sande positive og falske positive satser på tværs af demografier. Ligestillede odds forhindrer både manglende salgsmuligheder i at koncentrere sig i specifikke grupper og falske beskyldninger i at koncentrere sig i specifikke grupper.

Opnåelse af ligestillede odds kræver ofte separate beslutningstærskler pr. demografisk gruppe. I USA er det i henhold til afsnit VII (Civil Rights Act of 1964) forbudt at justere scores eller fastsætte forskellige afskæringsscores for beskæftigelsesrelaterede beslutninger efter beskyttet klasse, så der kan ikke søges efter lige odds på denne måde ved ansættelse. I andre kontekster og i andre jurisdiktioner rejser det juridiske spørgsmål om eksplicit differentiel behandling, så rådfør dig med en juridisk rådgiver, før du implementerer gruppespecifikke tærskler.

  • Uensartet påvirkningsforhold: Fire-fifths reglen indeholder en screening tærskel: Hvis en gruppe modtager positive resultater på mindre end 80 % af frekvensen for den mest effektive gruppe, kan du undersøge bias. Et 75 %-forhold (f.eks. en 45 % godkendelsesfrekvens kontra en 60 % godkendelsesfrekvens) falder under tærsklen på fire femtedele og angiver potentiel diskrimination, der kræver begrundelse eller reduktion.

Uensartet påvirkningsanalyse er standard i ansættelsesret og anvendes i stigende grad på AI-systemer. Hvor rationer falder under 80 %, er dokumentundersøgelse og rettelsestrin. Hvor rettelse ikke løfter forholdet, kan teams konkludere, at anvendelsessituationen ikke passer godt.

  • Individuel retfærdighed: Tilsvarende enkeltpersoner modtager lignende forudsigelser, uanset gruppemedlemskab. To kunder med identisk kreditværdighed, købshistorik og engagement modtager lignende kreditgrænseanbefalinger, uanset demografiske forskelle.

Individuel rimelighed er filosofisk vigtigt, men operationelt udfordrende, fordi “ligestilling” er subjektiv og kontekstafhængig. Brug individuel rimelighed som et designprincip, der guider funktionsvalg og test i stedet for en streng matematisk begrænsning.

To platformsfunktioner registrerer data til biasregistrering. Trustt generativt AI-revisionsspor for hver Agentforce: de meddelelser, der sendes til modellen, de svar, der returneres, de anvendte landestandardkilder og Trust, f.eks. toksicitetsscores. Agentforce registrerer trinvis argumentation bag hver beslutning. Sammen leverer de data, der understøtter biasregistrering og fairnessovervågning. Fortolkningen af disse data er menneskeligt arbejde og kræver typisk uddannede korrekturlæsere og dedikeret tid.

  • Svarlogføring: Trust Layer logfører meddelelser, modelsvar og Trust for hver genererende interaktion. Brug disse data til at analysere forudsigelsesdistributioner på tværs af demografiske grupper. Opbyg CRM Analytics-dashboards, der sammenligner godkendelsesfrekvenser, anbefalingsmønstre og risikoscores efter kundesegment.

Forespørgsels Trust Layer logføres regelmæssigt: Brug følgende meddelelse: “Vis mig alle salgsmulighedsforudsigelser af høj værdi i de sidste 30 dage grupperet efter kundebranche, område og kontostørrelse. Er forudsigelsesdistributioner ensartede på tværs af segmenter, eller scores bestemte segmenter systematisk højere/lavere?”

  • Grundlæggende sporregistrering: For Agentforce registrerer Agentforce, hvordan agenten nåede frem til sin beslutning, mens Trust Layer-revisionssporet registrerer meddelelser, svar og grundlæggende kilder, herunder hvilke Knowledge og Salesforce-registreringer der blev hentet. Gennemse begge, når brugere rapporterer bias for at forstå, hvilke datakilder, hentningsmønstre eller argumentationstrin der kan have introduceret bias.

Årsagsspor gør post-hoc fairness-revisioner mere detaljerede og nemmere at udføre, end de var med traditionelle systemer. Eksempel på 100-agentbeslutninger, der er stratificeret efter demografisk gruppe, og få korrekturlæsere til at vurdere, om kvaliteten af argumentation er sammenlignelig på tværs af grupper.

  • Anomal detection: Konfigurer advarsler, når agentbeslutningsmønstre afviger væsentligt fra basislinjen. Hvis godkendelsesfrekvenserne for et specifikt kundesegment falder med 20 % uge for uge, skal du udløse undersøgelse. Pludselige distributionsskift kan indikere Datakvalitetsproblemer, modelforskydning eller opstået bias, der kræver øjeblikkelig opmærksomhed.

Opbyg tilpasset overvågning for at advare om fairness-signaler: “Adviser, når den gennemsnitlige samtalelængde for Agentforce Serviceagent for ethvert kundesegment overstiger 1,5 gange det samlede gennemsnit i tre på hinanden følgende dage.” Længdeforskelle kan angive, at visse grupper modtager mindre effektiv service.

  • Fairness dashboard-skabeloner: Opbyg genanvendelige CRM Analytics-dashboardskabeloner til sporing af rimelighedsmetrikker for almindelige agentanvendelsessituationer. Inkluder demografiske paritetsberegninger, lige salgsmulighedsmetrikker, uensartede påvirkningsforhold og tendensdiagrammer, der viser metrikudvikling over tid. Del skabeloner på tværs af agentudviklingsteams, der standardiserer fairnessovervågning.

Når bias registreres, skal du anvende reduktion i den relevante fase baseret på grundlæggende årsag.

  • Forbehandling af data: Korrekt bias på dataniveauet før agentuddannelse eller RAG-indeksering. Eksempel på underrepræsenterede demografiske grupper i træningsdata, der sikrer afbalanceret repræsentation. Syntetiser yderligere data for underrepræsenterede grupper ved brug af teknikker som SMOTE (Synthetic Minority Oversampling Technique), når der er utilstrækkelige virkelige data. Bemærk, at SMOTE interpolerer numeriske tabelfunktioner, så det gælder for strukturerede CRM-træningsdata, ikke den ustrukturerede tekst, der bruges til RAG-landing.

Overvåg Salesforce CRM-data for demografiske mangler, før du bruger dem til modeluddannelse. Hvis historiske salgsmulighedsdata overrepræsenterer bestemte kundetyper, skal du genbalancere træningssæt eller bruge prøvevægt, der forhindrer agenter i at lære denne overrepræsentation som et beslutningssignal.

  • Begrænsninger for algoritme i behandling: Anvend rimelighedsbegrænsninger under modeltræning, der optimeres for både nøjagtighed og rimelighed samtidigt. Dette kan reducere rå nøjagtighed med 2-3 % og dramatisk forbedre rimeligheden på tværs af grupper. Hvor du kontrollerer modeltræning, er fairness-begrænset uddannelse ofte den mest effektive reduktionsmetode.

For Agentforce, der bruger grundlæggende modeller, hvor du ikke kan redigere uddannelse, kan du begrænse agentadfærd gennem systemmeddelelser: “Behandl alle kundedemoer med lige professionalisme og detaljer. Angiv forklaringer af sammenlignelig længde og kvalitet, uanset kundekommunikationstypografi eller -baggrund.”

  • Tærskeljustering efter forarbejdning: Hvor det er lovligt, kan justering af beslutningstærskler pr. demografisk gruppe ligestille resultatfrekvenser efter modeltræning. En godkendelsesagent kan f.eks. anvende en konfidensstærskel på 80 % for en gruppe og en tærskel på 75 % for en anden for at forskyde den underliggende modelbias. Antidiskrimineringslove begrænser kraftigt denne teknik, og nogle jurisdiktioner forbyder den direkte for visse beslutninger (se nedenfor).

Tærskeljustering er kontroversiel, fordi den eksplicit behandler grupper anderledes, og anti-diskriminationslove i mange jurisdiktioner begrænser eller forbyder det. I USA er det for beskæftigelsesrelaterede beslutninger strengt forbudt at: Titel VII (Civil Rights Act of 1964) forbyder justering af scores eller brug af forskellige afslutningsscores efter beskyttet klasse, og ingen mængde dokumenteret begrundelse gør praksisen lovlig. Andre jurisdiktioner pålægger deres egne begrænsninger, så bekræft de regler, der gælder for dine brugere. Hvor praksis er tilladt, skal du dokumentere juridisk begrundelse, når du implementerer gruppespecifikke tærskler og validere, at tærskler forbedrer rimelighed uden at skabe andre diskriminerende effekter.

  • Proxy funktion registrering og fjernelse: Identificer funktioner, der er forbundet med beskyttede egenskaber og fungerer som indirekte diskrimineringsmekanismer. Almindelige proxyer omfatter:
  • Zip code proxies for race, etnicitet og indkomstniveau
  • Navnemønstre proxy for køn og etnicitet
  • Kommunikationstidsplaner for religion og plejeansvar
  • Proxyer af enhedstype for indtjeningsniveau
  • Territorietildeling kan hjælpe med demografisk sammensætning

Beregn korrelationskoefficienter mellem alle modelfunktioner og beskyttede egenskaber. For højt korrelerede funktioner skal du evaluere, om en legitim forudsigelsesværdi retfærdiggør inkludering, eller om alternative funktioner kan levere lignende forudsigelser uden proxy-effekter.

Agentforce agenter kan arbejde med menneskelig tilsyn, der er designet til at gøre en gennemgang mere grundlæggende end nominel. Det rette niveau af tilsyn afhænger af beslutningsinteresser, reversibilitet og bestemmelseskrav.

Distribuer følsomme beslutninger gennem human review før kørsel. Om en beslutning er tilstrækkeligt stor til at berettige menneskelig gennemgang er en risikobaseret vurdering: veje alvorsgraden af den potentielle skade og sandsynligheden for, at den pågældende skade forekommer. Konsekvente beslutninger opstår ofte inden for regulerede domæner, f.eks. sundhedspleje, finansielle tjenester og den offentlige sektor, men de opstår også uden for dem. Almindelige kontekster med høje indsatser omfatter:

  • Anvendelsesbeslutninger - Ansættelse, forfremmelse, opsigelse, godtgørelse, præstationsvurdering
  • Kredit- og finansieringstjenester – kreditgodkendelser, ændringer af grænser, kontoafslutninger, priser
  • Sundhedspleje - Diagnoseforslag, behandlingsanbefalinger, dækningsbeslutninger
  • Rettigheder - fortolkning af kontrakter, løsning af tvister, adgang til tjenester
  • Lejlighed - Lejerundersøgelse, lejegodkendelser, henstillinger om udvisning

Design Agentforce i disse kontekster for at analysere, anbefale og forberede beslutninger, mens der kræves menneskelig godkendelse før kørsel. Placer agenter som beslutningssupportværktøjer, der forbedrer menneskelig dom, ikke autonome beslutningstagere, der erstatter mennesker.

Konfigurer konfidenstærskler, der udløser gennemsyn baseret på agentusikkerhed:

  • Høj tillid (>90%) - Agent fortsætter selvstændigt med fuld revisionslogføring
  • Moderer tillid (70-90%) - Agent anbefaler med menneskelig gennemgang før handling
  • Lav konfidens (<70%) - Agent henviser helt til menneske med kontekstsammendrag

Kalibrer tærskler ved brug af produktionsdata. En “70 % konfidens”-forudsigelse lykkes ca. 70 % af tiden, når den valideres. Forkerte konfidensscores underminerer Trust i eskaleringsmekanismer.

Testkalibrering ved at prøve agentbeslutninger ved hvert konfidensbånd og beregne faktiske succesfrekvenser. Hvis “høj konfidens”-beslutninger kun lykkes 75 % af tiden, skal du genkalibrere tærskler eller forbedre estimatet af modelkonfidens.

Hvis Agentforce ikke kan løse en anmodning inden for definerede grænser, skal du eskalere til mennesker. Kontroller, at eskaleringsdestinationen har kapacitet til at hjælpe – distribution til overbelastede køer reducerer ikke skade.

Angiv eskaleringsudløsere:

  • Samtale drejninger – Efter 5-7 drejninger uden løsning, eskalere
  • Medgået tid – Efter 10 minutter uden løsning, eskaleres
  • Bruger sentiment – Når brugeren udtrykker frustration, eskalere
  • Gentagelsesregistrering – Eskaler, når agent gentager det samme svar

Konfigurer Omni-Channel til at distribuere eskalerede sager til relevante færdighedsbaserede køer med fuld samtalekontekst. Træn agenter til at håndtere eskaleringer effektivt uden at kræve, at brugere gentager oplysninger, der allerede er angivet til agenten.

Gør det muligt for autoriserede personer at tilsidesætte enhver Agentforce på ethvert tidspunkt med dokumenteret grundlag. Tilsidesættelser tjener flere formål:

  • Fejlkorrektion: Mennesker retter agentfejl, der ville skade brugere eller overtræde politik. Tilsidesættelsesfunktion giver en sikkerhedsventil for autonome systemer, der kører i komplekse miljøer, hvor kanttilfælde er uundgåelige.
  • Bias registrering: Hvis mennesker tilsidesætter Agentforce oftere for visse demografiske oplysninger end andre, skal du undersøge begge muligheder: agenten kan systematisk nedsætte den pågældende gruppe, og personer kan rette den, eller tilsidesættere kan introducere nye bias. Det første mønster peger på gennemgang af agenten, det andet på korrekturlæseruddannelse.
  • Agentforbedring: Tilsidesættelser med logik bliver uddannelsesdata til agentforbedring. Eksempel på tilsidesatte beslutninger, og analyser, hvorfor mennesker er uenige med agenter. Indarbejd tilsidesættelsesmønstre i meddelelsesjustering eller modeltræning.
  • Ansvar: Tilsidesætter tildeling af ansvar. Den person, der tilsidesætter en agentbeslutning, påtager sig ansvaret for beslutningens resultater. Tydelig ansvarlighed forhindrer udbredelse af ansvar, hvor alle antager, at AI er ansvarlig, og ingen tager ejerskab.

Tildel ansvar før implementering, ikke efter hændelser forekommer:

  • Modelejer: Data Science-emnet er ansvarlig for modelretfærdighed, nøjagtighed og adfærd. Godkender implementeringer, reagerer på fairness-advarsler, autoriserer opdateringer. Modelejeren er en navngivet person, der er dokumenteret i arkitektoniske beslutningsregistreringer.
  • Beslutningsejer: Produktejer, der er ansvarlig for at vælge at implementere AI til specifikke anvendelsessituationer og for virkelige påvirkninger af kunder. Beslutningsejeren kan ikke uddelegere ansvarlighed til AI-systemer.
  • Anmodningsmyndighed: Etiske gennemgangsrådet eller det udpegede team håndterer klager fra brugere, der mener, at agentbeslutninger var urimelige. Appellationsprocesser skal være tilgængelige, rettidige og bemyndigede for at fortryde agentbeslutninger.
  • Revisionsmyndighed: Det overensstemmelsesteam, der udfører periodiske revisioner, validerer agenter, der fungerer inden for rimelighedsparametre, og kan suspendere agenter, der mislykkes standarder, indtil de rettes.

Dokumenter alle roller med navne, ikke kun titler, hvilket sikrer, at ansvarlighed bevares gennem organisatoriske ændringer.

Når Agentforce agenter træffer beslutninger, der påvirker brugere, fortjener disse brugere forståelige forklaringer i forhold til beslutningens virkning.

Architect flere forklaringslag, der tjener forskellige målgrupper:

  • Brugerorienterede forklaringer: Almindelig sprogargumentation er forståelig uden teknisk ekspertise. “Din tjenesteanmodning kræver managergodkendelse, da det anmodede beløb ($ 12.000) overskrider din autorisationsgrænse ($ 10.000). Managergodkendelse fuldføres typisk inden for 24 timer eller inden for din aftalte serviceniveauaftale (SLA).”
  • Forretningsforklaringer: Driftsmæssige brugere ser nøglebeslutningfaktorer med forretningskontekst. “Emnescore: 73/100. Primære positive faktorer: Firmastørrelse (500 medarbejdere), Aktivt websiteengagement (12 besøg på 30 dage), Branchmatch (SaaS). Primære negative faktorer: Ingen MQL-engagement uden for målområdet.”
  • Tekniske forklaringer: Dataanalytikere ser modeldetaljer: funktionsvægte, konfidenskalibrering, modelversion, træningsdato, inputfordelinger. Tekniske forklaringer understøtter fejlfinding og biasundersøgelser.
  • Revisionsforklaringer: Overensstemmelsesteams ser komplette beslutningsspor: modelversion, nøjagtige inputværdier på beslutningstidspunktet, alle datakilder, der konsulteres, årsagssporing, konfigurationstilstand. Revisionsforklaringer understøtter reguleringsundersøgelser og rimelighedsrevisioner, der kræver præcis rekonstruktion.

Agentforce registrerer trinvise argumenter bag agentbeslutninger, mens Trustevisionssporet for meddelelse og svar, herunder grundlæggende kilder. Sammen giver de dig mulighed for at levere gennemsigtighed på relevante detaljeniveauer:

  • Gennemsigtighed i realtid: Når Agentforce træffer en beslutning, skal du vise sammendragsrejser for brugere: “Jeg anbefalede Produkt A baseret på din købshistorik (3 lignende køb), aktuel reklamekampagne (20 % rabat) og lagertilgængelighed (på lager, skibe i morgen).”
  • On-demand detaljeret forklaring: Angiv “Hvorfor anbefalede du dette?” link, der gør det muligt for brugere at se komplet argumentation, herunder alle hentede Knowledge, konsulterede Salesforce-registreringer og beslutningslogik. Detaljerede forklaringer skaber Trust og gør det muligt for brugerne at identificere fejl eller bias.
  • Historisk genopbygning: Når brugerne udfordrer tidligere beslutninger uger eller måneder senere, hentes der spor af sessionsarrangementer og Trust Layer-revisionshistorikken, så de kan forklare historiske beslutninger præcist. Historisk rekonstruktion understøtter klager og regulerende undersøgelser.
  • Aggreger mønsteranalyse: Eksempelsætningsspor stratificeret efter demografiske grupper for at analysere, om beslutningskvaliteten er ensartet. Gennemse 100 spor fra hvert kundesegment, og vurder, om grundlæggende dybde, kildekvalitet og logik er sammenlignelige på tværs af grupper.

Vis forudsigelseskonfidens i brugervenlige termer ved at undgå rå sandsynlighedsscores, som brugerne forkert fortolker.

I stedet for “73% konfidens” skal du kommunikere konfidens som:

  • Høj tillid – “Jeg er sikker på, at denne anbefaling er passende baseret på lignende sager”
  • Moderer tillid – “Denne anbefaling er sandsynligvis passende, men managervurdering anbefales”
  • Lav tillid – “Denne situation er usædvanlig. Jeg eskalerer til en ekspert, der kan give bedre vejledning”

Forklar, hvad konfidensniveau betyder for pålidelighed: “Højkonfidensanbefalinger er korrekte ca. 95 % af tiden baseret på historisk validering.”

For moderate eller lave konfidensbeslutninger kan du forklare, hvilken yderligere gennemgang der skal forekomme: “Da denne anmodning falder uden for vores standardparametre, vil den blive gennemset af en senior specialist med godkendelse, der typisk udføres inden for 24 timer, eller inden for din aftalte serviceniveauaftale (SLA).”

Vis brugere, hvad der ville ændre resultatet, når det er relevant. Kontrafaktualer sætter brugere i stand til at forbedre resultater gennem specifikke handlinger i stedet for blot at give dem besked om beslutninger, der allerede er truffet.

F.eks.: “Din emnescore ville øges med bekræftede beskæftigelsesoplysninger (+8 point) og yderligere kreditreferencer (+5 point). Hvis du leverer denne dokumentation, flyttes din applikation til prioritetsgennemgangskøen.”

Kontrafaktualer er effektive gennemsigtighedsmekanismer, men kræver omhyggeligt design. Undgå at angive counterfactuals, der opfordrer til at spille systemet, eller som utilsigtet afslører beskyttede egenskaber som beslutningfaktorer. “Din applikation ville score højere, hvis du var 10 år yngre” er ulovlig diskriminering, ikke nyttig gennemsigtighed.

I nogle jurisdiktioner er tydelig offentliggørelse af, at brugere interagerer med en bot, et juridisk krav, ikke kun en bedste fremgangsmåde for design. Angiv tydeligt, hvornår brugere interagerer med Agentforce agenter snarere end med menneskelige agenter. Offentliggørelse skal være fremtrædende og kontinuerlig, ikke begravet i forhold til service eller kun vist en gang ved interaktionens start.

Vis vedvarende visuelle indikatorer:

  • Agentavatar tydeligt markeret som “AI-assistent”
  • Sidehoved, der viser “Du taler med en Agentforce serviceagent”
  • Indstilling til at “Opret forbindelse til en menneskelig agent” er synlig gennem samtalen

Offentliggørelse respekterer brugerens autonomi, der aktiverer informeret valg om interaktionstilstand. Brugere, der foretrækker menneskelig interaktion, skal have denne indstilling uden friktion eller sanktioner for servicekvalitet.

Salesforce Platform-funktioner som Begivenhedsovervågning og Feltrevisionsspor, der er før agentisk AI, udvider algoritmisk ansvarlighed til de beslutninger, som individuelle agenter træffer.

  • Begivenhedsovervågning for agenthandlinger: Begivenhedsovervågning registrerer agentdataadgang, API-kald og systemændringer med Salesforce-kontrolleret integritet. Streambegivenhedsovervågningslogfiler til eksternt SIEM for langsigtet bevarelse og manipulationsbevis, der opfylder bestemmelseskravene for efterfølgende beslutninger.

Konfigurer Begivenhedsovervågning til at spore:

  • API-begivenhedslogfiler, der viser agentsysteminteraktioner
  • Loginbegivenheder for agentservicekonti
  • Rapporteksporter, når agenter får adgang til massedata
  • Feltrevisionsspor for AI-påvirkede data: Standardfelthistorik bevarer dataændringer i 18 måneder (24 måneder via API). Feltrevisionsspor giver dig mulighed for at bevare felthistorik uendeligt – arkivere den efter op til 18 måneder og derefter bevare de arkiverede data, indtil du sletter dem – og understøtter langsigtede revisioner af rimelighed og reguleringsundersøgelser. Aktiver feltrevisionsspor på objekter, der lagres eller påvirkes af agentbeslutninger, ved at vælge blandt de standardobjekter, som feltrevisionsspor understøtter plus eventuelle tilpassede objekter med felthistoriksporing aktiveret (op til 200 felter pr. objekt).

For kreditbeslutninger, ansættelsesbeslutninger og andre anvendelsessituationer med høje satser kan flerårig bevarelse være et regulerende krav. Bevarelsesperioder varierer efter regime. Bekræft det gældende krav for din anvendelsessituation.

  • Skjoldbegivenhedsovervågning for højeste indsatser: Shield-begivenhedsovervågning leverer forbedrede revisionsfunktioner med strukturerede begivenhedsfelter og integration med overensstemmelsesrapporteringsværktøjer. Begivenhedslogfildata bevares som standard i et år for både Begivenhedsovervågning og Shield-kunder. Brug Shield til agentbeslutninger, hvor revisionssporets integritet er vigtig.

Gem tilstrækkelige oplysninger til at rekonstruere enhver historisk agentbeslutning nøjagtigt:

  • Modelversion: Registrer, hvilken modelversion (grundlægningsmodel, meddelelsesversion, finjusteret model-id) der foretagede hver beslutning. Modelversioner ændres ofte og opretter forskellige output. Præcis versionssporing aktiverer grundlæggende årsagsanalyser, når der opdages bias.
  • Inputfunktionsværdier: Gem nøjagtige inputværdier på beslutningstidspunktet, ikke aktuelle værdier, der kan være ændret. Inputøjebliksbilleder giver dig mulighed for at teste, om en beslutning ville være anderledes med aktuelle data eller bekræfte, at den oprindelige beslutning var korrekt på baggrund af de tilgængelige oplysninger på det tidspunkt.
  • Konfigurationstilstand: Registreringstærskler, forretningsregler og parameterindstillinger er aktive på beslutningstidspunktet. Konfigurationsændringer påvirker resultaterne. Konfigurationshistorik aktiverer bestemmelse af, om beslutningsforskydning afspejler modelændringer eller konfigurationsændringer.
  • Miljøkontekst: Registrer relevant kontekst: brugeridentitet, tidsstempel, samtalehistorik, sessionskontekst. Kontekst påvirker agentadfærd og skal bevares for nøjagtig genopbygning.

Biasregistrering skal være kontinuerlig, ikke engangsvalidering før implementering. Agenter udvikles gennem meddelelsesopdateringer, ændringer af grundlæggende modelversion og skiftende datafordelinger.

  • Fairness metrik dashboards: Opbyg CRM Analytics-dashboards, der sporer fairness-metrikker fra Einstein Trust Layer-logfiler. Overvåg demografisk paritet, lige salgsmuligheder og uensartede påvirkningsforhold kontinuerligt. Konfigurer advarsler, når metrikker bryder definerede tærskler.

Opret et dashboard, der viser:

  • Beslutningsdistribution efter demografiske kundesegmenter (søjlediagrammer)
  • Fairness-metrikker over tid (tendenslinjer med advarselstærskler)
  • Uensartede påvirkningsforholdsberegninger med regelindikator på fire femtedele
  • Topprædiktorer, der bidrager til beslutninger, hvor den underliggende model viser dem
  • Tilsidesættelsesfrekvens efter demografisk gruppe
  • Forsendelsesvagtregistrering: Overvåg agentinputdistributioner for ændringer, der angiver potentielle rimelighedsproblemer. Hvis den demografiske sammensætning af brugere, der modtager agentbeslutninger, skifter væsentligt fra træningsdatademografier, kan modelfairheden forringes.

Advar, når inputfordelinger ændres: “Kundesegmentdistribution for Agentforce er skiftet med 15 % mod Enterprise inden for de sidste 30 dage. Gennemse, om distributionslogik forbliver rimelig for SMB-kunder, der nu modtager forskellige servicemønstre.”

  • Brugerfeedbackintegration: Gør det muligt for brugere at rapportere registreret bias gennem tilgængelige mekanismer. Brugerrapporter viser kvalitative problemer med manglende kvantitative metrikker.

Tilføj indstillingen “Rapporter bekymring” til Agentforce chatgrænseflade. Distribuer rapporter til etiske gennemgangspaneler med fuld samtalekontekst. Spor rapporter i et tilpasset objekt med et påkrævet undersøgelsesarbejdsflow og en dokumenteret løsning.

Design agentarkitekturer, der forudser eksterne revisioner af regulerende myndigheder, civilretlige organisationer eller kunder, der kræver demonstrationer af algoritmisk ansvarlighed.

  • Eksportmuligheder: Opbyg eksportfunktionalitet, der gør det muligt for complianceteams at udtrække komplette beslutningsdatasæt med demografisk stratifikation til ekstern revisorgennemgang. Eksportører skal respektere bestemmelser om datafortrolighed, mens de giver tilstrækkelig gennemsigtighed til validering af rimelighed.
  • Revisionsdokumentation: Vedligehold aktuel dokumentation:
  • Agentformål og tilsigtede anvendelsessituationer
  • Træningsdatademografi og kendte begrænsninger
  • Rimelige metrikker beregnet før implementering og i produktion
  • Bias-begrænsningsstrategier anvendt
  • Konfigurationer af menneskelig tilsyn
  • Overvågning af tilgang og advarselstærskler
  • Tildelinger af ansvar (modelejer, beslutningsejer, klageautoritet)
  • Algoritmiske konsekvensvurderinger: Før du implementerer agenter, der træffer konsekvensmæssige beslutninger, skal du udføre påvirkningsvurderinger, der evaluerer potentielle positive og negative effekter på tværs af interessentgrupper. Konsekvensvurderinger demonstrerer due diligence og proaktiv risikostyring, der er værdsat af regulatorer.

Brugerne bevarer meningsfuld kontrol over, hvordan Agentforce påvirker deres oplevelse.

  • Opt-in for efterfølgende agenter: Agenter, der træffer beslutninger, der påvirker brugere på en væsentlig måde, kræver eksplicit tilmelding i stedet for at være aktive som standard. Kreditbeslutningsagenter, jobscreeningagenter og serviceberettigelsesagenter aktiveres kun efter brugernes samtykke med en tydelig forståelse af, hvordan agenten vil påvirke dem.
  • Granulært samtykke: Aktiver samtykke pr. agentanvendelsessituation i stedet for samlet AI-samtykke. En kunde kan give samtykke til Agentforce, mens Agentforce afvises. Architektur, der understøtter samtykkesporing på anvendelsessagsniveau, er et input. Test og regelmæssig revision af håndhævelseslogikken hjælper med at bekræfte, at samtykkegaver findes i praksis.
  • Dynamisk samtykke til nye funktioner: Når du implementerer nye Agentforce, der påvirker eksisterende brugere, skal du proaktivt søge samtykke til nye anvendelsessituationer i stedet for at være afhængig af oprindeligt samtykke, der ikke overvejer specifikke applikationer. Hver væsentlig ny agentfunktionalitet, der påvirker brugere, udløser samtykketjek med tydelig forklaring.
  • Tilbagetrækning af samtykke med øjeblikkelig virkning: Gør det muligt for brugere til enhver tid at trække samtykket tilbage med øjeblikkelig ophør af agentbehandling. Tilbagetrækning af samtykke skal være lige så nemt som at tildele det, uden at der kræves nogen supportkontakter eller en bureaukratisk proces.
  • Præferencestyring: Gør det muligt for brugere at konfigurere agentadfærd inden for definerede grænser:
    • Kommunikationstypografi (koncise kontra detaljerede forklaringer)
    • Proaktivitetsniveau (svar kun, når der bliver spurgt, kontra proaktivt foreslået)
    • Eskaleringspræference (foretræk AI-løsning i forhold til at foretrække hurtigt menneskelig)

Gem præferencer i tilpassede brugerregistreringsfelter. Referencepræferencer i agentsystemmeddelelser: “Bruger foretrækker detaljerede forklaringer. Angiv omfattende svar med understøttende argumentation.”

  • Menneskelig håndtering efter behov: Angiv vedvarende “Opret forbindelse til menneskelig agent”-indstilling i hele Agentforce uden at kræve, at brugere fuldfører agentinteraktioner eller forklarer, hvorfor de foretrækker mennesker.

Konfigurer øjeblikkelig afvisning af distribution: Når brugeren vælger “Menneskeagent”, skal du dirigere til Omni-Channel med fuld samtalekontekst og prioritetsflag, der angiver brugerpræferencer. Der gælder ingen nedsatte service- eller ventetidssanktioner for valg af menneskelig interaktion.

  • Gennemsigtighedsindikatorer: Marker tydeligt agentinteraktioner med vedvarende visuelle indikatorer, der gør det muligt for brugere at bevare bevidstheden om interaktionstilstand. Brugere, der glemmer, at de interagerer med agenter, kan have urealistiske forventninger eller opleve bedrag, når begrænsninger vises.

Design agenter, der opretter rimelige resultater på tværs af beskyttede demografiske grupper gennem hensigtsmæssige arkitektoniske valg.

Agenter, der træffer konsekvensmæssige beslutninger, må ikke diskriminere på basis af beskyttede egenskaber (herunder, race, køn, alder, handicap, religion, national oprindelse eller seksuel orientering), medmindre det er juridisk berettiget til specifikke formål som handicaptilpasninger.

  • Funktionsrevision: Gennemse alle datakilder, der bruges i agentarrangering for beskyttet karakteristisk indhold. CRM-data, Data 360-segmenter og Knowledge kan indeholde demografiske oplysninger, som agenter ikke bør tage højde for for bestemte beslutninger.

Fjern eller masker beskyttede egenskaber fra agentinput, når disse egenskaber ikke er juridisk berettigede for beslutningstypen. For kreditbeslutninger skal du ekskludere invaliditetsstatus, da det er irrelevant. For anmodninger om handicapindhold er handicapstatus vigtig og skal inkluderes.

  • Prompt engineering for ikke-diskrimination: Inkluder eksplicitte ikke-diskrimineringsinstruktioner i agentsystemmeddelelser:

“Du er en kundeserviceagent. Behandl alle kunder med lige professionalisme, uanset deres navn, placering, kommunikationstypografi eller andre egenskaber. Angiv anbefalinger af samme kvalitet og detaljer til alle kunder. Opret aldrig antagelser om kunder baseret på demografiske karakteristika.”

  • Test med demografiske personaer: Før produktionsimplementering skal du teste agenter med forskellige personaer, der repræsenterer beskyttede grupper. Generer identiske anmodninger, der kun varierer demografiske signaler (herunder navne, der foreslår forskellige etniciteter, placeringer, der foreslår forskellige områder og kommunikationstypografier, der foreslår forskellige uddannelsesniveauer).

Sammenlign agentsvar på tværs af personaer for kvalitet, længde, professionalisme og resultater. Forskelle angiver bias, der kræver reduktion.

Overvåg Agentforce på tværs af kundedemografier, så du sikrer sammenlignelige oplevelser:

  • Løsningsfrekvens efter segment: Beregn hastigheder for løsning af første kontakt stratificeret efter kundesegment. Hvis Enterprise-kunder opnår 75 % løsning, mens SMB-kunder opnår 55 % løsning, skal du undersøge, om kvaliteten af Knowledge, agentuddannelse eller produktfunktioner er forskellige efter segment.
  • Svarkvalitet efter segment: Eksempel på agentsamtaler på tværs af segmenter, og få korrekturlæsere til at vurdere svarkvalitet på ensartede dimensioner: nøjagtighed, fuldstændighed, professionalisme, hjælpsomhed. Testen af pålidelighed mellem vurderinger sikrer, at korrekturlæsere anvender ensartede standarder.
  • Eskaleringsfrekvens efter segment: Spor, hvor ofte agenter eskalerer til mennesker, stratificeret efter kundedemo. Højere eskaleringsfrekvenser for bestemte segmenter angiver, at agenter er mindre effektive for disse brugere, hvilket skaber uoverensstemmelser i servicekvalitet.
  • Tilfredshed efter segment: Undersøg brugere fra alle demografiske grupper, og sammenlign tilfredshedsscores. Generel høj tilfredshed kan maskere dårlige oplevelser for mindretalsgrupper, der er druknet ud af majoritetstilfredshed.

Agentforce-grænseflader skal være tilgængelige for brugere med handicap, der opfylder WCAG 2.2 AA-standarder. Referer til komponenten Salesforce Lightning Design System og mønsterbiblioteker for genanvendelige, tilgængelige Agentforce-komponenter og designmønstre. Disse mønstre gør agentoplevelser tilgængelige, ensartede og lærbare.

  • Skærmlæserkompatibilitet: Lightning, der leverer Agentforce, inkluderer basistilgængelighed, når de bruges som designet. Tilpassede chatimplementeringer kræver manuel tilgængelighedsimplementering:
  • Semantisk HTML-struktur med korrekte milepæle
  • ARIA-liveområder annoncerer nye meddelelser
  • Tastaturnavigation gennem meddelelseshistorik
  • Ryd fokusindikatorer på interaktive elementer

Test med støttende teknologi til JAWS-, NVDA- og VoiceOver-skærmlæsere gennem udvikling, ikke kun automatiseret scanning.

  • Kognitive tilgængelighed: Agentsvar bruger almindeligt sprog for generelle målgrupper. Undgå jargon, og angiv ordlister for uundgåelige tekniske udtryk. Strukturer lange svar med overskrifter, og brug punktlister eller nummererede lister til at hjælpe med at forstå, hvor det er relevant.
  • Sproglighed: Agentforce understøtter flere sprog gennem flersprogede funktioner i basismodellen. Valider svarkvalitet kan sammenlignes på tværs af sprog gennem indbygget talerevaluering, ikke kun automatiserede metrikker, der mangler kulturelle nuancer.

For forretningskritiske anvendelsessituationer, der betjener forskellige sprogpopulationer, skal du konfigurere sprogspecifik håndtering (sprogvariabler, lokaliserede meddelelser og Knowledge efter sprog) og validere kvalitet pr. sprog i stedet for udelukkende at være afhængig af grundlæggende modeloversættelse på tværs af sprog, hvilket kan give nedsat kvalitet for sprog med lavere ressourcer.

Implementer fairness for Agentforce i faser, der er i overensstemmelse med agenten implementerings modenhed.

Fase 1: Foundation (før alle produktionsagenter)

  • Etabler etiske gennemgangspaneler med håndhævelsesmyndighed
  • Tildelinger af dokumentansvar (modelejer, beslutningsejer, klageautoritet)
  • Aktiver Einstein Trust Layer-revisionsregistrering
  • Konfigurer Begivenhedsovervågning for agenthandlinger
  • Opret dashboards til overvågning af grundlæggende fairness i CRM Analytics
  • Definer obligatoriske implementeringsgateways: dataovervågning, rimelighedsmetrikker, påvirkningsvurdering

Fase 2: Første produktionsagent

  • Udfør omfattende påvirkningsvurdering for anvendelsessituationer
  • Overvåg uddannelses-/RAG-data for demografisk repræsentation
  • Beregn rimelighedsmetrikker på tværs af demografiske grupper
  • Implementer mønster for menneskelig tilsyn (menneskelig i løb, konfidenseskalering eller tidsbegrænset)
  • Konfigurer biasrapporteringsmekanisme for brugere
  • Dokumentmodelversion, konfiguration og beslutningsgenopbygningsmetode

Fase 3: kontinuerlig overvågning

  • Overvåg fairness-dashboards ugentligt og undersøg tærskelovertrædelser inden for 24 timer (eller din organisations aftalte svar-SLA)
  • Udfør månedlige analyser af tilsidesættelsesmønster, der identificerer systematiske problemer
  • Gennemse brugerbiasrapporter ugentligt med dokumenterede undersøgelsesresultater
  • Udfør kvartalsmæssige omfattende rimelighedsrevisioner for agenter med store interesser
  • Opdater dokumentation, efterhånden som agenter udvikles gennem meddelelsesopdateringer eller modelændringer

Fase 4: Skalering og styring

  • Opret genanvendelige fairness-dashboardskabeloner for almindelige agenttyper
  • Opbyg værktøjer til agentbeslutningskonstruktion, der aktiverer selvbetjening for overensstemmelsesteam
  • Standardiser samtykkestyringsmønstre på tværs af alle nye agenter
  • Implementer automatiseret fairness-regressionstest i CI/CD-pipelines
  • Planlægge halvårlige eksterne fairness-revisioner af tredjeparter
  • Vedligeholde lovgivningsmæssig overvågning og tilpasse sig til aktive og nye forpligtelser, herunder EU AI Act (faseindgåelse indtil 2025-2027), statslige love og sektorregler

Fairness er en kernearkitektonisk bekymring for agentiske systemer på Salesforce Platform. Organisationer, der designer Agentforce med fairness som en førsteklasses arkitektonisk bekymring, placerer sig foran lovgivningskravene, mens de opbygger løsninger, som alle brugere kan Trust og bruge effektivt. Platformsfunktionerne findes. Spørgsmålet er, om arkitekter vil bruge dem.

Del din feedback om den veludformede ramme.