Justicia

En arquitecturas de Salesforce, equidad significa crear soluciones que sirven a los usuarios de forma equitativa a través de interfaces accesibles, detección y mitigación de sesgos, decisiones transparentes y gobernanza ética. Las predicciones de Einstein influyen en los resultados que afectan a clientes y empleados, lo que significa que los arquitectos deben diseñar sistemas que produzcan resultados equitativos entre grupos demográficos y que también permanezcan accesibles para usuarios con discapacidades.

Salesforce proporciona funciones de plataforma creadas específicamente para la equidad, y nos esforzamos por cumplir con WCAG 2.2 AA. Cuando se utiliza correctamente, Salesforce Lightning Design System (SLDS) proporciona componentes diseñados para dar cobertura a este objetivo. Echemos un vistazo con más detalle a cada componente.

Shield Platform Encryption protege atributos confidenciales como datos demográficos, y Supervisión de eventos proporciona los seguimientos de auditoría que admiten la gestión transparente de datos.
La Capa Einstein Trust (ETL) captura un seguimiento de auditoría seguro para solicitudes de IA generativa y respuestas para fines de supervisión y cumplimiento.
Experience Cloud incluye controles de accesibilidad.
El seguimiento de auditoría de campo proporciona retención a largo plazo del historial de cambios de datos a nivel de campo, que admite la responsabilidad algorítmica cuando los datos de decisiones de IA se almacenan en campos con seguimiento.

Estas funciones ayudan a reducir los costes operativos de las prácticas de equidad de Salesforce.

En Salesforce, la equidad opera en tres dimensiones para proporcionar soluciones. El diseño inclusivo ayuda a hacer que los componentes web Lightning (LWC), las páginas Visualforce y los sitios de Experience Cloud sean completamente accesibles, con navegación de teclado sencilla, compatibilidad con lectores de pantalla y adaptaciones de diseño cognitivo. Las prácticas de equidad de IA ayudan a las predicciones Einstein a producir resultados equitativos utilizando detección de sesgos, datos de entrenamiento diversos y supervisión continua. La gobernanza proporciona los procesos y controles para mantener la equidad a medida que evolucionan los modelos y se amplían los casos de uso.

Descuidar la equidad crea un riesgo agravado. Los sitios de Experience Cloud inaccesibles pueden exponer las organizaciones a litigios de la Ley de Estadounidenses con Discapacidades (ADA) y, para agencias federales y sus contratistas, infracciones de cumplimiento de la Sección 508. Dependiendo de la clasificación de riesgos del sistema y de las nuevas leyes de rendición de cuentas algorítmicas, las predicciones de Einstein sesgadas pueden infringir los requisitos de la Ley de IA. Las decisiones dirigidas únicamente por IA automatizadas con efectos legales o similares significativos que carecen de información significativa sobre la lógica de la decisión pueden violar los derechos de información del artículo 22 y el artículo 15, apartado 1, letra h), del RGPD.

Las organizaciones que diseñan para la equidad tienden a reducir el daño previsible a los clientes, empleados y comunidades afectados por sus sistemas. Los fallos de equidad pueden causar daños materiales tangibles a las personas afectadas, incluyendo daños económicos, oportunidades denegadas, angustia emocional y refuerzo de la discriminación sistémica. La alineación reguladora tiende a seguir de servir bien a las personas afectadas.

Utilice estos principios para guiar sus decisiones de arquitectura para la equidad en la plataforma.

Diseño para patrones de accesibilidad Lightning. Cuando cree, utilice Lightning Design System y componentes web Lightning estándar diseñados para admitir la accesibilidad WCAG 2.2 AA siempre que sea posible. Cuando crea con SLDS, está aprovechando una biblioteca donde la accesibilidad es un principio de diseño principal. Los componentes SLDS se investigan para la accesibilidad del teclado y la compatibilidad con la tecnología de asistencia, y muchos incluyen una sección de accesibilidad con sugerencias del desarrollador. Si se requiere un componente personalizado, la implementación explícita de Aplicaciones de Internet enriquecidas accesibles (WAI-ARIA), HTML semántico y patrones de navegación por teclado deben validarse a través de pruebas de tecnología de asistencia.
Reduzca y supervise el sesgo con las herramientas adecuadas para cada tipo de modelo. Valide resultados de IA para resultados equitativos entre grupos demográficos antes de la implementación y de forma continua en producción. Para modelos predictivos, capture datos de decisiones a través de Einstein Discovery e instrumentación personalizada y analícelos en CRM Analytics para medir mediciones de equidad; para funciones de IA generativa y Agentforce, utilice el seguimiento de auditoría Capa de Trust de Einstein (ETL) de solicitudes y respuestas. Documente las decisiones para cumplir los requisitos de transparencia regulatoria.
Leverage Shield Platform Encryption para controles de protección de datos. Utilice Shield Platform Encryption con esquemas deterministas para atributos confidenciales que requieren consultas de coincidencia exacta mientras protege datos personales. Enrute registros de Supervisión de eventos a un sistema externo de Gestión de eventos e información de seguridad (SIEM) para admitir seguimientos de auditoría a prueba de manipulaciones, cuando el SIEM aplica almacenamiento de una sola escritura y segregación de acceso que superan los plazos de retención nativos de Salesforce para las leyes requeridas.
Diseñe flujos de trabajo de revisión para predicciones de alto riesgo. Configure procesos de aprobación y mecanismos de revisión en Salesforce Flow para garantizar que las predicciones Einstein afectando a decisiones consiguientes reciben una revisión humana apropiada. Utilice umbrales de confianza y reglas comerciales para determinar cuándo requieren validación las predicciones antes de realizar acciones.
Aplique los valores predeterminados de toda la organización (OWD) y la seguridad a nivel de campo (FLS) para la no discriminación. Arquitecte patrones de acceso a datos utilizando OWD y FLS para restringir el acceso de forma predeterminada, y solo otorgue el acceso adicional que cada función necesita utilizando reglas de colaboración. Evite otorgar a los perfiles un acceso excesivo que pueda exponer atributos confidenciales y activar la toma de decisiones discriminatoria.
Active la agencia de usuarios a través del consentimiento de plataforma. Utilice las funciones de gestión de consentimiento en Data 360 u objetos de consentimiento personalizados con Seguimiento de auditoría de campo para realizar un seguimiento del consentimiento de IA granular por caso de uso. Permita a los usuarios anular la suscripción a funciones dirigidas por IA y proporcionar alternativas humanas (cuando sea posible).

Las decisiones de arquitectura de datos determinan las poblaciones que se vuelven visibles (e invisibles) en sistemas de Salesforce. La mala calidad de los datos no es solo un problema técnico. Se convierte en un problema de equidad cuando las brechas de datos perjudican sistemáticamente a grupos demográficos específicos.

Revise los campos obligatorios para la disponibilidad de datos. Cuando los campos obligatorios asumen la disponibilidad de información que varía entre datos demográficos, la exhaustividad de los datos se convierte en discriminatoria. Los usuarios que no pueden proporcionar la información requerida se vuelven invisibles en sistemas que rechazan registros incompletos.
- Requerir direcciones de correo electrónico excluye poblaciones que no tienen acceso a Internet fiable o direcciones de correo electrónico personales.
- Requerir números de seguridad social de EE.UU. (SSN) excluye clientes internacionales e inmigrantes recientes a los que no se les emitió aún un SSN.
- Requerir direcciones de calle excluye a las poblaciones sin hogar y a los usuarios con direcciones no tradicionales.
Audite justificaciones comerciales para campos obligatorios. Para cada campo obligatorio, es importante documentar por qué la información es obligatoria en lugar de opcional. Si los procesos pueden funcionar sin ciertos datos a través de enfoques alternativos, haga que esos campos sean opcionales y diseñe sistemas para gestionar valores que faltan correctamente. Esto ayuda a garantizar que los usuarios que no pueden proporcionar dichos datos no se excluyan.

Los campos de nombre que siguen convenciones de nomenclatura occidental (Nombre, Apellidos) pueden excluir culturas con diferentes prácticas de nomenclatura.

Muchas culturas utilizan:

Nombres únicos (o monónimos) sin apellidos
Sistemas patronímicos donde el “apellido” cambia generacionalmente
Múltiples nombres o apellidos
Nombres que cambian basándose en eventos de vida o contexto social
Nombres donde “primero” y “último” son distinciones culturalmente sin sentido

Diseñe la arquitectura de nombres utilizando un campo de nombre completo único o una estructura flexible de múltiples partes que se adapte a convenciones de nomenclatura comunes. Evite realizar suposiciones sobre la ordenación de nombres, patrones de herencia o normas culturales.

Pruebe la arquitectura de nombres utilizando diversos nombres internacionales para asegurarse de que los campos de nombre aceptan:

Nombres de una sola palabra (por ejemplo, Sukarno, Cher y Teller)
Nombres largos que superan los límites de longitud de campo comunes
Nombres con diacríticos, apóstrofos, guiones y espacios
Nombres con escrituras no latinas (por ejemplo, árabe, chino, cirílico y devanagari)

Cuando la validación de nombre rechaza el nombre legítimo de un usuario, experimentan un rechazo del sistema basado en su identidad cultural.

Los servicios de validación de direcciones a menudo están optimizados para formatos de EE.UU. y Europa Occidental y con frecuencia no reconocen:

Formatos de dirección internacionales con diferente ordenación de campos
Direcciones rurales sin nombres de calle
Direcciones militares (por ejemplo, APO y FPO)
Apartados de correos y ubicaciones de entrega alternativas
Tierras tribales con sistemas de direcciones exclusivos
Países con secuencias de comandos no latinas para componentes de dirección

Cuando las validaciones de direcciones rechazan formatos de dirección no tradicionales, evitan la creación de cuentas, el envío y la entrega de servicios para usuarios cuyas direcciones no coinciden con las expectativas de la base de datos de validación.

Estas son algunas formas de diseñar validaciones de direcciones teniendo en cuenta la accesibilidad:

Implemente la validación de direcciones permisiva.
Acepte la entrada de dirección de formato libre cuando fallen las validaciones estructuradas.
Almacene direcciones a medida que las introducen los usuarios en vez de obligar a los usuarios a realizar correcciones no válidas.
Utilice la validación de direcciones para el enriquecimiento de datos y la detección de duplicaciones, no para validar el formato de direcciones.

En vez de bloquear capturas de datos por adelantado, cree la verificación de dirección en procesos de realización donde la precisión de la dirección importa de forma operativa.

Los supuestos de acceso universal para canales de comunicación específicos excluyen poblaciones con diferentes preferencias o acceso de tecnología.

La comunicación de solo correo electrónico excluye:

Usuarios sin acceso a Internet fiable
Personas de edad avanzada que se sienten menos cómodas utilizando el correo electrónico
Usuarios en regiones donde SMS o aplicaciones de mensajería son el método de comunicación principal

La comunicación solo telefónica excluye:

Usuarios sordos y con dificultades auditivas
Usuarios sin acceso telefónico o aquellos que utilizan teléfonos compartidos

Diseñe una arquitectura de comunicación omnicanal que permita a los usuarios controlar las preferencias de canal. Almacene métodos de comunicación preferidos en registros Contacto y respete de forma coherente las preferencias en todos los sistemas de comunicación salientes. Proporcione una variedad de alternativas de comunicación en vez de asumir que los métodos de canal único funcionan de forma universal.

La recopilación de datos demográficos para la supervisión de la equidad requiere una arquitectura cuidadosa para evitar el uso indebido.

La recopilación y el procesamiento de datos demográficos depende de la jurisdicción y está legalmente restringida (en la UE, el artículo 9 del RGPD los trata como datos de categoría especial que requieren una base legal específica; en EE.UU., la supervisión de sesgos normalmente se basa en la autoidentificación voluntaria de EEO). Donde existe una base legal, las organizaciones utilizan datos demográficos para:

Supervisar mediciones de equidad estratificadas por grupos protegidos
Detectar sesgos en sistemas de automatización e IA
Demostrar cumplimiento normativo con requisitos antidiscriminatorios

La recopilación de datos demográficos crea ciertos riesgos:

Los datos pueden utilizarse con fines discriminatorios si fallan los controles de acceso
Los usuarios pueden desconfiar de los métodos de recopilación y proporcionar datos imprecisos
La recopilación puede sentirse invasiva o discriminatoria

Arquitecte la autoidentificación voluntaria y diseñe la recopilación de datos demográficos utilizando información que sea:

Explicado claramente con un propósito transparente (por ejemplo, supervisión de equidad o creación de informes de cumplimiento)
Voluntario e incluye una opción “Prefiere no responder” que está siempre disponible
Separado de datos operativos con FLS estricto para evitar acceso inapropiado
Agregado para creación de informes y análisis y no vinculado a decisiones individuales
Supervisado a través de Supervisión de eventos Shield para auditoría de patrón de acceso

Es importante documentar en políticas de privacidad exactamente cómo se utilizarán y no se utilizarán los datos demográficos. Violar la Trust de los usuarios a través del uso de datos no revelados puede dañar gravemente la credibilidad, de la que puede ser difícil recuperarse.

El enriquecimiento de datos de terceros que anexa datos demográficos, firmográficos o de comportamiento a registros de Salesforce puede introducir sesgos a través de:

Inferencias imprecisas basadas en estereotipos
Cobertura incompleta con brechas que se correlacionan con datos demográficos
Algoritmos propios que utilizan propiedades de equidad desconocidas
Datos originados desde registros históricos sesgados

Antes de implementar servicios de enriquecimiento de datos, es importante auditar:

Pruebas de equidad de proveedores y prácticas de mitigación de sesgos
Precisión y cobertura de datos entre grupos demográficos
Metodologías y funciones de inferencia que se utilizan para crear predicciones
Restricciones de uso de datos contractuales y políticas de retención

Tenga en cuenta que una vez que los datos externos entran en su organización de Salesforce pueden afectar a las decisiones, creando un sesgo introducido por el proveedor que también se refleja como un sesgo en su organización.

En contextos de Salesforce, la accesibilidad hace referencia a la arquitectura de componentes web Lightning, páginas Visualforce y sitios de Experience Cloud que funcionan para usuarios con discapacidades. Los componentes Lightning estándar proporcionan accesibilidad de línea base cuando se utilizan correctamente; sin embargo, el desarrollo personalizado y la configuración de Experience Cloud requieren una implementación de accesibilidad explícita.

Los componentes del sistema Lightning Design están diseñados para admitir la conformidad WCAG 2.2 AA cuando se utilizan según lo diseñado. Salesforce se esfuerza por lograr (pero no certifica) la conformidad completa. Desviarse de los patrones SLDS o crear componentes personalizados sin tener en cuenta la accesibilidad crea barreras para los usuarios con discapacidades.

Los componentes web Lightning estándar proporcionan accesibilidad integrada. Los componentes como Lightning input, Lightning Combobox, Lightning Datatable y Lightning Card incluyen automáticamente atributos ARIA apropiados, asociaciones de etiquetas, navegación por teclado y gestión de enfoque. Cuando sea posible, utilice componentes estándar en vez de crear alternativas personalizadas con un aspecto similar pero que podrían carecer de la infraestructura de accesibilidad apropiada.

Utilice HTML semántico en componentes web Lightning personalizados. Cuando cree componentes personalizados, utilice elementos HTML semánticos (
,
,
,
,
,
) en vez de componentes
anidados de forma confusa. Los lectores de pantalla utilizan la estructura semántica para transmitir la organización de la página y activar la navegación de puntos de referencia. Evite el uso de marcas puramente visuales que quitan significado a la jerarquía de contenido.
Implemente ARIA en componentes personalizados. Aplique puntos de referencia, funciones y propiedades de ARIA cuando HTML semántico no pueda transmitir el comportamiento de la interfaz. Las actualizaciones de contenido dinámico requieren regiones en vivo de aria que anuncian cambios en lectores de pantalla. Los componentes interactivos personalizados necesitan definiciones de funciones explícitas que coincidan con su comportamiento. Los componentes base Lightning gestionan ARIA automáticamente; sin embargo, los componentes personalizados requieren validación manual de ARIA a través de pruebas de lector de pantalla.
Prueba con tecnología de asistencia: Valide componentes Lightning utilizando lectores de pantalla reales (por ejemplo, JAWS y NVDA para Windows, VoiceOver para macOS e iOS y TalkBack para Android). Basándose en el estudio a gran escala de Deque, las herramientas automatizadas como Axe Core capturan aproximadamente el 57% de los problemas de accesibilidad por volumen. Los problemas restantes requieren pruebas manuales con tecnología de asistencia por personas que comprenden los patrones de navegación del lector de pantalla.
Utilice la gestión de enfoque en flujos Lightning. Cuando los modales se abren, se carga contenido dinámico o los usuarios completan flujos de múltiples pasos, debe gestionar el enfoque de forma programática para guiar a los usuarios del teclado a nuevo contenido. Los componentes modal y emergente Lightning proporcionan una gestión de enfoque básica, pero los flujos complejos necesitan una lógica de enfoque explícita para mover el enfoque de forma apropiada a medida que cambia el contenido.

Los sitios de Experience Cloud sirven a usuarios externos, incluyendo clientes, socios y audiencias públicas, que requieren un diseño accesible que podría necesitar cumplir los requisitos de la ADA, la Sección 508 y/o la Ley de accesibilidad (dependiendo de la jurisdicción, la audiencia y el tipo de organización).

Utilice plantillas accesibles. Las plantillas de Experience Cloud creadas utilizando Lightning Web Runtime (LWR) incluyen accesibilidad de línea base. Las plantillas estándar como Portal de cuentas de clientes y Centro de ayuda proporcionan bases de WCAG 2.2 AA cuando se configuran correctamente. Las plantillas personalizadas requieren una implementación de accesibilidad explícita, incluyendo marcado semántico, navegación por teclado y compatibilidad con lectores de pantalla.
Verifique el cumplimiento de WCAG en temas. Los temas personalizados y los sitios con marca requieren validación de contraste de color. La configuración Tema de Experience Builder controla los colores, la tipografía y el espaciado. Asegúrese de que todo el texto cumple un contraste de 4,5:1 para texto normal (menos de 18 puntos para normal o menos de 14 puntos para negrita) y 3:1 para texto grande (18 puntos o más para normal o 14 puntos o más para negrita) y componentes de la interfaz de usuario. Utilice herramientas de desarrollador de navegador o comprobadores de contraste en línea para validar el cumplimiento. Pruebe con zoom de navegador al 200% para garantizar que el texto se amplía sin perder contenido o funcionalidad.
Utilice la navegación del teclado en menús de navegación. Los componentes de navegación de Experience Cloud deben admitir el funcionamiento solo del teclado sin dependencia del ratón. Los usuarios deben navegar dentro y fuera de menús desplegables, mega menús y navegación de volantes utilizando las teclas Tabulación, Intro, Escapar y Flecha sin trampas de enfoque. Pruebe todas las rutas de navegación utilizando solo el teclado para validar la accesibilidad.
Active la accesibilidad de formularios en Experience Cloud. Asocie etiquetas explícitamente con todas las entradas de formulario utilizando elementos de etiqueta apropiados o aria-labeledby. Por sí solo, el texto del marcador de posición falla los requisitos de accesibilidad porque el texto desaparece en cuanto comienza la entrada de datos, lo que deja a los usuarios lectores de pantalla sin contexto suficiente y persistente. Los componentes de entrada Lightning proporcionan asociación de etiquetas integrada cuando se configuran utilizando los atributos de etiqueta requeridos. Los formularios Visualforce personalizados requieren una asociación explícita etiqueta-entrada.
Pruebe sitios de Experience Cloud utilizando tecnología de asistencia. Antes de iniciar sitios de Experience Cloud de cara al público, debe realizar pruebas de accesibilidad integrales utilizando lectores de pantalla, navegación solo por teclado y zoom de navegador. Es importante incluir usuarios con discapacidades en pruebas de capacidad de uso para revelar barreras prácticas de experiencia vivida que las revisiones de expertos a menudo pueden perder. Probar solo páginas Lightning internas sin validar la accesibilidad de Experience Cloud externa deja los sitios de cara al público vulnerables a quejas y litigios de accesibilidad.
Utilice texto alternativo para imágenes e iconos. Todas las imágenes informativas, iconos y contenido gráfico en Experience Cloud requieren texto alternativo. Las imágenes decorativas utilizan texto alternativo vacío (alt=""), que permite a los lectores de pantalla omitirlas. Las imágenes informativas proporcionan texto alternativo significativo que describe contenido y función. Cuando escriba texto alternativo para iconos, céntrese en la acción o el propósito del icono en vez de su apariencia visual (por ejemplo, en vez de describir un icono de lupa como “lupa”, el texto alternativo debe indicar su utilidad funcional, como “Sitio de búsqueda”). Al gestionar imágenes, el CMS debe solicitar a los autores de contenido que introduzcan texto alternativo o marcar explícitamente la imagen como decorativa (que establece alt=""). Esto garantiza la accesibilidad evitando que falte texto alternativo y descripciones forzadas para imágenes estéticas.

La accesibilidad completa del teclado significa que los usuarios pueden acceder a todas las funciones utilizando su teclado sin requerir la interacción del ratón o táctil en ningún punto.

Utilice el orden de enfoque lógico en páginas Lightning. Asegúrese de que el orden de enfoque sigue el formato visual y el flujo de interacción. Cuando los usuarios pulsan Tabulación, el enfoque visual debe moverse por elementos interactivos en el orden que esperan los usuarios basándose en el diseño visual. Lightning App Builder y Experience Builder establecen el orden de enfoque basándose en la colocación de componentes. Los componentes personalizados requieren una gestión de índices de tabulación explícita para garantizar una progresión de enfoque lógica.
Utilice indicadores de enfoque visibles para cumplir los requisitos de contraste. Lightning Design System proporciona estilos de enfoque para cumplir los requisitos de WCAG para la mayoría de los componentes. Es posible que los componentes personalizados necesiten indicadores de enfoque mejorados para cumplir el requisito de contraste 3:1 frente al contenido circundante. Los indicadores de enfoque deben ser claramente visibles para permitir a los usuarios con baja visión navegar a través del teclado. Nunca elimine indicadores de enfoque con CSS (esquema: ninguno) sin proporcionar un estilo de enfoque visible alternativo.
Utilice mitigaciones de trampas de teclado en modos y superposiciones. Los diálogos de modal deben atrapar el enfoque dentro del modal mientras está abierto, lo que evita que los usuarios del teclado alcancen contenido en segundo plano oculto. La trampa de enfoque debe liberarse al cerrar el modal y devolver el enfoque al elemento desencadenador. El contenido integrado, incluyendo iframes y widgets externos, no debe capturar permanentemente el enfoque del teclado sin un mecanismo de escape.
Utilice teclas de acceso directo sin conflictos. Lightning proporciona accesos directos del teclado estándar que se documentan en la Ayuda de Salesforce. Los accesos directos del teclado personalizados deben diseñarse para evitar conflictos con los controles estándar del navegador y los comandos de navegación del lector de pantalla. En alineación con los criterios de éxito de WCAG, los accesos directos de un solo carácter (por ejemplo, pulsando una sola letra o signo de puntuación) no deben desencadenar acciones globales. Deben restringir la activación a cuando un componente específico tiene enfoque activo o proporcionar a los usuarios una forma de desactivar o volver a asignar el acceso directo por completo.

Construya la validación de accesibilidad en oportunidades en curso de CI/CD para encontrar problemas estructurales automáticamente en cada implementación en vez de tratar la accesibilidad como auditorías manuales periódicas.

Utilice sa11y para pruebas de accesibilidad de componentes web Lightning. Las bibliotecas sa11y de Salesforce (el paquete @sa11y/jest) incluyen el motor de accesibilidad principal para agregar un comparador toBeAccessible() para pruebas de unidad de Jest. Redacte pruebas de accesibilidad que validen el uso apropiado de ARIA, las asociaciones de etiquetas, los índices de contraste y el marcado semántico automáticamente como parte de las pruebas de unidad. Configure compilaciones para fallar cuando se detectan problemas de accesibilidad críticos.
Utilice Lighthouse CI para Experience Cloud. Google Lighthouse audita la accesibilidad de páginas web, incluyendo sitios de Experience Cloud. Integre Lighthouse CI en oportunidades en curso de implementación para explorar páginas de cara al público en busca de problemas de accesibilidad. Configure umbrales de puntuación para requerir puntuaciones de accesibilidad mínimas antes de las aprobaciones de implementación.
Utilice el Agente de accesibilidad, disponible a través del paquete Salesforce DX MCP. En entornos compatibles con MCP o en Agentforce Vibes, revisa el código con respecto a estándares WCAG, aflora soluciones dirigidas y puede generar una solicitud de extracción para que un ingeniero revise, valide y combine.

El sesgo ha existido en la automatización determinista de Salesforce mucho antes de que la IA entrara en escena. Las reglas de asignación, las decisiones de flujo, las reglas de validación y el diseño de territorios codifican el juicio humano que puede perpetuar la discriminación. A diferencia del sesgo de IA, que los arquitectos examinan exhaustivamente, el sesgo de automatización a menudo pasa sin examinar porque la lógica determinista se siente objetiva.

Siga las reglas de asignación de candidatos y casos. Distribuya el trabajo entre equipos de ventas y servicio. Cuando la lógica de asignación utiliza criterios que se correlacionan con características protegidas, la automatización crea disparidades sistemáticas en la calidad del servicio y el acceso a las oportunidades.
Las reglas de asignación que utilizan territorio, código postal o características de cuenta pueden enrutar oportunidades de alto valor de forma desproporcionada a equipos específicos mientras enrutan trabajo de menor valor a otro lugar. Si los límites de territorios se correlacionan con datos demográficos de clientes y estructuras de compensación que varían entre territorios, la automatización de asignaciones crea discriminación económica.
Resultados de reglas de asignación de auditoría regularmente. Calcule distribuciones de asignaciones entre territorios y equipos estratificados por datos demográficos de clientes. Si las cuentas de empresa están concentradas en territorios específicos mientras las cuentas de PYME están distribuidas en otro lugar (y si los territorios de empresa reciben mejores compensaciones o recursos), las reglas de asignación pueden producir resultados no equitativos que garanticen una revisión de equidad.
Revise el enrutamiento basado en habilidades de OmniCanal. Esto puede afectar a la calidad del servicio entre poblaciones de clientes. Si la lógica de enrutamiento asume implícitamente que ciertas habilidades se correlacionan con el valor del cliente o la complejidad del problema, los clientes pueden recibir diferentes resultados de servicio basándose en proxys demográficos.

Es importante supervisar el tiempo medio de gestión, las resoluciones de primer contacto y la satisfacción del cliente entre rutas de enrutamiento. Las disparidades pueden indicar si ciertos segmentos de clientes reciben sistemáticamente agentes con menos experiencia o menos opciones de enrutamiento.

Revise las automatizaciones de Salesforce Flow. Tomar decisiones de aprobación, determinaciones de aptitud o concesiones de acceso pueden codificar lógica discriminatoria a través de reglas comerciales aparentemente inocuas. Algunos flujos crean discriminación indirecta cuando los criterios se correlacionan con características protegidas.
Revise decisiones de flujos teniendo en cuenta la equidad. Para cada flujo que toma decisiones consecuentes que afectan a los usuarios, es importante preguntar:
¿Qué sucede con los usuarios que no se ajustan al perfil de cliente habitual?
¿Se correlacionan los criterios de decisión con las características demográficas?
¿Se gestionan las excepciones y los casos extremos de forma equitativa o perjudican sistemáticamente a grupos específicos?

Es importante documentar la lógica de decisión de flujo y las consideraciones de equidad en registros de decisiones de arquitectura, y someter flujos de alto riesgo a las mismas políticas de revisión ética que los sistemas de IA.

Revise las reglas de validación. Evitar la entrada de datos puede excluir datos válidos de usuarios cuya información no coincide con los supuestos del sistema. Las reglas de validación que rechazan datos legítimos crean poblaciones invisibles. Los usuarios cuyos datos no se ajustan a patrones de validación no pueden implicarse con ciertos sistemas. Los fallos de validación a menudo no se notifican porque los usuarios abandonan sus solicitudes en vez de reportar errores técnicos. Estos son varios patrones de sesgo de validación comunes:
Las validaciones de nombres que requieren caracteres latinos pueden excluir nombres con diacríticos y escrituras no latinas.
Las validaciones de números de teléfono a menudo utilizan formatos de EE.UU./Oeste, lo que excluye números internacionales y métodos de comunicación alternativos.
Las validaciones de direcciones no reconocen direcciones no estándar (por ejemplo, apartados de correos, rutas rurales, tierras tribales y formatos internacionales).
Las validaciones de correo electrónico que requieren direcciones de correo electrónico personales pueden crear una desventaja para los usuarios que no tienen acceso de correo electrónico personal.
Pruebe reglas de validación utilizando datos diversos. Incluya direcciones internacionales, nombres no occidentales y formatos de teléfono alternativos en pruebas de validación. Cuando la validación rechaza datos legítimos, debe ampliar la lógica de validación para evitar excluir usuarios válidos.

Revise diseños de territorios de ventas. Las estrategias de segmentación de clientes y los diseños de territorios de ventas determinan la asignación de recursos entre poblaciones de clientes. Cuando los límites de territorio o los criterios de segmentación se correlacionan con datos demográficos que dan como resultado una asignación de recursos desigual, esa asignación puede producir resultados discriminatorios. Los diseños de territorios que utilizan límites geográficos a menudo se correlacionan con datos demográficos raciales, étnicos y económicos debido a patrones de segregación residencial. Si la compensación, los niveles de plantilla o las inversiones de recursos varían entre territorios, la geografía puede convertirse en un mecanismo para la asignación discriminatoria de recursos.
Analice datos demográficos de territorios antes de finalizar los diseños. Asigne datos demográficos de clientes entre límites de territorio propuestos. Cuando surgen concentraciones demográficas, evalúe si la asignación de recursos es equitativa en todos los territorios independientemente de la composición demográfica. Si la justificación comercial requiere diferentes niveles de recursos entre territorios (por ejemplo, madurez del mercado, intensidad competitiva y potencial de crecimiento), documente esa justificación explícitamente y supervise los resultados para garantizar que los territorios desatendidos reciben oportunidades de inversión adecuadas para evitar disparidades arraigadas.

Mantenga la transparencia en la lógica de automatización. Documente reglas comerciales, criterios de asignación y lógica de decisión de flujo en Salesforce Knowledge o registros de decisiones de arquitectura. La automatización transparente permite revisar la equidad de una forma que evita la lógica oculta.
Resultados de auditoría regularmente. Programe auditorías trimestrales para analizar resultados de automatización que pueden estratificarse por datos demográficos de clientes. Tenga en cuenta que las disparidades desencadenan investigaciones y posibles soluciones.
Es importante realizar un seguimiento de:
Distribuciones de asignaciones entre equipos y territorios
Índices de aprobación para flujos que toman decisiones de aptitud
Índices de rechazo de reglas de validación por patrón de datos
Rendimiento de territorios y asignación de recursos
Revise la automatización de alto riesgo a través de una lente ética. Someta los flujos y las reglas de asignación que afectan al empleo, el crédito, el acceso a servicios u otros resultados consiguientes al mismo proceso de revisión ética que los sistemas de IA. El sesgo de automatización necesita el mismo nivel de escrutinio que el sesgo algorítmico.

En Salesforce, la equidad de la IA se centra en utilizar Einstein para validar que las predicciones producen resultados equitativos en todos los grupos demográficos. Einstein Discovery e instrumentación personalizada capturan datos de decisiones de modelo predictivo que activan la detección de sesgos. Los paneles de CRM Analytics realizan un seguimiento de mediciones de equidad. Seguimiento de auditoría de campo y Supervisión de eventos capturan datos de decisiones para la rendición de cuentas algorítmica.

Las predicciones Einstein que afectan a decisiones consiguientes (por ejemplo, puntuación de candidatos, previsiones de oportunidades y segmentación de clientes) requieren evaluaciones de equidad previas a la implementación que funcionan como un paso equivalente obligatorio (similar a revisiones de seguridad).

Analice todas las funciones del modelo predictivo para la correlación con características protegidas utilizando métodos estadísticos. Elimine o transforme funciones proxy después de evaluar si su valor predictivo justifica la inclusión a pesar de los efectos proxy.

Audite datos de Salesforce CRM antes de la formación. Las organizaciones de Salesforce contienen décadas de decisiones humanas basadas en prácticas históricas. Si los equipos de ventas anteriores priorizaron ciertos datos demográficos, Einstein Lead Scoring aprende esos patrones y los perpetúa. Antes de entrenar modelos predictivos en datos históricos, es importante auditar esos datos para brechas de representación demográfica e incoherencias de medición entre segmentos de clientes.
Calcule mediciones de equidad entre grupos demográficos. Antes de implementar modelos predictivos, es importante calcular la paridad demográfica, la igualdad de oportunidades y los índices de impacto dispares entre grupos protegidos, donde tiene una base legal para recopilar y procesar los datos demográficos requeridos. Si Puntuación de candidatos Einstein asigna puntuaciones altas al segmento A el 50% de las veces pero solo el 30% de las veces al segmento B, una proporción del 60% falla la regla de cuatro quintas partes (80%) y requiere investigación y mitigación. La cifra del 80% es un desencadenador de selección, no una partida de aprobación/reprobación legal: la regla de las cuatro quintas partes es una regla general federal de EE.UU. para la selección de empleo, y despejarla no es un puerto seguro: una disparidad estadísticamente significativa puede garantizar el escrutinio en índices más altos, y otros regímenes miden el impacto adverso de forma diferente (la ley de discriminación indirecta de la UE, por ejemplo, cambia si una práctica crea una “desventaja particular”, sin umbral fijo). Calibrar umbrales de investigación en las jurisdicciones y casos de uso en los que opera.
Capture datos de decisiones de modelo predictivo para la detección de sesgos. Para detectar sesgos en modelos predictivos como Puntuación de candidatos y Puntuación de oportunidades, capture datos de decisiones mediante Einstein Discovery e instrumentación personalizada: almacene entradas, salidas y versiones de modelo de predicción en campos con seguimiento y active Seguimiento de auditoría de campo. Analice esos datos en CRM Analytics para realizar un seguimiento de patrones de decisión entre grupos demográficos a lo largo del tiempo y crear paneles que alerten cuando las mediciones de paridad demográfica o igualdad de oportunidades se desplazan más allá de umbrales aceptables.
Detecte funciones proxy en modelos predictivos. Las funciones que se correlacionan con características protegidas activan la discriminación indirecta incluso cuando las características protegidas se excluyen de los modelos.
- Los datos de Salesforce contienen habitualmente funciones proxy:
Territorio o código postal (proxies por raza, etnia e ingresos)
Patrones de nombre de cuenta (proxies para tamaño de organización y datos demográficos del sector)
Tiempo de actividad de comunicación (proxies para zonas horarias, religión y responsabilidades de cuidado)
Tipo de dispositivo o navegador desde datos de actividad (proxies para nivel de ingresos)

Cuando se detecta sesgo en predicciones Einstein, debe aplicar mitigación en la etapa de canalización apropiada (basándose en la causa raíz y las restricciones técnicas).

Equilibre los datos antes del entrenamiento del modelo. Vuelva a equilibrar los datos de Salesforce CRM mediante el sobremuestreo de segmentos de clientes infrarrepresentados o el submuestreo de segmentos sobrerrepresentados antes de entrenar modelos predictivos. Utilice Data 360 para agregar datos entre múltiples organizaciones para garantizar conjuntos de entrenamiento diversos. La generación de datos sintéticos puede complementar segmentos dispersos preservando la privacidad a través de técnicas de privacidad diferenciales.
Elimine proxys en ingeniería de funciones. Cuando se identifican funciones proxy, sustitúyalas por funciones alternativas que proporcionan potencia predictiva sin correlación demográfica. Si el territorio sirve como proxy demográfico, considere la clasificación del sector o el tamaño de la empresa como alternativas. Si los patrones de nombre de cuenta se correlacionan con datos demográficos, utilice atributos firmográficos en su lugar.
Ajuste los umbrales durante el postprocesamiento. Ajuste los umbrales de decisión por segmento demográfico para igualar los índices de resultados después de los modelos de formación. Para decisiones relacionadas con el empleo, esto está prohibido de plano: El título VII (Ley de derechos civiles de 1991) prohíbe ajustar las puntuaciones o utilizar puntuaciones de corte diferentes por clase protegida, y ninguna justificación documentada hace que la práctica sea legal. Donde no está prohibido, documente ajustes de umbral con justificación comercial para un trato diferencial cuando las predicciones informan decisiones automatizadas.
Entrene modelos periódicamente utilizando datos actualizados. Programe el reciclaje del modelo trimestralmente (o cuando se produzcan turnos de distribución de datos significativos). El reentrenamiento en datos actualizados captura patrones de sesgo emergentes y corrige cualquier desviación de las líneas base de equidad originales. Revalide las mediciones de equidad en cada versión de modelo antes de la implementación de producción para garantizar que el reciclaje no introdujo nuevos sesgos.

La Capa Einstein Trust captura solicitudes, respuestas y señales Trust para funciones de IA generativa y Agentforce, admitiendo transparencia y cumplimiento normativo para IA generativa. Para modelos predictivos, la transparencia y el linaje de decisiones proceden de Einstein Discovery y Model Manager, que requieren instrumentación personalizada para retener datos de auditoría.

Cree capacidad de explicación en soluciones Einstein desde la arquitectura inicial en vez de actualizar explicaciones en sistemas opacos después de la implementación.

Aflore explicaciones de Einstein Discovery en puntos de decisión. Einstein Discovery proporciona explicaciones de factores de predicción que muestran qué variables influyeron más en predicciones específicas con impacto direccional. Arquitecte componentes Lightning que muestran estas explicaciones a los usuarios en el punto de decisión en vez de requerir navegación para separar paneles de CRM Analytics. Cuando las decisiones afectan a los usuarios, necesitan transparencia, no mediciones de rendimiento de modelo abstractas.
Explicaciones de capas para diferentes audiencias. Proporcione una profundidad de explicación apropiada para cada audiencia:
Usuarios comerciales: “Este candidato obtuvo una puntuación alta porque los ingresos anuales superan 1 millón de dólares y la puntuación de implicación está en el 10% más alto”.
Usuarios técnicos: Proporcione a una tarjeta de modelo Einstein Discovery ponderaciones de funciones, características de datos de entrenamiento y mediciones de validación.
Clientes: “Esta recomendación se basa en sus compras recientes y clientes con preferencias similares.”
Auditores: Proporcione linaje de decisiones desde Einstein Discovery y Gestor de modelos (versión de modelo, valores de entrada y los factores que impulsaron la predicción) capturados a través de instrumentación personalizada.
Comunique la confianza adecuadamente. Muestre confianza de predicción en términos apropiados para el usuario y evite puntuaciones de probabilidad sin procesar que los usuarios puedan interpretar erróneamente. En vez de mostrar “73% de confianza”, comunique esto utilizando categorías (por ejemplo, Alta confianza, Moderada confianza y Necesita revisión) con explicaciones de lo que significa cada nivel de confianza para la fiabilidad de las decisiones, así como qué revisiones adicionales se producirán.

Mantenga seguimientos de auditoría completos e inmutables que admiten la rendición de cuentas, la depuración y el cumplimiento normativo para todas las decisiones dirigidas por la IA que afectan a los usuarios.

Capture datos de auditoría predictiva con las herramientas correctas. Almacene datos de auditoría de modelo predictivo (entradas, salidas y versiones de modelo de predicción) en campos con seguimiento con Seguimiento de auditoría de campo activado. Arquitecte políticas de retención de datos para cumplir los requisitos normativos, que varían por sector y jurisdicción:
- Las reglas de servicios financieros establecen la retención por regulación (por ejemplo, la regla FINRA 4511(b) establece un periodo de retención predeterminado de seis años para registros que no tienen un periodo de retención especificado bajo las reglas FINRA o la regla SEA 17a-4).
- La retención de cuidados médicos también se rige por reglas específicas (por ejemplo, la HIPAA requiere un mínimo de seis años para la documentación de cumplimiento; la retención de registros médicos se establece por leyes estatales individuales) en vez de mandatos generales de retención indefinida.
Analice datos de decisiones de modelo predictivo con CRM Analytics. Cree paneles de CRM Analytics sobre los datos de decisiones de modelo predictivo que captura (entradas, salidas y versiones de modelo de predicción en campos con seguimiento) para analizar patrones de decisión, mediciones de equidad y rendimiento de modelo a lo largo del tiempo. Cree lentes que muestran distribuciones de predicciones por nivel de confianza, segmento demográfico y tipo de resultado. Configure historias de Einstein Discovery que identifican patrones anómalos que requieren investigación adicional.
Utilice el Seguimiento de auditoría de campo para la retención a largo plazo. El historial de campos estándar realiza un seguimiento de los cambios durante 18 meses en la interfaz de usuario y hasta 24 meses a través de la API. El seguimiento de auditoría de campo le permite mantener el historial de campos indefinidamente para objetos personalizados que almacenan datos de decisiones de IA. Archiva el historial después de hasta 18 meses de forma predeterminada, luego retiene los datos archivados hasta que los elimine. Active Seguimiento de auditoría de campo en objetos que contienen registros de consentimiento, decisiones de sustitución e informes de sesgo para cumplir los requisitos de retención reguladores.
Utilice Supervisión de eventos para interacciones Agentforce. Supervisión de eventos captura eventos a nivel de invocación para Agentforce, como cuando se ejecutan acciones y flujos. Exporte datos de Supervisión de eventos a un SIEM externo (datos de Archivo de registro de eventos estándar a través de la API y el subconjunto de eventos Supervisión de eventos en tiempo real a través de Eventos de plataforma) para el almacenamiento que supera el plazo de retención nativo de Salesforce. La evidencia de manipulación depende del comportamiento SIEM concreto que aplica el almacenamiento de una sola escritura y la segregación de acceso. Configure consultas SIEM para detectar patrones de sesgo entre grandes volúmenes de interacciones Agentforce.
Auditar conversaciones Agentforce con la Einstein Trust Layer. La Capa Einstein Trust captura el seguimiento de auditoría de solicitudes de conversación y respuestas de Agentforce, almacenadas en Data 360, proporcionando el registro a nivel de transcripción para transparencia y cumplimiento normativo.

Echemos un vistazo con más detalle a las funciones de transparencia de Arquitecto que están posicionadas para el cumplimiento de leyes de IA actuales y emergentes en múltiples jurisdicciones.

Requisitos de transparencia de la Ley de IA de la UE. Los sistemas de IA de alto riesgo en virtud de la Ley de IA de la UE requieren documentación de transparencia, documentación técnica, capacidades de supervisión humana y mediciones de precisión/equidad. Los seguimientos de auditoría de Capa Einstein Trust y las tarjetas de modelo Einstein Discovery proporcionan bases para estos requisitos. Documente datos demográficos de entrenamiento de modelo, enfoques de validación y limitaciones conocidas en registros de decisiones de arquitectura.
Derecho de explicación del RGPD. El RGPD otorga a los titulares de datos de la UE el derecho a información significativa sobre la lógica de una decisión cuando esa decisión se basa únicamente en el procesamiento automatizado y produce efectos legales o similares. Este derecho se deriva del artículo 15, apartado 1, letra h), y del artículo 22, apartado 3, leídos conjuntamente con el considerando 71, y fue aclarado por el TJUE en el asunto Dun & Bradstreet (2025). Diseñe sistemas que generen explicaciones coherentes bajo demanda para cualquier decisión histórica en plazos de tiempo de solicitud de acceso de titulares de datos, que varían (dependiendo de la jurisdicción) entre 15 y 45 días. Los datos de decisiones de modelo predictivo que captura (entradas, salidas, versiones de modelo y factores de explicación Einstein Discovery) le permiten reconstruir explicaciones cuando se almacenan con suficiente retención.
Leyes de responsabilidad algorítmica. Las leyes de rendición de cuentas algorítmicas a nivel estatal de EE.UU. requieren cada vez más evaluaciones de impacto y creación de informes de transparencia para sistemas de decisiones automatizados. Los datos de decisiones de modelo predictivo que captura y los paneles de supervisión de equidad de CRM Analytics proporcionan las bases de datos para estos informes. Realice evaluaciones de impacto algorítmicas antes de implementar la IA resultante como cumplimiento proactivo en vez de como una respuesta reactiva a consultas reguladoras.

Los OWD, las reglas de colaboración y la seguridad a nivel de campo (FLS) dan forma a los patrones de acceso a los datos que determinan qué información pueden revisar y utilizar los usuarios para tomar decisiones. La configuración apropiada evita el acceso discriminatorio a atributos confidenciales mientras garantiza un servicio equitativo.

Diseñe OWD y Seguridad a nivel de campo para restringir el acceso de forma predeterminada. Para reglas de colaboración, utilice el principio de menor privilegio (PoLP) para otorgar solo el acceso adicional que cada función necesita legítimamente, lo que evita la toma de decisiones discriminatorias basadas en características protegidas.

Active OWD restrictivo como predeterminado. Utilice OWD privados para objetos que contienen datos confidenciales de clientes y otorgue acceso por jerarquía de funciones y reglas de colaboración. Los OWD de Lectura/Escritura pública interrumpen la restricción del acceso más adelante (ajustar el valor predeterminado desencadena un nuevo cálculo de colaboración y entra en vigor solo después de completarse) en vez de imposible. Los OWD privados con subvenciones de colaboración explícitas crean patrones de acceso auditables que admiten el cumplimiento de la no discriminación.
Aplique Seguridad a nivel de campo para atributos confidenciales. Oculte campos confidenciales que contienen características protegidas (por ejemplo, origen étnico, religión y estado de discapacidad) a usuarios que no requieren acceso para fines comerciales legítimos. Configure FLS para eliminar el acceso de lectura para campos confidenciales en la mayoría de los perfiles. Cuando estos campos son obligatorios para fines específicos (por ejemplo, creación de informes de diversidad y ajustes razonables), otorgue acceso mínimo utilizando conjuntos de permisos con justificación comercial documentada.
Diseñe reglas de asignación y colaboración para resultados equitativos. Utilice reglas de asignación, colas y enrutamiento de OmniCanal para distribuir el trabajo de forma equitativa entre territorios, equipos y agentes de servicio. Evite la colaboración manual que concentra oportunidades de alto valor o clientes con grupos de usuarios específicos sin justificación comercial documentada. Configure reglas de colaboración automáticas basándose en criterios objetivos (por ejemplo, sector, geografía y línea de productos) en vez de la discreción subjetiva del gestor, que puede activar el sesgo.
Proporcione conjuntos de permisos para acceso temporal. Otorgue acceso temporal a datos confidenciales a través de conjuntos de permisos en vez de modificar perfiles, lo que afecta a todos los usuarios de forma permanente. Cuando los usuarios necesitan acceder a datos demográficos para proyectos específicos (por ejemplo, análisis de diversidad y solicitudes de alojamiento), asigne conjuntos de permisos con vencimientos documentados. Los flujos programados pueden revocar conjuntos de permisos automáticamente después de periodos definidos.

Utilice Supervisión de eventos Shield e informes para detectar patrones de acceso a datos que indican posible discriminación o sesgo en el uso de datos.

Utilice Supervisión de eventos Shield para auditar el acceso a datos confidenciales. Utilice Supervisión de eventos para capturar eventos de acceso a nivel de objeto (exportaciones de informes, consultas de API y vistas de página) en objetos que contienen características protegidas o atributos confidenciales. Configure consultas sobre estos eventos para aflorar quién accedió al objeto, cuándo y en qué contexto, y tratar patrones anómalos (por ejemplo, picos repentinos y acceso de usuarios inesperados) como desencadenadores para la investigación.
Informe sobre distribuciones de reglas de colaboración. Cree informes que analizan cómo se distribuyen los registros entre usuarios, equipos y territorios. Calcule estadísticas de distribución por datos demográficos de clientes para garantizar que las cuentas y oportunidades de alto valor se distribuyen de forma equitativa. Identifique concentraciones donde grupos de usuarios específicos reciben acceso desproporcionado a registros valiosos sin justificación comercial documentada.
Auditar infracciones CRUD y FLS. Revise el Seguimiento de auditoría de configuración para cambios en parámetros de OWD, reglas de colaboración, configuraciones de FLS y conjuntos de permisos. Los cambios no autorizados en los controles de acceso a datos pueden indicar intentos de acceder a datos confidenciales de forma inapropiada. Utilice políticas de Seguridad de transacciones para actuar en eventos de Supervisión de eventos en tiempo real de alto riesgo (por ejemplo, actividad de API anómala, inicios de sesión sospechosos y grandes exportaciones de informes o vistas de lista de datos confidenciales). Como Seguridad de transacciones solo opera en estos eventos de tiempo de ejecución en vez de cambios de DML o FLS a nivel de registro, debe confiar en la Configuración del seguimiento de auditoría y las aprobaciones de gestión de cambios documentadas para FLS y los cambios de colaboración.

En Salesforce, agencia de usuario significa que los clientes y empleados mantienen un control significativo sobre cómo afecta la IA a su experiencia. Las funciones de gestión de consentimiento de Salesforce, el consentimiento de Data 360 y los objetos de consentimiento personalizado permiten un control granular sobre las interacciones de IA.

Diseñe el seguimiento de consentimiento utilizando la gestión de consentimiento de Data 360, el consentimiento de Marketing Cloud u objetos de consentimiento personalizados que utilizan Seguimiento de auditoría de campo para requisitos de consentimiento específicos de IA.

Active el consentimiento granular por caso de uso de IA. Active el consentimiento por caso de uso de IA en vez de utilizar un consentimiento de IA general. Los clientes pueden dar su consentimiento a recomendaciones de productos Einstein pero rechazan decisiones de crédito dirigidas por IA. Active Seguimiento de auditoría de campo en objetos de consentimiento para la retención a largo plazo y el cumplimiento de requisitos normativos. Diseñe objetos de consentimiento personalizados con campos que realizan un seguimiento de:
Propósito de consentimiento (por ejemplo, Puntuación de candidatos Einstein, Recomendaciones de respuestas Einstein y Generador de recomendaciones Einstein)
Fecha de concesión de consentimiento y Método de concesión (por ejemplo, formulario web, API, teléfono y correo electrónico)
Fecha de retirada del consentimiento (si procede)
Id. de usuario o contacto relacionado
Utilice el consentimiento de Data 360 para la personalización. Utilice la gestión de consentimiento de Data 360 para funciones Personalización de Einstein. Data 360 introduce y almacena preferencias de consentimiento desde sistemas ascendentes a través de conectores asignados al Modelo de datos de privacidad, que le permite utilizar esos atributos de consentimiento como criterios de filtro en segmentación y en activación. Asignar atributos de consentimiento a casos de uso de IA específicos para permitir a los usuarios anular la personalización mientras mantienen los servicios principales
Active la integración de consentimiento de Marketing Cloud. Integre el consentimiento de Marketing Cloud con Perspectivas de mensajería de Einstein y funciones de marketing dirigidas por IA. Respete el estado de suscripción y el consentimiento de Marketing Cloud en todas las comunicaciones dirigidas por IA.

Proporcione anulaciones de suscripción significativas desde funciones dirigidas por IA con controles accesibles que respetan las preferencias del usuario a través de alternativas humanas de calidad comparable.

Proporcione anulaciones de suscripción accesibles en la configuración del perfil. Permita a los usuarios anular la suscripción a interacciones dirigidas por IA a través de controles de preferencias accesibles en configuración de perfil de Experience Cloud o Mi configuración en aplicaciones internas. Proporcione descripciones claras de lo que significa cada anulación de suscripción y la experiencia alternativa que recibirán los usuarios al anular la suscripción. Almacene preferencias en registros Usuario o Contacto.
Proporcione opciones de preferencias persistentes entre canales. Almacene preferencias de IA en registros de Usuario o Contacto para garantizar la coherencia entre canales (por ejemplo, web, móvil, teléfono y correo electrónico). Consulte preferencias de forma coherente en todos los flujos de interacción para evitar que los usuarios tengan que reafirmar repetidamente preferencias en diferentes canales.

La gobernanza de IA ética proporciona estructuras organizativas que ayudan a garantizar que la equidad persiste a medida que evolucionan los modelos, cambian los datos y se amplían los casos de uso. Sin gobernanza, los esfuerzos iniciales de equidad se deterioran a medida que cambia la atención de la organización.

Establezca la documentación obligatoria y revise los puntos de control antes de implementar Einstein. Piense en esto como una puerta que es tan importante como las revisiones de seguridad.

Proporcione documentación del modelo. Almacene documentación de modelo en Salesforce utilizando un objeto Modelo personalizado o Archivos de Salesforce adjuntos a Proyectos para activar la capacidad de búsqueda y el control de versiones. Documente cada modelo predictivo de producción utilizando:
Datos demográficos de entrenamiento y brechas de representación conocidas (para modelos predictivos entrenados por el cliente como Einstein Discovery y Generador de predicciones)
Mediciones de equidad previas a la implementación calculadas por grupo demográfico
Casos de uso previstos y usos inapropiados conocidos
Estrategias de mitigación del sesgo que se aplican durante el desarrollo
Enfoque de supervisión de la equidad y umbrales de alerta
Requisitos de supervisión humana y flujos de trabajo de aprobación
Revisar programaciones y partes responsables
Consideraciones normativas y posicionamiento de cumplimiento
Active Puertas de equidad previas a la implementación. Los modelos que no superen cualquier prueba de puerta no deben continuar en producción. Trate las puertas de equidad con el mismo rigor que las puertas de seguridad. En otras palabras, tienen autoridad para bloquear implementaciones. Antes de implementar predicciones Einstein en producción, debe:
Revise auditorías de datos de formación. Todas las brechas de representación deben analizarse y documentarse.
Revise mediciones de equidad (por ejemplo, paridad demográfica, igualdad de oportunidades e impacto dispar deben calcularse y confirmarse para cumplir umbrales).
Revise evaluaciones de impacto. Evalúe el daño potencial entre las poblaciones afectadas.
Diseño con supervisión humana. Todos los patrones de distribución, flujos de trabajo de aprobación y mecanismos de sustitución deben diseñarse y probarse de forma apropiada.
Complete una revisión de transparencia. Las funciones de explicación deben validarse para todos los tipos de decisiones.
Documentación completa. Todos los artefactos de documentación de modelo requeridos deben estar aprobados.

Establezca procesos de revisión para aplicaciones de IA de alto riesgo que proporcionan supervisión interfuncional y tienen autoridad de aplicación.

Revisar composición del consejo. Incluya expertos técnicos (por ejemplo, arquitectos y científicos de datos), partes interesadas comerciales (por ejemplo, propietarios de productos y personal de operaciones), asesores legales, especialistas en privacidad y representantes de comunidades afectadas (cuando sea posible). Recuerde, las diversas perspectivas afloran problemas de equidad que los grupos homogéneos a menudo pierden.
Revise todos los desencadenadores que requieren la aprobación del consejo de ética. Defina qué casos de uso de IA requieren revisión ética antes de la implementación:
Decisiones que afectan al empleo, el crédito, la vivienda, el cuidado de la salud o los derechos legales
Sistemas automatizados que afectan a más de 10.000 usuarios o transacciones al año
Aplicaciones de IA que utilizan datos personales confidenciales, incluyendo datos sanitarios, financieros o demográficos
Casos de uso novedosos que no tienen un precedente organizativo establecido
Sistemas donde los posibles sesgos pueden causar daños significativos a individuos o grupos
Revise y determine quién tiene autoridad para bloquear implementaciones. Las juntas de revisión ética deben tener la autoridad para requerir cambios, imponer condiciones de supervisión o bloquear implementaciones que no cumplen con estándares éticos. Los exámenes sólo consultivos (sin autoridad coercitiva) pueden limitar la eficacia del proceso de gobernanza. Documente todas las revisiones en objetos personalizados de Salesforce que realizan un seguimiento de: nombre de solicitud, fecha de revisión, problemas planteados, requisitos de mitigación y condiciones de aprobación.

La supervisión de equidad es un proceso continuo que requiere atención continua para detectar desviación de sesgos a medida que cambian las distribuciones de datos y cambian las poblaciones de usuarios.

Cree paneles de equidad de CRM Analytics. Cree paneles que realizan un seguimiento de mediciones de equidad utilizando los datos de decisiones de modelo predictivo que captura. Supervise la paridad demográfica, la igualdad de oportunidades, los índices de impacto dispares y las mediciones de calidad de predicciones por segmentos de clientes. Configure alertas de CRM Analytics que se desencadenan cuando las mediciones de equidad infringen umbrales definidos y requieren una investigación.
Active la supervisión personalizada para señales de equidad. Cree una supervisión de equidad personalizada para detectar señales (por ejemplo, cambios repentinos en distribuciones de decisiones por grupo demográfico, picos en registros de casos relacionados con sesgos o degradación en el rendimiento del modelo para poblaciones específicas).
Programar auditorías de equidad. Realice auditorías de equidad integrales y trimestrales para sistemas de IA de alto riesgo (por ejemplo, crédito, empleo y cuidados sanitarios) y auditorías semestrales para sistemas de bajo riesgo (por ejemplo, recomendaciones y personalización). Las auditorías deben examinar mediciones de equidad actuales, revisar patrones de anulación en el historial de aprobaciones, analizar comentarios de usuarios e informes de sesgos y validar que los controles de gobernanza permanecen efectivos.
Implemente una respuesta ante incidentes por fallos de equidad. Establezca procesos claros que estén documentados en Salesforce Knowledge detallando cómo responder cuando se detecta un sesgo:
Inmediato: Evalúe la gravedad y el alcance consultando los datos de decisiones del modelo predictivo en CRM Analytics. Si el incidente es grave, suspenda toda la toma de decisiones automatizada a la espera de una investigación.
A corto plazo: Implemente estrategias de mitigación temporales (por ejemplo, una mayor supervisión humana a través de umbrales de confianza ajustados, desactivación de funciones o suspensión completa de agentes).
Investigación: Complete un análisis de causa raíz (RCA) para identificar cómo entró o evolucionó el sesgo en el sistema. Durante la RCA, analice datos de entrenamiento, versiones de modelo y cambios de configuración a través de la Seguimiento de auditoría de campo.
Remediación: Implemente una solución permanente a través de la corrección de datos, el reciclaje de modelos o cambios de procesos.
Comunicación: Notifique a los usuarios afectados a través de anuncios de Casos, correo electrónico o Experience Cloud.
Prevención: Procese los cambios para evitar que se repitan y documente los métodos de prevención en libros de ejecución.

Utilice esta lista de comprobación durante revisiones de arquitectura, antes de la implementación de producción y periódicamente para una evaluación continua.

Calidad de los datos y equidad representacional

Haga que los campos sean opcionales donde un proceso pueda funcionar sin los datos y diseñe procesos descendentes para gestionar valores que faltan, de modo que los usuarios que no pueden proporcionar información (correo electrónico, SSN, dirección postal) no se excluyan.
Campos Nombre de arquitecto como un campo de nombre completo único o estructura flexible de múltiples partes que acepta monónimos, escrituras no latinas, diacríticos y nombres largos, en vez de asumir el orden occidental primero/último.
Implemente la validación de direcciones permisiva que acepta formatos internacionales y de formato libre, almacenando direcciones como introducidas en vez de bloquear la creación de registros en una falta de coincidencia de formato.
Almacene preferencias de canales de comunicación en registros Contacto y admita alternativas de OmniCanal (correo electrónico, SMS, teléfono, correo postal, chat, voz) en vez de suponer que un único canal alcanza a todos los usuarios.
Recopile datos demográficos a través de la autoidentificación voluntaria con la opción “Preferir no responder”, almacenada por separado bajo OWD privado con FLS, agregada para la creación de informes y supervisada a través de Supervisión de eventos Shield.
Realice una auditoría de proveedores de enriquecimiento externos para pruebas de equidad, cobertura demográfica y metodología de inferencia antes de anexar datos demográficos o de comportamiento a registros.

Accesibilidad y diseño inclusivo

Utilice componentes Lightning Design System, que están diseñados para admitir la accesibilidad WCAG 2.2 AA. Tenga en cuenta que Salesforce se esfuerza por cumplir, pero los componentes aún requieren un uso correcto.
Valide componentes web Lightning personalizados con pruebas de lector de pantalla (por ejemplo, JAWS, NVDA y VoiceOver).
Asegúrese de que la navegación completa del teclado está presente en páginas Lightning y sitios de Experience Cloud sin dependencia del ratón.
Verifique que los índices de contraste cumplen 4,5:1 para texto normal utilizando herramientas de desarrollo de navegador o comprobadores de contraste.
Integrar la exploración de accesibilidad sa11y o Lighthouse en oportunidades en curso de CI/CD que fallan se basa en problemas críticos.
Pruebe sitios de Experience Cloud utilizando tecnología de asistencia antes del lanzamiento público.
Verifique los comentarios auditivos confirmando que todos los cambios dinámicos (por ejemplo, estados de error, spinners de carga o menús en expansión) están claramente anunciados y el contenido hablado coincide con la intención visual de la interfaz de usuario.

Justicia en la automatización de Salesforce

Revise las reglas de asignación y enrutamiento para la correlación con características protegidas que podrían concentrar resultados favorables o desfavorables en grupos demográficos específicos.
Lógica de decisión de automatización de procesos y flujo de auditoría para sesgos, documentación de reglas comerciales y criterios en Salesforce Knowledge o registros de decisiones de arquitectura.
Evalúe reglas de validación para índices de rechazo que afectan de forma desproporcionada a patrones de datos o poblaciones específicos.
Analice los diseños de territorios y segmentación para la correlación demográfica, documentando la justificación comercial explícita y supervisando territorios desatendidos para la asignación equitativa de recursos.
Someta los flujos de alto riesgo y las reglas de asignación (empleo, crédito, acceso a servicios) al mismo proceso de revisión ética que los sistemas de IA, y programe auditorías trimestrales de resultados de automatización estratificados por datos demográficos.

Equidad de IA y Detección de sesgos

Realice una auditoría de datos de Salesforce CRM para detectar brechas de representación demográfica antes de la formación de modelo predictivo.
Calcule la paridad demográfica, la igualdad de oportunidades y los índices de impacto dispares por grupo demográfico antes de la implementación.
Implemente evaluaciones de equidad como una puerta de implementación obligatoria (piense en esto como equivalente a una revisión de seguridad).
Cree paneles de CRM Analytics que realizan un seguimiento de mediciones de equidad utilizando datos de decisiones de modelo predictivo capturados con el Seguimiento de auditoría de campo.
Analice funciones de modelo predictivo para correlación proxy con características protegidas (por ejemplo, patrones de nombre de territorio y cuenta).
Programe auditorías de equidad completas y trimestrales para todos los sistemas de IA de alto riesgo.

Transparencia y capacidad de auditoría

Aflore explicaciones de predicción Einstein Discovery en puntos de decisión en componentes Lightning.
Configure capturas de auditoría de Capa Einstein Trust utilizando métodos de retención que cumplen los requisitos normativos.
Active Seguimiento de auditoría de campo en todos los objetos personalizados que almacenan datos de decisiones de IA para la retención a largo plazo.
Exporte datos de Supervisión de eventos a un SIEM externo (datos de Archivo de registro de eventos a través de la API y eventos de Supervisión de eventos en tiempo real a través de Eventos de plataforma) para almacenamiento que supera la retención nativa, con controles de escritura única del lado del SIEM para pruebas de manipulación.
Proporcione una comunicación de confianza apropiada para el usuario (por ejemplo, Alta, Moderada y Baja) en vez de probabilidades sin procesar.

Supervisión humana con Salesforce Automation

Configure umbrales de distribución basados en confianza en Flujo y enrute predicciones de baja confianza a revisión humana.
Utilice procesos de aprobación de Salesforce para decisiones de alto riesgo que requieren cadenas de revisión de múltiples etapas.
Integre el enrutamiento Agentforce y OmniCanal para permitir una distribución sencilla a agentes humanos.
Proporcione una opción persistente “Conectar con agente humano” en las interfaces Agentforce para respetar la agencia de usuarios.
Requerir un seguimiento documentado de la justificación y el historial de aprobaciones para sustituciones Agentforce que se capturan en campos personalizados.

No discriminación con controles de acceso a datos

Active OWD privado y luego otorgue acceso adicional a través de reglas de colaboración y jerarquía de funciones.
Configure Seguridad a nivel de campo para ocultar campos demográficos confidenciales a usuarios que no requieren acceso.
Supervise eventos de acceso a nivel de objeto (exportaciones de informes y consultas de API) para datos confidenciales a través de Supervisión de eventos Shield y analícelos para patrones de acceso anómalos.
Cree informes que analizan distribuciones de reglas de colaboración para garantizar una asignación de registros equitativa entre territorios.
Revise Configuración Seguimiento de auditoría para cambios de configuración de OWD, regla de colaboración o FLS no autorizados.

Agencia de usuario y consentimiento

Diseñe objetos de consentimiento personalizados utilizando Seguimiento de auditoría de campo para realizar un seguimiento del consentimiento de IA granular por caso de uso.
Integre el consentimiento de Data 360 o Marketing Cloud con Personalización de Einstein y funciones Agentforce.
Almacene preferencias de IA en registros de Usuario o Contacto para garantizar la coherencia entre canales (por ejemplo, web, móvil y teléfono).
Proporcione anulaciones de suscripción accesibles en parámetros de perfil y alternativas humanas a través del enrutamiento de OmniCanal.
Consulte registros de consentimiento en Flujo antes de que predicciones Einstein o implicación Agentforce afecten a los usuarios.

Gobernanza ética de la IA

Documente todos los modelos predictivos de producción, incluyendo mediciones de equidad y estrategias de mitigación; para modelos predictivos entrenados por el cliente (como Einstein Discovery y Prediction Builder), también documente datos demográficos de entrenamiento.
Establezca puertas de equidad previas a la implementación obligatorias que bloqueen la implementación hasta que se cumplan todos los criterios de equidad.
Cree una Junta de revisión de ética de IA como autoridad de aplicación para todas las aplicaciones de IA de alto riesgo.
Cree paneles de CRM Analytics para supervisar mediciones de equidad en una cadencia programada a través de alertas de CRM Analytics.
Defina procedimientos de respuesta ante incidentes para fallos de equidad y documente el proceso en Salesforce Knowledge.
Programe auditorías de equidad trimestrales que analizan patrones de anulación y comentarios de usuarios para todos los sistemas de alto riesgo.

Comparta sus comentarios sobre el Marco bien diseñado.