Equità

Nelle architetture Salesforce, equità significa creare soluzioni che servano equamente gli utenti attraverso interfacce accessibili, rilevamento e mitigazione delle distorsioni, decisioni trasparenti e governance etica. Le previsioni Einstein influenzano i risultati che riguardano clienti e dipendenti, il che significa che gli architetti dovrebbero progettare sistemi che producano risultati equi in tutti i gruppi demografici pur rimanendo accessibili agli utenti con disabilità.

Salesforce offre funzionalità della piattaforma appositamente create per garantire l'equità e si impegna a rispettare le WCAG 2.2 AA. Se utilizzato correttamente, Salesforce Lightning Design System (SLDS) fornisce componenti progettati per supportare questo obiettivo. Vediamo più nel dettaglio ogni componente.

Shield Platform Encryption protegge attributi sensibili come i dati demografici e Monitoraggio evento fornisce gli itinerari di controllo che supportano la gestione trasparente dei dati.
Einstein Trust Layer (ETL) acquisisce un itinerario di controllo sicuro per i prompt e le risposte generative di intelligenza artificiale a fini di monitoraggio e conformità.
Experience Cloud include controlli di accessibilità.
L'itinerario di controllo campi fornisce la conservazione a lungo termine della cronologia delle modifiche dei dati a livello di campo, che supporta la responsabilità algoritmica quando i dati delle decisioni AI sono memorizzati in campi tracciati.

Queste funzionalità consentono di ridurre i costi operativi delle procedure di equità di Salesforce.

In Salesforce, l'equità opera in tre dimensioni per fornire soluzioni. La progettazione inclusiva consente di rendere i componenti Web Lightning (LWC), le pagine Visualforce e i siti Experience Cloud completamente accessibili, grazie alla navigazione da tastiera senza interruzioni, alla compatibilità con gli screen reader e alla progettazione cognitiva. Le procedure di equità dell'intelligenza artificiale aiutano le previsioni Einstein a produrre risultati equi utilizzando il rilevamento della distorsione, dati di addestramento diversi e un monitoraggio continuo. La governance fornisce i processi e i controlli necessari per garantire l'equità man mano che i modelli si evolvono e i casi d'uso si espandono.

Trascurare l'equità crea un rischio aggiuntivo. I siti Experience Cloud inaccessibili possono esporre le organizzazioni a contenziosi in materia di ADA (Americans with Disabilities Act) e, per le agenzie federali e i loro appaltatori, alle violazioni della conformità della Sezione 508. A seconda della classificazione del rischio del sistema e delle leggi emergenti in materia di responsabilità algoritmica, le previsioni Einstein distorte possono violare i requisiti della legge EU AI. Solo le decisioni basate sull'intelligenza artificiale automatizzate con effetti legali o simili significativi che non contengono informazioni significative sulla logica decisionale possono violare i diritti di informazione dell'articolo 22 e dell'articolo 15, paragrafo 1, lettera h).

Le organizzazioni che progettano per correttezza tendono a ridurre i danni prevedibili per i clienti, i dipendenti e le comunità interessate dai loro sistemi. Gli errori di equità possono causare danni materiali tangibili alle persone colpite, inclusi danni economici, opportunità negate, disagio emotivo e rafforzamento della discriminazione sistemica. L'allineamento normativo tende a derivare dal servire bene le persone colpite.

Utilizzare questi principi per guidare le decisioni relative all'architettura per garantire l'equità sulla piattaforma.

Progettazione per modelli di accessibilità Lightning. Durante la creazione, utilizzare Lightning Design System e i componenti Web Lightning standard progettati per supportare l'accessibilità WCAG 2.2 AA ogni volta che sia possibile. Quando si crea con SLDS, si sfrutta una libreria in cui l'accessibilità è un principio di progettazione fondamentale. I componenti SLDS sono controllati per l'accessibilità della tastiera e la compatibilità con la tecnologia per l'accesso facilitato e molti includono una sezione sull'accessibilità con suggerimenti per gli sviluppatori. Se è necessario un componente personalizzato, l'implementazione esplicita delle applicazioni WAI-ARIA (Accessible Rich Internet Applications), l'HTML semantico e gli schemi di navigazione da tastiera devono essere convalidati tramite test di tecnologia per l'accesso facilitato.
Ridurre e monitorare la distorsione con gli strumenti appropriati per ogni tipo di modello. Convalidare gli output AI per risultati equi in tutti i gruppi demografici prima della distribuzione e in modo continuativo nella produzione. Per i modelli predittivi, acquisire i dati delle decisioni tramite Einstein Discovery e la strumentazione personalizzata e analizzarli in CRM Analytics per misurare le metriche di equità; per le funzioni di intelligenza artificiale generativa e Agentforce, utilizzare l'itinerario di controllo Einstein Trust Layer (ETL) di prompt e risposte. Documentare le decisioni per soddisfare i requisiti di trasparenza normativa.
Sfruttare Shield Platform Encryption per i controlli sulla protezione dei dati. Utilizzare Shield Platform Encryption con schemi deterministici per attributi sensibili che richiedono query di corrispondenza esatta proteggendo al contempo i dati personali. Instradare i registri di Monitoraggio evento a un sistema SIEM (Security Information and Event Management) esterno per supportare gli itinerari di controllo senza manomissioni, quando il SIEM applica la separazione di archiviazione e accesso write-once che superano le finestre di conservazione native di Salesforce per i regolamenti richiesti.
Progettare flussi di lavoro di revisione per le previsioni con rischi elevati. Configurare i processi di approvazione e i meccanismi di revisione nel flusso Salesforce per assicurarsi che le previsioni Einstein che influiscono sulle decisioni consequenziali ricevano un esame umano appropriato. Utilizzare le soglie di confidenza e le regole aziendali per determinare quando le previsioni richiedono la convalida prima di intraprendere azioni.
Applicare le impostazioni predefinite a livello di organizzazione (OWD) e la protezione a livello di campo (FLS) per la non discriminazione. Progettare schemi di accesso ai dati utilizzando OWD e FLS per limitare l'accesso per impostazione predefinita e concedere solo l'accesso aggiuntivo necessario a ogni ruolo utilizzando le regole di condivisione. Evitare di concedere ai profili un accesso eccessivo che potrebbe esporre attributi sensibili e consentire processi decisionali discriminatori.
Abilitare l'agenzia utente tramite il consenso della piattaforma. Utilizzare le funzionalità di gestione del consenso di Data 360 o degli oggetti consenso personalizzati con Itinerario di controllo campi per tenere traccia del consenso AI granulare per ogni caso d'uso. Consentire agli utenti di disattivare le funzioni basate sull'intelligenza artificiale e fornire alternative umane (quando possibile).

Le decisioni sull'architettura dei dati determinano le popolazioni che diventano visibili e invisibili nei sistemi Salesforce. La scarsa qualità dei dati non è solo un problema tecnico. Diventa una questione di equità quando i gap nei dati svantaggiano sistematicamente gruppi demografici specifici.

Verificare la disponibilità dei dati nei campi obbligatori. Quando i campi obbligatori presumono una disponibilità delle informazioni che varia a seconda dei dati demografici, la completezza dei dati diventa discriminatoria. Gli utenti che non possono fornire le informazioni richieste diventano invisibili nei sistemi che rifiutano i record incompleti.
- L'obbligo di indirizzi email esclude le popolazioni che non dispongono di un accesso a Internet affidabile o di indirizzi email personali.
- L'obbligo dei numeri di previdenza sociale degli Stati Uniti (SSN) esclude i clienti internazionali e gli immigrati recenti a cui non è ancora stato rilasciato un SSN.
- L'obbligo degli indirizzi stradali esclude le popolazioni senza fissa dimora e gli utenti con indirizzi non tradizionali.
Controllare le giustificazioni aziendali per i campi obbligatori. Per ogni campo obbligatorio, è importante documentare il motivo per cui le informazioni sono obbligatorie anziché facoltative. Se i processi possono funzionare senza determinati dati tramite approcci alternativi, rendere tali campi facoltativi e progettare sistemi per gestire i valori mancanti in modo fluido. Ciò consente di garantire che gli utenti che non possono fornire tali dati non vengano esclusi.

I campi nome che seguono le convenzioni di denominazione occidentali (Nome, Cognome) possono escludere le culture con pratiche di denominazione diverse.

Molte culture utilizzano:

Nomi singoli, o mononimi, senza cognomi
Sistemi patronimici in cui il "cognome" cambia in modo generazionale
Più nomi o cognomi
Nomi che cambiano in base agli eventi di vita o al contesto sociale
Nomi in cui "primo" e "ultimo" sono distinzioni culturalmente prive di significato

Progettare l'architettura dei nomi utilizzando un singolo campo completo o una struttura flessibile in più parti che soddisfa le convenzioni di denominazione comuni. Evitare di fare supposizioni sull'ordinamento dei nomi, sugli schemi di eredità o sulle norme culturali.

Testare l'architettura dei nomi utilizzando nomi internazionali diversi per assicurarsi che i campi nome accettino:

Nomi di parole singole (ad esempio, Sukarno, Cher e Teller)
Nomi lunghi che superano i limiti di lunghezza dei campi comuni
Nomi con caratteri diacritici, apostrofi, trattini e spazi
Nomi con caratteri non latini (ad esempio, arabo, cinese, cirillico e devanagari)

Quando la convalida del nome rifiuta il nome legittimo di un utente, l'utente subisce un rifiuto del sistema basato sulla sua identità culturale.

I servizi di convalida degli indirizzi sono spesso ottimizzati per i formati degli Stati Uniti e dell'Europa occidentale e spesso non riconoscono:

Formati degli indirizzi internazionali con ordinamento dei campi diverso
Indirizzi rurali senza nomi di strade
Indirizzi militari (ad esempio, APO e FPO)
Caselle postali e posizioni di consegna alternative
Tribal lands con sistemi di indirizzi univoci
Paesi con script non latini per i componenti indirizzo

Quando le convalide degli indirizzi rifiutano i formati di indirizzo non tradizionali, impediscono la creazione, la spedizione e l'erogazione di servizi per gli utenti i cui indirizzi non corrispondono alle aspettative del database di convalida.

Di seguito sono riportati alcuni modi per progettare convalide degli indirizzi tenendo presente l'accessibilità:

Implementare la convalida degli indirizzi permissiva.
Accetta l'immissione di un indirizzo in formato libero quando le convalide strutturate non riescono.
Memorizza gli indirizzi man mano che vengono immessi dagli utenti anziché costringerli a correzioni non valide.
Utilizzare la convalida degli indirizzi per l'arricchimento dei dati e il rilevamento dei duplicati, non per convalidare la formattazione degli indirizzi.

Anziché bloccare in anticipo le acquisizioni di dati, integrare la verifica dell'indirizzo nei processi di evasione in cui la precisione dell'indirizzo è importante a livello operativo.

I presupposti di accesso universale per canali di comunicazione specifici escludono le popolazioni con accesso o preferenze tecnologiche diverse.

La comunicazione solo email esclude:

Utenti senza accesso a Internet affidabile
Popolazioni anziane che si sentono meno a proprio agio con le email
Utenti in regioni in cui le app SMS o di messaggistica sono il metodo di comunicazione principale

La comunicazione solo telefono esclude:

Utenti sordi e ipoudenti
Utenti senza accesso telefonico o che utilizzano telefoni condivisi

Progettare un'architettura di comunicazione Omnicanale che consenta agli utenti di controllare le preferenze del canale. Memorizzare i metodi di comunicazione preferiti nei record Referente e rispettare costantemente le preferenze in tutti i sistemi di comunicazione in uscita. Offrire una varietà di alternative di comunicazione anziché presumere che i metodi a canale singolo funzionino universalmente.

La raccolta di dati demografici per il monitoraggio dell'equità richiede un'architettura attenta per evitare abusi.

La raccolta e il trattamento dei dati demografici sono dipendenti dalla giurisdizione e soggetti a restrizioni legali (nell'UE, l'articolo 9 del GDPR li considera come dati di categoria speciale che richiedono una base giuridica specifica; negli Stati Uniti, il monitoraggio della distorsione si basa in genere sull'autoidentificazione volontaria dell'EEO). Ove esista una base giuridica, le organizzazioni utilizzano i dati demografici per:

Monitoraggio delle metriche di equità stratificate per gruppi protetti
Rilevamento della distorsione nei sistemi di automazione e intelligenza artificiale
Dimostrare la conformità normativa ai requisiti antidiscriminazione

La raccolta di dati demografici crea alcuni rischi:

I dati possono essere utilizzati per scopi discriminatori se i controlli di accesso non riescono
Gli utenti potrebbero non considerare affidabili i metodi di raccolta e fornire dati imprecisi
La raccolta può risultare invasiva o discriminatoria

Progettare l'autoidentificazione volontaria degli architetti e progettare la raccolta dei dati demografici utilizzando le informazioni seguenti:

Spiegazione chiara con uno scopo trasparente (ad esempio, monitoraggio dell'equità o rapporti sulla conformità)
Facoltativa e include un'opzione "Preferisci non rispondere" sempre disponibile
Separato dai dati operativi con FLS rigorosa per impedire l'accesso inappropriato
Aggregati per rapporti e analisi e non collegati a decisioni individuali
Monitorato tramite Shield Event Monitoring per il controllo degli schemi di accesso

È importante documentare nelle policy sulla privacy esattamente come verranno e non verranno utilizzati i dati demografici. Violare il Trust degli utenti attraverso l'utilizzo di dati non divulgati può danneggiare gravemente la credibilità, che può essere difficile da recuperare.

L'arricchimento dei dati di terze parti che aggiunge dati demografici, firmografici o comportamentali ai record Salesforce può introdurre distorsioni attraverso:

Inferenze imprecise basate su stereotipi
Copertura incompleta con lacune correlate ai dati demografici
Algoritmi proprietari che utilizzano proprietà di equità sconosciute
Dati provenienti da record storici distorti

Prima di implementare i servizi di arricchimento dati, è importante controllare:

Test di equità del fornitore e pratiche di mitigazione della distorsione
Copertura e precisione dei dati in tutti i gruppi demografici
Metodologie di inferenza e funzioni utilizzate per creare previsioni
Limitazioni contrattuali di utilizzo dei dati e policy di conservazione

Tenere presente che una volta che i dati di terze parti entrano nell'organizzazione Salesforce, possono influire sulle decisioni, creando una distorsione introdotta dal fornitore che si riflette anche in una distorsione nell'organizzazione.

Nei contesti Salesforce, l'accessibilità si riferisce all'architettura di componenti Web Lightning, pagine Visualforce e siti Experience Cloud che funzionano per gli utenti con disabilità. I componenti Lightning standard offrono l'accessibilità di base se utilizzati correttamente; tuttavia, lo sviluppo personalizzato e la configurazione di Experience Cloud richiedono un'implementazione esplicita dell'accessibilità.

I componenti Lightning Design System sono progettati per supportare la conformità WCAG 2.2 AA quando vengono utilizzati come progettato. Salesforce si impegna a raggiungere, ma non certifica, la piena conformità. La deviazione dagli schemi SLDS o la creazione di componenti personalizzati senza considerazioni sull'accessibilità creano barriere per gli utenti con disabilità.

I componenti Web Lightning standard offrono l'accessibilità incorporata. Componenti come Lightninginput, Lightningcombobox, Lightningdatatable e Lightning includono automaticamente attributi ARIA appropriati, associazioni di etichette, navigazione da tastiera e gestione dei focus. Ove possibile, utilizzare componenti standard anziché creare alternative personalizzate che abbiano un aspetto simile ma che potrebbero non disporre dell'infrastruttura di accessibilità appropriata.

Utilizzare HTML semantico nei componenti Web Lightning personalizzati. Quando si creano componenti personalizzati, utilizzare elementi HTML semantici (
,
,
,
,
,
) anziché componenti
nidificati. Gli screen reader utilizzano la struttura semantica per comunicare l'organizzazione delle pagine e abilitare la navigazione nei punti salienti. Evitare di utilizzare markup puramente visivo che elimini il significato dalla gerarchia dei contenuti.
Implementare ARIA nei componenti personalizzati. Applicare punti di riferimento, ruoli e proprietà ARIA quando l'HTML semantico non è in grado di trasmettere il comportamento dell'interfaccia. Gli aggiornamenti dinamici del contenuto richiedono regioni in diretta che annunciano modifiche agli screen reader. I componenti interattivi personalizzati richiedono definizioni di ruolo esplicite che corrispondano al loro comportamento. I componenti di base Lightning gestiscono automaticamente ARIA; tuttavia, i componenti personalizzati richiedono la convalida manuale di ARIA tramite il test dello screen reader.
Test con tecnologia di supporto: Convalidare i componenti Lightning utilizzando screen reader effettivi (ad esempio, JAWS e NVDA per Windows, VoiceOver per macOS e iOS e TalkBack per Android). In base allo studio su larga scala di Deque, strumenti automatici come axe-core rilevano circa il 57% dei problemi di accessibilità in termini di volume. I problemi rimanenti richiedono test manuali con tecnologia di supporto da parte di persone che conoscono gli schemi di navigazione dello screen reader.
Utilizzare la gestione dei focus nei flussi Lightning. Quando si aprono le finestre modali, si caricano contenuti dinamici o gli utenti completano flussi in più fasi, è necessario gestire l'attivazione a livello di programmazione per guidare gli utenti della tastiera verso nuovi contenuti. I componenti modali e pop-over Lightning offrono una gestione di base dell'attivazione, ma i flussi complessi richiedono una logica esplicita per spostare l'attivazione in modo appropriato al variare del contenuto.

I siti Experience Cloud servono gli utenti esterni, inclusi clienti, partner e pubblici, che necessitano di una progettazione accessibile che potrebbe dover soddisfare i requisiti ADA, Sezione 508 e/o European Accessibility Act (a seconda della giurisdizione, del pubblico e del tipo di organizzazione).

Utilizzare modelli accessibili. I modelli Experience Cloud creati utilizzando Lightning Web Runtime (LWR) includono l'accessibilità di base. I modelli standard come il Portale account clienti e il Centro assistenza offrono le basi WCAG 2.2 AA quando sono configurati correttamente. I modelli personalizzati richiedono un'implementazione esplicita dell'accessibilità, inclusi markup semantico, navigazione da tastiera e compatibilità con screen reader.
Verificare la conformità delle WCAG nei temi. I temi personalizzati e i siti con immagine aziendale richiedono la convalida del contrasto cromatico. Le impostazioni del tema di Generatore di esperienze controllano i colori, la tipografia e la spaziatura. Assicurarsi che tutto il testo soddisfi il contrasto 4.5:1 per il testo normale (sotto 18 pt per il testo normale o sotto 14 pt per il grassetto) e 3:1 per il testo grande (18 pt o più grande per il testo normale o 14 pt o più grande per il grassetto) e i componenti dell'interfaccia utente. Utilizzare gli strumenti per sviluppatori del browser o i controllori di contrasto online per verificare la conformità. Eseguire il test con lo zoom del browser al 200% per verificare che il testo venga ridimensionato senza perdere contenuti o funzionalità.
Utilizzare la navigazione da tastiera nei menu di navigazione. I componenti di navigazione Experience Cloud devono supportare il funzionamento solo da tastiera senza dipendenza del mouse. Gli utenti devono spostarsi all'interno e all'esterno dei menu a discesa, dei menu mega e della navigazione flyout utilizzando i tasti Tab, Invio, Esc e Freccia senza trappole. Testare tutti i percorsi di navigazione utilizzando solo la tastiera per convalidare l'accessibilità.
Abilitare l'accessibilità dei moduli in Experience Cloud. Associare le etichette in modo esplicito a tutti gli input del modulo utilizzando elementi di etichetta appropriati o aria-labeledby. Da solo, il testo segnaposto non soddisfa i requisiti di accessibilità perché il testo scompare non appena inizia l'immissione dei dati, lasciando gli utenti screen reader senza contesto sufficiente e persistente. I componenti di input Lightning offrono un'associazione di etichette integrata quando sono configurati utilizzando gli attributi di etichetta richiesti. I moduli Visualforce personalizzati richiedono un'associazione esplicita etichetta-input.
Testare i siti Experience Cloud utilizzando la tecnologia di supporto. Prima di avviare siti Experience Cloud rivolti al pubblico, è necessario eseguire test di accessibilità completi utilizzando screen reader, navigazione solo tastiera e zoom del browser. È importante includere gli utenti con disabilità nei test di fruibilità per individuare le barriere pratiche che le recensioni degli esperti possono spesso ignorare. Testare solo le pagine Lightning interne senza convalidare l'accessibilità di Experience Cloud esterni rende i siti rivolti al pubblico vulnerabili a reclami e controversie sull'accessibilità.
Utilizzare testo alternativo per immagini e icone. Tutte le immagini informative, le icone e i contenuti grafici in Experience Cloud richiedono testo alternativo. Le immagini decorative utilizzano testo alternativo vuoto (alt=""), che consente agli screen reader di ignorarle. Le immagini informative forniscono un testo alternativo significativo che descrive il contenuto e la funzione. Quando si scrive testo alternativo per le icone, concentrarsi sull'azione o lo scopo dell'icona anziché sul suo aspetto visivo (ad esempio, anziché descrivere un'icona a forma di lente di ingrandimento come "lente di ingrandimento", il testo alternativo dovrebbe indicare la sua utilità funzionale, ad esempio "Cerca sito"). Durante la gestione delle immagini, il CMS deve richiedere agli autori del contenuto di immettere testo alternativo o contrassegnare esplicitamente l'immagine come decorativa (che imposta alt=""). Ciò garantisce l'accessibilità evitando la mancanza di testo alternativo e descrizioni forzate per le immagini estetiche.

L'accessibilità completa della tastiera significa che gli utenti possono accedere a tutte le funzionalità utilizzando la tastiera senza richiedere l'interazione del mouse o del tocco in qualsiasi momento.

Utilizzare l'ordine logico di attivazione nelle pagine Lightning. Assicurarsi che l'ordine di attivazione segua il layout visivo e il flusso di interazione. Quando gli utenti premono il tasto Tab, l'attivazione visiva deve spostarsi tra gli elementi interattivi nell'ordine previsto in base alla progettazione visiva. Il Generatore di app Lightning e il Generatore di esperienze stabiliscono l'ordine di attivazione in base al posizionamento dei componenti. I componenti personalizzati richiedono una gestione esplicita dell'indice schede per garantire una progressione logica del focus.
Utilizzare indicatori di messa a fuoco visibili per soddisfare i requisiti di contrasto. Lightning Design System fornisce stili di messa a fuoco per soddisfare i requisiti WCAG per la maggior parte dei componenti. I componenti personalizzati possono richiedere indicatori di messa a fuoco ottimizzati per soddisfare il requisito di contrasto 3:1 rispetto ai contenuti circostanti. Gli indicatori di messa a fuoco devono essere chiaramente visibili per consentire agli utenti ipovedenti di navigare da tastiera. Non rimuovere mai gli indicatori di messa a fuoco con CSS (contorno: nessuno) senza fornire uno stile alternativo di messa a fuoco visibile.
Utilizzare le misure di attenuazione delle trappole da tastiera nelle modali e nelle sovrapposizioni. I dialoghi modali dovrebbero intrappolare l'attivazione all'interno della finestra modale mentre è aperta, impedendo agli utenti della tastiera di raggiungere contenuti in background oscurati. La trappola del focus deve essere rilasciata alla chiusura modale e restituire il focus all'elemento trigger. Il contenuto incorporato, inclusi iframe e widget di terze parti, non deve acquisire in modo permanente l'attivazione della tastiera senza un meccanismo di escape.
Utilizzare i tasti di scelta rapida senza conflitti. Lightning fornisce scelte rapide da tastiera standard documentate nella Guida di Salesforce. Le scelte rapide da tastiera personalizzate devono essere progettate in modo da evitare conflitti con i comandi standard del browser e i comandi di navigazione dello screen reader. In linea con i criteri di successo delle WCAG, le scelte rapide a carattere singolo (ad esempio, la pressione di una sola lettera o di un segno di punteggiatura) non devono attivare azioni globali. Devono limitare l'attivazione al momento in cui un componente specifico è attivo oppure fornire agli utenti un modo per disattivare o rimappare completamente la scelta rapida.

Incorporare la convalida dell'accessibilità nelle pipeline CI/CD per trovare automaticamente i problemi strutturali in ogni distribuzione anziché considerare l'accessibilità come controlli manuali periodici.

Utilizzare sa11y per i test di accessibilità dei componenti Web Lightning. Le librerie sa11y di Salesforce (il pacchetto @sa11y/jest) inseriscono il motore di accessibilità axe-core per aggiungere una corrispondenza toBeAccessible() per i test di unità Jest. Scrivere automaticamente test di accessibilità che convalidano l'utilizzo corretto di ARIA, le associazioni di etichette, i rapporti di contrasto e il markup semantico nell'ambito dei test di unità. Configurare le build in modo che abbiano esito negativo quando vengono rilevati problemi critici di accessibilità.
Utilizzare Lighthouse CI per Experience Cloud. Google Lighthouse controlla l'accessibilità delle pagine Web, inclusi i siti Experience Cloud. Integrare Lighthouse CI nelle opportunità di distribuzione per cercare problemi di accessibilità nelle pagine rivolte al pubblico. Configurare le soglie dei punteggi per richiedere punteggi minimi di accessibilità prima delle approvazioni della distribuzione.
Utilizzare l'agente dell'accessibilità, disponibile tramite il pacchetto MCP Salesforce DX. In ambienti compatibili con MCP o all'interno di Agentforce Vibes, esamina il codice in base agli standard WCAG, evidenzia correzioni mirate e può generare una richiesta di estrazione per un tecnico da rivedere, convalidare e unire.

La distorsione esisteva nell'automazione deterministica di Salesforce molto prima dell'introduzione dell'intelligenza artificiale. Le regole di assegnazione, le decisioni sui flussi, le regole di convalida e la progettazione dei territori codificano il giudizio umano che può perpetuare la discriminazione. A differenza della distorsione dell'intelligenza artificiale, che gli architetti esaminano ampiamente, la distorsione dell'automazione spesso passa attraverso l'inesame perché la logica deterministica si sente obiettiva.

Seguire le regole di assegnazione di lead e casi. Distribuire il lavoro tra i team di vendita e assistenza. Quando la logica di assegnazione utilizza criteri correlati alle caratteristiche protette, l'automazione crea disparità sistematiche nella qualità del servizio e nell'accesso alle opportunità.
Le regole di assegnazione che utilizzano caratteristiche di territorio, codice postale o account possono instradare opportunità di valore elevato in modo sproporzionato a team specifici mentre instradano altrove il lavoro di valore inferiore. Se i confini dei territori sono correlati ai dati demografici dei clienti e alle strutture retributive che differiscono da un territorio all'altro, l'automazione delle assegnazioni crea una discriminazione economica.
Controllare regolarmente gli esiti delle regole di assegnazione. Calcolare le distribuzioni delle assegnazioni nei territori e nei team stratificati in base ai dati demografici dei clienti. Se gli account Enterprise sono concentrati in territori specifici mentre gli account PMI sono distribuiti altrove e se i territori Enterprise ricevono risorse o retribuzioni migliori, le regole di assegnazione possono produrre esiti non equi che richiedono un controllo dell'equità.
Rivedere l'instradamento Omnicanale basato sulle competenze. Ciò può influire sulla qualità del servizio in tutte le popolazioni di clienti. Se la logica di instradamento presuppone implicitamente che determinate competenze siano correlate al valore del cliente o alla complessità del problema, i clienti possono ricevere risultati di servizio diversi in base ai proxy demografici.

È importante monitorare il tempo medio di gestione, le risoluzioni al primo contatto e la soddisfazione dei clienti nei vari percorsi di instradamento. Le disparità possono indicare se alcuni segmenti di clienti ricevono sistematicamente agenti meno esperti o meno opzioni di instradamento.

Rivedere le automazioni dei flussi Salesforce. Prendere decisioni di approvazione, determinare l'idoneità o concedere l'accesso può codificare una logica discriminatoria attraverso regole aziendali apparentemente innocue. Alcuni flussi creano una discriminazione indiretta quando i criteri sono correlati a caratteristiche protette.
Rivedere le decisioni relative ai flussi con equità. Per ogni flusso che prende decisioni consequenziali che riguardano gli utenti, è importante chiedere:
Che cosa accade agli utenti che non rientrano nel profilo cliente tipico?
I criteri decisionali sono correlati alle caratteristiche demografiche?
Le eccezioni e i casi limite vengono gestiti in modo equo o svantaggiano sistematicamente gruppi specifici?

È importante documentare la logica decisionale dei flussi e le considerazioni sull'equità nei record decisione dell'architettura e sottoporre i flussi con stake elevati alle stesse policy di riesame etico dei sistemi AI.

Rivedere le regole di convalida. Impedendo l'immissione dei dati si potrebbero escludere i dati validi degli utenti le cui informazioni non corrispondono ai presupposti di sistema. Le regole di convalida che rifiutano i dati legittimi creano popolazioni invisibili. Gli utenti i cui dati non rientrano negli schemi di convalida non possono interagire con determinati sistemi. Gli errori di convalida spesso non vengono segnalati perché gli utenti abbandonano le richieste anziché segnalare errori tecnici. Di seguito sono riportati alcuni schemi di distorsione di convalida comuni:
Le convalide dei nomi che richiedono caratteri latini possono escludere i nomi con caratteri diacritici e non latini.
Le convalide dei numeri di telefono utilizzano spesso formati USA/Ovest, esclusi i numeri internazionali e i metodi di comunicazione alternativi.
Le convalide degli indirizzi non riconoscono gli indirizzi non standard (ad esempio caselle postali, percorsi rurali, terre tribali e formati internazionali).
Le convalide email che richiedono indirizzi email personali possono creare uno svantaggio per gli utenti che non dispongono dell'accesso email personale.
Testare le regole di convalida utilizzando dati diversi. Includere indirizzi internazionali, nomi non occidentali e formati di telefono alternativi nei test di convalida. Quando la convalida rifiuta i dati legittimi, è necessario espandere la logica di convalida per evitare di escludere gli utenti validi.

Rivedere le strutture dei territori di vendita. Le strategie di segmentazione dei clienti e le strutture dei territori di vendita determinano l'allocazione delle risorse nelle popolazioni di clienti. Quando i confini dei territori o i criteri di segmentazione sono correlati a dati demografici che determinano un'allocazione ineguale delle risorse, tale allocazione può produrre esiti discriminatori. I disegni dei territori che utilizzano confini geografici spesso sono correlati a dati demografici razziali, etnici ed economici a causa di schemi di segregazione residenziale. Se le retribuzioni, i livelli di personale o gli investimenti nelle risorse variano da un territorio all'altro, l'area geografica può diventare un meccanismo di allocazione discriminatoria delle risorse.
Analizzare i dati demografici dei territori prima di finalizzare i progetti. Mappare i dati demografici dei clienti oltre i confini dei territori proposti. Quando emergono concentrazioni demografiche, valutare se l'allocazione delle risorse è equa in tutti i territori indipendentemente dalla composizione demografica. Se la giustificazione aziendale richiede livelli di risorse diversi nei vari territori (ad esempio, maturità del mercato, intensità competitiva e potenziale di crescita), documentare esplicitamente la giustificazione e monitorare i risultati per assicurarsi che i territori sottoserviti ricevano opportunità di investimento adeguate per evitare disparità radicate.

Mantenere la trasparenza nella logica di automazione. Documentare le regole aziendali, i criteri di assegnazione e la logica decisionale del flusso nei record decisione di Salesforce Knowledge o dell'architettura. L'automazione trasparente consente di rivedere l'equità in un modo che la logica nascosta impedisce.
Controllare regolarmente i risultati. Pianificare controlli trimestrali per analizzare gli esiti dell'automazione che possono essere stratificati in base ai dati demografici dei clienti. Tenere presente che le disparità attivano indagini e potenziali rimedi.
È importante tenere traccia di:
Distribuzioni delle assegnazioni tra team e territori
Percentuali di approvazione per i flussi che prendono decisioni di idoneità
Percentuali di rifiuto delle regole di convalida per schema di dati
Prestazioni dei territori e allocazione delle risorse
Rivedere l'automazione ad alto rischio attraverso una lente etica. Sottoporre i flussi e le regole di assegnazione che influiscono su occupazione, credito, accesso ai servizi o altri esiti conseguenti allo stesso processo di riesame etico dei sistemi AI. La distorsione dell'automazione richiede lo stesso livello di controllo della distorsione algoritmica.

In Salesforce, l'equità dell'intelligenza artificiale si concentra sull'utilizzo di Einstein per confermare che le previsioni producono risultati equi in tutti i gruppi demografici. Einstein Discovery e la strumentazione personalizzata acquisiscono dati decisionali del modello predittivo che consentono il rilevamento della distorsione. I cruscotti digitali CRM Analytics tengono traccia delle metriche di equità. Itinerario di controllo campi e Monitoraggio evento acquisiscono i dati delle decisioni per la responsabilità algoritmica.

Le previsioni Einstein che influiscono sulle decisioni consequenziali (ad esempio, calcolo del punteggio dei lead, previsione delle opportunità e segmentazione dei clienti) richiedono valutazioni dell'equità pre-distribuzione che funzionano come un passaggio equivalente obbligatorio (simile ai riesami della sicurezza).

Analizzare tutte le funzioni del modello predittivo per la correlazione con le caratteristiche protette utilizzando metodi statistici. Rimuovere o trasformare le funzioni proxy dopo aver valutato se il loro valore predittivo giustifica l'inclusione nonostante gli effetti proxy.

Controllare i dati di Salesforce CRM prima della formazione. Le organizzazioni Salesforce contengono decenni di decisioni umane basate su pratiche storiche. Se i team di vendita precedenti hanno assegnato la priorità a determinati dati demografici, Calcolo dei punteggi lead Einstein impara questi schemi e li perpetua. Prima di addestrare i modelli predittivi sui dati storici, è importante controllare che i dati non contengano lacune nella rappresentazione demografica e incoerenze di misurazione nei segmenti di clienti.
Calcolare le metriche di equità in tutti i gruppi demografici. Prima di distribuire i modelli predittivi, è importante calcolare la parità demografica, le pari opportunità e i rapporti di impatto discriminatori tra i gruppi protetti, in cui si dispone di una base giuridica per raccogliere ed elaborare i dati demografici richiesti. Se Calcolo dei punteggi lead Einstein assegna punteggi elevati al segmento A per il 50% del tempo ma solo per il 30% del tempo al segmento B, un rapporto del 60% non rispetta la regola dei quattro quinti (80%) e richiede un'indagine e un'attenuazione. La percentuale dell'80% è un trigger di screening, non una linea di pass/fail legale: la regola dei quattro quinti è una regola federale degli Stati Uniti per la selezione dell'occupazione e cancellarla non è un porto sicuro: una disparità statisticamente significativa può giustificare un esame a percentuali più alte e altri regimi misurano l'impatto negativo in modo diverso (la legge UE sulla discriminazione indiretta, ad esempio, determina se una pratica crea uno "svantaggio particolare", senza una soglia fissa). Calibrare le soglie delle indagini nelle giurisdizioni e nei casi d'uso in cui si opera.
Acquisire dati decisionali del modello predittivo per il rilevamento della distorsione. Per rilevare la distorsione in modelli predittivi come Calcolo dei punteggi lead e Calcolo dei punteggi opportunità, acquisire i dati delle decisioni tramite Einstein Discovery e la strumentazione personalizzata: memorizzare gli input, gli output e le versioni dei modelli di previsione nei campi tracciati e abilitare Itinerario di controllo campi. Analizzare i dati in CRM Analytics per tenere traccia degli schemi decisionali in tutti i gruppi demografici nel tempo e creare cruscotti digitali che avvisano quando le metriche relative alla parità demografica o alle pari opportunità superano le soglie accettabili.
Rilevamento delle funzioni proxy nei modelli predittivi. Le funzioni correlate alle caratteristiche protette abilitano la discriminazione indiretta anche quando le caratteristiche protette sono escluse dai modelli.
- I dati Salesforce contengono in genere funzioni proxy:
Territorio o CAP (deleghe per razza, etnia e reddito)
Schemi dei nomi account (proxy per le dimensioni dell'organizzazione e i dati demografici del settore)
Tempistica dell'attività di comunicazione (proxy per fusi orari, religione e responsabilità di assistenza)
Tipo di dispositivo o browser dai dati dell'attività (proxy per il livello di reddito)

Quando viene rilevata una distorsione nelle previsioni Einstein, è necessario applicare la mitigazione nella fase della pipeline appropriata (in base alla causa principale e ai vincoli tecnici).

Bilanciare i dati prima dell'addestramento del modello. Riequilibrare i dati di Salesforce CRM mediante sovracampionamento dei segmenti di clienti sottorappresentati o sottocampionamento dei segmenti sovrarappresentati prima di addestrare i modelli predittivi. Utilizzare Data 360 per aggregare i dati in più organizzazioni per garantire serie di formazione diverse. La generazione di dati sintetici può integrare segmenti scarsi preservando la privacy attraverso tecniche di privacy differenziate.
Rimuovere i proxy nella progettazione delle funzioni. Quando vengono identificate le funzioni proxy, sostituirle con funzioni alternative che forniscono potenza predittiva senza correlazione demografica. Se il territorio funge da proxy demografico, considerare la classificazione del settore o le dimensioni dell'azienda come alternative. Se gli schemi dei nomi account sono correlati ai dati demografici, utilizzare invece gli attributi firmografici.
Modificare le soglie durante la post-elaborazione. Modificare le soglie decisionali per segmento demografico per uniformare le percentuali di risultati dopo i modelli di addestramento. Per le decisioni relative all'occupazione ciò è vietato in via definitiva: Il Titolo VII (Civil Rights Act del 1991) impedisce la rettifica dei punteggi o l'utilizzo di punteggi di cutoff diversi per classe protetta e nessuna quantità di giustificazione documentata rende la pratica lecita. Ove non sia vietato, documentare le rettifiche delle soglie con giustificazione aziendale per il trattamento differenziato quando le previsioni influenzano le decisioni automatiche.
Riaddestrare periodicamente i modelli utilizzando dati aggiornati. Pianificare il riaddestramento del modello ogni trimestre (o quando si verificano turni significativi di distribuzione dei dati). La riqualificazione sui dati aggiornati rileva gli schemi di distorsione emergenti e corregge qualsiasi deviazione dai valori di riferimento originali per l'equità. Riconvalidare le metriche di equità su ogni versione del modello prima della distribuzione in produzione per assicurarsi che la riqualificazione non introduca nuove distorsioni.

Einstein Trust Layer acquisisce prompt, risposte e segnali Trust per le funzioni di intelligenza artificiale generativa e Agentforce, supportando la trasparenza e la conformità normativa per l'intelligenza artificiale generativa. Per i modelli predittivi, la trasparenza e la discendenza decisionale provengono da Einstein Discovery e dal Gestore modelli, che richiedono una strumentazione personalizzata per conservare i dati di controllo.

È possibile integrare la spiegabilità nelle soluzioni Einstein dall'architettura iniziale anziché adattare le spiegazioni ai sistemi opachi dopo la distribuzione.

Emergono spiegazioni di Einstein Discovery nei punti decisionali. Einstein Discovery fornisce spiegazioni sui fattori di previsione che mostrano quali variabili hanno influenzato maggiormente previsioni specifiche con impatto direzionale. Componenti Lightning Architect che visualizzano queste spiegazioni agli utenti al momento della decisione anziché richiedere la navigazione per separare i cruscotti digitali CRM Analytics. Quando le decisioni influiscono sugli utenti, è necessaria trasparenza, non metriche astratte delle prestazioni del modello.
Spiegazioni dei livelli per pubblici diversi. Fornire una spiegazione più approfondita e adatta a ogni pubblico:
Utenti aziendali: "Questo lead ha ottenuto un punteggio alto perché il reddito annuale supera 1 milione di dollari e il punteggio di coinvolgimento è tra i primi 10%."
Utenti tecnici: Fornire una scheda modello Einstein Discovery con pesi delle funzioni, caratteristiche dei dati di addestramento e metriche di convalida.
Clienti: "Questo consiglio si basa sugli acquisti recenti e sui clienti con preferenze simili."
Revisori: Fornire una discendenza decisionale da Einstein Discovery e dal Gestore modelli (versione del modello, valori di input e fattori che hanno determinato la previsione) acquisita tramite strumentazione personalizzata.
Comunicare la fiducia in modo appropriato. Visualizzare la confidenza della previsione in termini appropriati per l'utente ed evitare punteggi di probabilità non elaborati che gli utenti potrebbero interpretare in modo errato. Anziché mostrare una "confidenza del 73%", comunicarlo utilizzando le categorie (ad esempio, Alta confidenza, Moderata confidenza e Necessita di riesame) con spiegazioni su ciò che ogni livello di confidenza significa per l'affidabilità delle decisioni e su quali esami aggiuntivi si verificheranno.

Gestire percorsi di controllo completi e immutabili che supportano la responsabilità, il debug e la conformità normativa per tutte le decisioni basate sull'intelligenza artificiale che riguardano gli utenti.

Acquisire i dati di controllo predittivo con gli strumenti appropriati. Archiviare i dati di controllo del modello predittivo (input previsione, output e versioni del modello) nei campi tracciati con Itinerario di controllo campi abilitato. Progettare policy di conservazione dei dati per soddisfare i requisiti normativi, che variano a seconda del settore e della giurisdizione:
- Le regole sui servizi finanziari impostano la conservazione in base al regolamento (ad esempio, la regola FINRA 4511(b) imposta un periodo di conservazione predefinito di sei anni per i record che non hanno altrimenti un periodo di conservazione specificato in base alle regole FINRA o alla regola VAS 17a-4).
- La conservazione delle cartelle cliniche è inoltre disciplinata da norme specifiche (ad esempio, l’HIPAA richiede un minimo di sei anni per la documentazione di conformità; la conservazione delle cartelle cliniche è stabilita dalle singole leggi statali) anziché prevedere mandati di conservazione a tempo indeterminato.
Analizza i dati decisionali del modello predittivo con CRM Analytics. Creare cruscotti digitali CRM Analytics sui dati decisionali del modello predittivo acquisiti (input previsione, output e versioni del modello nei campi tracciati) per analizzare gli schemi decisionali, le metriche di equità e le prestazioni del modello nel tempo. Creare lenti che mostrano le distribuzioni delle previsioni per livello di confidenza, segmento demografico e tipo di risultato. Configurare le storie Einstein Discovery che identificano schemi anomali che richiedono ulteriori indagini.
Utilizzare l'itinerario di controllo campi per la conservazione a lungo termine. La cronologia dei campi standard tiene traccia delle modifiche per 18 mesi nell'interfaccia utente e fino a 24 mesi tramite l'API. L'itinerario di controllo campi consente di conservare la cronologia dei campi indefinitamente per gli oggetti personalizzati che memorizzano i dati decisionali AI. Archivia la cronologia dopo un massimo di 18 mesi per impostazione predefinita, quindi conserva i dati archiviati fino a quando non vengono eliminati. Abilitare Itinerario di controllo campi per gli oggetti che contengono record consenso, ignorano le decisioni e i rapporti di distorsione per soddisfare i requisiti di conservazione previsti dalla normativa.
Utilizzare Monitoraggio evento per le interazioni Agentforce. Monitoraggio evento acquisisce gli eventi a livello di chiamata per Agentforce, ad esempio quando vengono eseguite azioni e flussi. Esportare i dati di Monitoraggio evento in un SIEM esterno (dati standard del file registro eventi tramite l'API) e il sottoinsieme di eventi di Monitoraggio evento in tempo reale tramite Eventi piattaforma) per archiviare dati che superano la finestra di conservazione nativa di Salesforce. Le prove di manomissione dipendono da un particolare comportamento SIEM che impone la memorizzazione in scrittura e la separazione degli accessi. Configurare le query SIEM per rilevare schemi di distorsione in grandi volumi di interazioni Agentforce.
Controllare le conversazioni Agentforce con Einstein Trust Layer. Einstein Trust Layer acquisisce l'itinerario di controllo dei prompt di conversazione e delle risposte Agentforce, archiviati in Data 360, fornendo il record a livello di trascrizione per la trasparenza e la conformità ai regolamenti.

Vediamo più in dettaglio le funzionalità di trasparenza di Architect posizionate per la conformità ai regolamenti AI attuali ed emergenti in più giurisdizioni.

Requisiti di trasparenza della legge AI dell'UE. I sistemi di intelligenza artificiale ad alto rischio ai sensi della legge UE richiedono documentazione sulla trasparenza, documentazione tecnica, capacità di sorveglianza umana e metriche di accuratezza/equità. Gli itinerari di controllo Einstein Trust Layer e le schede dei modelli Einstein Discovery offrono le basi per questi requisiti. Dati demografici dei dati di addestramento del modello di documento, approcci di convalida e limitazioni note nei record decisione dell'architettura.
GDPR diritto alla spiegazione. Il GDPR concede agli interessati dell'UE il diritto a informazioni significative sulla logica di una decisione quando tale decisione si basa esclusivamente sul trattamento automatizzato e produce effetti giuridici o analoghi significativi. Questo diritto deriva dall'articolo 15, paragrafo 1, lettera h), e dall'articolo 22, paragrafo 3, letti con il considerando 71, ed è stato chiarito dalla Corte di giustizia europea nella causa Dun & Bradstreet (2025). Progettare sistemi che generano spiegazioni coerenti su richiesta per qualsiasi decisione storica nell'ambito dei tempi di richiesta di accesso dell'interessato, che variano (a seconda della giurisdizione) tra 15 e 45 giorni. I dati decisionali del modello predittivo acquisiti (input delle previsioni, output, versioni del modello e fattori di spiegazione Einstein Discovery) consentono di ricostruire le spiegazioni quando vengono memorizzate con sufficiente conservazione.
Leggi sulla responsabilità algoritmica. Le leggi statunitensi sulla responsabilità algoritmica a livello statale richiedono sempre più valutazioni dell'impatto e rapporti sulla trasparenza per i sistemi decisionali automatizzati. I dati decisionali del modello predittivo acquisiti e i cruscotti digitali CRM Analytics per il monitoraggio dell'equità costituiscono le basi di dati per questi rapporti. Eseguire valutazioni d'impatto algoritmiche prima di distribuire l'intelligenza artificiale consequenziale come conformità proattiva anziché come risposta reattiva alle richieste normative.

OWD, regole di condivisione e protezione a livello di campo (FLS) definiscono gli schemi di accesso ai dati che determinano quali informazioni gli utenti possono esaminare e utilizzare per prendere decisioni. Una configurazione corretta impedisce l'accesso discriminatorio agli attributi sensibili garantendo al contempo un servizio equo.

Progettare OWD e Protezione livello campo per limitare l'accesso per impostazione predefinita. Per le regole di condivisione, utilizzare il principio dei privilegi minimi (PoLP) per concedere solo l'accesso aggiuntivo di cui ogni ruolo ha legittimamente bisogno, evitando decisioni discriminatorie basate su caratteristiche protette.

Abilitare OWD restrittivo come impostazione predefinita. Utilizzare OWD privati per gli oggetti che contengono dati sensibili dei clienti e concedere l'accesso in base alla gerarchia dei ruoli e alle regole di condivisione. Le OWD Lettura/Scrittura pubblica rendono la limitazione dell'accesso più tardi dirompente – il restringimento delle impostazioni predefinite attiva un ricalcolo della condivisione e ha effetto solo al termine – anziché impossibile. Gli OWD privati con sovvenzioni di condivisione esplicite creano schemi di accesso controllabili che supportano la conformità alla non discriminazione.
Applicare la protezione a livello di campo per gli attributi sensibili. Nascondere i campi sensibili che contengono caratteristiche protette (ad esempio, etnia, religione e stato di disabilità) agli utenti che non necessitano dell'accesso per scopi aziendali legittimi. Configurare FLS per rimuovere l'accesso in lettura per i campi sensibili nella maggior parte dei profili. Quando questi campi sono obbligatori per scopi specifici (ad esempio, segnalazione della diversità e soluzioni ragionevoli), concedere un accesso minimo utilizzando insiemi di autorizzazioni con giustificazione aziendale documentata.
Progettare regole di assegnazione e condivisione per risultati equi. Utilizzare le regole di assegnazione, le aree di attesa e l'instradamento Omnicanale per distribuire equamente il lavoro tra territori, team e agenti dell'assistenza. Evitare la condivisione manuale che concentra opportunità di valore elevato o clienti con gruppi di utenti specifici senza una giustificazione aziendale documentata. Configurare le regole di condivisione automatiche in base a criteri oggettivi (ad esempio, settore, area geografica e linea di prodotti) anziché in base alla discrezionalità soggettiva del responsabile, che può abilitare la distorsione.
Fornire insiemi di autorizzazioni per l'accesso temporaneo. Concedere l'accesso temporaneo ai dati sensibili tramite gli insiemi di autorizzazioni anziché modificare i profili, operazione che interessa tutti gli utenti in modo permanente. Quando gli utenti necessitano dell'accesso ai dati demografici per progetti specifici (ad esempio, analisi della diversità e richieste di alloggio), assegnare insiemi di autorizzazioni con scadenze documentate. I flussi pianificati possono revocare automaticamente gli insiemi di autorizzazioni dopo periodi definiti.

Utilizzare Monitoraggio evento Shield e i rapporti per rilevare schemi di accesso ai dati che indicano una potenziale discriminazione o distorsione nell'utilizzo dei dati.

Utilizzare Monitoraggio evento Shield per controllare l'accesso ai dati sensibili. Utilizzare Monitoraggio evento per acquisire eventi di accesso a livello di oggetto (esportazioni di rapporti, query API e visualizzazioni pagina) su oggetti che contengono caratteristiche protette o attributi sensibili. Configurare le query su questi eventi per mettere in evidenza chi ha eseguito l'accesso all'oggetto, quando e in quale contesto e trattare gli schemi anomali (ad esempio, picchi improvvisi e accesso da parte di utenti imprevisti) come trigger per le indagini.
Rapporto sulle distribuzioni delle regole di condivisione. Creare rapporti che analizzano come vengono distribuiti i record tra utenti, team e territori. Calcolare le statistiche di distribuzione in base ai dati demografici dei clienti per garantire che gli account e le opportunità di valore elevato siano distribuiti equamente. Identificare le concentrazioni in cui gruppi di utenti specifici ricevono un accesso sproporzionato a record importanti senza una giustificazione aziendale documentata.
Controllare le violazioni di CRUD e FLS. Consultare l'itinerario di controllo delle impostazioni per le modifiche alle impostazioni OWD, alle regole di condivisione, alle configurazioni FLS e agli insiemi di autorizzazioni. Modifiche non autorizzate ai controlli di accesso ai dati possono indicare tentativi di accesso inappropriato ai dati sensibili. Utilizzare le policy sulla sicurezza delle transazioni per agire su eventi di Monitoraggio evento in tempo reale ad alto rischio (ad esempio, attività API anomale, accessi sospetti ed esportazioni di dati sensibili da rapporti o visualizzazioni elenco di grandi dimensioni). Poiché la sicurezza delle transazioni funziona solo su questi eventi di runtime anziché sulle modifiche DML o FLS a livello di record, è necessario basarsi sull'itinerario di controllo delle impostazioni e sulle approvazioni documentate della gestione del cambiamento per FLS e le modifiche della condivisione.

In Salesforce, l'agenzia utente significa che clienti e dipendenti mantengono un controllo significativo su come l'intelligenza artificiale influisce sulla loro esperienza. Le funzionalità di gestione del consenso di Salesforce, il consenso di Data 360 e gli oggetti consenso personalizzati consentono un controllo granulare sulle interazioni AI.

Progettare il tracciamento del consenso utilizzando la gestione del consenso di Data 360, il consenso di Marketing Cloud o gli oggetti consenso personalizzati che utilizzano Itinerario di controllo campi per i requisiti di consenso specifici dell'intelligenza artificiale.

Abilitare il consenso granulare per caso d'uso AI. Abilitare il consenso per caso d'uso AI anziché utilizzare un consenso AI generale. I clienti possono acconsentire ai consigli sui prodotti Einstein ma rifiutare le decisioni sul credito basate sull'intelligenza artificiale. Abilitare Itinerario di controllo campi per gli oggetti Consenso per la conservazione a lungo termine e il rispetto dei requisiti normativi. Progettare oggetti Consenso personalizzati con campi che tengono traccia di:
Scopo del consenso (ad esempio Calcolo dei punteggi lead Einstein, Consigli risposte Einstein e Generatore di consigli Einstein)
Data concessione consenso e Metodo di concessione (ad esempio, modulo Web, API, telefono e email)
Data di revoca del consenso (se applicabile)
ID utente o referente correlato
Utilizzare il consenso di Data 360 per la personalizzazione. Utilizzare la gestione del consenso di Data 360 per le funzioni di Personalizzazione Einstein. Data 360 inserisce e memorizza le preferenze di consenso dei sistemi a monte tramite connettori mappati al modello di dati sulla privacy, che consente di utilizzare tali attributi di consenso come criteri di filtro nella segmentazione e all'attivazione. Mappare gli attributi del consenso a casi d'uso specifici di intelligenza artificiale per consentire agli utenti di disattivare la personalizzazione mantenendo al contempo i servizi principali
Abilitare l'integrazione del consenso di Marketing Cloud. Integrare il consenso di Marketing Cloud con Approfondimenti messaggistica Einstein e funzioni di marketing basate sull'intelligenza artificiale. Rispettare lo stato e il consenso dell'abbonamento a Marketing Cloud in tutte le comunicazioni basate sull'intelligenza artificiale.

Offrire un significativo rifiuto esplicito delle funzioni basate sull'intelligenza artificiale con controlli accessibili che rispettano le preferenze degli utenti tramite alternative umane di qualità comparabile.

Concedere l'opzione di rifiuto accessibile nelle impostazioni del profilo. Consentire agli utenti di disattivare le interazioni basate sull'intelligenza artificiale tramite controlli delle preferenze accessibili nelle impostazioni del profilo Experience Cloud o Impostazioni personali nelle app interne. Fornire descrizioni chiare del significato di ogni rifiuto esplicito e dell'esperienza alternativa che gli utenti riceveranno al momento del rifiuto esplicito. Memorizzare le preferenze nei record Utente o Referente.
Offrire opzioni di preferenza persistenti nei vari canali. Memorizzare le preferenze AI nei record Utente o Referente per garantire la coerenza tra i canali (ad esempio, Web, cellulare, telefono ed email). Eseguire query coerenti sulle preferenze in tutti i flussi di interazione per evitare che gli utenti debbano ripetere ripetutamente le preferenze in canali diversi.

La governance etica dell'intelligenza artificiale fornisce strutture organizzative che consentono di garantire che l'equità continui man mano che i modelli si evolvono, i dati cambiano e i casi d'uso si espandono. Senza governance, gli sforzi iniziali di equità peggiorano man mano che l'attenzione dell'organizzazione si sposta.

Stabilire la documentazione obbligatoria e rivedere i checkpoint prima della distribuzione Einstein. Considerare questo come un cancello importante quanto le revisioni della sicurezza.

Fornire la documentazione del modello. Archiviare la documentazione del modello in Salesforce utilizzando un oggetto Modello personalizzato o Salesforce Files allegato a Progetti per consentire la ricerca e il controllo delle versioni. Documentare ogni modello predittivo di produzione utilizzando:
Addestramento dei dati demografici e delle lacune di rappresentazione note (per modelli predittivi addestrati dai clienti come Einstein Discovery e Generatore di previsioni)
Metriche di equità pre-distribuzione calcolate per gruppo demografico
Casi d'uso previsti e usi inappropriati noti
Strategie di mitigazione della distorsione applicate durante lo sviluppo
Approccio al controllo dell'equità e soglie di allarme
Requisiti di supervisione umana e flussi di lavoro di approvazione
Esaminare le pianificazioni e le parti responsabili
Considerazioni normative e posizionamento della conformità
Abilitare i cancelli di equità pre-distribuzione. I modelli che non superano alcun test del cancello non devono passare alla produzione. Trattare i cancelli di equità con lo stesso rigore dei cancelli di sicurezza. In altre parole, hanno l'autorità di bloccare le distribuzioni. Prima di distribuire le previsioni Einstein in produzione, è necessario:
Rivedere i controlli dei dati di addestramento. Tutte le lacune di rappresentazione devono essere analizzate e documentate.
Rivedere le metriche (ad esempio, parità demografica, pari opportunità e impatto discriminatorio devono essere calcolate e confermate per soddisfare le soglie).
Rivedere le valutazioni d'impatto. Valutare i danni potenziali nelle popolazioni colpite.
Progettare con la supervisione umana. Tutti gli schemi di inoltro al livello superiore, i flussi di lavoro di approvazione e i meccanismi di sostituzione devono essere progettati e testati in modo appropriato.
Completare un esame della trasparenza. Le funzionalità di spiegazione devono essere convalidate per tutti i tipi di decisioni.
Documentazione completa. Tutti gli elementi della documentazione del modello richiesti devono essere approvati.

Stabilire processi di riesame per le applicazioni AI con rischi elevati che forniscono una supervisione interfunzionale e hanno autorità di applicazione.

Composizione del consiglio di revisione. Includere esperti tecnici (ad esempio architetti e data scientist), stakeholder aziendali (ad esempio titolari di prodotti e personale operativo), consulenti legali, specialisti della privacy e rappresentanti delle comunità interessate (quando possibile). Ricordare che prospettive diverse evidenziano problemi di equità che spesso mancano ai gruppi omogenei.
Esaminare tutti i trigger che richiedono l'approvazione del comitato etico. Definire i casi d'uso AI che richiedono un riesame etico prima della distribuzione:
Decisioni che influiscono su diritti lavorativi, creditizi, abitativi, sanitari o legali
Sistemi automatici che interessano più di 10.000 utenti o transazioni all'anno
Applicazioni AI che utilizzano dati personali sensibili, inclusi dati sanitari, finanziari o demografici
Nuovi casi d'uso che non hanno un precedente organizzativo stabilito
Sistemi in cui potenziali distorsioni possono causare danni significativi a persone o gruppi
Rivedere e determinare chi è autorizzato a bloccare le distribuzioni. I comitati di revisione etica dovrebbero avere l'autorità di richiedere modifiche, imporre condizioni di monitoraggio o bloccare le distribuzioni che non rispettano gli standard etici. I riesami solo consultivi (senza autorità di controllo) possono limitare l'efficacia del processo di governance. Documentare tutti i riesami negli oggetti personalizzati Salesforce che tengono traccia di: nome della richiesta, data del riesame, dubbi sollevati, requisiti di mitigazione e condizioni di approvazione.

Il monitoraggio dell'equità è un processo continuo che richiede un'attenzione continua per rilevare la fluttuazione dei bias man mano che le distribuzioni dei dati cambiano e le popolazioni di utenti cambiano.

Creare cruscotti digitali di equità CRM Analytics. Creare cruscotti digitali che tengono traccia delle metriche di equità utilizzando i dati decisionali del modello predittivo acquisiti. Monitorare la parità demografica, le pari opportunità, i rapporti disparità-impatto e le metriche qualità-previsione per segmenti di clienti. Configurare gli avvisi CRM Analytics che vengono attivati quando le metriche di equità superano le soglie definite e richiedono un'indagine.
Abilitare il monitoraggio personalizzato per i segnali di equità. Creare un monitoraggio personalizzato dell'equità per rilevare i segnali (ad esempio, cambiamenti improvvisi nelle distribuzioni delle decisioni per gruppo demografico, picchi nei record Caso correlati alla distorsione o peggioramento delle prestazioni del modello per popolazioni specifiche).
Programmare controlli dell'equità. Eseguire controlli di equità completi trimestrali per i sistemi di intelligenza artificiale con rischi elevati (ad esempio, credito, occupazione e assistenza sanitaria) e controlli semestrali per i sistemi con rischi minori (ad esempio, consigli e personalizzazione). I controlli devono esaminare le attuali metriche di equità, rivedere gli schemi di sostituzione nella cronologia approvazioni, analizzare i commenti degli utenti e i rapporti di distorsione e verificare che i controlli di governance rimangano efficaci.
Implementare la risposta agli incidenti in caso di errori di equità. Stabilire processi chiari documentati in Salesforce Knowledge che descrivono in dettaglio come rispondere quando viene rilevata una distorsione:
Immediato: Valutare la gravità e la portata eseguendo query sui dati decisionali del modello predittivo in CRM Analytics. Se l'incidente è grave, sospendere tutte le decisioni automatizzate in attesa di un'indagine.
Breve termine: Implementare strategie di mitigazione temporanee (ad esempio, una maggiore supervisione umana tramite soglie di confidenza rettificate, disabilitazione delle funzioni o sospensione completa dell'agente).
Indagine: Completare un'analisi della causa principale (RCA) per identificare come la distorsione è entrata nel sistema o si è evoluta. Durante l'RCA, analizzare i dati di addestramento, le versioni del modello e le modifiche della configurazione tramite l'itinerario di controllo campi.
Bonifica: Implementare una correzione definitiva tramite correzione dei dati, addestramento del modello o modifiche dei processi.
Comunicazione: Avvisare gli utenti interessati tramite casi, email o annunci Experience Cloud.
Prevenzione: Elaborare le modifiche per evitare che si ripetano e documentare i metodi di prevenzione nei runbook.

Utilizzare questo elenco di controllo durante le revisioni dell'architettura, prima della distribuzione in produzione e periodicamente per una valutazione continua.

Qualità dei dati ed equità rappresentativa

Rendere facoltativi i campi in cui un processo può funzionare senza i dati e progettare processi a valle per gestire i valori mancanti, in modo che gli utenti che non possono fornire informazioni (email, SSN, indirizzo postale) non vengano esclusi.
I campi Architect Name (Nome architetto) sono un singolo campo completo o una struttura flessibile in più parti che accetta mononimi, caratteri non latini, caratteri diacritici e nomi lunghi, anziché assumere il primo/ultimo ordinamento occidentale.
Implementare la convalida degli indirizzi permissiva che accetta formati in formato libero e internazionali, memorizzando gli indirizzi come immessi anziché bloccare la creazione di record in caso di mancata corrispondenza del formato.
Memorizzare le preferenze dei canali di comunicazione nei record Referente e supportare le alternative Omnicanale (email, SMS, telefono, posta, chat, voce) anziché presumere che un singolo canale raggiunga tutti gli utenti.
Raccogliere dati demografici tramite autoidentificazione volontaria con un'opzione "Preferisci non rispondere", archiviati separatamente in OWD privato con FLS, aggregati per la generazione di rapporti e monitorati tramite Monitoraggio evento Shield.
Controllare i fornitori di arricchimento di terze parti per verificare l'equità, la copertura demografica e la metodologia di inferenza prima di aggiungere dati demografici o comportamentali ai record.

Accessibilità e progettazione inclusiva

Utilizzare i componenti Lightning Design System, progettati per supportare l'accessibilità WCAG 2.2 AA. Tenere presente che Salesforce si impegna per la conformità, ma i componenti richiedono comunque un utilizzo corretto.
Convalidare i componenti Web Lightning personalizzati con test screen reader (ad esempio, JAWS, NVDA e VoiceOver).
Assicurarsi che la navigazione completa da tastiera sia presente nelle pagine Lightning e nei siti Experience Cloud senza dipendenza del mouse.
Verificare che i rapporti di contrasto soddisfino 4.5:1 per il testo normale utilizzando gli strumenti di sviluppo del browser o i controlli del contrasto.
Integrare la scansione dell'accessibilità sa11y o Lighthouse nelle pipeline CI/CD in caso di errore in base a problemi critici.
Testare i siti Experience Cloud utilizzando la tecnologia di supporto prima del lancio pubblico.
Verificare il feedback uditivo verificando che tutte le modifiche dinamiche (ad esempio, stati di errore, caricamento di spinner o espansione dei menu) siano chiaramente annunciate e che il contenuto parlato corrisponda all'intento visivo dell'interfaccia utente.

Equità nell'automazione Salesforce

Esaminare le regole di assegnazione e instradamento per verificare la correlazione con le caratteristiche protette che potrebbero concentrare esiti favorevoli o sfavorevoli in gruppi demografici specifici.
Controllare la logica decisionale del flusso e dell'automazione dei processi per la distorsione, documentando le regole e i criteri aziendali nei record decisione di Salesforce Knowledge o dell'architettura.
Valutare le regole di convalida per le percentuali di rifiuto che influiscono in modo sproporzionato su schemi di dati o popolazioni specifici.
Analizzare i progetti di territorio e segmentazione per la correlazione demografica, documentando una giustificazione aziendale esplicita e monitorando i territori sottoserviti per un'allocazione equa delle risorse.
Sottoporre i flussi e le regole di assegnazione (impiego, credito, accesso ai servizi) a un processo di revisione etica analogo a quello dei sistemi di intelligenza artificiale e pianificare controlli trimestrali degli esiti dell'automazione stratificati per dati demografici.

Equità AI e rilevamento della distorsione

Controllare i dati di Salesforce CRM per individuare eventuali lacune nella rappresentazione demografica prima dell'addestramento del modello predittivo.
Calcolare la parità demografica, le pari opportunità e i diversi rapporti di impatto per gruppo demografico prima della distribuzione.
Implementare le valutazioni dell'equità come una porta di distribuzione obbligatoria (considerare questo come equivalente a un esame di sicurezza).
Creare cruscotti digitali CRM Analytics che tengono traccia delle metriche di equità utilizzando i dati decisionali del modello predittivo acquisiti con l'itinerario di controllo campi.
Analizzare le caratteristiche del modello predittivo per la correlazione proxy con le caratteristiche protette (ad esempio, schemi di nome di territorio e account).
Pianificare controlli di equità completi e trimestrali per tutti i sistemi di intelligenza artificiale ad alto rischio.

Trasparenza e verificabilità

Far emergere spiegazioni delle previsioni Einstein Discovery nei punti decisionali nei componenti Lightning.
Configurare le acquisizioni di controllo Einstein Trust Layer utilizzando metodi di conservazione che soddisfano i requisiti normativi.
Abilitare Itinerario di controllo campi su tutti gli oggetti personalizzati che memorizzano i dati delle decisioni AI per la conservazione a lungo termine.
Esportare i dati di Monitoraggio evento in un SIEM esterno (dati del file registro eventi tramite l'API ed eventi di Monitoraggio evento in tempo reale tramite Eventi piattaforma) per archiviare dati che superano la conservazione nativa, con controlli write-once lato SIEM per le prove di manomissione.
Fornire una comunicazione di confidenza appropriata agli utenti (ad esempio, Alta, Moderata e Bassa) anziché le probabilità non elaborate.

Supervisione umana con Salesforce Automation

Configurare le soglie di inoltro al livello superiore basate sulla confidenza in Flusso e instradare le previsioni con bassa confidenza all'esame umano.
Utilizzare i processi di approvazione Salesforce per le decisioni con rischi elevati che richiedono catene di revisione a più fasi.
Integrare l'instradamento Agentforce e Omnicanale per consentire l'inoltro senza problemi agli agenti umani.
Fornire un'opzione "Connetti a un agente umano" permanente nelle interfacce Agentforce per rispettare l'agenzia utente.
Richiedere il tracciamento documentato della cronologia approvazioni e della motivazione per le esclusioni Agentforce acquisite nei campi personalizzati.

Non discriminazione con i controlli di accesso ai dati

Abilitare OWD privato e quindi concedere un accesso aggiuntivo tramite la gerarchia dei ruoli e le regole di condivisione.
Configurare la protezione a livello di campo per nascondere i campi demografici sensibili agli utenti che non richiedono l'accesso.
Monitorare gli eventi di accesso a livello di oggetto (esportazioni di rapporti e query API) per i dati sensibili tramite Shield Event Monitoring e analizzarli per individuare schemi di accesso anomali.
Creare rapporti che analizzano le distribuzioni delle regole di condivisione per garantire un'allocazione equa dei record tra i territori.
Consultare Itinerario di controllo impostazioni per verificare la presenza di modifiche non autorizzate alla configurazione OWD, regola di condivisione o FLS.

Agenzia utente e consenso

Progettare oggetti Consenso personalizzati utilizzando Itinerario di controllo campi per tenere traccia del consenso AI granulare per caso d'uso.
Integrare il consenso di Data 360 o Marketing Cloud con Personalizzazione Einstein e funzioni Agentforce.
Memorizzare le preferenze AI nei record Utente o Referente per garantire la coerenza tra i canali (ad esempio, Web, cellulare e telefono).
Fornire opzioni di rifiuto accessibili nelle impostazioni del profilo e nelle alternative umane tramite l'instradamento Omnicanale.
Eseguire query sui record consenso in Flusso prima che le previsioni Einstein o il coinvolgimento Agentforce abbiano effetto sugli utenti.

Governance etica dell'intelligenza artificiale

Documentare tutti i modelli predittivi di produzione, incluse le metriche di equità e le strategie di mitigazione; per i modelli predittivi addestrati dai clienti (ad esempio Einstein Discovery e Generatore di previsioni), documentare anche i dati demografici dei dati di addestramento.
Stabilire porte di equità obbligatorie pre-distribuzione che blocchino la distribuzione fino a quando non vengono soddisfatti tutti i criteri di equità.
Creare una Commissione di revisione etica dell'intelligenza artificiale come autorità di applicazione per tutte le applicazioni di intelligenza artificiale con rischi elevati.
Creare cruscotti digitali CRM Analytics per monitorare le metriche di equità con cadenza pianificata tramite avvisi CRM Analytics.
Definire le procedure di risposta agli incidenti in caso di errori di equità e documentare il processo in Salesforce Knowledge.
Pianificare controlli trimestrali dell'equità che analizzano gli schemi di sostituzione e i commenti degli utenti per tutti i sistemi con rischi elevati.

Condividere i propri commenti sul framework ben progettato.