AI-etik och styrning - mönster

Lär dig mer om Välarkitektad rättvisa → Etisk AI-styrning

Mönster

Var man ska leta	Hur bra ser ut
Einstein \| Utbildningsdata	✅ Salesforce CRM-data granskas för demografiska representationsluckor och inkonsekvenser i mätningar innan prediktiva modeller utbildas
Einstein \| Utbildningsdata	✅ Historiska konverteringsdata analyseras av kunddemografi för att identifiera underrepresenterade segment som kräver översampling eller ytterligare datainsamling
Einstein \| Distribuering	✅ Rättviseutvärdering behandlas som obligatorisk grind motsvarande säkerhetsgranskning innan prediktiva modeller når produktion
Einstein \| Distribuering	✅ Demografisk paritet, lika möjligheter och olika påverkanförhållanden beräknas över skyddade grupper innan distribuering
Einstein \| Distribuering	✅ Rättvisemått utvärderas mot fyra femtedelsregeln (80 % tröskel) som en screeningutlösare — inte en laglig passning / fellinje — för alla kundsegment innan modelldistribuering
Einstein Discovery \| Instrumentering	✅ Beslutsdata för prediktiva modeller—inmatningar av förutsägelser, utdata och modellversioner—samlas in genom Einstein Discovery och egen instrumentering som möjliggör biasupptäckt
CRM Analytics \| Övervakning	✅ CRM Analytics-instrumentpaneler analyserar insamlade prediktiva modellbeslutsdata för beslutsmönster över demografiska grupper över tid
CRM Analytics \| Övervakning	✅ CRM Analytics-varningar utlöses när demografisk paritet eller lika säljprojektmått glider över acceptabla tröskelvärden
Einstein \| Funktionsteknik	✅ Alla prediktiva modellfunktioner analyseras för korrelation med skyddade egenskaper med hjälp av statistiska metoder
Einstein \| Funktionsteknik	✅ Proxyfunktioner (område, postnummer, kontonamnmönster, aktivitetstidpunkt, enhetstyp) identifieras och utvärderas för demografisk korrelation
Einstein \| Funktionsteknik	✅ Proxyfunktioner tas bort eller transformeras efter utvärdering av om prediktiva värden motiverar inkludering trots proxyeffekter

Antimönster

Var man ska leta	Hur dåligt ser ut
Einstein \| Utbildningsdata	⚠️ Leadbetyg tränas på 10 års historiska data utan att undersöka demografiska representationer eller skillnader i servicekvalitet
Einstein \| Utbildningsdata	⚠️ Historiska konverteringsdata används direkt utan att granska om olika demografier behandlades olika
Einstein \| Distribuering	️ Einstein funktioner distribueras endast baserat på övergripande precisionsmått utan rättviseutvärdering
Einstein \| Distribuering	⚠️ Demografisk paritet eller disparata påverkanförhållanden beräknas inte innan produktionsdistribuering
Einstein \| Trust	⚠️ Agentforce-interaktioner distribueras utan att aktivera Trust Layer-granskningsinsamling för biasupptäckt
CRM Analytics \| Övervakning	️ Beslutsmönster följs inte av demografiska grupper över tid; biasdrift upptäcks inte
Einstein \| Funktionsteknik	⚠️ Skyddade egenskaper tas bort från inlärningsdata om detta automatiskt eliminerar biasering.
Einstein \| Funktionsteknik	⚠️ Mönster för område, postnummer och kontonamn används som funktioner utan proxykorrelationsanalys
Einstein \| Funktionsteknik	⚠️ Proxyfunktioner som fungerar som perfekta demografiska proxys behålls utan att utvärdera alternativ

Mönster

Var man ska leta	Hur bra ser ut
Agentforce \| Analytics	✅ CRM Analytics-instrumentpaneler följer Agentforces beslutsresultat efter kunddemografi med hjälp av granskningsdata från Einstein Trust Layer
Agentforce \| Analytics	✅ Godkännanderesultat, servicesvarstider, omflyttningsresultat och nöjdhetsbetyg bevakas stratifierade efter demografisk grupp
Agentforce \| Analytics	✅ CRM Analytics-varningar konfigureras när rättvisemått bryter mot definierade trösklar som kräver utredning
Agentforce \| Händelseövervakning	✅ händelseövervakningsloggar dirigeras till externa SIEM för långtidslagring som överskrider inbyggda lagringsgränser
Agentforce \| Händelseövervakning	✅ SIEM-frågor identifierar avvikande koncentrationer av negativa resultat för specifika användarpopulationer
Agentforce \| Fältgranskningslogg	✅ Fältgranskningslogg är aktiverad på egna objekt som lagrar Agentforce beslutsdata och behåller arkiverad historik tills den tas bort
Agentforce \| Fältgranskningslogg	✅ Fältgranskningslogg stöder långsiktiga rättviserevisioner och regelutredningar som kräver rekonstruktion av historiska AI-beslut
CRM Analytics \| Övervakning	✅ CRM Analytics-instrumentpaneler följer rättvisesignaler: plötsliga ändringar i beslutsfördelningar, ökningar i biasrelaterade kundcase, prestandaförsämring för specifika populationer
CRM Analytics \| Övervakning	✅ Varningar utlöses när godkännanderesultat för något kundsegment faller mer än 15% vecka-över-vecka som kräver rättviseutredning

Antimönster

Var man ska leta	Hur dåligt ser ut
Agentforce \| Analytics	️ Beslutsresultat följs inte av demografi; biasdrift upptäcks inte när datadistributioner ändras
Agentforce \| Analytics	⚠️ Tjänstekvalitetsmått är inte stratifierade efter demografisk grupp; olika resultat förblir dolda
Agentforce \| Händelseövervakning	⚠️ Loggar för händelseövervakning förlitar sig på inbyggda lagringsgränser utan externt SIEM för granskningar av långsiktig rättvisa
Agentforce \| Händelseövervakning	️ Beslutsmönster analyseras inte över stora volymer interaktioner; avvikande koncentrationer missas
Agentforce \| Fältgranskningslogg	⚠️ Fältgranskningslogg är inte aktiverad; historiska AI-beslut kan inte rekonstrueras för regelutredningar
CRM Analytics \| Övervakning	⚠️ Rättvisa signaler bevakas inte; plötsliga ändringar i beslutsfördelningar går obemärkta förbi

Mönster

Var man ska leta	Hur bra ser ut
Einstein \| Utbildningsdata	✅ Salesforce CRM-data ombalanseras genom översampling av underrepresenterade segment eller undersampling av överrepresenterade segment innan utbildning
Data 360 \| Arkitektur	✅ Data 360 aggregerar data över flera organisationer vilket säkerställer olika utbildningsuppsättningar för prediktiva modeller
Einstein \| Utbildningsdata	✅ Syntetiska dataskapande kompletterar glesa segment samtidigt som sekretess bevaras genom differentierade sekretesstekniker
Einstein \| Funktionsteknik	✅ Proxyfunktioner ersätts med alternativa funktioner som ger prediktiv kraft utan demografisk korrelation
Einstein \| Funktionsteknik	✅ Branschklassificering eller företagsstorlek används istället för område när området fungerar som demografisk proxy
Einstein \| Funktionsteknik	✅ Firmografiska attribut används istället för kontonamnmönster när namn korrelerar med demografi
Agentforce \| Efterbearbetning	✅ Beslutströsklar justeras per demografiskt segment för att utjämna resultatresultat efter modellutbildning, förutom att Title VII (Civil Rights Act från 1991) förbjuder justering av betyg eller brytpunkter efter skyddad klass för anställningsrelaterade beslut i USA och andra jurisdiktioner inför sina egna begränsningar
Agentforce \| Efterbearbetning	✅ Olika förtroendetrösklar används för olika sammanhang för att uppnå rättvisa godkännanderesultat medan du använder samma underliggande prediktiva modell
Agentforce \| Efterbearbetning	✅ Tröskeljusteringar dokumenteras med affärsmotivering för differentierad behandling, med hänsyn till att ingen dokumentation i USA gör poäng per grupp eller cutoff-justeringar lagliga för anställningsrelaterade beslut enligt avdelning VII
Einstein \| Omskolning av modeller	✅ Kvartalsvis eller händelsedriven omskolning schemaläggs för att fånga upp nya biasmönster och korrigera drift från ursprungliga rättvisebaslinjer
Einstein \| Omskolning av modeller	✅ Rättvisemått valideras på varje modellversion innan produktionsdistribuering vilket säkerställer att omskolning inte introducerade ny biasering

Antimönster

Var man ska leta	Hur dåligt ser ut
Einstein \| Utbildningsdata	️ Utbildningsdata används direkt utan att balansera underrepresenterade eller överrepresenterade segment
Einstein \| Utbildningsdata	️ Glesa demografiska segment kompletteras inte med syntetiska data eller korsorganisationsaggregering
Einstein \| Funktionsteknik	⚠️ Proxyfunktioner behålls utan att utvärdera alternativa funktioner som ger prediktiv kraft utan demografisk korrelation
Agentforce \| Efterbearbetning	⚠️ Samma förtroendetrösklar tillämpas för alla demografiska segment utan att utjämna resultatresultaten
Agentforce \| Efterbearbetning	⚠️ Differentiell behandling genom tröskeljusteringar saknar dokumenterad affärsmotivering, eller tillämpas i Förenta staterna över huvud taget på anställningsrelaterade beslut, där avdelning VII förbjuder justering av betyg eller brytpunkter efter skyddad klass oavsett dokumentation
Einstein \| Omskolning av modeller	️ Modeller distribueras och återutbildas aldrig; nya biasmönster och drift går inte att korrigera
Einstein \| Omskolning av modeller	️ Omskolning sker utan att rättvisemått valideras igen; ny biasering införs tyst

Mönster

Var man ska leta	Hur bra ser ut
Einstein Discovery \| UX	✅ Einstein Discovery förklaringar som visar förutsägelsefaktorer visas i Lightning komponenter vid tidpunkten för beslutet
Einstein Discovery \| UX	✅ Förklaringar visar vilka variabler som mest påverkat specifika förutsägelser med riktningspåverkan för användare vid beslutspunkter
Einstein Discovery \| UX	✅ Förklaringar är skiktade för olika målgrupper: affärsanvändare, tekniska användare, kunder och granskare
Einstein Discovery \| UX	✅ Affärsanvändare ser “Denna lead betyg högt eftersom årliga intäkter överstiger $ 1M och engagemang betyg är i topp 10%“
Einstein Discovery \| UX	✅ Tekniska användare ser modellkort med funktionsvikter, inlärningsdataegenskaper och valideringsmått
Einstein Discovery \| UX	✅ Kunder ser “Denna rekommendation baseras på dina senaste inköp och kunder med liknande inställningar”
Einstein Discovery \| UX	✅ Granskare ser fullständig beslutshärkomst från Einstein Discovery och Modellhanteraren med modellversion, indatavärden och de faktorer som drev förutsägelsen
Einstein Discovery \| UX	✅ Förutsägelseförtroende visas i användarlämpliga termer som kategorier (Högt förtroende, Måttligt förtroende, Behöver granskning) med förklaringar
Einstein Discovery \| UX	✅ Förtroendekategorier förklarar vad förtroendenivå innebär för beslutstillförlitlighet och vilken ytterligare granskning som kommer att inträffa

Antimönster

Var man ska leta	Hur dåligt ser ut
Einstein Discovery \| UX	⚠️ Förklaringar monteras i efterhand på ogenomskinliga system efter distribuering istället för att bygga in förklaringar i arkitekturen från början
Einstein Discovery \| UX	⚠️ Förutsägelseförklaringar kräver navigering för att separera CRM Analytics-instrumentpaneler istället för att visas vid beslutspunkter
Einstein Discovery \| UX	⚠️ Användare ser abstrakta modellprestandamått istället för transparenta förklaringar när beslut påverkar dem
Einstein Discovery \| UX	⚠️ Förklaringar varierar inte beroende på målgrupp; kort med tekniska modeller visas för kunder eller företagsanvändare
Einstein Discovery \| UX	⚠️ Råa förutsägelsebetyg (0,73) visas utan förklaring av vad numret betyder eller vilka faktorer som drev förutsägelse
Einstein Discovery \| UX	⚠️ Förtroende visas som sannolikhetsprocent som användare misstolkar utan sammanhang om pålitlighet eller granskning

Mönster

Var man ska leta	Hur bra ser ut
Einstein \| Trust	✅ Einstein Trust Layer loggar uppmaningar, svar, jordningskällor och Trust signaler automatiskt utan egen instrumentering
Einstein \| Trust	✅ Datalagringspolicyer är utformade för att uppfylla lagstadgade krav som varierar beroende på bransch och jurisdiktion (till exempel anger FINRA-regel 4511(b) en standardlagringsperiod på sex år och HIPAA kräver minst sex år för efterlevnadsdokumentation).
CRM Analytics \| Övervakning	✅ CRM Analytics-instrumentpaneler analyserar insamlade beslutsdata för prediktiva modeller för beslutsmönster, rättvisemått och modellprestanda över tid
CRM Analytics \| Övervakning	✅ CRM Analytics-linser visar förutsägelsefördelningar efter förtroendenivå, demografiskt segment och resultattyp
CRM Analytics \| Övervakning	✅ Einstein Discovery berättelser identifierar avvikande mönster som kräver utredning
Plattform \| Fältgranskningslogg	✅ Fältgranskningslogg är aktiverad på egna objekt som lagrar AI-beslutsdata, behåller arkiverad historik tills den tas bort för samtyckesposter, åsidosätta beslut och biasrapporter
Plattform \| Händelseövervakning	✅ Händelseövervakning samlar in Agentforce konversationsavskrifter, verktygsåberopningar och beslutspunkter
Plattform \| Händelseövervakning	✅ Händelseövervakningsloggar dirigeras till externa SIEM via plattformshändelser för manipulationssäker lagring
Plattform \| Händelseövervakning	✅ SIEM-frågor upptäcker biasmönster över stora volymer Agentforce interaktioner

Antimönster

Var man ska leta	Hur dåligt ser ut
Einstein \| Trust	⚠️ Agentforce distribueras utan att aktivera insamling av Trust eller definiera lagringspolicyer
Einstein \| Trust	️ Lagringspolicyer tar inte hänsyn till branschspecifika lagstadgade krav (finansiella tjänster, hälso- och sjukvård).
CRM Analytics \| Övervakning	⚠️ Insamlade beslutsdata för prediktiva modeller analyseras inte; beslutsmönster och rättvisemått följs inte över tid
Plattform \| Fältgranskningslogg	⚠️ Standardfälthistorik på 18 månader används för granskningskedjor för AI-beslut utan att överväga lagstadgade lagringskrav
Plattform \| Fältgranskningslogg	⚠️ Fältgranskningslogg är inte aktiverad för objekt med samtyckesposter, åsidosättningsbeslut och biasering av rapporter
Plattform \| Händelseövervakning	⚠️ Händelseövervakningsloggar förlitar sig på inbyggda lagringsgränser utan externt SIEM för manipulationssäker långtidslagring
Plattform \| Händelseövervakning	⚠️ Agentforce interaktionsloggar analyseras inte för biasmönster över stora volymer

Mönster

Var man ska leta	Hur bra ser ut
Styrning \| EU AI Act	✅ AI-system med hög risk dokumenteras med transparensdokumentation, teknisk dokumentation, mänsklig tillsynskapacitet och precision / rättvisa mått
Styrning \| EU AI Act	✅ Einstein Trust Layer-granskningsloggar och Discovery-modellkort ger grunder för transparenskrav i EU AI Act
Styrning \| EU AI Act	✅ Modellutbildningsdata demografi, valideringsmetoder och kända begränsningar dokumenteras i arkitekturbeslutposter
Styrning \| GDPR	✅ System skapar sammanhängande förklaringar för historiska beslut på begäran inom tidsramar för registrerades åtkomstbegäran (som varierar beroende på jurisdiktion, mellan 15 och 45 dagar)
Styrning \| GDPR	✅ Insamlade beslutsdata för prediktiva modeller och förklaringsfaktorer för Einstein Discovery lagras med tillräcklig lagring för att möjliggöra rekonstruktion av förklaringar för GDPR rätt till förklaring
Styrning \| Algoritmisk ansvarighet	✅ Algoritmiska konsekvensbedömningar utförs innan du distribuerar efterföljande AI som proaktiv efterlevnad istället för reaktivt svar
Styrning \| Algoritmisk ansvarighet	✅ Insamlade prediktiva modellbeslutsdata och CRM Analytics-instrumentpaneler för rättviseövervakning ger datagrunder för algoritmisk rapportering av ansvarighet

Antimönster

Var man ska leta	Hur dåligt ser ut
Styrning \| EU AI Act	⚠️ AI-system med hög risk distribueras utan transparensdokumentation, kapacitet för mänsklig tillsyn eller rättvisemått
Styrning \| EU AI Act	⚠️ Demografi av modellinlärningsdata och kända begränsningar dokumenteras inte i poster för arkitekturbeslut
Styrning \| GDPR	️ System kan inte skapa sammanhängande förklaringar för historiska beslut inom tidsramar för åtkomstbegäran för registrerade i GDPR
Styrning \| GDPR	⚠️ Datalagring av insamlade prediktiva modellbeslut är otillräckligt för att stödja rekonstruktion av förklaringar för tidigare beslut
Styrning \| Algoritmisk ansvarighet	⚠️ Algoritmiska konsekvensbedömningar utförs inte innan efterföljande AI-distribuering; efterlevnaden är reaktiv efter lagstiftningsförfrågan

Mönster

Var man ska leta	Hur bra ser ut
Plattform \| OWD	✅ Privat organisationsomfattande standarder upprättas för objekt som innehåller känsliga kunddata med åtkomst beviljad genom rollhierarki och delningsregler
Plattform \| OWD	✅ Privata OWD med uttryckliga delningsbidrag skapar granskningsbara åtkomstmönster som stöder efterlevnad av icke-diskriminering
Plattform \| Fältnivåsäkerhet	✅ Känsliga fält som innehåller skyddade egenskaper (etnicitet, religion, funktionshinder status) döljs via FLS från användare utan legitima affärsbehov
Plattform \| Fältnivåsäkerhet	✅ Läsåtkomst till känsliga fält tas bort via FLS för de flesta profiler; åtkomst beviljas minimalt genom behörighetsuppsättningar med dokumenterad motivering
Plattform \| Tilldelning och dirigering	✅ Tilldelningsregler, köer och Omni-Channel-dirigering distribuerar arbete jämnt över områden, team och serviceagenter baserat på objektiva kriterier
Plattform \| Delningsregler	✅ Automatiska delningsregler är baserade på objektiva kriterier (bransch, geografi, produktlinje) snarare än subjektiv chefsdisposition
Plattform \| Behörighetsuppsättningar	✅ Tillfällig åtkomst till känsliga data beviljas genom behörighetsuppsättningar med dokumenterad utgång snarare än permanenta profiländringar
Plattform \| Behörighetsuppsättningar	✅ Schemalagt flöde återkallar behörighetsuppsättningar automatiskt efter definierade perioder när åtkomst till demografiska data behövs för specifika projekt

Antimönster

Var man ska leta	Hur dåligt ser ut
Plattform \| OWD	⚠️ Offentliga Läsa/Skriva OWD:er gör begränsning av åtkomst senare störande (att skärpa standarden utlöser en omräkning av delning); granskningsbara åtkomstmönster finns inte
Plattform \| OWD	⚠️ Konto-OWD är inställd till Offentligt Läsa/Skriva med oskyddade demografiska fält synliga för alla användare som aktiverar subjektiv biasering
Plattform \| Fältnivåsäkerhet	️ Känsliga demografiska fält är synliga för alla profiler utan FLS-begränsningar; diskriminerande dataanvändning förhindras inte
Plattform \| Delningsregler	⚠️ Manuell delning koncentrerar säljprojekt med högt värde till specifika användargrupper utan dokumenterad affärsmotivering
Plattform \| Delningsregler	️ Delningsregler förlitar sig på subjektiv chefsbefogenhet snarare än objektiva kriterier som möjliggör biasering
Plattform \| Behörighetsuppsättningar	⚠️ Profiler ändras permanent och påverkar alla användare istället för att bevilja tillfällig åtkomst genom behörighetsuppsättningar
Plattform \| Behörighetsuppsättningar	⚠️ Behörighetsuppsättningar som beviljar åtkomst till känsliga data löper inte ut automatiskt; åtkomst förblir tills vidare efter att projektet har slutförts

Mönster

Var man ska leta	Hur bra ser ut
Sköld \| Händelseövervakning	✅ Shield händelseövervakning spårar åtkomst till fält som innehåller skyddade egenskaper eller känsliga attribut
Sköld \| Händelseövervakning	✅ Event Monitoring-frågor följer vem som får åtkomst till demografiska fält, när och i vilket sammanhang som upptäcker avvikande mönster
Sköld \| Händelseövervakning	✅ avvikande åtkomstmönster (plötsliga spikar, åtkomst av oväntade användare) utlöser utredning för potentiellt missbruk
Plattform \| Rapportering	✅ Rapporter analyserar hur delningsregler distribuerar poster över användare, team och områden och beräknar distributionsstatistik efter kunddemografi
Plattform \| Rapportering	✅ Rapporter identifierar koncentrationer där specifika användargrupper får oproportionerlig åtkomst till värdefulla poster utan dokumenterad motivering
Plattform \| Granskningslogg för inställningar	✅ Inställningar Granskningslogg granskas för ändringar av OWD-inställningar, delningsregler, FLS-konfigurationer och behörighetsuppsättningar som upptäcker oauktoriserade ändringar
Plattform \| Transaktionssäkerhet	✅ Transaktionssäkerhetspolicyer agerar på händelser med hög risk för händelseövervakning i realtid (avvikande API-aktivitet, misstänkta inloggningar, stora exporter av känsliga data); FLS och delningsändringar förlitar sig på granskningslogg och dokumenterade godkännanden av ändringshantering

Antimönster

Var man ska leta	Hur dåligt ser ut
Sköld \| Händelseövervakning	⚠️ Åtkomst till känsliga demografiska fält bevakas inte; potentiell felaktig användning upptäcks inte
Sköld \| Händelseövervakning	⚠️ Avvikande åtkomstmönster (spikar, oväntade användare) spåras eller undersöks inte
Plattform \| Rapportering	️ Delningsregeldistributioner analyseras inte; oproportionerlig åtkomst till värdefulla poster förblir osynlig
Plattform \| Rapportering	️ Koncentrationer av konton med högt värde med specifika användargrupper saknar dokumenterad affärsmotivering
Plattform \| Granskningslogg för inställningar	⚠️ Granskningslogg för inställningar granskas inte; obehöriga ändringar av dataåtkomstkontroller som aktiverar åtkomst till känsliga data upptäcks inte
Plattform \| Transaktionssäkerhet	⚠️ Händelseövervakningshändelser med hög risk i realtid (avvikande API-aktivitet, stora exporter av känsliga data) hanteras inte med transaktionssäkerhetspolicyer

Mönster

Var man ska leta	Hur bra ser ut
Plattform \| Egna objekt	✅ Granulärt samtycke per AI-användningsfall aktiveras genom eget syfte för spårning av samtyckesobjekt, beviljandedatum / metod, uttagsdatum och relaterat användar-/kontakt-ID
Plattform \| Egna objekt	✅ Kunder samtycker till Einsteins produktrekommendationer medan de avböjer AI-drivna kreditbeslut genom separata samtyckesposter per användningsfall
Plattform \| Fältgranskningslogg	✅ Fältgranskningslogg är aktiverad i objektet Samtycke för långsiktig lagring som uppfyller lagstadgade krav
Data 360 \| Samtycke	✅ Samtyckeshantering för Data 360 används för Einstein Personanpassning, tar in och lagrar samtyckesinställningar via anslutare mappade till sekretessdatamodellen och använder dem som filterkriterier i segmentering och vid aktivering
Data 360 \| Samtycke	✅ Samtyckeskategorier mappar till specifika AI-användningsfall så att användare kan välja bort personanpassning med bibehållen huvudtjänst
Marketing Cloud \| Samtycke	✅ Marketing Cloud-samtycke integreras med Einstein Meddelandeinsikter och Agentforces marknadsföringsagenter vad gäller prenumerationsstatus
Marketing Cloud \| Samtycke	✅ Samtyckesstatus för Marketing Cloud frågas innan Agentforce inleder automatiserat uppsökande för att förhindra oönskad kontakt med användare som har avböjt att delta

Antimönster

Var man ska leta	Hur dåligt ser ut
Plattform \| Egna objekt	⚠️ AI-samtycke spåras i kalkylblad eller förlitar sig på inloggning som implicit samtycke utan uttryckliga poster
Plattform \| Egna objekt	⚠️ Samtycke för filt-AI används istället för detaljerat samtycke per användningsfall; användare kan inte avböja specifika AI-funktioner
Plattform \| Fältgranskningslogg	⚠️ Fältgranskningslogg är inte aktiverad för objektet Samtycke; långtidslagring som uppfyller lagstadgade krav upprätthålls inte
Data 360 \| Samtycke	⚠️ Data 360-samtycke används inte för Einstein Personanpassning; samtyckeskategorier mappas inte till specifika användningsfall
Marketing Cloud \| Samtycke	️ Marketing Cloud-samtycke är inte integrerat med Einstein eller Agentforce; prenumerationsstatus respekteras inte i automatiserade uppsökande

Mönster

Var man ska leta	Hur bra ser ut
Experience Cloud \| Profilinställningar	✅ Användare avböjer Agentforce genom åtkomstkontroll i Experience Cloud-profilinställningar eller Mina inställningar med tydliga beskrivningar
Plattform \| Användar-/kontaktposter	✅ AI-preferenser lagras i användar- eller kontaktposter och möjliggör sökfrågor i flöde och Agentforce beslutslogik
Agentforce \| Omni-Channel	✅ Användare som avböjer Agentforce dirigeras till mänskliga agenter via Omni-Channel istället för att få försämrad service
Agentforce \| Flöde	✅ Flödet kontrollerar samtycke och inställningsfält innan Agentforce; om användaren avböjt skapas arbetspost och dirigeras till mänsklig kö
Agentforce \| Omni-Channel	✅ Mänsklig köpersonal ger jämförbara väntetider till automatiserad tjänst för användare som avböjt
Plattform \| Användar-/kontaktposter	✅ AI-preferenser lagras i användar- eller kontaktposter för att säkerställa enhetlighet över kanaler (webb, mobil, telefon, e-post)
Plattform \| Flöde	✅ Preferensen frågas konsekvent i alla interaktionsflöden vilket förhindrar användare från att behöva hävda inställningar upprepade gånger på varje kanal

Antimönster

Var man ska leta	Hur dåligt ser ut
Experience Cloud \| Profilinställningar	⚠️ Att avböja är endast tillgängligt via e-post till supportteam; tillgängliga inställningskontroller finns inte
Plattform \| Användar-/kontaktposter	⚠️ AI-preferenser lagras inte i användar- eller kontaktposter; inställningar kan inte frågas i flödes- eller Agentforce
Agentforce \| Omni-Channel	⚠️ Användare som avböjer får sämre service som underförstått tryck att acceptera AI istället för att dirigera till mänskliga agenter
Agentforce \| Flöde	⚠️ Flödet kontrollerar inte samtyckes- eller inställningsfält innan Agentforce; inställningar för att avböja ignoreras
Plattform \| Användar-/kontaktposter	⚠️ Inställningarna är inte enhetliga i alla kanaler; användare måste åter hävda att de avböjer på webb, mobil, telefon och e-post separat

Mönster

Var man ska leta	Hur bra ser ut
Styrning \| Dokumentation	✅ Varje prediktiv modell för produktion dokumenteras med utbildningsdata demografi, rättvisa mått, avsedda användningsfall, strategier för begränsning av biasering och övervakningsmetoder
Styrning \| Dokumentation	✅ Modelldokumentation inkluderar rättviseövervakningsmetod, varningströsklar, krav på mänsklig tillsyn, granskningsschema och regelöverväganden
Plattform \| Egna objekt	✅ Modelldokumentation lagras i Salesforce med egna modellobjekt eller Salesforce Files bifogade till projekt som möjliggör sökbarhet och versionshantering
Styrning \| Distributionsportar	✅ Rättvisegrindar för fördistribuering kräver granskning av utbildningsdata, beräkning av rättvisemått, konsekvensbedömning, utformning av mänsklig tillsyn och transparensgranskning innan produktion
Styrning \| Distributionsportar	✅ Utbildningsdatarepresentationsluckor analyseras och dokumenteras som obligatorisk distributionsport
Styrning \| Distributionsportar	✅ Demografisk paritet, lika möjligheter och disparat påverkan beräknas uppfylla trösklar som obligatorisk grind
Styrning \| Distributionsportar	✅ Konsekvensbedömning utvärderar potentiella skador över berörda populationer som obligatorisk grind
Styrning \| Distributionsportar	✅ Mänsklig tillsyn design inklusive omflyttningsmönster, godkännandeflöden och åsidosättningsmekanismer är utformade och testade som obligatorisk grind
Styrning \| Distributionsportar	✅ Förklaring kapacitet valideras för alla beslutstyper som obligatorisk grind
Styrning \| Distributionsportar	✅ Rättvisa grindar behandlas med samma stringens som säkerhetsgrindar med behörighet att blockera distribueringar som misslyckas med någon grind

Antimönster

Var man ska leta	Hur dåligt ser ut
Styrning \| Dokumentation	⚠️ Einstein funktioner distribueras utan att dokumentera utbildningsdata, rättvisemått, begränsning av biasering eller övervakningsmetoder
Styrning \| Dokumentation	️ Modelldokumentation inkluderar inte rättviseövervakning, krav på mänsklig tillsyn eller lagstadgade överväganden
Plattform \| Egna objekt	⚠️ Modelldokumentation lagras i kalkylblad eller wikier utan sökbarhet eller versionshantering
Styrning \| Distributionsportar	⚠️ Einstein fortsätter till produktion utan rättvisa grindar; distribuering baseras endast på övergripande precisionsmått
Styrning \| Distributionsportar	⚠️ Utbildningsdatagranskning, beräkning av rättvisemått eller konsekvensbedömning hoppas över innan produktionsdistribuering
Styrning \| Distributionsportar	⚠️ Utformning av mänsklig tillsyn, transparensgranskning eller validering av förklaringar utförs inte innan produktion
Styrning \| Distributionsportar	⚠️ Rättvisegrindarna är endast rådgivande och har inte behörighet att blockera distribueringar; modellerna fortsätter trots att de inte uppfyller rättvisekriterierna

Mönster

Var man ska leta	Hur bra ser ut
Styrning \| Granskningsnämnden	✅ Granskningsnämnden består av tekniska experter (arkitekter, dataforskare), affärsintressenter, juridiska rådgivare, sekretessspecialister och representanter från berörda samhällen
Styrning \| Granskningsnämnden	✅ Olika perspektiv lyfter fram rättviseproblem homogena grupper missar under etisk granskning
Styrning \| Granska utlösare	✅ Granska utlösare definieras: beslut som påverkar anställning/kredit/bostad/hälsovård/juridiska rättigheter, system som påverkar >10 000 användare årligen, nya användningsfall, betydande skaderisk
Styrning \| Granska utlösare	✅ AI-program som använder känsliga personuppgifter (hälsa, ekonomi, demografi) kräver etisk granskning innan distribution
Styrning \| Granska myndighet	✅ Etikprövningsnämnden har befogenhet att kräva ändringar, införa övervakningsvillkor eller blockera distribueringar som inte uppfyller etiska standarder
Plattform \| Egna objekt	✅ Alla granskningar dokumenteras i Salesforces egna objektspårningsprogramnamn, granskningsdatum, problem som tagits upp, begränsningskrav och godkännandevillkor

Antimönster

Var man ska leta	Hur dåligt ser ut
Styrning \| Granskningsnämnden	⚠️ Granskningsnämnden saknar mångfald (endast tekniska experter); homogena grupper missar rättvisefrågor som påverkar olika befolkningsgrupper
Styrning \| Granskningsnämnden	️ Företrädare från berörda samhällen inkluderas inte; blinda fläckar i rättviseöverväganden resulterar
Styrning \| Granska utlösare	⚠️ Granskningsutlösare har inte definierats; AI-program med hög risk fortsätter utan etisk granskning innan distribuering
Styrning \| Granska myndighet	️ Etikgranskning är endast rådgivande utan tillämpning; utplaceringar fortsätter trots att de etiska standarderna inte uppfylls (ansvarsutkrävande)
Plattform \| Egna objekt	⚠️ Granskningar dokumenteras inte systematiskt; historiska granskningsbeslut, problem och begränsningar spåras inte

Mönster

Var man ska leta	Hur bra ser ut
CRM Analytics \| Övervakning	✅ CRM Analytics-instrumentpaneler följer Einstein och Agentforces rättvisemått från insamlade beslutsdata och Trust Layer-granskningsdata på en schemalagd kadens
CRM Analytics \| Övervakning	✅ Demografisk paritet, lika möjligheter, olika påverkanförhållanden och servicekvalitetsmått övervakas av kundsegment
CRM Analytics \| Övervakning	✅ CRM Analytics-varningar konfigureras när rättvisemått bryter mot definierade trösklar som kräver utredning
CRM Analytics \| Övervakning	✅ CRM Analytics-instrumentpaneler följer rättvisesignaler: plötsliga ändringar i beslutsfördelningar, ökningar i biasrelaterade kundcase, prestandaförsämring för specifika populationer
CRM Analytics \| Övervakning	✅ Varningar utlöses för Einstein Säljprojektbetyg när godkännanderesultaten för något segment sjunker med mer än 15 % vecka för vecka, vilket kräver rättviseutredning
Styrning \| Schemalagda granskningar	✅ Omfattande rättviserevisioner utförs kvartalsvis för AI med höga insatser (kredit, anställning, hälso- och sjukvård) eller halvårsvis för system med lägre insatser
Styrning \| Schemalagda granskningar	✅ Revisioner undersöker aktuella rättvisemått, granskar åsidosättningsmönster, analyserar användarfeedback och biaseringsrapporter och validerar styrningskontroller förblir effektiva
Styrning \| Incidentsvar	✅ Tydliga incidentsvarsprocesser dokumenteras i Salesforce Knowledge för att svara när biasering upptäcks
Styrning \| Incidentsvar	✅ Omedelbar allvarlighetsbedömning genom att fråga beslutsdata för prediktiva modeller i CRM Analytics; allvarlig bias avbryter automatiserat beslutsfattande i väntan på utredning
Styrning \| Incidentsvar	✅ Tillfällig begränsning implementerar ökad mänsklig tillsyn via justerade förtroendetrösklar, funktionsinaktivering eller fullständig agentavstängning
Styrning \| Incidentsvar	✅ Grundorsaksanalys identifierar hur biasering angetts eller utvecklats; utbildningsdata, modellversioner och konfigurationsändringar analyseras via Fältgranskningslogg
Styrning \| Incidentsvar	✅ Permanent korrigering implementerar datakorrigering, modellomskolning eller processändringar med lämplig kommunikation till påverkade användare
Styrning \| Incidentsvar	✅ Förebyggande åtgärder dokumenteras i körböcker för att förhindra återkommande biasincidenter

Antimönster

Var man ska leta	Hur dåligt ser ut
CRM Analytics \| Övervakning	⚠️ Rättvisemått spåras inte i någon schemalagd kadens från insamlade beslutsdata eller Trust Layer-granskningsdata; biasdrift upptäcks inte när datadistributioner ändras
CRM Analytics \| Övervakning	⚠️ CRM Analytics-varningar är inte konfigurerade; brott mot rättvisemått som kräver utredning utlöses inte
CRM Analytics \| Övervakning	⚠️ Rättvisesignaler övervakas inte; plötsliga ändringar i beslutsfördelningar upptäcks inte
Styrning \| Schemalagda granskningar	⚠️ Omfattande rättviserevisioner utförs inte enligt något schema; styrningskontroller glider och blir ineffektiva
Styrning \| Schemalagda granskningar	⚠️ Åsidosättningsmönster, användarfeedback och biasrapporter analyseras inte systematiskt under granskningar
Styrning \| Incidentsvar	️ Tydliga incidenthanteringsprocesser dokumenteras inte; biasspårning leder till ad hoc-svar utan systematiskt tillvägagångssätt
Styrning \| Incidentsvar	️ Tillfällig begränsning eller permanent sanering genomförs inte systematiskt.
Styrning \| Incidentsvar	⚠️ Grundorsaksanalys utförs inte; hur biasering har angetts eller utvecklats är fortfarande okänt
Styrning \| Incidentsvar	️ Förebyggande åtgärder dokumenteras inte, återkommande förhindras inte

Mönster

Var man ska leta	Hur bra ser ut
Plattform \| Obligatoriska fält	✅ Varje obligatoriskt fält har en dokumenterad verksamhetsmotivering för varför data är obligatoriska snarare än valfria; fält som en process kan fungera utan är valfria med hantering längre ner för saknade värden
Plattform \| Obligatoriska fält	✅ E-post är valfritt med alternativa kommunikationsmetoder (SMS, telefon, post) så att användare utan tillförlitlig internet eller personlig e-post inte utesluts från kontoskapande
Plattform \| Namnfält	✅ Namnarkitektur använder ett enda fullständigt namnfält eller flexibel flerdelad struktur som rymmer mononymer, patronymikasystem och flera för- eller familjenamn utan att anta ordning eller arv
Plattform \| Namnfält	✅ Namnfält testas med olika internationella namn, accepterar namn med ett ord, långa namn, diakritiska, apostrofer, bindestreck och icke-latinska skrivtecken (arabiska, kinesiska, kyrilliska, Devanagari)
Plattform \| Adressvalidering	✅ Tillåten adressvalidering accepterar friforminmatning när strukturerad validering misslyckas och lagrar adresser medan användare anger dem istället för att tvinga fram ogiltiga korrigeringar
Plattform \| Adressvalidering	✅ Adressverifiering är inbyggd i uppfyllandeprocesser där precision är viktigt operativt snarare än att blockera datainsamling direkt
Plattform \| Kommunikationsinställningar	✅ Föredragna kommunikationsmetoder lagras i kontaktposter och respekteras enhetligt i alla utgående system, vilket erbjuder omnikanalalternativ istället för antaganden i en kanal
Eget objekt \| Demografiska data	✅ Frivilliga demografiska data samlas in genom en separat undersökning med alternativet “Föredra att inte svara”, lagras i ett eget objekt med privat OWD, begränsad av FLS, och används endast för aggregerad rättviseanalys
Sköld \| Händelseövervakning	✅ Shield händelseövervakning loggar åtkomsthändelser (rapportexporter, API-objektfrågor) på demografiska data för att granska åtkomstmönster
Plattform \| Berikning från tredje part	✅ Tredjepartsleverantörer granskas för rättvisetester, demografisk täckning och precision, härledningsmetodik och avtalsenliga dataanvändningsbegränsningar innan implementering

Antimönster

Var man ska leta	Hur dåligt ser ut
Plattform \| Obligatoriska fält	⚠️ E-post krävs för att skapa konton utan alternativ, och validering av telefonnummer eller adress avvisar icke-amerikanska format, postboxar och landsbygdsrutter, exkludera användare som inte kan tillhandahålla data
Plattform \| Obligatoriska fält	⚠️ Fält markeras som obligatoriska utan att dokumentera om processen kan fungera utan data, vilket skapar osynliga populationer från avvisade ofullständiga poster
Plattform \| Namnfält	⚠️ Namnfält tillämpar västerländska för-/efterkonventioner och avvisar mononymer, diakritiska eller icke-latinska skrivtecken, vilket utsätter användare för systemavvisande baserat på kulturell identitet
Plattform \| Adressvalidering	️ Adressvalidering kräver amerikanskt postformat och känner inte igen internationella adresser, postboxar, militära adresser (APO/FPO) eller stamlandsadresser, vilket blockerar kontoskapande och tjänsteleverans
Plattform \| Kommunikationsinställningar	️ En enda kommunikationskanal antas vara universell (endast e-post eller telefon), med undantag för användare utan internet, utan telefonåtkomst eller döva eller hörselskadade.
Eget objekt \| Demografiska data	⚠️ Demografiska data hämtas från namn eller platser utan User Knowledge, lagras i standardkontaktfält som är synliga för alla användare och används i leadbetyg eller prognoser utan att avslöjas
Plattform \| Berikning från tredje part	⚠️ Data från tredje part läggs till utan att granska leverantörers rättvisa praxis eller demografiska täckning, importera leverantörsintroducerad bias till organisationsbeslut

Mönster

Var man ska leta	Hur bra ser ut
Plattform \| Tilldelning och dirigering	✅ Tilldelnings- och dirigeringsregler använder objektiva kriterier (produktlinjer, servicenivåavtal, språkkrav) och tilldelningsfördelningar granskas kvartalsvis, stratifierade efter kunders demografi, för att säkerställa att inga koncentrationsmönster uppstår
Plattform \| Omni-Channel	✅ Genomsnittlig tid att hantera, lösning vid första kontakt och kundnöjdhet övervakas över dirigeringsvägar för att upptäcka om kundsegment systematiskt får mindre erfarna agenter
Plattform \| Flöde	✅ Flöden som fattar följdbeslut granskas för kriterier som korrelerar med skyddade egenskaper (kontots varaktighet, kanalpreferens, inköpshistorik, öppettider) och deras beslutslogik dokumenteras i poster för arkitekturbeslut
Plattform \| Flöde	✅ Flöden med höga insatser som påverkar anställning, kredit eller serviceåtkomst är föremål för samma etiska granskningsprocess som AI-system
Plattform \| Valideringsregler	✅ Valideringsregler testas med olika data (internationella adresser, icke-västerländska namn, alternativa telefonformat) och utökas när de avvisar legitima data; Namnfält accepterar Unicode och alla skript
Plattform \| Områdesdesign	✅ Kunddemografi mappas över föreslagna områdesgränser innan designen slutförs; där koncentrationer uppstår utvärderas resursallokeringen för rättvisa och verksamhetsmotivering dokumenteras och övervakas
Plattform \| Granskning	✅ Automatiseringslogik (verksamhetsregler, tilldelningskriterier, flödesbeslut) dokumenteras i Salesforce Knowledge eller ADR och resultaten granskas kvartalsvis stratifierade efter demografi — tilldelningsfördelningar, flödesgodkännanderesultat, valideringsavvisanderesultat och allokering av områdesresurser

Antimönster

Var man ska leta	Hur dåligt ser ut
Plattform \| Tilldelning och dirigering	⚠️ Tilldelningsregler prioriterar leads från vissa postnummer till “bäst presterande” baserat på historiska vinstresultat utan att undersöka om denna framgång återspeglar kompetens eller demografiska fördelar
Plattform \| Omni-Channel	⚠️ Dirigeringskvalitetsmått bevakas inte över kundsegment, så skillnader i agenters upplevelse eller lösning upptäcks inte
Plattform \| Flöde	⚠️ Kriterier för flödesbeslut korrelerar med skyddade egenskaper (varaktighet, kanal, inköpsvolym, tidszon) och behandlas som objektiva eftersom deterministisk logik känns neutral
Plattform \| Flöde	⚠️ Flöden med höga insatser fattar följdbeslut utan etisk granskning, ADR-dokumentation eller hantering för användare utanför den typiska kundprofilen
Plattform \| Valideringsregler	⚠️ Namnvalidering är begränsad till A-Ö och avvisar diakritiska eller icke-latinska skrivtecken, och adressvalidering kräver amerikanskt postformat — legitima data avvisas och användare överger begäranden som inte rapporteras
Plattform \| Områdesdesign	⚠️ Områdesgränserna följer geografin som korrelerar med demografin, med olika kompensationer eller personal mellan områdena och ingen analys av demografisk koncentration
Plattform \| Granskning	⚠️ Automatiseringslogik är odokumenterad och resultat granskas aldrig, så diskriminerande mönster i tilldelning, godkännanden, validering eller områdestilldelning förblir dolda