Fairness

Em arquiteturas do Salesforce, a imparcialidade significa criar soluções que atendam os usuários de maneira justa por meio de interfaces acessíveis, detecção e mitigação de viés, decisões transparentes e governança ética. As previsões do Einstein influenciam os resultados que afetam os clientes e os funcionários, o que significa que os arquitetos devem projetar sistemas que produzam resultados justos em todos os grupos demográficos, ao mesmo tempo que permanecem acessíveis aos usuários com deficiência.

O Salesforce fornece recursos de plataforma projetados para a justiça e nos esforçamos para estar em conformidade com a WCAG 2.2 AA. Quando usado corretamente, o Salesforce Lightning Design System (SLDS) fornece componentes projetados para suportar essa meta. Vamos analisar em mais detalhes cada componente.

O Shield Platform Encryption protege atributos confidenciais, como dados demográficos, e o Monitoramento de evento fornece as trilhas de auditoria que dão suporte ao tratamento de dados transparentes.
A Camada de Trust do Einstein (ETL) captura uma trilha de auditoria segura para avisos e respostas de IA generativa para fins de monitoramento e conformidade.
O Experience Cloud inclui controles de acessibilidade.
A Trilha de auditoria de campo fornece a retenção de longo prazo do histórico de alteração de dados no nível do campo, que dá suporte à responsabilidade algorítmica quando os dados de decisão de IA são armazenados em campos rastreados.

Esses recursos ajudam a reduzir os custos operacionais das práticas de equidade do Salesforce.

No Salesforce, a imparcialidade opera em três dimensões para fornecer soluções. O design inclusivo ajuda a tornar os Componentes da Web Lightning (LWC), as páginas do Visualforce e os sites do Experience Cloud totalmente acessíveis, com navegação contínua por teclado, compatibilidade com o leitor de tela e acomodações de design cognitivo. As práticas de imparcialidade de IA ajudam as previsões do Einstein a produzir resultados justos usando detecção de viés, dados de treinamento diversos e monitoramento contínuo. A governança fornece os processos e os controles para manter a equidade conforme os modelos evoluem e os casos de uso se expandem.

Negligenciar a imparcialidade cria um risco composto. Os sites do Experience Cloud inacessíveis podem expor as organizações a litígios da Lei Americana de Pessoas com Deficiência (ADA) e, para agências federais e seus prestadores de serviço, violações do cumprimento da seção 508. Dependendo da classificação de risco do sistema e das novas leis de responsabilização algorítmica, as previsões com viés do Einstein podem violar os requisitos da Lei de IA da UE. Apenas decisões automatizadas conduzidas por IA com efeitos legais ou semelhantes significativos que carecem de informações significativas sobre a lógica de decisão podem violar os direitos de informação do artigo 22 do RGPD e do artigo 15(1)(h).

Organizações que se dedicam à justiça tendem a reduzir o prejuízo previsto para os clientes, funcionários e comunidades afetados por seus sistemas. Falhas de imparcialidade podem causar dano material tangível a indivíduos afetados, incluindo prejuízo econômico, oportunidades negadas, sofrimento emocional e reforço da discriminação sistêmica. O alinhamento regulatório tende a seguir a atender bem as pessoas afetadas.

Use esses princípios para orientar suas decisões arquitetônicas quanto à justiça na plataforma.

Design para padrões de acessibilidade do Lightning. Ao criar, use o Lightning Design System e os Componentes da Web Lightning padrão projetados para suportar a acessibilidade WCAG 2.2 AA sempre que possível. Quando você cria com SLDS, está aproveitando uma biblioteca em que a acessibilidade é um princípio essencial do design. Os componentes SLDS são testados quanto à acessibilidade do teclado e compatibilidade com tecnologia assistiva, e muitos incluem uma seção de acessibilidade com dicas do desenvolvedor. Se um componente personalizado for necessário, a implementação explícita de Rich Accessible Internet Applications (WAI-ARIA), HTML semântico e padrões de navegação por teclado devem ser validados por meio de testes de tecnologia assistiva.
Reduza e monitore o viés com as ferramentas certas para cada tipo de modelo. Valide saídas de IA para resultados justos em grupos demográficos antes da implantação e continuamente na produção. Para modelos preditivos, capture dados de decisão por meio do Einstein Discovery e de instrumentos personalizados e analise-os no CRM Analytics para medir métricas de imparcialidade; para recursos de IA generativa e Agentforce, use a trilha de auditoria Einstein Trust Layer (ETL) de avisos e respostas. Documente as decisões para cumprir os requisitos de transparência regulatória.
Leverage Shield Platform Encryption para controles de proteção de dados. Use o Shield Platform Encryption com esquemas determinísticos para atributos confidenciais que exigem consultas de correspondência exata, ao mesmo tempo que protege dados pessoais. Encaminhe os registros do Monitoramento de evento para um sistema externo de Gerenciamento de eventos e Informações de segurança (SIEM) para dar suporte a trilhas de auditoria comprovadas por adulteração, quando o SIEM impõe a segregação de acesso e armazenamento de gravação única que excede as janelas de retenção nativas do Salesforce para os regulamentos necessários.
Projete fluxos de trabalho de revisão para previsões de alta participação. Configure processos de aprovação e mecanismos de revisão no Salesforce Flow para garantir que as previsões do Einstein que afetam decisões consequenciais recebam a revisão humana adequada. Use limites de confiança e regras de negócios para determinar quando as previsões precisam de validação antes de agir.
Aplicar padrões para toda a organização (OWD) e segurança em nível de campo (FLS) para não discriminação. Arquite padrões de acesso a dados usando OWD e FLS para restringir o acesso por padrão e conceda apenas o acesso adicional de que cada papel precisa usando regras de compartilhamento. Evite conceder aos perfis acesso excessivo que possa expor atributos confidenciais e permitir a tomada de decisão discriminatória.
Habilite a agência do usuário por meio do consentimento de plataforma. Use os recursos de gerenciamento de consentimento no Data 360 ou objetos de consentimento personalizados com a Trilha de auditoria de campo para rastrear o consentimento de IA granular por caso de uso. Permita que os usuários recusem recursos conduzidos por IA e forneçam alternativas humanas (quando possível).

As decisões de arquitetura de dados determinam as populações que se tornam visíveis e invisíveis nos sistemas do Salesforce. A baixa qualidade dos dados não é apenas um problema técnico. Ele se torna um problema de imparcialidade quando lacunas de dados sistematicamente desvantagem grupos demográficos específicos.

Revise os campos obrigatórios para a disponibilidade dos dados. Quando os campos obrigatórios presumem a disponibilidade de informações que varia entre os dados demográficos, a completude dos dados se torna discriminatória. Os usuários que não conseguem fornecer as informações necessárias ficam invisíveis em sistemas que rejeitam registros incompletos.
- Exigir endereços de email exclui populações que não têm acesso à Internet confiável ou endereços de email pessoais.
- Exigir números de seguridade social (SSN) dos EUA exclui clientes internacionais e imigrantes recentes que ainda não receberam um SSN.
- Exigir endereços ruas exclui pessoas sem-teto e usuários com endereços não tradicionais.
Auditar justificativas de negócios para campos obrigatórios. Para cada campo obrigatório, é importante documentar por que as informações são obrigatórias em vez de opcionais. Se os processos puderem funcionar sem determinados dados por meio de abordagens alternativas, torne esses campos opcionais e projete sistemas para lidar com valores ausentes com facilidade. Isso ajuda a garantir que os usuários que não puderem fornecer esses dados não sejam excluídos.

Campos de nome que seguem convenções de nomenclatura ocidentais (Primeiro nome, Sobrenome) podem excluir culturas com diferentes práticas de nomenclatura.

Muitas culturas usam:

Nomes únicos (ou monônimos) sem nomes de família
Sistemas patronímicos em que o sobrenome muda de modo generalizado
Vários nomes ou nomes de família fornecidos
Nomes que mudam com base em eventos da vida ou contexto social
Nomes em que “primeiro” e “último” são distinções culturalmente sem significado

Projete a arquitetura de nome usando um único campo de nome completo ou uma estrutura flexível de várias partes que acomode convenções de nomenclatura comuns. Evite fazer pressuposições sobre ordenação de nomes, padrões de herança ou normas culturais.

Teste a arquitetura de nomes usando diversos nomes internacionais para garantir que os campos de nome aceitem:

Nomes de palavra única (por exemplo, Sukarno, Cher e Teller)
Nomes longos que excedem os limites de comprimento de campo comum
Nomes com diácritos, apostrofes, hifens e espaços
Nomes com scripts não latinos (por exemplo, árabe, chinês, cirílico e Devanagari)

Quando a validação de nome rejeita o nome legítimo de um usuário, ele é rejeitado pelo sistema com base em sua identidade cultural.

Os serviços de validação de endereço geralmente são otimizados para formatos dos EUA e da Europa Ocidental e geralmente não reconhecem:

Formatos de endereço internacional com ordem de campo diferente
Endereços rurais sem nomes de ruas
Endereços militares (por exemplo, APO e FPO)
Caixas de PO e locais de entrega alternativos
Terras tribais com sistemas de endereço exclusivos
Países com scripts não latinos para componentes de endereço

Quando as validações de endereço rejeitam formatos de endereço não tradicionais, isso impede a criação de conta, o envio e a entrega de serviços para usuários cujos endereços não correspondem às expectativas do banco de dados de validação.

Aqui estão algumas maneiras de projetar validações de endereço pensando em acessibilidade:

Implementar validação de endereço permissiva.
Aceite a entrada de endereço em forma livre quando as validações estruturadas falharem.
Armazene endereços conforme inseridos pelos usuários, em vez de forçar os usuários a fazer correções inválidas.
Use a validação de endereço para aprimoramento de dados e detecção de duplicação, não para validar a formatação de endereço.

Em vez de bloquear capturas de dados antecipadamente, crie a verificação de endereço em processos de cumprimento em que a precisão do endereço importa operacionalmente.

As pressuposições de acesso universal para canais de comunicação específicos excluem populações com diferentes preferências ou acesso à tecnologia.

A comunicação somente por email exclui:

Usuários sem acesso confiável à Internet
Populações mais idosas que estão menos à vontade usando email
Usuários em regiões em que SMS ou aplicativos de mensagens são o método de comunicação principal

A comunicação somente por telefone exclui:

Usuários que são surdos e com dificuldade auditiva
Usuários sem acesso telefônico ou que usam telefones compartilhados

Projete uma arquitetura de comunicação do Omnichannel que permita aos usuários controlar as preferências de canal. Armazene métodos de comunicação preferenciais em registros de Contato e respeite de modo consistente as preferências em todos os sistemas de comunicação de saída. Forneça uma variedade de alternativas de comunicação em vez de presumir que os métodos de canal único funcionem universalmente.

Coletar dados demográficos para monitoramento de equidade requer uma arquitetura cuidadosa para evitar o uso incorreto.

A coleta e o processamento de dados demográficos dependem da jurisdição e são legalmente restritos (na UE, o artigo 9 do RGPD trata-os como dados de categorias especiais que exigem uma base jurídica específica; nos EUA, o monitoramento de viés geralmente depende da autoidentificação voluntária do EEO). Quando há uma base legal, as organizações usam dados demográficos para:

Monitore métricas de imparcialidade estratificadas por grupos protegidos
Detectar viés em sistemas de automação e IA
Demonstrar a conformidade regulatória com os requisitos anti-discriminação

A coleta de dados demográficos cria determinados riscos:

Os dados podem ser usados para fins discriminatórios se os controles de acesso falharem
Os usuários podem desconfiar dos métodos de coleta e fornecer dados imprecisos
A coleção pode parecer invasiva ou discriminatória

Arquite a autoidentificação voluntária e projete a coleção de dados demográficos usando informações que são:

Explicado claramente com um propósito transparente (por exemplo, monitoramento de equidade ou relatório de conformidade)
Voluntário e inclui uma opção “Preferir não responder” que está sempre disponível
Separado de dados operacionais com FLS rígida para evitar acesso impróprio
Agregado para relatórios e análise e não vinculado a decisões individuais
Monitorado por meio do Monitoramento de evento Shield para auditoria de padrão de acesso

É importante documentar em políticas de privacidade exatamente como os dados demográficos serão e não serão usados. Violar a Trust do usuário através do uso de dados não divulgados pode prejudicar gravemente a credibilidade, o que pode ser difícil de recuperar.

Aprimoramento de dados de terceiros que anexa dados demográficos, firmográficos ou comportamentais a registros do Salesforce pode introduzir um viés por meio de:

inferências imprecisas baseadas em estereótipos
Cobertura incompleta com lacunas correlacionadas às demografias
Algoritmos proprietários que usam propriedades de equidade desconhecidas
Dados adquiridos de registros históricos com viés

Antes de implementar serviços de aprimoramento de dados, é importante auditar:

Testes de imparcialidade do fornecedor e práticas de mitigação de viés
Cobertura e precisão dos dados entre grupos demográficos
Inferir metodologias e recursos usados para criar previsões
Restrições de uso de dados contratuais e políticas de retenção

Lembre-se de que, quando dados de terceiros entram na sua organização do Salesforce, isso pode afetar decisões, criando um viés introduzido pelo fornecedor que também se reflete como um viés na sua organização.

Em contextos do Salesforce, a acessibilidade se refere à arquitetura de Componentes da Web Lightning, páginas do Visualforce e sites do Experience Cloud que funcionam para usuários com deficiência. Os componentes padrão do Lightning fornecem acessibilidade de linha de base quando usados corretamente; no entanto, o desenvolvimento personalizado e a configuração do Experience Cloud exigem uma implementação explícita de acessibilidade.

Os componentes do Lightning Design System são projetados para oferecer suporte à conformidade WCAG 2.2 AA quando usados conforme projetado. O Salesforce busca, mas não certifica, a conformidade total. O desvio dos padrões SLDS ou a criação de componentes personalizados sem consideração de acessibilidade cria barreiras para usuários com deficiência.

Componentes da Web Lightning padrão fornecem acessibilidade integrada. Componentes como Lightning, Lightning, Lightning e Lightning incluem automaticamente atributos de ARIA adequados, associações de rótulo, navegação do teclado e gerenciamento de foco. Quando possível, use componentes padrão em vez de criar alternativas personalizadas semelhantes, mas que possam não ter a infraestrutura de acessibilidade adequada.

Usar HTML semântico em Componentes da Web Lightning personalizados. Ao criar componentes personalizados, use elementos HTML semânticos (
,
,
,
,
,
) em vez de componentes
aninhados de forma confusa. Os leitores de tela usam a estrutura semântica para transmitir a organização da página e habilitar a navegação por marcos. Evite usar marcação puramente visual que remova o significado da hierarquia de conteúdo.
Implemente ARIA em componentes personalizados. Aplique marcos, papéis e propriedades do ARIA quando o HTML semântico não puder transmitir o comportamento da interface. Atualizações de conteúdo dinâmicas exigem regiões ativas aria que anunciam alterações aos leitores de tela. Componentes interativos personalizados precisam de definições de papel explícitas que correspondam ao seu comportamento. Os componentes de base do Lightning tratam do ARIA automaticamente; no entanto, os componentes personalizados exigem validação manual do ARIA por meio de testes do leitor de tela.
Teste com tecnologia assistiva: Valide componentes do Lightning usando leitores de tela reais (por exemplo, JAWS e NVDA para Windows, VoiceOver para macOS e iOS e TalkBack para Android). Com base no estudo em grande escala de Deque, ferramentas automatizadas como o axial-core capturam aproximadamente 57% dos problemas de acessibilidade por volume. Os problemas restantes exigem testes manuais com tecnologia assistiva por pessoas que entendem os padrões de navegação do leitor de tela.
Usar o gerenciamento de foco em fluxos do Lightning. Quando os modais são abertos, o conteúdo dinâmico é carregado ou os usuários concluem fluxos de várias etapas, você deve gerenciar programaticamente o foco para orientar os usuários do teclado para o novo conteúdo. Os componentes modal e pop-over do Lightning fornecem o gerenciamento básico de foco, mas fluxos complexos precisam de lógica de foco explícita para mover o foco adequadamente conforme o conteúdo muda.

Os sites do Experience Cloud atendem a usuários externos, incluindo clientes, parceiros e públicos, que exigem um design acessível que possa precisar atender aos requisitos da ADA, da Seção 508 e/ou da Lei Europeia de Acessibilidade (dependendo da jurisdição, do público e do tipo de organização).

Use modelos acessíveis. Os modelos do Experience Cloud criados usando o Lightning Web Runtime (LWR) incluem acessibilidade de linha de base. Modelos padrão, como o Portal de conta do cliente e a Central de ajuda, fornecem as noções básicas do WCAG 2.2 AA quando configurados corretamente. Modelos personalizados exigem implementação de acessibilidade explícita, incluindo marcação semântica, navegação por teclado e compatibilidade com o leitor de tela.
Verifique a conformidade com WCAG no tema. Temas personalizados e sites com marca exigem validação de contraste de cores. As configurações de Tema do Criador de experiências controlam cores, tipografia e espaçamento. Garanta que todo o texto atenda ao contraste de 4,5:1 para texto normal (menos de 18pt para texto normal ou menos de 14pt para negrito) e 3:1 para texto grande (18pt ou maior para texto normal ou 14pt ou maior para negrito) e componentes da interface do usuário. Use ferramentas de desenvolvedor de navegador ou verificadores de contraste online para validar a conformidade. Teste com zoom de navegador de 200% para garantir que o texto seja dimensionado sem perder conteúdo ou funcionalidade.
Usar navegação por teclado nos menus de navegação. Os componentes de navegação do Experience Cloud devem oferecer suporte à operação somente de teclado sem dependência de mouse. Os usuários devem navegar para dentro e para fora de menus suspensos, mega menus e navegação flyout usando as teclas Tab, Enter, Escape e Arrow sem armadilhas de foco. Teste todos os caminhos de navegação usando apenas o teclado para validar a acessibilidade.
Habilite a acessibilidade de formulário no Experience Cloud. Associe rótulos explicitamente a todas as entradas de formulário usando elementos de rótulo adequados ou aria-labelledby. Por si só, o texto de espaço reservado falha nos requisitos de acessibilidade porque o texto desaparece assim que a entrada de dados começa, o que deixa os usuários do leitor de tela sem contexto suficiente e persistente. Os componentes de entrada do Lightning fornecem associação de rótulo integrada quando são configurados usando os atributos de rótulo obrigatórios. Formulários personalizados do Visualforce exigem associação explícita de rótulo-entrada.
Teste sites do Experience Cloud usando tecnologia assistiva. Antes de iniciar sites do Experience Cloud voltados para o público, você deve realizar testes abrangentes de acessibilidade usando leitores de tela, navegação somente com teclado e zoom do navegador. É importante incluir usuários com deficiência nos testes de usabilidade para revelar barreiras práticas da experiência real que revisões de especialistas geralmente podem perder. Testar apenas páginas internas do Lightning sem validar a acessibilidade externa do Experience Cloud deixa os sites voltados para o público vulneráveis a reclamações e litígios de acessibilidade.
Use texto alternativo para imagens e ícones. Todas as imagens, ícones e conteúdos gráficos informativos no Experience Cloud exigem texto alternativo. As imagens decorativas usam texto alternativo vazio (alt=”), que permite que os leitores de tela ignorem. Imagens informativas fornecem texto alternativo relevante que descreve o conteúdo e a função. Quando você está escrevendo texto alternativo para ícones, concentre-se na ação ou na finalidade do ícone, em vez de sua aparência visual (por exemplo, em vez de descrever um ícone de lupa como “largura”, o texto alternativo deve indicar seu utilitário funcional, como “Pesquisar site”). Ao gerenciar imagens, o CMS deve solicitar que os autores de conteúdo insiram texto alternativo ou marquem explicitamente a imagem como decorativa (o que define alt=”). Isso garante a acessibilidade evitando a ausência de texto alternativo e descrições forçadas para imagens estéticas.

A acessibilidade completa do teclado significa que os usuários podem acessar todas as funcionalidades usando o teclado sem exigir interação com o mouse ou o toque em qualquer ponto.

Usar ordem de foco lógica em páginas do Lightning. Certifique-se de que a ordem de foco siga o layout visual e o fluxo de interação. Quando os usuários pressionam Tab, o foco visual deve passar pelos elementos interativos na ordem que os usuários esperam com base no design visual. O Criador de aplicativo Lightning e o Criador de experiências estabelecem a ordem de foco com base no posicionamento do componente. Componentes personalizados exigem gerenciamento de tabindex explícito para garantir a progressão do foco lógico.
Use indicadores de foco visíveis para atender aos requisitos de contraste. O Lightning Design System fornece estilos de foco para atender aos requisitos do WCAG para a maioria dos componentes. Os componentes personalizados podem precisar de indicadores de foco aprimorados para atender ao requisito de contraste 3:1 em relação ao conteúdo envolvente. Os indicadores de foco devem estar claramente visíveis para permitir que usuários com baixa visão naveguem por meio do teclado. Nunca remova indicadores de foco com CSS (descrição: nenhum) sem fornecer um estilo alternativo de foco visível.
Use mitigações de armadilha de teclado em modais e sobreposições. Os diálogos modais devem colocar o foco dentro do modal enquanto ele está aberto, o que impede que os usuários do teclado acessem conteúdo de segundo plano oculto. A armadilha de foco deve ser liberada ao fechar o modal e retornar o foco ao elemento acionador. O conteúdo integrado, incluindo iframes e widgets de terceiros, não deve capturar permanentemente o foco do teclado sem um mecanismo de escape.
Use teclas de atalho sem conflitos. O Lightning fornece atalhos de teclado padrão que são documentados na Ajuda do Salesforce. Os atalhos de teclado personalizados devem ser projetados para evitar conflitos com os controles padrão do navegador e com os comandos de navegação do leitor de tela. De acordo com os critérios de sucesso do WCAG, os atalhos de caracteres únicos (por exemplo, pressionar uma única letra ou ponto de pontuação) não devem acionar ações globais. Eles devem restringir a ativação para quando um componente específico tem foco ativo ou fornecer aos usuários uma maneira de desativar ou remapear totalmente o atalho.

Crie validação de acessibilidade em pipelines CI/CD para encontrar problemas estruturais automaticamente em cada implantação, em vez de tratar a acessibilidade como auditorias manuais periódicas.

Use sa11y para testes de acessibilidade de Componente da Web Lightning. As bibliotecas sa11y do Salesforce (o pacote @sa11y/jest) encapsulam o mecanismo de acessibilidade do axe-core para adicionar um correspondente toBeAccessible() para testes de unidade Jest. Escreva testes de acessibilidade que validam o uso adequado de ARIA, associações de rótulo, proporções de contraste e marcação semântica automaticamente como parte dos testes de unidade. Configure as compilações para falhar quando problemas críticos de acessibilidade forem detectados.
Usar o Lighthouse CI para Experience Cloud. O Google Lighthouse audita a acessibilidade da página da Web, incluindo sites do Experience Cloud. Integre a CI do Lighthouse a pipelines de implementação para verificar páginas voltadas para o público quanto a problemas de acessibilidade. Configure limites de pontuação para exigir pontuações mínimas de acessibilidade antes das aprovações de implantação.
Use o Agente de acessibilidade, disponível por meio do pacote Salesforce DX MCP. Em ambientes compatíveis com MCP ou dentro do Agentforce Vibes, ele revisa o código em relação aos padrões WCAG, detecta correções direcionadas e pode gerar uma solicitação de pull para um engenheiro revisar, validar e mesclar.

O viés existia na automação determinística do Salesforce muito antes de a IA entrar no quadro. Regras de atribuição, decisões de fluxo, regras de validação e design de território codificam a estimativa humana que pode perpetuar a discriminação. Diferentemente do viés de IA, que os arquitetos analisam extensivamente, o viés de automação costuma passar por inexaminado porque a lógica determinística parece objetiva.

Siga as regras de atribuição de lead e caso. Distribua o trabalho entre equipes de vendas e serviço. Quando a lógica de atribuição usa critérios que se correlacionam com características protegidas, a automação cria disparidades sistemáticas na qualidade do serviço e no acesso à oportunidade.
As regras de atribuição que usam características de território, CEP ou conta podem encaminhar oportunidades de alto valor de maneira desproporcionada para equipes específicas enquanto encaminham trabalho de valor inferior para outro lugar. Se os limites de território estiverem correlacionados com as estruturas demográficas e de compensação do cliente que diferem entre territórios, a automação de atribuição criará discriminação econômica.
Audite os resultados da regra de atribuição regularmente. Calcule as distribuições de atribuição entre territórios e equipes estratificados pela demografia do cliente. Se as contas Enterprise estiverem concentradas em territórios específicos enquanto as contas SMB forem distribuídas em outro lugar (e se os territórios Enterprise receberem uma melhor remuneração ou recursos), as regras de atribuição poderão produzir resultados desiguais que justifiquem a análise de equidade.
Revise o roteamento baseado em habilidades do Omni-Channel. Isso pode afetar a qualidade do serviço entre as populações de clientes. Se a lógica de roteamento presume implicitamente que determinadas habilidades estão correlacionadas com o valor do cliente ou com a complexidade do problema, os clientes poderão receber diferentes resultados de serviço com base em proxies demográficos.

É importante monitorar o tempo médio para processamento, as resoluções de primeiro contato e a satisfação do cliente nos caminhos de roteamento. As discrepâncias podem indicar se determinados segmentos do cliente recebem sistematicamente agentes menos experientes ou menos opções de roteamento.

Revise as automações do Salesforce Flow. Tomar decisões de aprovação, determinações de elegibilidade ou concessões de acesso podem codificar a lógica discriminatória por meio de regras de negócios aparentemente inofensivas. Determinados fluxos criam discriminação indireta quando os critérios estão correlacionados a características protegidas.
Revise decisões de Fluxo com a justiça em mente. Para cada Fluxo que toma decisões consequentes que afetam os usuários, é importante perguntar:
O que acontece com os usuários que não se encaixam no perfil de cliente típico?
Os critérios de decisão estão correlacionados às características demográficas?
Exceções e casos de extremidade são tratados de modo justo ou sistematicamente desvantajam grupos específicos?

É importante documentar a lógica de decisão de Fluxo e as considerações de equidade em registros de decisão de arquitetura e submeter fluxos de alto nível às mesmas políticas de análise de ética que os sistemas de IA.

Revisar regras de validação. Evitar a entrada de dados pode excluir dados válidos de usuários cujas informações não correspondam às pressuposições do sistema. Regras de validação que rejeitam dados legítimos criam populações invisíveis. Usuários cujos dados não se encaixam nos padrões de validação não podem interagir com determinados sistemas. Falhas de validação geralmente não são relatadas porque os usuários abandonam suas solicitações em vez de relatar erros técnicos. Aqui estão vários padrões de viés de validação comuns:
Validações de nome que exigem caracteres latinos podem excluir nomes com caracteres dinâmicos e scripts não latinos.
As validações de número de telefone costumam usar formatos EUA/Oeste, o que exclui números internacionais e métodos de comunicação alternativos.
As validações de endereço não reconhecem endereços não padrão (por exemplo, caixas de PO, rotas rurais, terras tribais e formatos internacionais).
Validações de email que exigem endereços de email pessoais podem criar uma desvantagem para usuários que não têm acesso de email pessoal.
Teste regras de validação usando dados diversos. Inclua endereços internacionais, nomes não ocidentais e formatos de telefone alternativos nos testes de validação. Quando a validação rejeita dados legítimos, você deve expandir a lógica de validação para evitar excluir usuários válidos.

Revise os designs de território de vendas. Estratégias de segmentação de clientes e designs de território de vendas determinam a alocação de recursos entre as populações de clientes. Quando limites de território ou critérios de segmentação se correlacionam com demografia que resulta em alocação desigual de recursos, essa alocação pode produzir resultados discriminatórios. Os designs de território que usam limites geográficos geralmente se correlacionam com demografia racial, étnica e econômica devido a padrões de segregação residencial. Se a remuneração, os níveis de pessoal ou os investimentos de recursos forem diferentes entre territórios, a geografia poderá se tornar um mecanismo para alocação de recursos discriminatórios.
Analisar a demografia do território antes de finalizar os projetos. Mapeie a demografia do cliente nos limites de território propostos. Quando ocorrerem concentrações demográficas, avalie se a alocação de recursos é uniforme em todos os territórios, independentemente da composição demográfica. Se a justificativa de negócios exigir diferentes níveis de recursos entre territórios (por exemplo, maturidade do mercado, intensidade da concorrência e potencial de crescimento), documente essa justificativa explicitamente e monitore os resultados para garantir que territórios subatendidos recebam oportunidades de investimento adequadas para evitar disparidades fundamentais.

Mantenha a transparência na lógica de automação. Documente regras de negócios, critérios de atribuição e lógica de decisão de fluxo nos registros de decisão do Salesforce Knowledge ou da arquitetura. Automação transparente permite que a imparcialidade seja revisada de uma maneira que a lógica oculta impede.
Resultados de auditoria regulares. Agende auditorias trimestrais para analisar os resultados da automação que podem ser estratificados por demografia do cliente. Lembre-se de que as disparidades acionam investigações e possíveis soluções.
É importante rastrear:
Distribuições de atribuição entre equipes e territórios
Taxas de aprovação para fluxos que tomam decisões de elegibilidade
Taxas de rejeição de regra de validação por padrão de dados
Desempenho do território e alocação de recursos
Revise a automação de alto nível por meio de uma lente ética. Fluxos de assunto e regras de atribuição que afetam o emprego, o crédito, o acesso ao serviço ou outros resultados consequentes para o mesmo processo de análise de ética que os sistemas de IA. O viés de automação precisa do mesmo nível de análise que o viés algorítmico.

No Salesforce, a fairness de IA se concentra em usar o Einstein para validar que as previsões produzem resultados justos em todos os grupos demográficos. O Einstein Discovery e a instrumentação personalizada capturam dados de decisão de modelo preditivo que possibilitam a detecção de viés. Os painéis do CRM Analytics rastreiam métricas de equidade. A Trilha de auditoria de campo e o Monitoramento de evento capturam dados de decisão para responsabilidade algorítmica.

As previsões do Einstein que afetam decisões consequenciais (por exemplo, pontuação de lead, previsões de oportunidade e segmentação de clientes) exigem avaliações de imparcialidade pré-implementação que funcionam como uma etapa equivalente obrigatória (semelhante às análises de segurança).

Analise todos os recursos do modelo preditivo para correlação com características protegidas usando métodos estatísticos. Remova ou transforme recursos de proxy depois de avaliar se seu valor preditivo justifica a inclusão apesar dos efeitos de proxy.

Audite os dados do Salesforce CRM antes do treinamento. As organizações do Salesforce contêm décadas de decisões humanas baseadas em práticas históricas. Se as equipes de vendas anteriores priorizaram determinados dados demográficos, a Pontuação de leads do Einstein aprende esses padrões e os perpetua. Antes de treinar modelos preditivos em dados históricos, é importante auditar esses dados quanto a lacunas de representação demográfica e inconsistências de medição entre segmentos de clientes.
Calcule métricas de equidade entre grupos demográficos. Antes de implementar modelos preditivos, é importante calcular a paridade demográfica, a igualdade de oportunidades e as proporções de impacto diferentes entre grupos protegidos, em que você tenha uma base legal para coletar e processar os dados demográficos necessários. Se a Pontuação de leads do Einstein atribuir pontuações altas ao segmento A 50% do tempo, mas apenas 30% do tempo ao segmento B, uma proporção de 60% falhará na regra de quatro quintos (80%) e exigirá investigação e mitigação. O valor de 80% é um acionador de triagem, não uma linha de aprovação/falha legal: a regra de quatro quintos é uma regra de polegar federal dos EUA para seleção de emprego, e limpá-la não é um porto seguro — uma disparidade estatisticamente significativa pode justificar o escrutínio em proporções mais altas, e outros regimes medem o impacto negativo de maneira diferente (a lei de discriminação indireta da UE, por exemplo, ativa se uma prática cria uma “desvantagem particular”, sem um limite fixo). Calibre limites de investigação para as jurisdições e casos de uso em que você opera.
Capture dados de decisão de modelo preditivo para detecção de viés. Para detectar viés em modelos preditivos, como Pontuação de lead e Pontuação de oportunidade, capture dados de decisão por meio do Einstein Discovery e de instrumentos personalizados: armazene entradas, saídas e versões de modelo de previsão em campos rastreados e habilite a Trilha de auditoria de campo. Analise esses dados no CRM Analytics para rastrear padrões de decisão entre grupos demográficos ao longo do tempo e criar painéis que alertem quando as métricas de paridade demográfica ou de igualdade de oportunidades ultrapassam limites aceitáveis.
Detecte recursos de proxy em modelos preditivos. Recursos que estão correlacionados com características protegidas permitem discriminação indireta mesmo quando características protegidas são excluídas dos modelos.
- Os dados do Salesforce costumam conter recursos de proxy:
Território ou CEP (proxies para raça, etnia e renda)
Padrões de nome da conta (proxies para tamanho da organização e demografia do setor)
Tempo da atividade de comunicação (proxies para fusos horários, religião e responsabilidades de cuidados)
Tipo de dispositivo ou navegador dos dados de Atividade (proxies para nível de renda)

Quando um viés é detectado em previsões do Einstein, você deve aplicar a mitigação na fase de pipeline apropriada (com base na causa raiz e nas restrições técnicas).

Dados de equilíbrio antes do treinamento do modelo. Reequilibre os dados do Salesforce CRM excedendo a amostragem de segmentos de clientes subrepresentados ou subexcluindo a amostragem de segmentos sobrerepresentados antes de treinar modelos preditivos. Use o Data 360 para agregar dados entre várias organizações para garantir vários conjuntos de treinamento. A geração de dados sintéticos pode complementar segmentos escassos enquanto preserva a privacidade por meio de técnicas de privacidade diferenciadas.
Remova proxies na engenharia de recursos. Quando os recursos de proxy forem identificados, substitua-os por recursos alternativos que forneçam poder preditivo sem correlação demográfica. Se o território servir como proxy demográfico, considere a classificação do setor ou o tamanho da empresa como alternativas. Se os padrões de nome da conta estiverem correlacionados com a demografia, use atributos firmográficos.
Ajustar limites durante o pós-processamento. Ajuste os limites de decisão por segmento demográfico para igualar as taxas de resultado após os modelos de treinamento. Para decisões relacionadas ao emprego, isso é totalmente proibido: O título VII (Lei dos Direitos Civis de 1991) proíbe ajustar pontuações ou usar pontuações de corte diferentes por classe protegida, e nenhuma quantidade de justificação documentada torna a prática legal. Quando não for proibido, documente ajustes de limite com justificativa comercial para tratamento diferencial quando as previsões informarem decisões automatizadas.
Retrain modelos periodicamente usando dados atualizados. Agende o novo treinamento do modelo trimestralmente (ou quando ocorrerem turnos significativos de distribuição de dados). Treinar novamente em dados novos captura padrões de viés emergentes e corrige qualquer desvio de linhas de base de fairness originais. Revalide as métricas de fairness em cada versão do modelo antes da implementação de produção para garantir que o treinamento não tenha introduzido novos vieses.

A Camada do Trust do Einstein captura avisos, respostas e sinais Trust para recursos de IA generativa e Agentforce, apoiando a transparência e a conformidade regulatória para IA generativa. Para modelos preditivos, a transparência e a linha de decisão vêm do Einstein Discovery e do Gerenciador de modelo, que exigem instrumentos personalizados para reter dados de auditoria.

Crie capacidade de explicação nas soluções do Einstein a partir da arquitetura inicial, em vez de adaptar explicações a sistemas opacos após a implantação.

Explique o Einstein Discovery em pontos de decisão. O Einstein Discovery fornece explicações de fatores de previsão que mostram quais variáveis mais influenciaram previsões específicas com impacto direcional. Arquite componentes do Lightning que exibem essas explicações aos usuários no ponto de decisão, em vez de exigir navegação para separar painéis do CRM Analytics. Quando as decisões afetam os usuários, elas precisam de transparência, não de métricas de desempenho de modelo abstratas.
Explicações de camada para diferentes públicos. Forneça a profundidade da explicação adequada a cada público:
Usuários de negócios: “Esse lead obteve uma pontuação alta porque a receita anual excede US$ 1 milhão e a pontuação de engajamento está nos 10% superiores.”
Usuários técnicos: Forneça um cartão de modelo do Einstein Discovery com pesos de recursos, características de dados de treinamento e métricas de validação.
Clientes: “Essa recomendação é baseada em suas compras recentes e clientes com preferências semelhantes.”
Auditores: Forneça a linha de decisão do Einstein Discovery e do Gerenciador de modelo (versão do modelo, valores de entrada e os fatores que impulsionaram a previsão) capturados por meio de instrumentos personalizados.
Comunique confiança adequadamente. Exiba a confiança da previsão em termos adequados ao usuário e evite pontuações de probabilidade brutas que os usuários possam interpretar incorretamente. Em vez de mostrar “confiança de 73%”, comunique isso usando categorias (por exemplo, Alta confiança, Moderar confiança e Requer revisão) com explicações do que cada nível de confiança significa para a confiabilidade da decisão, bem como quais revisões adicionais ocorrerão.

Mantenha trilhas de auditoria abrangentes e imutáveis que dão suporte à responsabilidade, depuração e conformidade regulatória para todas as decisões conduzidas por IA que afetam os usuários.

Capture dados de auditoria preditiva com as ferramentas certas. Armazene dados de auditoria de modelo preditivo (entradas de previsão, saídas e versões de modelo) em campos rastreados com a Trilha de auditoria de campo habilitada. Crie políticas de retenção de dados para atender aos requisitos regulatórios, que variam de acordo com o setor e a jurisdição:
- As regras de serviços financeiros estabelecem a retenção por regulamento (por exemplo, a Regra 4511(b) da FINRA estabelece um período de retenção padrão de seis anos para registros que de outra forma não tenham um período de retenção especificado de acordo com as regras da FINRA ou a Regra 17a-4 da SEA).
- A retenção de cuidados de saúde também é regulada por regras específicas (por exemplo, a HIPAA exige um mínimo de seis anos para a documentação de conformidade; a retenção de registros médicos é definida pelas leis individuais dos estados) em vez de mandatos de retenção indefinida.
Analisar dados de decisão de modelo preditivo com o CRM Analytics. Crie painéis do CRM Analytics nos dados de decisão de modelo preditivo que você captura (entradas de previsão, saídas e versões de modelo em campos rastreados) para analisar padrões de decisão, métricas de equidade e desempenho do modelo ao longo do tempo. Crie lenses que mostrem distribuições de previsão por nível de confiança, segmento demográfico e tipo de resultado. Configure histórias do Einstein Discovery que identificam padrões anômalos que exigem investigação adicional.
Use a Trilha de auditoria de campo para retenção de longo prazo. O histórico de campo padrão rastreia alterações para 18 meses na UI e até 24 meses por meio da API. A Trilha de auditoria de campo permite manter o histórico de campo indefinidamente para objetos personalizados que armazenam dados de decisão de IA. Ele arquiva o histórico após até 18 meses por padrão, então retém os dados arquivados até você excluí-los. Habilite a Trilha de auditoria de campo em objetos que contêm registros de consentimento, substituição de decisões e relatórios com viés para cumprir os requisitos de retenção regulatória.
Usar o Monitoramento de evento para interações do Agentforce. O Monitoramento de evento captura eventos de nível de invocação para Agentforce, como quando ações e fluxos são executados. Exporte dados do Monitoramento de evento para um SIEM externo – dados padrão do Arquivo de logs de evento por meio da API e o subconjunto de Monitoramento de evento em tempo real de eventos por meio de Eventos de plataforma – para armazenamento que exceda a janela de retenção nativa do Salesforce. A evidência de falha depende de um comportamento específico do SIEM que impõe a segregação de acesso e armazenamento de gravação única. Configure consultas SIEM para detectar padrões de viés em grandes volumes de interações do Agentforce.
Audite conversas do Agentforce com a Camada de confiança do Einstein. A Camada de Trust do Einstein captura a trilha de auditoria de avisos e respostas de conversa do Agentforce, armazenados no Data 360, fornecendo o registro em nível de transcrição para transparência e conformidade regulatória.

Vamos analisar mais detalhadamente os recursos de transparência do Arquiteto que estão posicionados para conformidade com os regulamentos atuais e emergentes de IA em várias jurisdições.

Requisitos de transparência da Lei da IA da UE. Os sistemas de IA de alto risco ao abrigo da Lei UE de IA exigem documentação de transparência, documentação técnica, capacidades de supervisão humana e métricas de precisão/equidade. As trilhas de auditoria da Camada de Trust do Einstein e os cartões de modelo do Einstein Discovery fornecem a base para esses requisitos. O modelo de documento treina dados demográficos, abordagens de validação e limitações conhecidas em registros de decisão de arquitetura.
Direito à explicação do RGPD. O GDPR dá aos sujeitos de dados da UE o direito de obter informações relevantes sobre a lógica de uma decisão quando essa decisão é baseada apenas em processamento automatizado e produz efeitos legais ou semelhantes. Este direito decorre do artigo 15.o, n.o 1, alínea h), e do artigo 22.o, n.o 3, no considerando 71, e foi clarificado pelo TJUE no processo Dun & Bradstreet (2025). Projete sistemas que geram explicações coerentes sob demanda para qualquer decisão histórica dentro dos períodos de solicitação de acesso do sujeito dos dados, que variam (dependendo da jurisdição) entre 15 e 45 dias. Os dados de decisão do modelo preditivo que você captura (entradas de previsão, saídas, versões do modelo e fatores de explicação do Einstein Discovery) permitem reconstruir explicações quando armazenadas com retenção suficiente.
Legislação de responsabilidade algorítmica. As leis de responsabilidade algorítmica em nível de estado dos EUA estão exigindo cada vez mais avaliações de impacto e relatórios de transparência para sistemas de decisão automatizados. Os dados de decisão do modelo preditivo que você captura e os painéis de monitoramento de equidade do CRM Analytics fornecem as bases de dados para esses relatórios. Realize avaliações de impacto algorítmico antes de implementar a IA consequente como conformidade proativa, em vez de uma resposta reativa a consultas regulatórias.

OWDs, regras de compartilhamento e segurança em nível de campo (FLS) moldam os padrões de acesso aos dados que determinam que informações os usuários podem revisar e usar para tomar decisões. A configuração adequada impede o acesso discriminatório a atributos confidenciais, ao mesmo tempo que garante um serviço justo.

Projete OWDs e Segurança em nível de campo para restringir o acesso por padrão. Para regras de compartilhamento, use o princípio de privilégio mínimo (PoLP) para conceder apenas o acesso adicional de que cada papel precisa legalmente, o que impede a tomada de decisões discriminatórias com base em características protegidas.

Habilite o OWD restritivo como padrão. Use OWDs privados para objetos que contêm dados confidenciais do cliente e conceda acesso por hierarquia de papéis e regras de compartilhamento. OWDs de leitura/gravação pública tornam a restrição de acesso mais tarde disruptiva. A restrição do padrão aciona um recálculo de compartilhamento e entra em vigor apenas após a conclusão, em vez de impossível. OWDs privados com concessões de compartilhamento explícitas criam padrões de acesso auditáveis que dão suporte à conformidade de não discriminação.
Aplicar Segurança em nível de campo para atributos confidenciais. Oculte campos confidenciais que contenham características protegidas (por exemplo, etnia, religião e status de deficiência) de usuários que não precisam de acesso para fins comerciais legítimos. Configure o FLS para remover o acesso de leitura para campos confidenciais na maioria dos perfis. Quando esses campos são necessários para fins específicos (por exemplo, relatórios de diversidade e acomodação razoável), conceda acesso mínimo usando conjuntos de permissões com justificativa de negócios documentada.
Desenvolver regras de atribuição e compartilhamento para resultados justos. Use regras de atribuição, filas e roteamento do Omni-Channel para distribuir o trabalho de maneira uniforme entre territórios, equipes e agentes de serviço. Evite o compartilhamento manual que concentre oportunidades de alto valor ou clientes com grupos de usuários específicos sem justificativa de negócios documentada. Configure regras de compartilhamento automáticas com base em critérios objetivos (por exemplo, setor, geografia e linha de produto) em vez de critério subjetivo do gerente, o que pode habilitar o viés.
Forneça conjuntos de permissões para acesso temporário. Conceda acesso temporário a dados confidenciais por meio de conjuntos de permissões em vez de modificar perfis, o que afeta todos os usuários permanentemente. Quando os usuários precisarem de acesso a dados demográficos para projetos específicos (por exemplo, análise de diversidade e solicitações de acomodação), atribua conjuntos de permissões com expirações documentadas. Fluxos agendados podem revogar conjuntos de permissões automaticamente após períodos definidos.

Use o Monitoramento de evento Shield e relatórios para detectar padrões de acesso a dados que indicam possível discriminação ou viés no uso de dados.

Use o Monitoramento de evento Shield para auditar o acesso a dados confidenciais. Use o Monitoramento de evento para capturar eventos de acesso em nível de objeto (exportações de relatório, consultas de API e exibições de página) em objetos que contêm características protegidas ou atributos confidenciais. Configure consultas sobre esses eventos para detectar quem acessou o objeto, quando e em que contexto e trate padrões anômalos (por exemplo, picos súbitos e acesso por usuários inesperados) como acionadores para investigação.
Relatório sobre distribuições de regra de compartilhamento. Crie relatórios que analisem como os registros são distribuídos entre usuários, equipes e territórios. Calcule as estatísticas de distribuição por demografia do cliente para garantir que contas e oportunidades de alto valor sejam distribuídas de maneira uniforme. Identifique concentrações em que grupos de usuários específicos recebem acesso desproporcionado a registros valiosos sem justificativa de negócios documentada.
Auditar violações de CRUD e FLS. Revise a Trilha de auditoria de configuração para alterações nas configurações de OWD, regras de compartilhamento, configurações de FLS e conjuntos de permissões. Alterações não autorizadas nos controles de acesso a dados podem indicar tentativas de acessar dados confidenciais inadequadamente. Use políticas de Segurança da transação para agir em eventos de Monitoramento de evento em tempo real de alto risco (por exemplo, atividade de API anômala, logins suspeitos e exportações de dados confidenciais de modo de exibição de lista ou relatório grande). Como a Segurança da transação opera apenas nesses eventos de tempo de execução, em vez de alterações de DML ou FLS em nível de registro, você deve contar com a Trilha de auditoria de configuração e aprovações de gerenciamento de alterações documentadas para alterações de FLS e compartilhamento.

No Salesforce, agência do usuário significa que os clientes e os funcionários mantêm um controle significativo sobre como a IA afeta a experiência deles. Os recursos de gerenciamento de consentimento do Salesforce, consentimento do Data 360 e objetos de consentimento personalizados permitem um controle granular sobre interações de IA.

Projete o rastreamento de consentimento usando o gerenciamento de consentimento do Data 360, o consentimento do Marketing Cloud ou objetos de consentimento personalizados que usam a Trilha de auditoria de campo para requisitos de consentimento específicos da IA.

Habilite o consentimento granular por caso de uso de IA. Habilite o consentimento por caso de uso de IA em vez de usar um consentimento de IA geral. Os clientes podem concordar com as recomendações de produto do Einstein, mas recusar decisões de crédito conduzidas por IA. Habilite a Trilha de auditoria de campo em objetos de consentimento para retenção de longo prazo e cumprir os requisitos regulatórios. Projete objetos personalizados de consentimento com campos que rastreiam:
Finalidade do consentimento (por exemplo, Pontuação de leads do Einstein, Recomendações de resposta do Einstein e Criador de recomendações do Einstein)
Data de concessão de consentimento e Método de concessão (por exemplo, formulário da Web, API, telefone e email)
Data de retirada do consentimento (se aplicável)
Usuário relacionado ou ID do contato
Use o consentimento do Data 360 para personalização. Use o gerenciamento de consentimento do Data 360 para recursos de Personalização do Einstein. O Data 360 ingere e armazena as preferências de consentimento de sistemas a montante por meio de conectores mapeados para o Modelo de dados de privacidade, que permite usar esses atributos de consentimento como critérios de filtro na segmentação e na ativação. Mapeie atributos de consentimento para casos de uso de IA específicos para permitir que os usuários recusem a personalização enquanto mantêm os serviços principais
Habilite a integração de consentimento do Marketing Cloud. Integre o consentimento do Marketing Cloud aos Insights de mensagens do Einstein e recursos de marketing orientados por IA. Respeite o status e o consentimento da assinatura do Marketing Cloud em todas as comunicações conduzidas por IA.

Forneça recusas significativas de recursos conduzidos por IA com controles acessíveis que respeitam as preferências do usuário por meio de alternativas humanas de qualidade comparável.

Forneça opções acessíveis nas configurações de perfil. Permita que os usuários recusem interações conduzidas por IA por meio de controles de preferência acessíveis nas configurações de perfil do Experience Cloud ou Minhas configurações em aplicativos internos. Forneça descrições claras do que cada recusa significa e da experiência alternativa que os usuários receberão ao recusarem. Armazenar preferências em registros de Usuário ou Contato.
Forneça opções de preferência persistentes entre canais. Armazene as preferências de IA em registros de Usuário ou Contato para garantir a consistência entre canais (por exemplo, Web, celular, telefone e email). Consulte as preferências de modo consistente em todos os fluxos de interação para evitar que os usuários precisem repetidamente declarar preferências em diferentes canais.

A governança de IA ética fornece estruturas organizacionais que ajudam a garantir que a equidade persista à medida que os modelos evoluem, os dados mudam e os casos de uso se expandem. Sem governança, os esforços de equidade iniciais se deterioram conforme a atenção da organização muda.

Estabelecer documentação obrigatória e verificar os pontos de verificação antes da implantação do Einstein. Pense nisso como um gate que é tão importante quanto análises de segurança.

Forneça a documentação do modelo. Armazene a documentação do modelo no Salesforce usando um objeto Modelo personalizado ou Salesforce Files anexado a Projetos para habilitar a capacidade de pesquisa e o controle de versão. Documente cada modelo preditivo de produção usando:
Treinar dados demográficos e lacunas de representação conhecidas (para modelos preditivos treinados pelo cliente, como o Einstein Discovery e o Criador de previsões)
Métricas de equidade pré-implementação calculadas por grupo demográfico
Casos de uso pretendidos e usos inadequados conhecidos
Estratégias de mitigação de viés aplicadas durante o desenvolvimento
Abordagem de monitoramento de equidade e limites de alerta
Requisitos de supervisão humana e fluxos de trabalho de aprovação
Revisar agendas e partes responsáveis
Considerações regulatórias e posicionamento de conformidade
Habilite Portões de equidade pré-implementação. Modelos que falham em qualquer teste de gate não devem prosseguir para produção. Trate os portões de equidade com a mesma rigor que os portões de segurança. Em outras palavras, eles têm a autoridade de bloquear implantações. Antes de implantar previsões do Einstein em produção, você deve:
Revisar auditorias de dados de treinamento. Todas as lacunas de representação devem ser analisadas e documentadas.
Revisar métricas de equidade (por exemplo, paridade demográfica, igualdade de oportunidades e impacto desigual devem ser calculados e confirmados para cumprir os limiares).
Revisar avaliações de impacto. Avalie o possível dano em todas as populações afetadas.
Design com supervisão humana. Todos os padrões de escalação, fluxos de trabalho de aprovação e mecanismos de substituição devem ser projetados e testados adequadamente.
Conclua uma análise de transparência. Os recursos de explicação devem ser validados para todos os tipos de decisão.
Documentação completa. Todos os artefatos de documentação de modelo necessários devem ser aprovados.

Estabeleça processos de revisão para aplicativos de IA de alto interesse que forneçam supervisão interfuncional e têm autoridade de imposição.

Composição do Conselho de Revisão. Inclua especialistas técnicos (por exemplo, arquitetos e cientistas de dados), partes interessadas de negócios (por exemplo, proprietários de produto e pessoal de operações), consultores jurídicos, especialistas em privacidade e representantes de comunidades afetadas (quando possível). Lembre-se de que perspectivas diversas detectam problemas de equidade que grupos homogêneos costumam perder.
Revise todos os acionadores que exigem aprovação do conselho de ética. Defina quais casos de uso de IA exigem revisão de ética antes da implantação:
Decisões que afetam emprego, crédito, habitação, cuidados de saúde ou direitos legais
Sistemas automatizados que afetam mais de 10 mil usuários ou transações por ano
Aplicativos de IA que usam dados pessoais confidenciais, incluindo dados de saúde, financeiros ou demográficos
Novos casos de uso que não têm um precedente organizacional estabelecido
Sistemas em que possíveis vieses podem causar danos significativos a indivíduos ou grupos
Revise e determine quem tem autoridade para bloquear implantações. Os painéis de análise de ética devem ter a autoridade de exigir alterações, impor condições de monitoramento ou bloquear implantações que não estão em conformidade com os padrões éticos. As revisões apenas consultivas (sem autoridade de imposição) podem limitar a eficácia do processo de governança. Documente todas as análises em objetos personalizados do Salesforce que rastreiam: nome da solicitação, data da revisão, preocupações geradas, requisitos de mitigação e condições de aprovação.

O monitoramento de imparcialidade é um processo contínuo que requer atenção contínua para detectar o desvio de viés conforme as distribuições de dados mudam e as populações de usuários mudam.

Criar painéis de fairness do CRM Analytics. Crie painéis que rastreiam métricas de equidade usando os dados de decisão do modelo preditivo que você captura. Monitore a paridade demográfica, a igualdade de oportunidades, as proporções de impacto diferentes e as métricas de qualidade da previsão por segmentos do cliente. Configure alertas do CRM Analytics que são acionados quando métricas de justiça violam limites definidos e exigem uma investigação.
Habilite o monitoramento personalizado para sinais de imparcialidade. Crie monitoramento de fairness personalizado para detectar sinais (por exemplo, alterações súbitas nas distribuições de decisão por grupo demográfico, picos em registros de caso relacionados a viés ou degradação no desempenho do modelo para populações específicas).
Agendar auditorias de imparcialidade. Realize auditorias de imparcialidade trimestrais abrangentes para sistemas de IA de alta participação (por exemplo, crédito, emprego e saúde) e auditorias semestrais para sistemas de baixa participação (por exemplo, recomendações e personalização). As auditorias devem examinar métricas de fairness atuais, revisar padrões de substituição no histórico de aprovação, analisar relatórios de feedback e viés do usuário e validar se os controles de governança permanecem efetivos.
Implementar resposta a incidentes para falhas de imparcialidade. Estabeleça processos claros documentados no Salesforce Knowledge detalhando como responder quando um viés é detectado:
Imediato: Avalie a gravidade e o escopo consultando os dados de decisão do modelo preditivo no CRM Analytics. Se o incidente for grave, suspenda toda a tomada de decisão automatizada pendente de uma investigação.
Tempo curto: Implemente estratégias de mitigação temporárias (por exemplo, maior supervisão humana por meio de limites de confiança ajustados, desabilitação de recurso ou suspensão completa do agente).
Investigação: Conclua uma análise de causa-raiz (RCA) para identificar como o viés entrou no sistema ou evoluiu. Durante a RCA, analise dados de treinamento, versões de modelo e alterações de configuração por meio da Trilha de auditoria de campo.
Remediação: Implemente uma correção permanente por meio de correção de dados, novo treinamento de modelo ou alterações de processo.
Comunicação: Notifique os usuários afetados por meio de Casos, email ou anúncios do Experience Cloud.
Prevenção: Processe alterações para evitar recorrência e documente os métodos de prevenção em manuais.

Use essa lista de verificação durante revisões de arquitetura, antes da implementação de produção e periodicamente para avaliação contínua.

Qualidade dos dados e equidade representativa

Torne os campos opcionais quando um processo puder funcionar sem os dados e projete processos a jusante para lidar com valores ausentes para que os usuários que não puderem fornecer informações (email, SSN, endereço) não sejam excluídos.
Campos de Nome do arquiteto como um único campo de nome completo ou estrutura flexível de várias partes que aceita monônimos, scripts não latinos, diácritas e nomes longos, em vez de assumir a primeira/última ordem ocidental.
Implemente a validação de endereço permissivo que aceita formatos de forma livre e internacionais, armazenando endereços como inseridos em vez de bloquear a criação de registro em uma discrepância de formato.
Armazene as preferências de canal de comunicação em registros de Contato e dê suporte a alternativas de omnichannel (email, SMS, telefone, correio postal, chat, voz) em vez de presumir que um único canal atinja todos os usuários.
Colete dados demográficos por meio de autoridentificação voluntária com uma opção “Preferir não responder”, armazenada separadamente em OWD privada com FLS, agregada para relatórios e monitorada por meio do Monitoramento de evento Shield.
Audite fornecedores de aprimoramento de terceiros quanto a testes de fairness, cobertura demográfica e metodologia de inferência antes de anexar dados demográficos ou comportamentais a registros.

Acessibilidade e design inclusivo

Use componentes do Lightning Design System, que são projetados para suportar a acessibilidade WCAG 2.2 AA. Lembre-se de que o Salesforce se esforça para a conformidade, mas os componentes ainda exigem o uso correto.
Valide Componentes da Web Lightning personalizados com testes do leitor de tela (por exemplo, JAWS, NVDA e VoiceOver).
Garanta que a navegação completa pelo teclado esteja presente em páginas do Lightning e sites do Experience Cloud sem dependência de mouse.
Verifique se as proporções de contraste atendem a 4,5:1 para texto normal usando ferramentas de desenvolvimento do navegador ou verificadores de contraste.
Integre a verificação de acessibilidade do Lighthouse ou sa11y em pipelines de CI/CD que falham na criação de problemas críticos.
Teste os sites do Experience Cloud usando tecnologia assistiva antes do lançamento público.
Verifique o feedback auditivo confirmando que todas as alterações dinâmicas (por exemplo, estados de erro, spinners de carregamento ou menus expandidos) são anunciadas claramente e que o conteúdo falado corresponde à intenção visual da IU.

Justiça na Automação do Salesforce

Revise as regras de atribuição e roteamento para correlação com características protegidas que podem concentrar resultados favoráveis ou desfavoráveis em grupos demográficos específicos.
Fluxo de auditoria e lógica de decisão de automação de processo para viés, documentando regras e critérios de negócios em registros de decisão do Salesforce Knowledge ou da arquitetura.
Avalie regras de validação para taxas de rejeição que afetam de maneira desproporcionada padrões ou populações de dados específicos.
Analise designs de território e segmentação para correlação demográfica, documente justificativa comercial explícita e monitore territórios subatendidos para alocação de recursos equitativa.
Assuma fluxos de alto nível e regras de atribuição (emprego, crédito, acesso a serviços) ao mesmo processo de análise de ética que os sistemas de IA e agende auditorias trimestrais dos resultados da automação estratificados por demografia.

IA Fairness e Detecção de viés

Audite os dados do Salesforce CRM quanto a lacunas de representação demográfica antes do treinamento de modelo preditivo.
Calcule a paridade demográfica, a igualdade de oportunidades e as razões de impacto diferentes por grupo demográfico antes da implementação.
Implemente avaliações de equidade como um gateway de implementação obrigatório (considere isso como equivalente a uma revisão de segurança).
Crie painéis do CRM Analytics que rastreiam métricas de equidade usando dados de decisão de modelo preditivo capturados com a Trilha de auditoria de campo.
Analise os recursos do modelo preditivo para correlação de proxy com características protegidas (por exemplo, padrões de nome de território e conta).
Agende auditorias de imparcialidade trimestrais abrangentes para todos os sistemas de IA de alto nível.

Transparência e capacidade de auditoria

Detecte explicações de previsão do Einstein Discovery em pontos de decisão em componentes do Lightning.
Configure as capturas de auditoria da Camada de Trust do Einstein usando métodos de retenção que atendem aos requisitos regulatórios.
Habilite a Trilha de auditoria de campo em todos os objetos personalizados que armazenam dados de decisão de IA para retenção de longo prazo.
Exporte dados de Monitoramento de evento para um SIEM externo – dados de Arquivo de registro de evento por meio da API e eventos de Monitoramento de evento em tempo real por meio de Eventos de plataforma – para armazenamento que exceda a retenção nativa, com controles de gravação única no lado do SIEM para evidência de adulteração.
Forneça a comunicação de confiança adequada ao usuário (por exemplo, Alta, Moderada e Baixa) em vez de probabilidades brutas.

Supervisão humana com automação do Salesforce

Configure limites de escalação baseados em confiança no Fluxo e encaminhe previsões de baixa confiança para revisão humana.
Use processos de aprovação do Salesforce para decisões de alto nível que exigem cadeias de revisão de vários estágios.
Integre o roteamento Agentforce e Omni-Channel para permitir uma escalação perfeita para agentes humanos.
Forneça uma opção persistente “Conectar-se ao agente humano” nas interfaces do Agentforce para respeitar a agência do usuário.
Exigir rastreamento de histórico de aprovação e raciocínio documentado para substituições do Agentforce capturadas em campos personalizados.

Não discriminação com controles de acesso aos dados

Habilite o OWD privado e conceda acesso adicional por meio de hierarquia de papéis e regras de compartilhamento.
Configure a Segurança em nível de campo para ocultar campos demográficos confidenciais de usuários que não precisam de acesso.
Monitore eventos de acesso em nível de objeto (exportações de relatório e consultas da API) para dados confidenciais por meio do Monitoramento de evento Shield e analise-os quanto a padrões de acesso anômalos.
Crie relatórios que analisem distribuições de regra de compartilhamento para garantir uma alocação de registro justa entre territórios.
Revise a Trilha de auditoria de configuração quanto a alterações não autorizadas de configuração de OWD, regra de compartilhamento ou FLS.

Agência do usuário e consentimento

Projete objetos de consentimento personalizados usando a Trilha de auditoria de campo para rastrear o consentimento de IA granular por caso de uso.
Integre o consentimento do Data 360 ou do Marketing Cloud com recursos de Personalização do Einstein e Agentforce.
Armazene as preferências de IA em registros de Usuário ou Contato para garantir a consistência entre canais (por exemplo, Web, celular e telefone).
Forneça recusas acessíveis em configurações de perfil e alternativas humanas por meio do roteamento do Omni-Channel.
Consulte registros de consentimento no Fluxo antes que as previsões do Einstein ou o engajamento do Agentforce afetem os usuários.

Governança de IA Ética

Documente todos os modelos preditivos de produção, incluindo métricas de equidade e estratégias de mitigação; para modelos preditivos treinados pelo cliente (como o Einstein Discovery e o Criador de previsões), também documente dados demográficos de treinamento.
Estabeleça portões de equidade obrigatórios pré-implementação que bloqueiem a implantação até que todos os critérios de equidade sejam atendidos.
Crie um Conselho de revisão de ética de IA como a autoridade de imposição para todos os aplicativos de IA de alto interesse.
Crie painéis do CRM Analytics para monitorar métricas de fairness em um ritmo agendado por meio de alertas do CRM Analytics.
Defina procedimentos de resposta a incidentes para falhas de imparcialidade e documente o processo no Salesforce Knowledge.
Agende auditorias de equidade trimestrais que analisem padrões de substituição e feedback do usuário para todos os sistemas de alta participação.

Compartilhe seu feedback sobre o Framework bem-construído.