AI-etiske og styringsmæssige - mønstre
Få mere at vide om veludviklet fairness → Practice Ethical AI Governance
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Einstein | Uddannelsesdata | ✅ Salesforce CRM-data revideres for demografiske repræsentationmangler og måleuoverensstemmelser før træning af forudsigelsesmodeller |
| Einstein | Uddannelsesdata | ✅ Historiske konverteringsdata analyseres af kundedemografier for at identificere underrepræsenterede segmenter, der kræver oversampling eller yderligere datasamling |
| Einstein | Installation | ✅ Ærlighedsevaluering behandles som obligatorisk gate, der svarer til sikkerhedsgennemgang, før forudsigelsesmodeller når produktion |
| Einstein | Installation | ✅ Demografisk paritet, lige salgsmulighed og uensartede påvirkningsforhold beregnes på tværs af beskyttede grupper før implementering |
| Einstein | Installation | ✅ Fairness-metrikker evalueres op mod fire-femtedelsreglen (80 % tærskel) som en screeningudløser – ikke en juridisk gennemgang/fejllinje – for alle kundesegmenter før modelimplementering |
| Einstein Discovery | Instrumentering | ✅ Forudsigelsesmodelbeslutningsdata – forudsigelsesinput, output og modelversioner – registreres gennem Einstein Discovery og tilpasset instrumentering, der aktiverer biasregistrering |
| CRM Analytics | Overvågning | ✅ CRM Analytics-dashboards analyserer registrerede forudsigelsesmodelbeslutningsdata for beslutningsmønstre på tværs af demografiske grupper over tid |
| CRM Analytics | Overvågning | ✅ CRM Analytics-advarsler udløses, når demografisk paritet eller lige salgsmulighedsmetrikker afviger ud over acceptable tærskler |
| Einstein | Funktionsteknik | ✅ Alle forudsigelsesmodelfunktioner analyseres for korrelation med beskyttede egenskaber ved brug af statistiske metoder |
| Einstein | Funktionsteknik | ✅ Proxyfunktioner (område, postnummer, kontonavnsmønstre, aktivitetstidsangivelse, enhedstype) identificeres og evalueres for demografisk korrelation |
| Einstein | Funktionsteknik | ✅ Proxyfunktioner fjernes eller transformeres efter evaluering af, om forudsigelsesværdi retfærdiggør inkludering på trods af proxyeffekter |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Einstein | Uddannelsesdata | ⚡️ Emnescoring trænes på 10 års historiske data uden at undersøge demografiske repræsentationer eller forskelle i servicekvalitet |
| Einstein | Uddannelsesdata | ⚡️ Historiske konverteringsdata bruges direkte uden at overvåge, om forskellige demografier modtog forskellig behandling |
| Einstein | Installation | ⚡️ Einstein implementeres udelukkende baseret på generelle nøjagtighedsmetrikker uden fairness-evaluering |
| Einstein | Installation | ⚡️ Demografisk paritet eller uensartede påvirkningsforhold beregnes ikke før produktionsimplementering |
| Einstein | Trust Layer | ⚡️ Agentforce implementeres uden at aktivere Trust Layer-revisionsregistrering for biasregistrering |
| CRM Analytics | Overvågning | ⚡️ Beslutningsmønstre spores ikke af demografiske grupper over tid. Biasforskydning bliver ikke registreret |
| Einstein | Funktionsteknik | ⚡️ Beskyttede egenskaber fjernes fra træningsdata, hvis dette automatisk eliminerer bias |
| Einstein | Funktionsteknik | Område-, postnummer- og kontonavnsmønstre bruges som funktioner uden proxy-korrelationsanalyser |
| Einstein | Funktionsteknik | ⚡️ Proxyfunktioner, der fungerer som perfekte demografiske proxyer bevares uden at evaluere alternativer |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Agentforce | Analytics | ✅ CRM Analytics-dashboards sporer Agentforce efter kundedemografi ved brug af Einstein Trust Layer-revisionsdata |
| Agentforce | Analytics | ✅ Godkendelsesfrekvenser, serviceresvartider, eskaleringsfrekvenser og tilfredshedsscores overvåges stratificeret efter demografisk gruppe |
| Agentforce | Analytics | ✅ CRM Analytics-advarsler konfigureres til at udløse, når rimelige metrikker bryder definerede tærskler, der kræver undersøgelse |
| Agentforce | Begivenhedsovervågning | ✅ Begivenhedsovervågningslogfiler distribueres til ekstern SIEM for langsigtet bevarelse, der overskrider de oprindelige bevarelsesgrænser |
| Agentforce | Begivenhedsovervågning | ✅ SIEM-forespørgsler identificerer afvigelseskoncentrationer af negative resultater for specifikke brugerpopulationer |
| Agentforce | Feltrevisionsspor | ✅ Feltrevisionsspor er aktiveret på tilpassede objekter, der lagrer Agentforce, bevarer arkiveret historik uendeligt, indtil den slettes |
| Agentforce | Feltrevisionsspor | ✅ Feltrevisionsspor understøtter langsigtede rimelighedsrevisioner og reguleringsundersøgelser, der kræver rekonstruktion af historiske AI-beslutninger |
| CRM Analytics | Overvågning | ✅ CRM Analytics-dashboards sporer fairness-signaler: pludselige ændringer i beslutningsdistributioner, spidser i biasrelaterede sager, nedgang i ydeevnen for specifikke populationer |
| CRM Analytics | Overvågning | ✅ Advarsler udløses, når godkendelsesfrekvenser for ethvert kundesegment falder mere end 15 % uge for uge, der kræver rimelig undersøgelse |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Agentforce | Analytics | ⚡️ Beslutningsresultater spores ikke af demografi. Biasforskydning bliver ikke registreret, når datafordelinger skifter |
| Agentforce | Analytics | ⚡️ Servicekvalitetsmetrikker er ikke stratificeret efter demografisk gruppe. Uensartede resultater forbliver usynlige |
| Agentforce | Begivenhedsovervågning | Event Monitoring-logfiler er afhængige af oprindelige bevarelsesgrænser uden ekstern SIEM for langsigtede rimelighedsrevisioner |
| Agentforce | Begivenhedsovervågning | ⚡️ Beslutningsmønstre analyseres ikke på tværs af store mængder interaktioner. Afvigelseskoncentrationer ignoreres |
| Agentforce | Feltrevisionsspor | ⚡️ Feltrevisionsspor er ikke aktiveret. Historiske AI-beslutninger kan ikke genoprettes for reguleringsundersøgelser |
| CRM Analytics | Overvågning | ⚡️ Fairness-signaler overvåges ikke. Pludselige ændringer i beslutningsdistributioner går ubemærket |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Einstein | Uddannelsesdata | ✅ Salesforce CRM-data genbalanceres gennem oversampling af underrepræsenterede segmenter eller undersampling af overrepræsenterede segmenter før uddannelse |
| Data 360 | Arkitektur | ✅ Data 360 aggregerer data på tværs af flere organisationer og sikrer forskellige træningssæt for forudsigelsesmodeller |
| Einstein | Uddannelsesdata | ✅ Syntetisk datagenerering supplerer sparsomme segmenter, mens fortrolighed bevares gennem differentielle fortrolighedsteknikker |
| Einstein | Funktionsteknik | ✅ Proxyfunktioner erstattes med alternative funktioner, der giver forudsigende styrke uden demografisk korrelation |
| Einstein | Funktionsteknik | ✅ Brancheklassificering eller firmastørrelse bruges i stedet for område, når område fungerer som demografisk proxy |
| Einstein | Funktionsteknik | ✅ Firmografiske attributter bruges i stedet for kontonavnemønstre, når navne er forbundet med demografi |
| Agentforce | Efterbehandling | ✅ Beslutningstærsklerne justeres pr. demografisk segment for at ligestille resultatfrekvenserne efter modeluddannelse, bortset fra at i USA forbyder afsnit VII (Civil Rights Act of 1991) justering af scores eller udskæringer efter beskyttet klasse for beskæftigelsesrelaterede beslutninger, og andre jurisdiktioner pålægger deres egne begrænsninger |
| Agentforce | Efterbehandling | ✅ Forskellige konfidenstærskler bruges til forskellige kontekster, der opnår rimelige godkendelsesfrekvenser, mens de bruger den samme underliggende forudsigelsesmodel |
| Agentforce | Efterbehandling | ✅ Tærskeljusteringer dokumenteres med forretningsjustering for forskellig behandling, idet det anerkendes, at i USA gør ingen dokumentation pr. gruppescore eller afslutningsjustering lovlig for beskæftigelsesrelaterede beslutninger under afsnit VII |
| Einstein | Modeluddannelse | ✅ Kvartalsvis eller begivenhedsstyret gentræningsplan er etableret for at fange nye biasmønstre og rette afvigelser fra oprindelige fairness-basislinjer |
| Einstein | Modeluddannelse | ✅ Fairness-metrikker valideres på ny på hver modelversion før produktionsimplementering, så omuddannelse ikke introducerede ny bias |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Einstein | Uddannelsesdata | ⚡️ Træningsdata bruges direkte uden at genbalancere underrepræsenterede eller overrepræsenterede segmenter |
| Einstein | Uddannelsesdata | ⚡️ Små demografiske segmenter suppleres ikke med syntetiske data eller krydsorganisationsaggregering |
| Einstein | Funktionsteknik | ⚡️ Proxyfunktioner bevares uden at evaluere alternative funktioner, der giver forudsigende styrke uden demografisk korrelation |
| Agentforce | Efterbehandling | ⚡️ Samme konfidenstærskler anvendes på alle demografiske segmenter uden at udligne resultatfrekvenser |
| Agentforce | Efterbehandling | Differentiel behandling gennem tærskeljusteringer mangler dokumenteret forretningsjustering, eller i USA anvendes den overhovedet på beskæftigelsesrelaterede beslutninger, hvor afsnit VII forbyder justering af scores eller udskæringer efter beskyttet klasse, uanset dokumentation |
| Einstein | Modeluddannelse | ⚡️ Modeller implementeres og trænes aldrig igen. Nye biasmønstre og afvigelser bliver ikke rettet |
| Einstein | Modeluddannelse | ⚡️ Gentræning sker uden at validere rimelighedsmetrikker igen. Ny bias introduceres i stilhed |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Einstein Discovery | UX | ✅ Einstein Discovery, der viser forudsigelsesfaktorer, vises i Lightning på beslutningstidspunktet |
| Einstein Discovery | UX | ✅ Forklaringer viser, hvilke variabler der mest påvirkede specifikke forudsigelser med retningsgivende påvirkning for brugere på beslutningspunkter |
| Einstein Discovery | UX | ✅ Forklaringer er lagret for forskellige målgrupper: forretningsbrugere, tekniske brugere, kunder og revisorer |
| Einstein Discovery | UX | ✅ Forretningsbrugere ser “Dette emne scorer højt, fordi den årlige omsætning overstiger $1M, og engagementsscoren er i top 10 %“ |
| Einstein Discovery | UX | ✅ Tekniske brugere ser modelkort med funktionsvægte, træningsdatakarakteristika og valideringsmetrikker |
| Einstein Discovery | UX | ✅ Kunder ser “Denne anbefaling er baseret på dine seneste køb og kunder med lignende præferencer” |
| Einstein Discovery | UX | ✅ Revisorer ser den komplette beslutningsforbindelse fra Einstein Discovery og Model Manager med modelversion, inputværdier og de faktorer, der drev forudsigelsen |
| Einstein Discovery | UX | ✅ Forudsigelseskonfidens vises i brugervenlige termer som kategorier (Høj konfidens, Moderer konfidens, Kræver gennemgang) med forklaringer |
| Einstein Discovery | UX | ✅ Konfidenskategorier forklarer, hvad konfidensniveau betyder for beslutningers pålidelighed, og hvilken yderligere gennemgang der skal forekomme |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Einstein Discovery | UX | ⚡️ Forklaringer eftermonteres på uigennemsigtige systemer efter implementering i stedet for at bygge forklarbarhed i arkitekturen fra starten |
| Einstein Discovery | UX | ⚡️ Forudsigelsesforklaringer kræver navigation for at adskille CRM Analytics-dashboards i stedet for at blive vist på beslutningspunkter |
| Einstein Discovery | UX | ⚡️ Brugere ser abstrakte modelydeevnemetrikker i stedet for gennemsigtige forklaringer, når beslutninger påvirker dem |
| Einstein Discovery | UX | ⚡️ Forklaringer varierer ikke efter målgruppe. Tekniske modelkort vises for kunder eller forretningsbrugere |
| Einstein Discovery | UX | ⚡️ Rå forudsigelsesscores (0,73) vises uden nogen forklaring på, hvad tallet betyder, eller hvilke faktorer der styrer forudsigelsen |
| Einstein Discovery | UX | ⚡️ Konfidens vises som sandsynlighedsprocenter, som brugere forkert fortolker uden kontekst om pålidelighed eller gennemgang |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Einstein | Trust Layer | ✅ Trustlser, svar, landestandardkilder og Trust automatisk uden tilpasset instrumentering |
| Einstein | Trust Layer | ✅ Databevarelsespolitikker er opbygget til at opfylde bestemmelser, der varierer efter branche og jurisdiktion (f.eks. FINRA-regel 4511(b) angiver en standardbevarelsesperiode på seks år, og HIPAA kræver mindst seks år for overensstemmelsesdokumentation) |
| CRM Analytics | Overvågning | ✅ CRM Analytics-dashboards analyserer registrerede forudsigelsesmodelbeslutningsdata for beslutningsmønstre, rimelighedsmetrikker og modelydeevne over tid |
| CRM Analytics | Overvågning | ✅ CRM Analytics-linser viser forudsigelsesdistributioner efter konfidensniveau, demografisk segment og resultattype |
| CRM Analytics | Overvågning | ✅ Einstein Discovery identificerer afvigelser, der kræver undersøgelse |
| Platform | Feltrevisionsspor | ✅ Feltrevisionsspor er aktiveret på tilpassede objekter, der lagrer AI-beslutningsdata, bevarer arkiveret historik uendeligt, indtil den slettes for samtykkeregistreringer, tilsidesætter beslutninger og biasrapporter |
| Platform | Begivenhedsovervågning | ✅ Begivenhedsovervågning registrerer Agentforce, værktøjskald og beslutningspunkter |
| Platform | Begivenhedsovervågning | ✅ Begivenhedsovervågningslogfiler distribueres til eksternt SIEM via platformsbegivenheder for lagring, der sikrer manipulation |
| Platform | Begivenhedsovervågning | ✅ SIEM-forespørgsler registrerer biasmønstre på tværs af store mængder Agentforce |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Einstein | Trust Layer | ⚡️ Agentforce implementeres uden at aktivere Trust Layer-revisionsregistrering eller definere bevarelsespolitikker |
| Einstein | Trust Layer | ⚡️ Bevarelsespolitikker tager ikke højde for branchespecifikke bestemmelser (finansielle tjenester, sundhedspleje) |
| CRM Analytics | Overvågning | Registrerede forudsigelsesmodelbeslutningsdata analyseres ikke. Beslutningsmønstre og rimelighedsmetrikker spores ikke over tid |
| Platform | Feltrevisionsspor | ⚡️ Standardfelthistorik over 18 måneder er baseret på AI-beslutningsrevisionsspor uden at tage hensyn til krav til regulerende bevarelse |
| Platform | Feltrevisionsspor | ⚡️ Feltrevisionsspor er ikke aktiveret på objekter med samtykkeregistreringer, tilsidesættelsesbeslutninger og biasrapporter |
| Platform | Begivenhedsovervågning | ⚡️ Begivenhedsovervågningslogfiler er afhængige af oprindelige bevarelsesgrænser uden ekstern SIEM for manipulationsbevisende langsigtet lagring |
| Platform | Begivenhedsovervågning | Agentforce interaktionslogfiler analyseres ikke for biasmønstre på tværs af store mængder |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Styring | EU AI Act | ✅ AI-systemer med høj risiko dokumenteres med gennemsigtighedsdokumentation, teknisk dokumentation, menneskelig tilsynsfunktioner og nøjagtigheds-/fairhedsmetrikker |
| Styring | EU AI Act | ✅ Einstein Trust Layer-revisionsspor og Discovery-modelkort giver grundlag for EU AI Act-gennemsigtighedskrav |
| Styring | EU AI Act | ✅ Modeltræningsdatademografi, valideringstilgange og kendte begrænsninger dokumenteres i arkitektoniske beslutningsregistreringer |
| Styring | GDPR | ✅ Systemer genererer sammenhængende forklaringer for enhver historisk beslutning om efterspørgsel inden for anmodningstidsrammer for adgang for registreret (som varierer efter jurisdiktion, mellem 15 og 45 dage) |
| Styring | GDPR | ✅ Registrerede forudsigelsesmodelbeslutningsdata og Einstein Discovery forklaringsfaktorer gemmes med tilstrækkelig bevarelse, der muliggør forklaringskonstruktion for GDPR-retten til forklaring |
| Styring | Algoritmisk ansvarlighed | ✅ Algoritmepåvirkningsvurderinger udføres, før der implementeres konsekvent AI som proaktiv overholdelse snarere end reaktive svar |
| Styring | Algoritmisk ansvarlighed | ✅ Registrerede forudsigelsesmodelbeslutningsdata og CRM Analytics-fairnessovervågningsdashboards giver databrundlag for algoritmisk ansvarsrapportering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Styring | EU AI Act | ⚡️ AI-systemer med høj risiko implementeres uden gennemsigtighedsdokumentation, menneskelig tilsynsfunktioner eller rimelighedsmetrikker |
| Styring | EU AI Act | ⚡️ Modeltræningsdatamografier og kendte begrænsninger dokumenteres ikke i arkitektoniske beslutningsregistreringer |
| Styring | GDPR | ⚡️ Systemer kan ikke generere kohærente forklaringer for historiske beslutninger inden for tidsrammer for anmodninger om adgang for GDPR-emner |
| Styring | GDPR | ⚡️ Bevarelse af registrerede forudsigelsesmodelbeslutningsdata er utilstrækkelig til at understøtte forklaringskonstruktion for tidligere beslutninger |
| Styring | Algoritmisk ansvarlighed | ⚡️ Algoritmepåvirkningsvurderinger udføres ikke før den efterfølgende AI-implementering. Overensstemmelse reagerer efter reguleringsundersøgelse |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | OWD | ✅ Private standarder for hele organisationen er etableret for objekter, der indeholder følsomme kundedata med adgang tildelt gennem rollehierarki og delingsregler |
| Platform | OWD | ✅ Private OWD’er med eksplicitte delingstildelinger opretter reviserbare adgangsmønstre, der understøtter ikke-diskrimineringsoverholdelse |
| Platform | Sikkerhed på feltniveau | ✅ Følsomme felter, der indeholder beskyttede egenskaber (etnicitet, religion, handicapstatus), skjules via FLS for brugere uden et legitimt forretningsbehov |
| Platform | Sikkerhed på feltniveau | ✅ Læseadgang til følsomme felter fjernes via FLS for de fleste profiler. Adgang tildeles minimalt gennem tilladelsessæt med dokumenteret begrundelse |
| Platform | Tildeling og distribution | ✅ Tildelingsregler, køer og Omni-Channel-distribution distribuerer arbejde ligeligt på tværs af områder, teams og serviceagenter baseret på målsætningskriterier |
| Platform | Delingsregler | ✅ Automatiske delingsregler er baseret på objektive kriterier (branche, geografi, produktlinje) snarere end subjektiv managerovervejelse |
| Platform | Tilladelsessæt | ✅ Midlertidig adgang til følsomme data tildeles gennem tilladelsessæt med dokumenteret udløb snarere end permanente profilændringer |
| Platform | Tilladelsessæt | ✅ Planlagt forløb tilbagekalder tilladelsessæt automatisk efter definerede perioder, når der er brug for adgang til demografiske data for specifikke projekter |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | OWD | Offentlige OWD’er Læs/Skriv gør begrænsning af adgang senere forstyrrende (tilstrækning af standarden udløser en delingsgenberegning). Reviderbare adgangsmønstre findes ikke |
| Platform | OWD | Konto-OVD er indstillet til Offentlig Læs/Skriv med ubeskyttede demografiske felter synlige for alle brugere, der aktiverer subjektiv bias |
| Platform | Sikkerhed på feltniveau | ⚡️ Følsomme demografiske felter er synlige for alle profiler uden FLS-begrænsninger. Diskriminerende dataanvendelse forhindres ikke |
| Platform | Delingsregler | ⚡️ Manuel deling koncentrerer salgsmuligheder af høj værdi med specifikke brugergrupper uden dokumenteret forretningsjustering |
| Platform | Delingsregler | ⚡️ Delingsregler er baseret på subjektiv managerdiskretion snarere end objektive kriterier, der aktiverer bias |
| Platform | Tilladelsessæt | Profiler redigeres permanent, hvilket påvirker alle brugere i stedet for at tildele midlertidig adgang gennem tilladelsessæt |
| Platform | Tilladelsessæt | Tilladelsessæt, der tildeler følsom dataadgang, udløber ikke automatisk. Adgang forbliver ubestemt efter projektfuldførelse |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Skilt | Begivenhedsovervågning | ✅ Shield-begivenhedsovervågning sporer adgang til felter, der indeholder beskyttede egenskaber eller følsomme attributter |
| Skilt | Begivenhedsovervågning | ✅ Begivenhedsovervågning sporer, hvem der får adgang til demografiske felter, hvornår og i hvilken kontekst der registrerer afvigelser |
| Skilt | Begivenhedsovervågning | ✅ Uregelmæssige adgangsmønstre (pludselige spidser, adgang af uventede brugere) udløser undersøgelse for potentiel misbrug |
| Platform | Rapportering | ✅ Rapporter analyserer, hvordan delingsregler distribuerer registreringer på tværs af brugere, teams og områder, der beregner distributionsstatistikker efter kundedemografi |
| Platform | Rapportering | ✅ Rapporter identificerer koncentrationer, hvor specifikke brugergrupper modtager uforholdsmæssig adgang til værdifulde registreringer uden dokumenteret begrundelse |
| Platform | Revisionsspor for opsætning | ✅ Revisionsspor for opsætning gennemses for ændringer af OWD-indstillinger, delingsregler, FLS-konfigurationer og tilladelsessæt, der registrerer uautoriserede ændringer |
| Platform | Transaktionssikkerhed | ✅ Politikker for transaktionssikkerhed reagerer på begivenhedsovervågning i høj risiko i realtid (afvigende API-aktivitet, mistænkelige logins, store eksporter af følsomme data); FLS og delingsændringer er afhængige af revisionsspor for opsætning og dokumenterede ændringsstyringsgodkendelser |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Skilt | Begivenhedsovervågning | Adgang til følsomme demografiske felter overvåges ikke. Potentiel misbrug bliver ikke registreret |
| Skilt | Begivenhedsovervågning | ⚡️ Uregelmæssige adgangsmønstre (spikes, uventede brugere) spores eller undersøges ikke |
| Platform | Rapportering | Delingsregeldistributioner analyseres ikke. Uforholdsmæssig adgang til værdifulde registreringer forbliver usynlig |
| Platform | Rapportering | ⚡️ Koncentrationer af konti af høj værdi med specifikke brugergrupper mangler dokumenteret forretningsjustering |
| Platform | Revisionsspor for opsætning | ⚡️ Revisionsspor for opsætning gennemses ikke. Uautoriserede ændringer af dataadgangskontroller, der aktiverer følsom dataadgang, registreres ikke |
| Platform | Transaktionssikkerhed | ⚡️ Højrisikobegivenhedsovervågning i realtid (afvigende API-aktivitet, store eksporter af følsomme data) handles ikke på med transaktionssikkerhedspolitikker |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Tilpassede objekter | ✅ Detaljerede samtykker pr. AI-anvendelsessituation er aktiveret gennem tilpasset samtykkeobjektsporingsformål, tildelingsdato/metode, tilbagetrækningsdato og relateret bruger-/kontakt-id |
| Platform | Tilpassede objekter | ✅ Kunder giver samtykke til Einstein, mens de afviser AI-styrede kreditbeslutninger gennem separate samtykkeregistreringer pr. anvendelsessituation |
| Platform | Feltrevisionsspor | ✅ Feltrevisionsspor er aktiveret på samtykkeobjekt for krav til regulativer for langsigtet bevarelse af opfyldelse |
| Data 360 | Samtykke | ✅ Data 360-samtykkeadministration bruges til Einstein-personalisering, overførsel og lagring af samtykkepræferencer via forbindelser, der er tilknyttet fortrolighedsdatamodellen og bruger dem som filterkriterier i segmentering og ved aktivering |
| Data 360 | Samtykke | ✅ Samtykketategorier knyttes til specifikke AI-anvendelsessituationer, der gør det muligt for brugere at framelde sig tilpasning, mens de vedligeholder kerneservice |
| Marketing Cloud | Samtykke | ✅ Marketing Cloud-samtykke integreres med Einstein Messaging Insights og Agentforce marketingagenter med hensyn til abonnementsstatus |
| Marketing Cloud | Samtykke | ✅ Marketing Cloud-samtykkestatus forespørges på, før Agentforce starter automatiseret opsøgende for at forhindre uønsket kontakt med brugere, der frameldte sig |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Tilpassede objekter | ⚡️ AI-samtykke spores i regneark eller er afhængig af login som implicit samtykke uden eksplicitte registreringer |
| Platform | Tilpassede objekter | ⚡️ Blanket AI-samtykke bruges i stedet for detaljeret samtykke pr. anvendelsessituation. Brugere kan ikke framelde sig specifikke AI-funktioner |
| Platform | Feltrevisionsspor | ⚡️ Feltrevisionsspor er ikke aktiveret på samtykkeobjektet. Krav til overholdelse af bestemmelser for langsigtet bevarelse bevares ikke |
| Data 360 | Samtykke | Data 360-samtykke bruges ikke til Einstein-personalisering; samtykketyper knyttes ikke til specifikke anvendelsessituationer |
| Marketing Cloud | Samtykke | Marketing Cloud-samtykke er ikke integreret med Einstein eller Agentforce; abonnementsstatus respekteres ikke i automatiseret opsøgende |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Experience Cloud | Profilindstillinger | ✅ Brugere framelder sig Agentforce gennem tilgængelige præferencekontroller i Experience Cloud-profilindstillinger eller Mine indstillinger med tydelige beskrivelser |
| Platform | Bruger-/kontaktregistreringer | ✅ AI-præferencer lagres i bruger- eller kontaktregistreringer, der aktiverer forespørgsel i forløbs- og Agentforce |
| Agentforce | Omni-Channel | ✅ Brugere, der framelder sig Agentforce, distribueres til menneskelige agenter via Omni-Channel i stedet for at modtage degraderet service |
| Agentforce | Forløb | ✅ Forløb kontrollerer samtykke- og præferencefelter før Agentforce. Hvis brugeren frameldte sig, oprettes og distribueres arbejdsregistreringen til den menneskelige kø |
| Agentforce | Omni-Channel | ✅ Personale i menneskelig kø giver sammenlignelige ventetider til automatiseret service for brugere, der frameldte sig |
| Platform | Bruger-/kontaktregistreringer | ✅ AI-præferencer lagres i bruger- eller kontaktregistreringer, der sikrer ensartethed på tværs af kanaler (web, mobil, telefon, mail) |
| Platform | Forløb | ✅ Præferencer forespørges på ensartet vis i alle interaktionsforløb, hvilket forhindrer brugere i at have brug for at bekræfte præferencer gentaget på hver kanal |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Experience Cloud | Profilindstillinger | ⚡️ Framelding er kun tilgængelig via mail til supportteamet. Tilgængelige præferencekontroller findes ikke |
| Platform | Bruger-/kontaktregistreringer | ⚡️ AI-præferencer gemmes ikke i bruger- eller kontaktregistreringer. Præferencer kan ikke forespørges på i forløbslogik eller Agentforce |
| Agentforce | Omni-Channel | ⚡️ Brugere, der framelder sig, modtager degraderet service som implicit pres for at acceptere AI i stedet for at distribuere til menneskelige agenter |
| Agentforce | Forløb | ⚡️ Forløb kontrollerer ikke samtykke- eller præferencefelter før Agentforce. Frameldingspræferencer ignoreres |
| Platform | Bruger-/kontaktregistreringer | Præferencer er ikke ensartede på tværs af kanaler. Brugere skal bekræfte framelding igen på web, mobil, telefon og mail separat |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Styring | Dokumentation | ✅ Hver produktionsforudsigelsesmodel dokumenteres med træningsdatademografi, rimelighedsmetrikker, tilsigtede anvendelsessituationer, biasreduktionsstrategier og overvågningsmetoder |
| Styring | Dokumentation | ✅ Modeldokumentationen inkluderer fairness-overvågningstilgang, advarselstærskler, krav til menneskelig tilsyn, gennemgangsplan og overvejelser i forbindelse med bestemmelser |
| Platform | Tilpassede objekter | ✅ Modeldokumentation lagres i Salesforce ved brug af tilpasset modelobjekt eller Salesforce-filer, der er vedhæftet til projekter, der aktiverer søgbarhed og versionskontrol |
| Styring | Implementeringsgateways | ✅ Fairness-portaler før implementering kræver uddannelsesdataovervågning, beregning af fairness-metrikker, påvirkningsvurdering, design af menneskelig tilsyn og gennemsigtighedsgennemgang før produktion |
| Styring | Implementeringsgateways | ✅ Træningsdatarepræsentationens mangler analyseres og dokumenteres som obligatorisk implementeringsgate |
| Styring | Implementeringsgateways | ✅ Demografisk ligestilling, lige salgsmulighed og uensartet påvirkning beregnes opfyldelsestærskler som obligatorisk gate |
| Styring | Implementeringsgateways | ✅ Konsekvensvurdering evaluerer potentielle skader på tværs af påvirkede populationer som obligatorisk gate |
| Styring | Implementeringsgateways | ✅ Design af menneskelig tilsyn, herunder eskaleringsmønstre, godkendelsesarbejdsflows og tilsidesættelsesmekanismer, er designet og testet som obligatorisk gate |
| Styring | Implementeringsgateways | ✅ Forklaringsfunktioner valideres for alle beslutningstyper som obligatorisk gate |
| Styring | Implementeringsgateways | ✅ Fairness-portaler behandles med samme rigor som sikkerhedsportaler med autoritet til at blokere implementeringer, der mislykkes. |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Styring | Dokumentation | ⚡️ Einstein implementeres uden at dokumentere træningsdata, rimelighedsmetrikker, biasbegrænsning eller overvågningstilgange |
| Styring | Dokumentation | ⚡️ Modeldokumentationen inkluderer ikke fairness-overvågningstilgang, krav til menneskelig tilsyn eller overvejelser i forbindelse med bestemmelser |
| Platform | Tilpassede objekter | ⚡️ Modeldokumentation lagres i regneark eller wikier uden søgbarhed eller versionskontrol |
| Styring | Implementeringsgateways | ⚡️ Einstein fortsætter til produktion uden fairness-portaler. Implementering er udelukkende baseret på generelle nøjagtighedsmetrikker |
| Styring | Implementeringsgateways | ⚡️ Uddannelsesdatakontrol, beregning af rimelige metrikker eller påvirkningsvurdering ignoreres før produktionsimplementering |
| Styring | Implementeringsgateways | ⚡️ Design af menneskelig tilsyn, gennemsigtighedsgennemgang eller forklaringsvalidering udføres ikke før produktion |
| Styring | Implementeringsgateways | ⚡️ Fairness-portaler er kun rådgivende uden autoritet til at blokere implementeringer. Modeller fortsætter på trods af mislykkede fairness-kriterier |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Styring | Gennemgangspanel | ✅ Gennemgangspanelet inkluderer tekniske eksperter (arkitekter, datavidenskabsfolk), forretningsinteresserede, juridiske rådgivere, datafortrolighedsspecialister og repræsentanter fra påvirkede fællesskaber |
| Styring | Gennemgangspanel | ✅ Diverse perspektiver viser retfærdighedsproblemer homogene grupper mangler under etisk gennemgang |
| Styring | Gennemse udløsere | ✅ Gennemse udløsere er defineret: beslutninger, der påvirker beskæftigelse/kredit/lejlighed/pleje/juridiske rettigheder, systemer, der påvirker >10.000 brugere årligt, nye anvendelsessituationer, risiko for væsentlig skade |
| Styring | Gennemse udløsere | ✅ AI-applikationer, der bruger følsomme personlige data (helbred, økonomi, demografi) kræver etisk gennemgang før implementering |
| Styring | Gennemgangsautoritet | ✅ Etiske gennemgangspaneler har autoritet til at kræve ændringer, pålægge overvågningsbetingelser eller blokere implementeringer, der mislykkes etiske standarder |
| Platform | Tilpassede objekter | ✅ Alle gennemgange dokumenteres i Salesforce-tilpasset objektsporingsapplikationsnavn, gennemgangsdato, rejste bekymringer, reduktionskrav og godkendelsesbetingelser |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Styring | Gennemgangspanel | ⚡️ Gennemgangspanelet mangler mangfoldighed (kun tekniske eksperter). Homogene grupper savner retfærdighedsproblemer, der påvirker forskellige populationer |
| Styring | Gennemgangspanel | Repræsentanter fra påvirkede fællesskaber er ikke inkluderet. Blinde pletter i rimelighedsovervejelser resulterer |
| Styring | Gennemse udløsere | ⚡️ Gennemgangsudløsere er ikke defineret. AI-applikationer med høj risiko fortsætter uden etisk gennemgang før implementering |
| Styring | Gennemgangsautoritet | ⚡️ Etisk gennemgang er kun rådgivning uden håndhævelse. Implementeringer fortsætter på trods af mislykkede etiske standarder (regnskabsteori) |
| Platform | Tilpassede objekter | ⚡️ Gennemgange dokumenteres ikke systematisk. Historiske gennemgangsbeslutninger, bekymringer og begrænsninger spores ikke |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| CRM Analytics | Overvågning | ✅ CRM Analytics-dashboards sporer Einstein og Agentforce fra registrerede beslutningsdata og Trust Layer-revisionsdata på en planlagt kadence |
| CRM Analytics | Overvågning | ✅ Demografisk paritet, lige salgsmulighed, uensartede påvirkningsforhold og servicekvalitetsmetrikker overvåges efter kundesegment |
| CRM Analytics | Overvågning | ✅ CRM Analytics-advarsler konfigureres til at udløse, når rimelige metrikker bryder definerede tærskler, der kræver undersøgelse |
| CRM Analytics | Overvågning | ✅ CRM Analytics-dashboards sporer fairness-signaler: pludselige ændringer i beslutningsdistributioner, spidser i biasrelaterede sager, nedgang i ydeevnen for specifikke populationer |
| CRM Analytics | Overvågning | ✅ Advarsler udløses for Einstein, når godkendelsesfrekvenser for et segment falder mere end 15 % uge for uge, der kræver fairhedsundersøgelse |
| Styring | Planlagte revisioner | ✅ Omfattende rimelighedsrevisioner udføres kvartalsvis for AI med høje satser (kredit, beskæftigelse, sundhedspleje) eller halvårligt for systemer med lavere satser |
| Styring | Planlagte revisioner | ✅ Revisioner undersøger aktuelle rimelighedsmetrikker, gennemser tilsidesættelsesmønstre, analyserer brugerfeedback og biasrapporter og validerer, at styringskontroller forbliver effektive |
| Styring | Hændelsessvar | ✅ Tydelige hændelsessvarprocesser dokumenteres i Salesforce Knowledge til at reagere, når der registreres bias |
| Styring | Hændelsessvar | ✅ Øjeblikkelig vurdering af alvorsgrad ved at forespørge på forudsigelsesmodelbeslutningsdata i CRM Analytics. Alvorlig bias suspenderer automatiseret beslutningstagning afventer undersøgelse |
| Styring | Hændelsessvar | ✅ Midlertidig reducering implementerer øget menneskelig tilsyn via justerede konfidenstærskler, funktionsinaktivering eller fuldstændig agentsuspension |
| Styring | Hændelsessvar | ✅ Rodårsagsanalyse identificerer, hvordan bias blev angivet eller udviklet. Træningsdata, modelversioner og konfigurationsændringer analyseres via feltrevisionsspor |
| Styring | Hændelsessvar | ✅ Permanent rettelse implementerer datakorrektion, modeltræning eller procesændringer med relevant kommunikation til påvirkede brugere |
| Styring | Hændelsessvar | ✅ Forebyggende foranstaltninger dokumenteres i kørselslister, der forhindrer gentagelse af biashændelser |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| CRM Analytics | Overvågning | Fairness-metrikker spores ikke på nogen planlagt kadence fra registrerede beslutningsdata eller Trust Layer-revisionsdata. Biasforskydning bliver ikke registreret, efterhånden som datafordelingerne ændres |
| CRM Analytics | Overvågning | CRM Analytics-advarsler er ikke konfigureret. Fairness-metrikbrud, der kræver undersøgelse, udløses ikke |
| CRM Analytics | Overvågning | ⚡️ Fairness-signaler overvåges ikke. Pludselige ændringer i beslutningsdistributioner registreres ikke |
| Styring | Planlagte revisioner | ⚡️ Omfattende rimelighedsrevisioner udføres ikke efter nogen tidsplan. Styringskontroller afviger og bliver ineffektive |
| Styring | Planlagte revisioner | ⚡️ Tilsidesættelsesmønstre, brugerfeedback og biasrapporter analyseres ikke systematisk under revisioner |
| Styring | Hændelsessvar | ⚡️ Ryd hændelsessvarprocesser dokumenteres ikke. Biasregistrering fører til ad hoc-svar uden systematisk tilgang |
| Styring | Hændelsessvar | ⚡️ Midlertidig begrænsning eller permanent rettelse implementeres ikke systematisk. Bias påvirker stadig brugere |
| Styring | Hændelsessvar | ⚡️ Rodårsagsanalyse udføres ikke. Hvordan bias blev angivet eller udviklet forbliver ukendt |
| Styring | Hændelsessvar | ⚡️ Forebyggende foranstaltninger er ikke dokumenteret. Gentagelse forhindres ikke |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Påkrævede felter | ✅ Hvert påkrævet felt indeholder en dokumenteret forretningsjustering for, hvorfor data er obligatoriske i stedet for valgfri. Felter, som en proces kan fungere uden, gøres valgfri med downstream-håndtering for manglende værdier |
| Platform | Påkrævede felter | ✅ Mail er valgfrit med alternative kommunikationsmetoder (SMS, telefon, postmail), så brugere uden pålidelig internet eller personlig mail ikke udelades fra kontooprettelse |
| Platform | Navn-felter | ✅ Navnearkitektur bruger et enkelt felt med et fuldt navn eller en fleksibel struktur med flere dele, der tager højde for mononymer, patronymiske systemer og flere navne eller familiens navne uden at antage rækkefølge eller overtagelse |
| Platform | Navn-felter | ✅ Navnefelter testes med forskellige internationale navne, der accepterer enkeltordsnavne, lange navne, diakritikker, apostrofer, bindestreger og ikke-latinske scripts (arabisk, kinesisk, cyrillisk, Devanagari) |
| Platform | Adressevalidering | ✅ Validering af tilladte adresser accepterer indtastning i frit format, når struktureret validering mislykkes, og lagrer adresser, når brugere indtaster dem i stedet for at gennemtvinge ugyldige rettelser |
| Platform | Adressevalidering | ✅ Adresseverifikation er indbygget i fuldførelsesprocesser, hvor nøjagtighed betyder noget operationelt snarere end at blokere dataregistrering på forhånd |
| Platform | Kommunikationspræferencer | ✅ Foretrukne kommunikationsmetoder lagres på kontaktregistreringer og respekteres ensartet på tværs af alle udgående systemer og tilbyder omnichannel-alternativer i stedet for antagelser med en enkelt kanal |
| Tilpasset objekt | Demografiske data | ✅ Frivillige demografiske data indsamles gennem en separat undersøgelse med indstillingen “Foretræk ikke at svare”, gemmes i et tilpasset objekt med Privat OWD, begrænset af FLS og bruges kun til aggregerede fairnessanalyser |
| Skilt | Begivenhedsovervågning | ✅ Shield-begivenhedsovervågning logfører adgangsbegivenheder (rapporteksporter, API-objektforespørgsler) på demografiske data for at overvåge adgangsmønstre |
| Platform | Berigelse fra tredjepart | ✅ Tredjeparts berigelsesleverandører revideres for fairness-test, demografisk dækning og nøjagtighed, afledningsmetodologi og kontraktmæssige dataanvendelsesbegrænsninger før implementering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Påkrævede felter | ⚡️ Mail er påkrævet for kontooprettelse uden noget alternativ, og telefon- eller adressevalidering afviser ikke-amerikanske formater, postkasser og landdistrikter, bortset fra brugere, der ikke kan angive dataene |
| Platform | Påkrævede felter | ⚡️ Felter markeres som påkrævede uden at dokumentere, om processen kan fungere uden dataene, hvilket skaber usynlige udfyldninger fra afviste ufuldstændige registreringer |
| Platform | Navn-felter | ⚡️ Navnefelter håndhæver konventionerne Western First/Last og afviser mononymer, diakritiske eller ikke-latinske scripts, hvilket udsætter brugere for systemafvisning baseret på kulturel identitet |
| Platform | Adressevalidering | ⚡️ Adressevalidering kræver amerikansk postformat og genkender ikke internationale adresser, PO-bokse, militære (APO/FPO) eller tribal-land-adresser, hvilket blokerer oprettelse af konto og levering af service |
| Platform | Kommunikationspræferencer | ⚡️ En enkelt kommunikationskanal antages at være universel (kun mail eller kun telefon), bortset fra brugere uden internet, uden telefonadgang, eller som er døve eller har svært ved at høre |
| Tilpasset objekt | Demografiske data | Demografiske data udledes fra navne eller steder uden bruger Knowledge, gemmes i standardkontaktfelter, der er synlige for alle brugere, og bruges til emnescoring eller prognosticering uden offentliggørelse |
| Platform | Berigelse fra tredjepart | ⚡️ Tredjepartsdata tilføjes uden revision af leverandørens fairnesspraksisser eller demografisk dækning, importerer leverandørintroduceret bias i organisationsbeslutninger |
Mønstre
| Hvor skal du se | Hvad der ser godt ud |
|---|---|
| Platform | Tildeling og distribution | ✅ Tildelings- og distributionsregler bruger målsætningskriterier (produktlinjer, servicelaftaler, sprogkrav), og tildelingsdistributioner revideres kvartalsvist, stratificeret efter kundedemografi, for at sikre, at der ikke opstår nogen koncentrationsmønstre |
| Platform | Omni-Channel | ✅ Gennemsnitlig tid til håndtering, løsning af første kontakt og kundetilfredshed overvåges på tværs af distributionsstier for at registrere, om kundesegmenter systematisk modtager mindre erfarne agenter |
| Platform | Forløb | ✅ Forløb, der træffer konsekvente beslutninger, gennemses for kriterier, der er forbundet med beskyttede egenskaber (kontoejerskab, kanalpræference, købshistorik, arbejdstider), og deres beslutningslogik er dokumenteret i arkitektoniske beslutningsregistreringer |
| Platform | Forløb | ✅ Forløb, der påvirker beskæftigelse, kredit eller adgang til service, er underlagt den samme etiske gennemgangsproces som AI-systemer |
| Platform | Valideringsregler | ✅ Valideringsregler testes med forskellige data (internationale adresser, ikke-vestlige navne, alternative telefonformater) og udvides, når de afviser lovlige data. Navnefelter accepterer Unicode og alle scripts |
| Platform | Områdedesign | ✅ Kundedemografier tilknyttes på tværs af foreslåede områdegrænser, før designs afsluttes. Hvor der opstår koncentrationer, evalueres ressourcetildeling for egenkapital, og forretningsjustering dokumenteres og overvåges |
| Platform | Revision | ✅ Automatiseringslogik (forretningsregler, tildelingskriterier, forløbsbeslutninger) dokumenteres i Salesforce Knowledge eller ADR’er, og resultaterne revideres kvartalsvis stratificeret efter demografi – tildelingsdistributioner, forløbsgodkendelsesfrekvenser, valideringsafvisningsfrekvenser og områdetildeling |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Tildeling og distribution | Tildelingsregler prioriterer emner fra bestemte postnumre til “toppræstationer” baseret på historiske succesfrekvenser uden at undersøge, om denne succes afspejler færdighed eller demografisk fordel |
| Platform | Omni-Channel | Distribueringskvalitetsmetrikker overvåges ikke på tværs af kundesegmenter, så forskelle i agentoplevelse eller løsning bliver ikke registreret |
| Platform | Forløb | Forløbsbeslutningskriterier korrelerer med beskyttede egenskaber (ejerskab, kanal, købsmængde, tidszone) og behandles som målsætninger, fordi deterministisk logik føles neutral |
| Platform | Forløb | Forløb med høje satser træffer følsomme beslutninger uden etisk gennemgang, ADR-dokumentation eller håndtering for brugere uden for den typiske kundeprofil |
| Platform | Valideringsregler | Validering af navne er begrænset til A-Z og afviser diakritiske eller ikke-latinske scripts, og adressevalidering kræver US-postformat – legitime data afvises, og brugere afviser anmodninger, der ikke er rapporteret |
| Platform | Områdedesign | Områdegrænser følger geografi, der er forbundet med demografi, med forskellig kompensation eller personale på tværs af områder og ingen analyse af demografisk koncentration |
| Platform | Revision | ⚡️ Automatiseringslogik er ikke-dokumenteret, og resultaterne bliver aldrig revideret, så diskriminerende mønstre i tildeling, godkendelser, validering eller områdetildeling forbliver usynlige |