AI-etikk og styring – mønstre
Lær mer om Well-Architected Fairness → Practice Ethical AI Governance
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Einstein | Opplæringsdata | ✅ Salesforce CRM-data revideres for gap i demografisk representasjon og målingskonsistens før opplæring av forutsigelsesmodeller |
| Einstein | Opplæringsdata | ✅ Historiske konverteringsdata analyseres av kundedemografi for å identifisere underrepresenterte segmenter som krever overutvalg eller ekstra datainnsamling |
| Einstein | Distribusjon | ✅ Fairness-vurdering behandles som obligatorisk gate som tilsvarer sikkerhetsvurdering før forutsigelsesmodeller når produksjon |
| Einstein | Distribusjon | ✅ Demografisk paritet, lik salgsmulighet og ulik innvirkning beregnes på tvers av beskyttede grupper før distribusjon |
| Einstein | Distribusjon | ✅ Fairness-målinger evalueres mot fire-femtes-regelen (80 %- terskel) som en screening-utløser – ikke en juridisk gjennomgang/feil-linje – for alle kundesegmenter før modelldistribusjon |
| Einstein Discovery | Instrumentering | ✅ Forutsigelsesmodellbeslutningsdata – forutsigelsesinndata, utdata og modellversjoner – fanges opp via Einstein Discovery og tilpasset instrumentering som muliggjør avvikdeteksjon |
| CRM Analytics | Overvåking | ✅ CRM Analytics-kontrollpaneler analyserer fangede forutsigelsesmodellbeslutningsdata for beslutningsmønstre på tvers av demografiske grupper over tid |
| CRM Analytics | Overvåking | ✅ CRM Analytics-varsler utløses når målinger av demografisk paritet eller lik salgsmulighet avviker utenfor gyldige terskler |
| Einstein | Funksjonsteknologi | ✅ Alle prediktive modellfunksjoner analyseres for korrelasjon med beskyttede egenskaper ved bruk av statistiske metoder |
| Einstein | Funksjonsteknologi | ✅ Proxyfunksjoner (område, postnummer, kontonavnmønstre, aktivitetstid, enhetstype) identifiseres og evalueres for demografisk korrelasjon |
| Einstein | Funksjonsteknologi | ✅ Proxyfunksjoner fjernes eller transformeres etter å ha vurdert om forutsigelsesverdi berettiger inkludering til tross for proxy-effekter |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Einstein | Opplæringsdata | ⚡️ Salgsemnescore blir opplært på 10 års historiske data uten å undersøke demografiske representasjoner eller forskjeller i tjenestenes kvalitet |
| Einstein | Opplæringsdata | ⚡️ Historiske konverteringsdata brukes direkte uten å kontrollere om forskjellige demografiske grupper har fått forskjellig behandling |
| Einstein | Distribusjon | ⚡️ Einstein distribueres bare basert på generelle nøyaktighetsmålinger uten vurdering av rettferdighet |
| Einstein | Distribusjon | ⚡️ Demografisk paritet eller ulik innvirkning beregnes ikke før produksjonsdistribusjon |
| Einstein | Trust | ⚡️ Agentforce distribueres uten å aktivere Trust Layer-revisjonsfangst for deteksjon av systematiske avvik |
| CRM Analytics | Overvåking | ⚡️ Beslutningsmønstre spores ikke av demografiske grupper over tid; systematiske avvik blir ikke oppdaget |
| Einstein | Funksjonsteknologi | ⚡️ Beskyttede egenskaper fjernes fra opplæringsdata forutsatt at dette automatisk eliminerer systematiske avvik |
| Einstein | Funksjonsteknologi | ⚡️ Område-, postnummer- og kontonavnmønstre brukes som funksjoner uten proxy-korrelasjonsanalyse |
| Einstein | Funksjonsteknologi | ⚡️ Proxyfunksjoner som fungerer som perfekte demografiske proxyer, beholdes uten å evaluere alternativer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Agentforce | Analytics | ✅ CRM Analytics-kontrollpaneler sporer Agentforce etter kundedemografi ved bruk av revisjonsdata for Einstein Trust Layer |
| Agentforce | Analytics | ✅ Godkjenningsfrekvenser, responstider for tjenester, eskaleringsfrekvenser og tilfredshetsscore overvåkes stratifisert etter demografisk gruppe |
| Agentforce | Analytics | ✅ CRM Analytics-varsler konfigureres for å utløses når fairness-målinger bryter definerte terskler som krever undersøkelse |
| Agentforce | Hendelsesovervåking | ✅ Hendelsesovervåkingslogger rutes til ekstern SIEM for langsiktig oppbevaring som overskrider grenser for innebygd oppbevaring |
| Agentforce | Hendelsesovervåking | ✅ SIEM-spørringer identifiserer unormale konsentrasjoner av negative utfall for bestemte brukerpopulasjoner |
| Agentforce | Feltrevisjonsspor | ✅ Feltrevisjonsspor er aktivert for tilpassede objekter som lagrer Agentforce beslutningsdata, beholder arkivert historikk på ubestemt tid til slettet |
| Agentforce | Feltrevisjonsspor | ✅ Feltrevisjonsspor støtter langsiktige rettferdighetsrevisjoner og forskriftsundersøkelser som krever rekonstruksjon av historiske AI-beslutninger |
| CRM Analytics | Overvåking | ✅ CRM Analytics-kontrollpaneler sporer rettferdighetssignaler: plutselige endringer i beslutningsfordelinger, økninger i skjevhetsrelaterte saker, nedgang i ytelsen for bestemte populasjoner |
| CRM Analytics | Overvåking | ✅ Varsler utløses når godkjenningsgrader for et kundesegment faller mer enn 15 % uke for uke, som krever rettferdighetsundersøkelse |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Agentforce | Analytics | ⚡️ Beslutningsresultater spores ikke av demografi. Avvik for systematiske avvik blir ikke oppdaget når datafordelinger skiftes |
| Agentforce | Analytics | ⚡️ Tjenestekvalitetsmålinger er ikke lagd etter demografisk gruppe, uensartede utfall forblir usynlige |
| Agentforce | Hendelsesovervåking | ⚡️ Hendelsesovervåkingslogger baseres på innebygde oppbevaringsgrenser uten ekstern SIEM for langsiktige rettferdighetsrevisjoner |
| Agentforce | Hendelsesovervåking | ⚡️ Beslutningsmønstre analyseres ikke på tvers av store antall interaksjoner, unormale konsentrasjoner mistes |
| Agentforce | Feltrevisjonsspor | ⚡️ Feltrevisjonsspor er ikke aktivert. Historiske AI-beslutninger kan ikke rekonstrueres for regulatoriske undersøkelser |
| CRM Analytics | Overvåking | ⚡️ Rettferdighetssignaler overvåkes ikke, plutselige endringer i beslutningsfordelinger blir ikke oppdaget |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Einstein | Opplæringsdata | ✅ Salesforce CRM-data blir balansert på nytt ved å oversamplere underrepresenterte segmenter eller undersamplere overrepresenterte segmenter før opplæring |
| Data 360 | Arkitektur | ✅ Data 360 samler data på tvers av flere organisasjoner og sikrer ulike opplæringssett for forutsigelsesmodeller |
| Einstein | Opplæringsdata | ✅ Generering av syntetiske data supplerer sparsomme segmenter samtidig som personvern bevares gjennom differensierte personvernteknikker |
| Einstein | Funksjonsteknologi | ✅ Proxyfunksjoner erstattes med alternative funksjoner som gir prediktiv kraft uten demografisk korrelasjon |
| Einstein | Funksjonsteknologi | ✅ Bransjeklassifisering eller firmas størrelse brukes i stedet for område når område fungerer som demografisk proxyside |
| Einstein | Funksjonsteknologi | ✅ Firmografiske attributter brukes i stedet for kontonavnmønstre når navn korrelerer med demografi |
| Agentforce | Etterbehandling | ✅ Beslutningsterskeler justeres per demografisk segment for å avstemme utfallstallene etter modellopplæring, bortsett fra at i USA forbyr Tittel VII (Civil Rights Act 1991) justering av score eller kutt etter beskyttet klasse for ansettelsesrelaterte beslutninger, og andre jurisdiksjoner pålegger sine egne begrensninger |
| Agentforce | Etterbehandling | ✅ Forskjellige konfidens terskler brukes for forskjellige kontekster for å oppnå rettferdige godkjenningsgrader ved bruk av den samme underliggende forutsigelsesmodellen |
| Agentforce | Etterbehandling | ✅ Terskeljusteringer dokumenteres med forretningsbegrunnelse for forskjellig behandling, idet det anerkjennes at i USA er det ingen dokumentasjon som gjør gruppescore- eller avgrensningsjustering lovlig for ansettelsesrelaterte beslutninger i henhold til tittel VII |
| Einstein | Modellopplæring | ✅ Kvartalsvis eller hendelsesdrevet omopplæringsplan er etablert for å fange opp nye skjevhetsmønstre og korrigere avvik fra opprinnelige rettferdighetsstandarder |
| Einstein | Modellopplæring | ✅ Fairness-målinger valideres på nytt for hver modellversjon før produksjonsdistribusjon for å sikre at omopplæring ikke introduserte nye systematiske avvik |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Einstein | Opplæringsdata | ⚡️ Opplæringsdata brukes direkte uten å balansere underrepresenterte eller overrepresenterte segmenter på nytt |
| Einstein | Opplæringsdata | ⚡️ Små demografiske segmenter suppleres ikke med syntetiske data eller aggregering på tvers av organisasjoner |
| Einstein | Funksjonsteknologi | ⚡️ Proxyfunksjoner beholdes uten å evaluere alternative funksjoner som gir forutsigelseskraft uten demografisk korrelasjon |
| Agentforce | Etterbehandling | ⚡️ Samme konfidens terskler brukes på alle demografiske segmenter uten å avstemme utfallstall |
| Agentforce | Etterbehandling | Differensiell behandling gjennom terskeljusteringer mangler dokumentert forretningsbegrunnelse, eller, i USA, brukes den i det hele tatt på ansettelsesrelaterte beslutninger, der Tittel VII forbyr justering av score eller kutt etter beskyttet klasse uavhengig av dokumentasjon |
| Einstein | Modellopplæring | ⚡️ Modeller distribueres og blir aldri opplært på nytt. Fremvoksende skjevhetsmønstre og avvik blir ikke korrigert |
| Einstein | Modellopplæring | ⚡️ Omlæring skjer uten å validere rettferdighetsmålinger på nytt. Nye systematiske avvik settes inn stille |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Einstein Discovery | Brukergrensesnitt | ✅ Einstein Discovery som viser forutsigelsesfaktorer, vises i Lightning ved beslutningssted |
| Einstein Discovery | Brukergrensesnitt | ✅ Forklaringer viser hvilke variabler som mest påvirket spesifikke forutsigelser med retningsinnvirkning for brukere ved beslutningspunkter |
| Einstein Discovery | Brukergrensesnitt | ✅ Forklaringer er lagd for forskjellige målgrupper: forretningsbrukere, tekniske brukere, kunder og revisorer |
| Einstein Discovery | Brukergrensesnitt | ✅ Forretningsbrukere ser “Dette salgsemnet scoret høyt fordi årlig omsetning overstiger 1 000 000 USD og engasjementsscore er i topp 10 %“ |
| Einstein Discovery | Brukergrensesnitt | ✅ Tekniske brukere ser modellkort med funksjonsvekter, opplæringsdataegenskaper og valideringsmålinger |
| Einstein Discovery | Brukergrensesnitt | ✅ Kunder ser “Denne anbefalingen er basert på dine siste kjøp og kunder med lignende preferanser” |
| Einstein Discovery | Brukergrensesnitt | ✅ Revisorer ser hele beslutningslinjen fra Einstein Discovery og Modellbehandling med modellversjon, inndataverdier og faktorene som drev forutsigelsen |
| Einstein Discovery | Brukergrensesnitt | ✅ Forutsigelseskonfidens vises i brukervennlige termer som kategorier (Høy konfidens, Moderere konfidens, Trenger gjennomgang) med forklaringer |
| Einstein Discovery | Brukergrensesnitt | ✅ Konfidenskategorier forklarer hva konfidensnivået betyr for beslutningspålitelighet og hvilken ytterligere gjennomgang som skal skje |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Einstein Discovery | Brukergrensesnitt | ⚡️ Forklaringer tilpasses på nytt til opaktige systemer etter distribusjon i stedet for å bygge forklarbarhet i arkitekturen fra start av |
| Einstein Discovery | Brukergrensesnitt | ⚡️ Forutsigelsesforklaringer krever navigering for å skille CRM Analytics-kontrollpaneler i stedet for å vises ved beslutningspunkter |
| Einstein Discovery | Brukergrensesnitt | ⚡️ Brukere ser abstrakte modellytelsesmålinger i stedet for gjennomsiktige forklaringer når beslutninger påvirker dem |
| Einstein Discovery | Brukergrensesnitt | ⚡️ Forklaringer varierer ikke etter målgruppe, teknisk modellkort vises til kunder eller forretningsbrukere |
| Einstein Discovery | Brukergrensesnitt | ⚡️ Rå forutsigelsesscore (0,73) vises uten noen forklaring på hva tallet betyr eller hvilke faktorer som førte til forutsigelse |
| Einstein Discovery | Brukergrensesnitt | ⚡️Konfidens vises som sannsynlighetsprosenter der brukere feiltolker uten kontekst om pålitelighet eller gjennomgang |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Einstein | Trust | ✅ Einstein Trust logger ledetekster, svar, jordingskilder og Trust automatisk uten tilpasset instrumentering |
| Einstein | Trust | ✅ Dataoppbevaringspolicyer er utformet for å oppfylle lovpålagte krav som varierer etter bransje og jurisdiksjon (FINRA-regel 4511(b) angir for eksempel en standard oppbevaringsperiode på seks år, og HIPAA krever minst seks år for samsvarsdokumentasjon) |
| CRM Analytics | Overvåking | ✅ CRM Analytics-kontrollpaneler analyserer innhentede forutsigelsesmodellbeslutningsdata for beslutningsmønstre, fairness-målinger og modellytelse over tid |
| CRM Analytics | Overvåking | ✅ CRM Analytics-linser viser forutsigelsesfordelinger etter konfidensnivå, demografisk segment og utfallstype |
| CRM Analytics | Overvåking | ✅ Einstein Discovery identifiserer avvikende mønstre som krever undersøkelse |
| Plattform | Feltrevisjonsspor | ✅ Feltrevisjonsspor er aktivert for tilpassede objekter som lagrer AI-beslutningsdata, beholder arkivert historikk på ubestemt tid til den slettes for samtykkeposter, overstyrer beslutninger og systematiske rapporter |
| Plattform | Hendelsesovervåking | ✅ Hendelsesovervåking fanger opp Agentforce, verktøykall og beslutningspunkter |
| Plattform | Hendelsesovervåking | ✅ Hendelsesovervåkingslogger rutes til ekstern SIEM via plattformhendelser for manipuleringssikker lagring |
| Plattform | Hendelsesovervåking | ✅ SIEM-spørringer oppdager skjevhetsmønstre på tvers av store volumer av Agentforce |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Einstein | Trust | ⚡️ Agentforce distribueres uten å aktivere kontrollfangst av Trust lag eller definere oppbevaringspolicyer |
| Einstein | Trust | ⚡️ Oppbevaringspolicyer tar ikke hensyn til bransjespesifikke lovpålagte krav (finansielle tjenester, helsetjenester) |
| CRM Analytics | Overvåking | ⚡️ Fangede forutsigelsesmodellbeslutningsdata analyseres ikke, beslutningsmønstre og fairness-målinger spores ikke over tid |
| Plattform | Feltrevisjonsspor | ⚡️ Standard 18-måneders felthistorikk baseres på AI-beslutningsrevisjonsspor uten å vurdere krav til lovpålagte oppbevaringskrav |
| Plattform | Feltrevisjonsspor | ⚡️ Feltrevisjonsspor er ikke aktivert for objekter med samtykkeposter, overstyr beslutninger og systematiske rapporter |
| Plattform | Hendelsesovervåking | ⚡️ Hendelsesovervåkingslogger baseres på innebygde oppbevaringsgrenser uten ekstern SIEM for manipuleringsklar langsiktig lagring |
| Plattform | Hendelsesovervåking | ⚡️ Agentforce interaksjonslogger analyseres ikke for systematiske skjevheter på tvers av store volumer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Styring | EU AI Act | ✅ AI-systemer med høy risiko er dokumentert med transparensdokumentasjon, teknisk dokumentasjon, muligheter for menneskelig oversikt og nøyaktighet/rettferdighetsmålinger |
| Styring | EU AI Act | ✅ Einstein Trust Layer-revisjonsspor og Discovery-modellkort gir grunnlag for gjennomsiktighetskravene i EUs AI Act |
| Styring | EU AI Act | ✅ Demografi for modellopplæringsdata, valideringstilnærminger og kjente begrensninger er dokumentert i arkitekturbeslutningsposter |
| Styring | GDPR | ✅ Systemer genererer sammenhengende forklaringer for alle historiske beslutninger på forespørsel innenfor tidsrammer for forespørsler om datasubjektets tilgang (som varierer etter jurisdiksjon, mellom 15 og 45 dager) |
| Styring | GDPR | ✅ Oppfangede forutsigelsesmodellbeslutningsdata og Einstein Discovery forklaringsfaktorer lagres med tilstrekkelig oppbevaring for å muliggjøre forklaringsrekonstruksjon for GDPR-retten til forklaring |
| Styring | Algoritmisk ansvarlighet | ✅ Algoritmiske innvirkningsvurderinger utføres før du distribuerer etterfølgende AI som proaktiv overholdelse i stedet for reaktive svar |
| Styring | Algoritmisk ansvarlighet | ✅ Registrerte forutsigelsesmodellbeslutningsdata og CRM Analytics-kontrollpaneler for overvåking av rettferdighet gir grunnlag for data for algoritmisk rapportering av ansvar |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Styring | EU AI Act | ⚡️ AI-systemer med høy risiko distribueres uten transparensdokumentasjon, muligheter for menneskelig oversikt eller fairness-målinger |
| Styring | EU AI Act | ⚡️ Demografi for modellopplæringsdata og kjente begrensninger dokumenteres ikke i arkitekturbeslutningsposter |
| Styring | GDPR | ⚡️ Systemer kan ikke generere sammenhengende forklaringer for historiske beslutninger innenfor tidsrammer for forespørsler om datasubjekttilgang |
| Styring | GDPR | ⚡️ Oppfanget oppbevaring av forutsigelsesmodellbeslutningsdata er ikke tilstrekkelig til å støtte rekonstruksjon av forklaringer for tidligere beslutninger |
| Styring | Algoritmisk ansvarlighet | ⚡️ Algoritmiske innvirkningsvurderinger utføres ikke før etterfølgende AI-distribusjon. Samsvar er reaktivt etter regulatorisk undersøkelse |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | OWD | ✅ Private organisasjonsomfattende standardinnstillinger er etablert for objekter som inneholder sensitive kundedata med tilgang gitt via rollehierarki og delingsregler |
| Plattform | OWD | ✅ Private OWD-er med eksplisitte delingstildelinger oppretter reviderbare tilgangsmønstre som støtter overholdelse av krav om ikke-diskriminering |
| Plattform | Feltnivåsikkerhet | ✅ Sensitive felt som inneholder beskyttede egenskaper (etnisitet, religion, funksjonshemmingsstatus) skjules via FLS for brukere uten legitim forretningsbehov |
| Plattform | Feltnivåsikkerhet | ✅ Lese-tilgang til sensitive felt fjernes via FLS for de fleste profiler. Tilgang gis minimalt via tillatelsessett med dokumentert begrunnelse |
| Plattform | Tildeling og ruting | ✅ Tildelingsregler, køer og Omnikanal-ruting fordeler arbeid rettferdig på tvers av områder, team og serviceagenter basert på objektive kriterier |
| Plattform | Delingsregler | ✅ Automatiske delingsregler er basert på objektive kriterier (bransje, geografi, produktlinje) i stedet for subjektiv lederbeskyttelse |
| Plattform | Tillatelsessett | ✅ Midlertidig tilgang til sensitive data gis via tillatelsessett med dokumentert utløp i stedet for permanente profilendringer |
| Plattform | Tillatelsessett | ✅ Planlagt flyt opphever automatisk tillatelsessett etter definerte perioder når tilgang til demografiske data er nødvendig for bestemte prosjekter |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | OWD | ⚡️ Offentlige lese/skrive-ODD-er gjør begrenset tilgang senere forstyrrende (tilstrekking av standardutløseren utløser en ny beregning av deling); det finnes ikke reviderbare tilgangsmønstre |
| Plattform | OWD | ⚡️ Konto-OVD er satt til Felles lese/skrive med ubeskyttede demografiske felt synlige for alle brukere som aktiverer subjektive systematiske avvik |
| Plattform | Feltnivåsikkerhet | ⚡️ Sensitive demografiske felt er synlige for alle profiler uten FLS-restriksjoner. Diskriminerende bruk av data hindres ikke |
| Plattform | Delingsregler | ⚡️ Manuell deling konsentrerer salgsmuligheter med høy verdi med bestemte brukergrupper uten dokumentert forretningsbegrunnelse |
| Plattform | Delingsregler | ⚡️ Delingsregler baseres på subjektiv lederbeskyttelse i stedet for objektive kriterier som aktiverer systematiske avvik |
| Plattform | Tillatelsessett | ⚡️ Profiler endres permanent og påvirker alle brukere i stedet for å gi midlertidig tilgang via tillatelsessett |
| Plattform | Tillatelsessett | ⚡️ Tillatelsessett som gir tilgang til sensitive data, utløper ikke automatisk. Tilgang forblir ubestemt etter at prosjektet er fullført |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Shield | Hendelsesovervåking | ✅ Shield-hendelsesovervåking sporer tilgang til felt som inneholder beskyttede egenskaper eller sensitive attributter |
| Shield | Hendelsesovervåking | ✅ Hendelsesovervåking sporer hvem som har tilgang til demografiske felt, når og i hvilken kontekst detekterer unormale mønstre |
| Shield | Hendelsesovervåking | ✅ Unormale tilgangsmønstre (plutselig spike, tilgang fra uventede brukere) utløser undersøkelse av potensiell misbruk |
| Plattform | Rapportering | ✅ Rapporter analyserer hvordan delingsregler distribuerer poster på tvers av brukere, team og områder ved å beregne distribusjonsstatistikk etter kundedemografi |
| Plattform | Rapportering | ✅ Rapporter identifiserer konsentrasjoner der bestemte brukergrupper får uforholdsmessig tilgang til verdifulle poster uten dokumentert begrunnelse |
| Plattform | Revisjonsspor for oppsett | ✅ Revisjonsspor for oppsett blir gjennomgått for endringer i OWD-innstillinger, delingsregler, FLS-konfigurasjoner og tillatelsessett som oppdager uautoriserte endringer |
| Plattform | Transaksjonssikkerhet | ✅ Transaksjonssikkerhetspolicyer handler på hendelser med høy risiko i Sanntids hendelsesovervåking (avvikende API-aktivitet, mistenkelige pålogginger, stor eksport av sensitive data); FLS- og delingsendringer er avhengig av Revisjonsspor for oppsett og dokumenterte godkjenninger av endringsbehandling |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Shield | Hendelsesovervåking | ⚡️ Tilgang til sensitive demografiske felt overvåkes ikke, potensielt misbruk blir ikke oppdaget |
| Shield | Hendelsesovervåking | ⚡️ Unormale tilgangsmønstre (spikes, uventede brukere) spores ikke eller undersøkes ikke |
| Plattform | Rapportering | ⚡️ Delingsregelfordelinger analyseres ikke. Uforholdsmessig tilgang til verdiposter forblir usynlig |
| Plattform | Rapportering | ⚡️ Konsentrasjoner av kontoer med høy verdi med bestemte brukergrupper mangler dokumentert forretningsbegrunnelse |
| Plattform | Revisjonsspor for oppsett | ⚡️ Revisjonsspor for oppsett gjennomgås ikke. Uautoriserte endringer i datatilgangskontroller som aktiverer sensitiv datatilgang, oppdages ikke |
| Plattform | Transaksjonssikkerhet | ⚡️ Hendelser med høy risiko i Sanntids hendelsesovervåking (avvikende API-aktivitet, store eksporter av sensitive data) håndteres ikke med transaksjonssikkerhetspolicyer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Tilpassede objekter | ✅ Detaljert samtykke per brukstilfelle med AI er aktivert via tilpasset formål for Sporing av samtykkeobjekt, tildelingsdato/metode, tilbaketrekningsdato og relatert bruker/kontakt-ID |
| Plattform | Tilpassede objekter | ✅ Kunder samtykker i Einstein samtidig som de avslår AI-drevne kredittbeslutninger via separate samtykkeposter per bruksområde |
| Plattform | Feltrevisjonsspor | ✅ Feltrevisjonsspor er aktivert i Samtykke-objektet for oppfyllelse av lovpålagte krav om langsiktig oppbevaring |
| Data 360 | Samtykke | ✅ Data 360-samtykkebehandling brukes til Einstein-tilpassing, til å hente inn og lagre samtykkepreferanser via koblinger som er tilordnet til personverndatamodellen, og bruke dem som filterkriterier i segmentering og ved aktivering |
| Data 360 | Samtykke | ✅ Samtykketegorier tilordnes til bestemte AI-brukstilfeller som gir brukere mulighet til å velge bort tilpassing samtidig som kjernetjenesten opprettholdes |
| Marketing Cloud | Samtykke | ✅ Marketing Cloud-samtykke integreres med Einstein Messaging-innsikt og Agentforce som tar hensyn til abonnementsstatus |
| Marketing Cloud | Samtykke | ✅ Samtykkestatusen for Marketing Cloud spørres før Agentforce starter automatisert oppfølging for å hindre uønsket kontakt med brukere som har valgt å ikke delta |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Tilpassede objekter | ⚡️ AI-samtykke spores i regneark eller baseres på pålogging som implisitt samtykke uten eksplisitte poster |
| Plattform | Tilpassede objekter | ⚡️ Samtykke med blanket AI brukes i stedet for detaljert samtykke per brukstilfelle. Brukere kan ikke velge bort bestemte AI-funksjoner |
| Plattform | Feltrevisjonsspor | ⚡️ Feltrevisjonsspor er ikke aktivert for Samtykke-objektet, krav om langsiktig oppbevaring oppfylles ikke vedlikeholdt |
| Data 360 | Samtykke | ⚡️ Data 360-samtykke brukes ikke til Einstein-tilpassing, samtykketegorier tilordnes ikke til bestemte bruksområder |
| Marketing Cloud | Samtykke | ⚡️ Marketing Cloud-samtykke er ikke integrert med Einstein eller Agentforce. Abonnementsstatus respekteres ikke i automatisert opplæring |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Experience Cloud | Profilinnstillinger | ✅ Brukere velger bort Agentforce via tilgjengelige preferansekontroller i Experience Cloud-profilinnstillinger eller Mine innstillinger med tydelige beskrivelser |
| Plattform | Bruker/kontakt-poster | ✅ AI-preferanser lagres i Bruker- eller Kontakt-poster som aktiverer spørring i Flyt- og Agentforce |
| Agentforce | Omnikanal | ✅ Brukere som velger bort Agentforce, rutes til menneskelige agenter via Omnikanal i stedet for å motta degradert service |
| Agentforce | Flyt | ✅ Flyt kontrollerer samtykke- og preferansefelt før Agentforce engasjerer seg. Hvis bruker velger bort, opprettes en arbeidspost og rutes til køen |
| Agentforce | Omnikanal | ✅ Personalet i køen gir sammenlignbare ventetider for automatisert tjeneste for brukere som har valgt bort |
| Plattform | Bruker/kontakt-poster | ✅ AI-preferanser lagres i Bruker- eller Kontakt-poster for å sikre konsistens på tvers av kanaler (nett, mobil, telefon, e-post) |
| Plattform | Flyt | ✅ Preferanse spørres konsistent i alle interaksjonsflyter for å hindre at brukere må deklarere preferanser på nytt gjentatte ganger i hver kanal |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Experience Cloud | Profilinnstillinger | ⚡️ Reservasjon er tilgjengelig bare via e-post til kundestøtteteamet. Tilgjengelige preferansekontroller finnes ikke |
| Plattform | Bruker/kontakt-poster | ⚡️ AI-preferanser lagres ikke i Bruker- eller Kontakt-poster. Preferanser kan ikke spørres i Flyt- eller Agentforce |
| Agentforce | Omnikanal | ⚡️ Brukere som velger bort, mottar degradert tjeneste som implisitt press for å godta AI i stedet for å rute til menneskelige agenter |
| Agentforce | Flyt | ⚡️ Flyt kontrollerer ikke samtykke- eller preferansefelt før Agentforce engasjerer; reservasjonspreferanser ignoreres |
| Plattform | Bruker/kontakt-poster | ⚡️ Preferanser er ikke konsistente på tvers av kanaler. Brukere må deklarere reservasjon på nytt på nett, mobil, telefon og e-post separat |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Styring | Dokumentasjon | ✅ Hver forutsigelsesmodell for produksjon er dokumentert med opplæringsdatademografi, rettferdighetsmålinger, tiltenkte brukstilfeller, strategier for avverging av systematiske avvik og overvåkingsmetoder |
| Styring | Dokumentasjon | ✅ Modelldokumentasjonen inkluderer tilnærmingen for overvåking av rettferdighet, varselterskler, krav til personlig tilsyn, tidsplan for gjennomgang og viktige punkter om forskrifter |
| Plattform | Tilpassede objekter | ✅ Modelldokumentasjon lagres i Salesforce med tilpasset Modell-objekt eller Salesforce Files knyttet til Prosjekter som aktiverer søkbarhet og versjonskontroll |
| Styring | Distribusjonsportaler | ✅ Fairness-portaler før distribusjon krever opplæringsdatarevisjon, beregning av fairness-målinger, innvirkningsvurdering, utforming av menneskelig oversikt og gjennomgang av gjennomsiktighet før produksjon |
| Styring | Distribusjonsportaler | ✅ Lukkene i opplæringsdatarepresentasjon analyseres og dokumenteres som obligatorisk distribusjonsgate |
| Styring | Distribusjonsportaler | ✅ Demografisk paritet, lik salgsmulighet og ulik innvirkning beregnes som oppfyllelsesterskler som obligatorisk gate |
| Styring | Distribusjonsportaler | ✅ Innvirkningsvurdering evaluerer potensiell skade på tvers av berørte populasjoner som obligatorisk portal |
| Styring | Distribusjonsportaler | ✅ Utformingen av menneskelig oversikt, inkludert eskaleringsmønstre, godkjenningsarbeidsflyter og overstyringsmekanismer, er utformet og testet som obligatorisk portal |
| Styring | Distribusjonsportaler | ✅ Forklaringsfunksjonalitet valideres for alle beslutningstyper som obligatorisk portal |
| Styring | Distribusjonsportaler | ✅ Fairness-portaler behandles med samme strenghet som sikkerhetsportaler med myndighet til å blokkere distribusjoner som mislykkes i noen porter |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Styring | Dokumentasjon | ⚡️ Einstein distribueres uten å dokumentere opplæringsdata, fairness-målinger, avbøying av systematiske avvik eller overvåkingstilnærminger |
| Styring | Dokumentasjon | ⚡️ Modelldokumentasjonen inkluderer ikke tilnærmingen for overvåking av rettferdighet, krav til personlig tilsyn eller viktige punkter om forskrifter |
| Plattform | Tilpassede objekter | ⚡️ Modelldokumentasjon lagres i regneark eller wikier uten søkbarhet eller versjonskontroll |
| Styring | Distribusjonsportaler | ⚡️ Einstein fortsetter til produksjon uten rettferdighetsportaler. Distribusjon er bare basert på generelle nøyaktighetsmålinger |
| Styring | Distribusjonsportaler | ⚡️ Opplæringsdatarevisjon, beregning av rettferdighetsmålinger eller innvirkningsvurdering hoppes over før produksjonsdistribusjon |
| Styring | Distribusjonsportaler | ⚡️ Personlig tilsynsutforming, gjennomsiktighetsgjennomgang eller forklaringsvalidering utføres ikke før produksjon |
| Styring | Distribusjonsportaler | ⚡️ Fairness-portaler er bare rådgivende uten autorisasjon til å blokkere distribusjoner. Modeller fortsetter selv om fairness-kriteriene mislykkes |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Styring | Review Board | ✅ Gjennomgangspanelet inkluderer tekniske eksperter (arkitekter, datateknikere), forretningsinteressenter, juridiske rådgivere, personvernspesialister og representanter fra berørte fellesskap |
| Styring | Review Board | ✅ Forskjellige perspektiver viser rettferdighetsproblemer homogene grupper mangler under etisk gjennomgang |
| Styring | Se gjennom utløsere | ✅ Se gjennom-utløsere er definert: beslutninger som påvirker ansettelse/kreditt/boliger/helse/lovlige rettigheter, systemer som påvirker over 10 000 brukere årlig, nye bruksområder, betydelig skaderisiko |
| Styring | Se gjennom utløsere | ✅ AI-programmer som bruker sensitive personlige data (helse, økonomi, demografi) krever etisk gjennomgang før distribusjon |
| Styring | Review Authority | ✅ Ethics Review Board har myndighet til å kreve endringer, innføre overvåkingsbetingelser eller blokkere distribusjoner som mislykkes med etiske standarder |
| Plattform | Tilpassede objekter | ✅ Alle vurderinger dokumenteres i Salesforce-tilpasset objektsporingsprogramnavn, gjennomgangsdato, oppståtte bekymringer, forebyggingskrav og godkjenningsbetingelser |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Styring | Review Board | ⚡️ Review Board mangler mangfold (bare tekniske eksperter); homogene grupper mangler rettferdighetsproblemer som påvirker forskjellige populasjoner |
| Styring | Review Board | ⚡️ Representanter fra berørte fellesskap inkluderes ikke. Blindflater i hensyn til rettferdighet resulterer |
| Styring | Se gjennom utløsere | ⚡️ Se gjennom-utløsere er ikke definert. Applikasjoner med AI med høy risiko fortsetter uten etisk gjennomgang før distribusjon |
| Styring | Review Authority | ⚡️ Etikkgjennomgang er bare rådgivning uten håndheving. Distribusjoner fortsetter til tross for mislykkede etiske standarder (ansvarsteater) |
| Plattform | Tilpassede objekter | ⚡️ Gjennomganger dokumenteres ikke systematisk, historiske gjennomgangsbeslutninger, bekymringer og avbøyninger spores ikke |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| CRM Analytics | Overvåking | ✅ CRM Analytics-kontrollpaneler sporer Einstein og Agentforce fairness-målinger fra registrerte beslutningsdata og Trust Layer-revisjonsdata i en planlagt kadens |
| CRM Analytics | Overvåking | ✅ Demografisk paritet, lik salgsmulighet, ulik innvirkning og målinger av tjenestenivå overvåkes etter kundesegment |
| CRM Analytics | Overvåking | ✅ CRM Analytics-varsler konfigureres for å utløses når fairness-målinger bryter definerte terskler som krever undersøkelse |
| CRM Analytics | Overvåking | ✅ CRM Analytics-kontrollpaneler sporer rettferdighetssignaler: plutselige endringer i beslutningsfordelinger, økninger i skjevhetsrelaterte saker, nedgang i ytelsen for bestemte populasjoner |
| CRM Analytics | Overvåking | ✅ Varsler utløses for Einstein når godkjenningsgrader for et segment faller mer enn 15 % uke for uke, noe som krever rettferdighetsundersøkelse |
| Styring | Planlagte revisjoner | ✅ Omfattende rettferdighetsrevisjoner utføres kvartalsvis for AI med høy innsats (kreditt, ansettelse, helsetjenester) eller halvårlig for systemer med lavere innsats |
| Styring | Planlagte revisjoner | ✅ Revisjoner undersøker gjeldende fairness-målinger, ser gjennom overstyringsmønstre, analyserer tilbakemeldinger fra brukere og systematiske rapporter, og validerer styringskontroller som forblir effektive |
| Styring | Hendelsesrespons | ✅ Clear hendelsesresponsprosesser er dokumentert i Salesforce Knowledge for å svare når systematiske avvik oppdages |
| Styring | Hendelsesrespons | ✅ Umiddelbar vurdering av alvorlighetsgrad ved å spørre mot forutsigelsesmodellbeslutningsdata i CRM Analytics; alvorlig systematiske avvik suspenderer automatisert beslutningstaking i påvente av undersøkelse |
| Styring | Hendelsesrespons | ✅ Midlertidig avbøying implementerer økt oversikt fra brukere via justerte konfidens terskler, funksjonsdeaktivering eller fullstendig suspendering av agent |
| Styring | Hendelsesrespons | ✅ Rotårsaksanalyse identifiserer hvordan systematiske avvik ble oppgitt eller utviklet. Opplæringsdata, modellversjoner og konfigurasjonsendringer analyseres via Feltrevisjonsspor |
| Styring | Hendelsesrespons | ✅ Permanent rettelse implementerer datakorrigering, modellopplæring på nytt eller prosessendringer med riktig kommunikasjon til berørte brukere |
| Styring | Hendelsesrespons | ✅ Forebyggende tiltak dokumenteres i kjørebøker som hindrer gjentagelse av systematiske avvikshendelser |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| CRM Analytics | Overvåking | Fairness-målinger spores ikke på noen planlagt kadens fra innhentede beslutningsdata eller Trust Layer-revisjonsdata; systematiske avvik blir ikke oppdaget etter hvert som datafordelingene endres |
| CRM Analytics | Overvåking | ⚡️ CRM Analytics-varsler er ikke konfigurert, brudd på fairness-målinger som krever undersøkelse, utløses ikke |
| CRM Analytics | Overvåking | ⚡️Rettferdighetssignaler overvåkes ikke, plutselige endringer i beslutningsfordelinger oppdages ikke |
| Styring | Planlagte revisjoner | ⚡️ Omfattende rettferdighetsrevisjoner utføres ikke etter noen tidsplan. Styringskontroller avviker og blir ineffektive |
| Styring | Planlagte revisjoner | ⚡️ Overstyringsmønstre, tilbakemeldinger fra brukere og systematiske avvik i rapporter analyseres ikke systematisk under revisjoner |
| Styring | Hendelsesrespons | ⚡️ Tydelige hendelsessvarprosesser dokumenteres ikke. Deteksjon av systematiske avvik fører til ad hoc-svar uten systematisk tilnærming |
| Styring | Hendelsesrespons | ⚡️ Midlertidig avbøying eller permanent rettelse implementeres ikke systematisk. systematiske avvik fortsetter å påvirke brukere |
| Styring | Hendelsesrespons | ⚡️ Rotårsaksanalyse utføres ikke. Hvordan systematiske avvik ble oppgitt eller utviklet, er ukjent |
| Styring | Hendelsesrespons | ⚡️ Forebyggende tiltak er ikke dokumentert, gjentagelse hindres ikke |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Nødvendige felt | ✅ Hvert nødvendige felt bærer en dokumentert forretningsbegrunnelse for hvorfor dataene er obligatoriske i stedet for valgfrie. Felt som en prosess kan fungere uten, gjøres valgfrie med nedstrøms håndtering av manglende verdier |
| Plattform | Nødvendige felt | ✅ E-post er valgfritt med alternative kommunikasjonsmetoder (SMS, telefon, post) slik at brukere uten pålitelig internett eller personlig e-post ikke utelukkes fra å opprette kontoer |
| Plattform- | Navn-felt | ✅ Navnearkitektur bruker ett felt med fullt navn eller en fleksibel struktur med flere deler som tar hensyn til mononymer, patronymiske systemer og flere gitte eller etternavn uten å anta rekkefølge eller arv |
| Plattform- | Navn-felt | ✅ Navnfelt testes med forskjellige internasjonale navn, som godtar enkeltordnavn, lange navn, diakritikk, apostrof, bindestreker og ikke-latinske skript (arabisk, kinesisk, cyrillisk, Devanagari) |
| Plattform | Adressevalidering | ✅ Tillatelsesvalidering av adresser godtar fritekstoppføring når strukturert validering mislykkes, og lagrer adresser etter hvert som brukere oppgir dem, i stedet for å tvinge ugyldige korrigeringer |
| Plattform | Adressevalidering | ✅ Adresseverifisering er innebygd i innfrielsesprosesser der nøyaktighet er viktig operativt i stedet for å blokkere datafangst på forhånd |
| Plattform | Kommunikasjonspreferanser | ✅ Foretrukne kommunikasjonsmetoder lagres i Kontakt-poster og respekteres konsistent på tvers av alle utgående systemer, og tilbyr alternativer for omnikanal i stedet for forutsetninger med én kanal |
| Tilpasset objekt | Demografiske data | ✅ Frivillige demografiske data samles inn via en separat undersøkelse med alternativet “Foretruk ikke å svare”, lagres i et tilpasset objekt med privat OWD, er begrenset av FLS og brukes bare til samlede rettferdighetsanalyser |
| Shield | Hendelsesovervåking | ✅ Shield-hendelsesovervåking logger tilgangshendelser (rapporteksporter, API-objektspørringer) i demografiske data for å revidere tilgangsmønstre |
| Plattform | Tredjeparts anriking | ✅ Tredjeparts anrikingsleverandører blir revidert for rettferdighetstesting, demografisk dekning og nøyaktighet, utledningsmetodologi og restriksjoner for kontraktsmessig bruk av data før implementering |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Nødvendige felt | ⚡️ E-post er nødvendig for å opprette en konto uten noe alternativ, og telefon- eller adressevalidering avviser ikke-USA-formater, postbokser og landlige ruter, unntatt brukere som ikke kan oppgi dataene |
| Plattform | Nødvendige felt | ⚡️ Felt merkes som nødvendige uten å dokumentere om prosessen kan fungere uten dataene og opprette usynlige populasjoner fra avviste ufullstendige poster |
| Plattform- | Navn-felt | ⚡️ Navnfelt håndhever Western First/Last-konvensjoner og avviser mononymer, diakritikk eller ikke-latinske skript, og utsetter brukere for systemavvisning basert på kulturell identitet |
| Plattform | Adressevalidering | ⚡️ Adressevalidering krever US-postformat og klarer ikke å gjenkjenne internasjonale adresser, postbokser, militære (APO/FPO) eller stamme-land-adresser, noe som blokkerer opprettelse av kontoer og levering av tjenester |
| Plattform | Kommunikasjonspreferanser | ⚡️ En enkelt kommunikasjonskanal antas å være universell (bare e-post eller bare telefon), unntatt brukere uten internett, uten telefontilgang eller som er døve eller har problemer med å høre |
| Tilpasset objekt | Demografiske data | Demografiske data utledes fra navn eller steder uten bruker Knowledge, lagres i standard Kontakt-felt synlige for alle brukere, og brukes i salgsemnescore eller prognoser uten utlevering |
| Plattform | Tredjeparts anriking | ⚡️ Tredjeparts data føyes til uten å revidere leverandørens rettferdighetsrutiner eller demografisk dekning, og importerer leverandøroppgitte systematiske avvik i organisasjonsbeslutninger |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Tildeling og ruting | ✅ Tildelings- og rutingsregler bruker objektive kriterier (produktserier, tjenesteavtaler, språkkrav), og tildelingsfordelinger revideres kvartalsvis, stratifisert etter kundedemografi, for å sikre at det ikke oppstår konsentrasjonsmønstre |
| Plattform | Omnikanal | ✅ Gjennomsnittlig tid til håndtering, første kontaktoppløsning og kundetilfredshet overvåkes på tvers av rutingsbaner for å finne ut om kundesegmenter systematisk mottar mindre erfarne agenter |
| Plattform | Flyt | ✅ Flyter som tar konsekvensbeslutninger, gjennomgås for kriterier som er korrelert med beskyttede egenskaper (kontovarighet, kanalpreferanse, kjøpshistorikk, åpningstider), og deres beslutningslogikk er dokumentert i arkitekstbeslutningsposter |
| Plattform | Flyt | ✅ Flyter som påvirker ansettelse, kreditt eller tjenestetilgang, er underlagt samme etiske gjennomgangsprosess som AI-systemer |
| Plattform | Valideringsregler | ✅ Valideringsregler testes med forskjellige data (internasjonale adresser, ikke-vestlige navn, alternative telefonnummerformater) og utvides når de avviser legitime data. Navn-felt godtar Unicode og alle skript |
| Plattform | Områdeutforming | ✅ Kundedemografi tilordnes på tvers av foreslåtte områdegrenser før utforminger blir ferdigstilt. Der det oppstår konsentrasjoner, evalueres ressurstildelingen for egenkapital og forretningsbegrunnelsen dokumenteres og overvåkes |
| Plattform | Revisjon | ✅ Automatiseringslogikk (forretningsregler, tildelingskriterier, Flytbeslutninger) dokumenteres i Salesforce Knowledge eller ADR-er, og resultatene revideres kvartalsvis stratifisert etter demografi – tildelingsfordelinger, Godkjenningsgrader for flyter, valideringsavvisningsgrader og tildeling av områderessurser |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Tildeling og ruting | ⚡️ Tildelingsregler prioriterer salgsemner fra bestemte postnumre til “toppresultater” basert på historiske andeler vunnet uten å undersøke om suksess gjenspeiler kvalifikasjoner eller demografiske fordeler |
| Plattform | Omnikanal | ⚡️ Rutingkvalitetsmålinger overvåkes ikke på tvers av kundesegmenter, så forskjeller i agentopplevelse eller løsning blir ikke oppdaget |
| Plattform | Flyt | ⚡️ Flytbeslutningskriterier korrelerer med beskyttede egenskaper (eierskap, kanal, kjøpsvolum, tidssone) og behandles som objektive fordi deterministisk logikk føles nøytral |
| Plattform | Flyt | Flyter med stor innsats tar konsekvensbeslutninger uten etisk gjennomgang, ADR-dokumentasjon eller håndtering for brukere utenfor den typiske kundeprofilen |
| Plattform | Valideringsregler | ⚡️ Navnevalidering er begrenset til A-Z og avviser diakritiske eller ikke-latinske skript, og adressevalidering krever US postformat – legitime data avvises og brukere avviser forespørsler som ikke rapporteres |
| Plattform | Områdeutforming | ⚡️ Områdegrenser følger geografi som er korrelert med demografi, med forskjellig kompensasjon eller ansatte på tvers av områder og ingen analyse av demografisk konsentrasjon |
| Plattform | Revisjon | ⚡️ Automatiseringslogikk er udokumentert og utfall revideres aldri, så diskriminerende mønstre i tildeling, godkjenninger, validering eller områdetildeling forblir usynlige |