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 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 mientras permanecen 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 más detallado a cada componente.

Shield Platform Encryption protege atributos confidenciales como datos demográficos, y Event Monitoring proporciona los seguimientos de auditoría que admiten la gestión transparente de datos.
Einstein Trust Layer (ETL) captura un seguimiento de auditoría seguro para solicitudes de IA generativa y respuestas para fines de monitoreo 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 costos 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 Componentes web Lightning (LWC), páginas Visualforce y 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 monitoreo continuo. 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 complejo. Los sitios de Experience Cloud inaccesibles pueden exponer 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 responsabilidad algorítmica, las predicciones Einstein sesgadas pueden infringir los requisitos de la Ley de IA. Solo las decisiones automatizadas dirigidas por IA 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 artículo 15(1)(h) de la 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 regulatoria 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. Al crear, 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 de 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 de teclado deben validarse a través de pruebas de tecnología de asistencia.
Reduzca y monitoree 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 mediante 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 de solicitudes y respuestas de Einstein Trust Layer (ETL). Documente decisiones para cumplir requisitos de transparencia regulatoria.
Aproveche 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 los registros de Monitoreo 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 el almacenamiento de una sola escritura y la 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 la revisión humana apropiada. Utilice umbrales de confianza y reglas de negocio para determinar cuándo requieren validación las predicciones antes de realizar acciones.
Aplique Valores predeterminados de toda la organización (OWD) y 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 necesita cada función utilizando reglas de colaboración. Evite otorgar a los perfiles acceso excesivo que pueda exponer atributos confidenciales y permitir 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 una disponibilidad de información que varía entre datos demográficos, la integridad 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 email excluye poblaciones que no tienen acceso a Internet fiable o direcciones de email personales.
- Requerir números de la seguridad social de EE.UU. (SSN) excluye clientes internacionales e inmigrantes recientes a los que aún no se les emitió un SSN.
- Requerir direcciones de calle excluye a las poblaciones sin hogar y los usuarios con direcciones no tradicionales.
Audite justificaciones de negocio para campos obligatorios. Para cada campo obligatorio, es importante documentar por qué la información es obligatoria en vez 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 los valores que faltan con gracia. 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, los patrones de herencia o las 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 Cajero)
Nombres largos que superan los límites de longitud de campo comunes
Nombres con diacríticos, apóstrofes, guiones y espacios
Nombres con escrituras no latinas (por ejemplo, árabe, chino, cirílico y devanagari)

Cuando la validación de nombres 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 postales 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, evita 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 las direcciones a medida que las ingresan los usuarios en vez de obligarlos 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 direcciones 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 solo por email excluye:

Usuarios sin acceso a Internet fiable
Poblaciones de edad avanzada que se sienten menos cómodas utilizando el email
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 entre todos los sistemas de comunicación salientes. Proporcione una variedad de alternativas de comunicación en vez de suponer que los métodos de un solo canal funcionan de forma universal.

La recopilación de datos demográficos para el monitoreo de equidad requiere una arquitectura cuidadosa para evitar un mal uso.

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., el monitoreo de sesgos normalmente se basa en la autoidentificación voluntaria de EEO). Donde existe una base legal, las organizaciones utilizan datos demográficos para:

Monitorear mediciones de equidad estratificadas por grupos protegidos
Detectar sesgos en sistemas de automatización e IA
Demostrar el cumplimiento normativo de los requisitos antidiscriminación

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, monitoreo de equidad o creación de reportes de cumplimiento)
Voluntario e incluye una opción “Preferir no responder” que está siempre disponible
Separado de datos operativos con FLS estricto para evitar acceso inapropiado
Agregado para creación de reportes y análisis y no vinculado a decisiones individuales
Monitoreado a través de Monitoreo de eventos Shield para auditoría de patrones 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 externos que anexa datos demográficos, de firma 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
Cobertura y precisión 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 Lightning Design System están diseñados para admitir la conformidad WCAG 2.2 AA cuando se utilizan como están diseñados. Salesforce se esfuerza, pero no certifica, la conformidad completa. Desviarse de patrones SLDS o crear componentes personalizados sin consideración de accesibilidad crea barreras para usuarios con discapacidades.

Los componentes web Lightning estándar proporcionan accesibilidad integrada. Los componentes como Lightning, Lightning, Lightning y Lightning 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 eliminan significado de 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.
Pruebe 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 captan 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 cuadros 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 emergentes y modales Lightning proporcionan una gestión de enfoque básica, pero los flujos complejos necesitan 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 están configuradas 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 navegadores o comprobadores de contraste online para validar el cumplimiento. Pruebe con zoom de navegador al 200% para garantizar que el texto se amplía sin perder contenido o funciones.
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 con teclado sin dependencia del ratón. Los usuarios deben navegar dentro y fuera de menús desplegables, mega menús y navegación desplegable utilizando las teclas Tab, Enter, Escape 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-labelledby. 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 con 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 perderse. 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 el contenido y la función. Cuando escriba texto alternativo para iconos, céntrese en la acción o el propósito del icono en vez de su aspecto 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 ingresen 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 el tacto 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 con el contenido circundante. Los indicadores de enfoque deben ser claramente visibles para permitir a los usuarios con visión reducida 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 cuadros modales y superposiciones. Los diálogos modales deben atrapar el enfoque dentro del cuadro 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 cuadro 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 de teclado estándar que están documentados 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, pulsar 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 completamente.

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) encierran el motor de accesibilidad principal para agregar un comparador toBeAccessible() para pruebas de unidad de Jest. Redacte pruebas de accesibilidad que validen el uso de ARIA apropiado, asociaciones de etiquetas, índices de contraste y marcado semántico automáticamente como parte de pruebas de unidades. 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 puntuaje para requerir puntuajes de accesibilidad mínimos 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 los 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 por no examinado porque la lógica determinista se siente objetiva.

Siga las reglas de asignación de prospectos 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 difieren entre territorios, la automatización de asignaciones crea discriminación económica.
Audite resultados de reglas de asignación regularmente. Calcule distribuciones de asignaciones entre territorios y equipos estratificados por datos demográficos de clientes. Si las cuentas de compañía están concentradas en territorios específicos mientras las cuentas de PYME están distribuidas en otros lugares (y si los territorios de compañía 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 proxies demográficos.

Es importante monitorear el tiempo medio para gestionar, 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 automatizaciones de Salesforce Flow. La toma de decisiones de aprobación, determinaciones de aptitud o concesiones de acceso pueden codificar lógica discriminatoria a través de reglas de negocio 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 decisiones de Flujo y 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 reglas de validación. Evitar el ingreso 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 email que requieren direcciones de email personales pueden crear una desventaja para usuarios que no tienen acceso de email 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 de negocio requiere diferentes niveles de recursos entre territorios (por ejemplo, madurez de mercado, intensidad competitiva y potencial de crecimiento), documente esa justificación de forma explícita y monitoree 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 de negocio, criterios de asignación y lógica de decisiones 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 regulares. 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
Desempeño de territorio 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 los 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 entre 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 tableros de CRM Analytics realizan un seguimiento de mediciones de equidad. Seguimiento de auditoría de campo y Monitoreo de eventos capturan datos de decisiones para la responsabilidad algorítmica.

Las predicciones Einstein que afectan a decisiones consiguientes (por ejemplo, puntuaje de prospectos, pronósticos 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 tras evaluar si su valor predictivo justifica la inclusión a pesar de los efectos proxy.

Audite datos de Salesforce CRM antes de la capacitació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, Puntuaje de prospectos Einstein 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 Puntuaje de prospectos Einstein asigna puntuajes altos al segmento A el 50% de las veces pero solo el 30% de las veces al segmento B, un índice 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 su eliminación no es un puerto seguro: una disparidad estadísticamente significativa puede justificar 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, activa si una práctica crea una “desventaja particular”, sin umbral fijo). Calibre 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 Puntuaje de prospectos y Puntuaje de oportunidades, capture datos de decisiones mediante Einstein Discovery e instrumentación personalizada: almacene entradas de predicción, salidas y versiones de modelo 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 decisiones entre grupos demográficos a lo largo del tiempo, y cree tableros que alerten cuando las mediciones de paridad demográfica o igualdad de oportunidades vayan 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 de raza, etnia e ingresos)
Patrones de nombre de cuenta (proxies para tamaño de organización y datos demográficos de la industria)
Cronología 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 insuficientemente representados 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 mientras mantiene la privacidad a través de técnicas de privacidad diferenciales.
Elimine proxies en ingeniería de funciones. Cuando se identifican funciones proxy, sustitúyalas por funciones alternativas que proporcionan poder predictivo sin correlación demográfica. Si el territorio sirve como proxy demográfico, considere la clasificación de la industria o el tamaño de la compañía 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 capacitació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 los puntuajes o utilizar puntuajes de corte diferentes por clase protegida, y ninguna cantidad de justificación documentada hace que la práctica sea legal. Donde no está prohibido, documente ajustes de umbral con justificación de negocio para un trato diferencial cuando las predicciones informan de decisiones automatizadas.
Entrene modelos periódicamente utilizando datos actualizados. Programe el reciclaje de modelos trimestralmente (o cuando se produzcan turnos de distribución de datos significativos). El reentrenamiento en datos actualizados capta patrones de sesgo emergentes y corrige cualquier desviación de las líneas de base de equidad originales. Vuelva a validar mediciones de equidad en cada versión de modelo antes de la implementación de producción para asegurarse de que el reciclaje no introdujo nuevos sesgos.

Einstein Trust Layer captura solicitudes, respuestas y señales Trust para funciones de IA generativa y Agentforce, lo que admite la transparencia y el cumplimiento normativo para la IA generativa. Para modelos predictivos, la transparencia y el linaje de decisiones proceden de Einstein Discovery y Gestor de modelos, 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 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. Arquitecto Componentes Lightning que muestran estas explicaciones a los usuarios en el punto de decisión en vez de requerir navegación para separar tableros de CRM Analytics. Cuando las decisiones afectan a usuarios, necesitan transparencia, no mediciones de desempeño de modelo abstractas.
Explicaciones de capas para diferentes audiencias. Proporcione una profundidad de explicación apropiada para cada audiencia:
Usuarios de negocio: “Este prospecto obtuvo un puntuaje alto porque los ingresos anuales superan 1 millón de dólares y el puntuaje de implicación está en el 10% superior”.
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 dirigieron la predicción) capturados a través de instrumentación personalizada.
Comunique la confianza apropiadamente. Muestre confianza de predicción en términos apropiados para el usuario y evite puntuajes 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 integrales e inmutables que admiten la rendición de cuentas, la depuración y el cumplimiento normativo para todas las decisiones dirigidas por 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 de predicción, salidas y versiones de modelo) en campos con seguimiento con Seguimiento de auditoría de campo activado. Arquitecto de políticas de retención de datos para cumplir los requisitos normativos, que varían por industria 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, 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. Construya tableros de CRM Analytics sobre los datos de decisiones de modelo predictivo que captura (entradas de predicción, salidas y versiones de modelo en campos con seguimiento) para analizar patrones de decisiones, mediciones de equidad y desempeño 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 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, sustituyen decisiones y sesgan reportes para cumplir requisitos de retención regulatorios.
Utilice Monitoreo de eventos para interacciones Agentforce. Monitoreo de eventos captura eventos a nivel de invocación para Agentforce, como cuando se ejecutan acciones y flujos. Exporte datos de Monitoreo 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 Monitoreo de eventos en tiempo real a través de Eventos de plataforma) para almacenamiento que supera el plazo de retención nativo de Salesforce. La evidencia de manipulación depende del comportamiento SIEM concreto que aplica la segregación de acceso y almacenamiento de escritura única. Configure consultas SIEM para detectar patrones de sesgo entre grandes volúmenes de interacciones Agentforce.
Auditar pláticas Agentforce con Einstein Trust Layer. Einstein Trust Layer captura el seguimiento de auditoría de solicitudes y respuestas de pláticas Agentforce, almacenadas en Data 360, proporcionando el registro a nivel de transcripción para la transparencia y el cumplimiento normativo.

Echemos un vistazo con más detalle a las funciones de transparencia de Arquitecto 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 previstos en la Ley de IA 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 Einstein Trust Layer y las tarjetas de modelo Einstein Discovery proporcionan las bases para estos requisitos. Documente datos demográficos de entrenamiento de modelos, enfoques de validación y limitaciones conocidas en registros de decisiones de arquitectura.
Derecho de explicación de 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 dicha 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 junto con el considerando 71 y aclarados por el TJUE en el asunto Dun & Bradstreet (2025). Diseñe sistemas que generen explicaciones coherentes on demand para cualquier decisión histórica en plazos 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 de predicción, 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 responsabilidad algorítmica a nivel estatal de EE.UU. requieren cada vez más evaluaciones de impacto y reportes de transparencia para sistemas de decisiones automatizados. Los datos de decisiones de modelo predictivo que captura y los tableros de monitoreo de equidad de CRM Analytics proporcionan las bases de datos para estos reportes. Realice evaluaciones de impacto algorítmicas antes de implementar la IA resultante como cumplimiento proactivo en vez de como una respuesta reactiva a consultas regulatorias.

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 garantizando al mismo tiempo 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. Las OWD de Lectura/Escritura públicas hacen que restringir el acceso más tarde sea perturbador (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 de negocio 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 reportes de diversidad y ajustes razonables), otorgue acceso mínimo utilizando conjuntos de permisos con justificación de negocio 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 equitativamente 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 de negocio documentada. Configure reglas de colaboración automáticas basándose en criterios objetivos (por ejemplo, industria, geografía y línea de productos) en vez de discreción de gestor subjetiva, 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 caducidades documentadas. Los flujos programados pueden revocar conjuntos de permisos automáticamente después de periodos definidos.

Utilice Monitoreo de eventos Shield y reportes para detectar patrones de acceso a datos que indican posible discriminación o sesgo en el uso de datos.

Utilice Monitoreo de eventos Shield para auditar el acceso a datos confidenciales. Utilice Monitoreo de eventos para capturar eventos de acceso a nivel de objeto (exportaciones de reportes, 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 trate patrones anómalos (por ejemplo, picos repentinos y acceso de usuarios inesperados) como desencadenadores para la investigación.
Reporte sobre distribuciones de reglas de colaboración. Cree reportes 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 de negocio documentada.
Audite 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 Monitoreo de eventos en tiempo real de alto riesgo (por ejemplo, actividad de API anómala, inicios de sesión sospechosos y grandes exportaciones de reportes o vistas de lista de datos confidenciales). Puesto que Seguridad de transacciones solo funciona en estos eventos de tiempo de ejecución en vez de cambios de DML o FLS a nivel de registro, debe basarse en la Configuración del seguimiento de auditoría y las aprobaciones de gestión de cambios documentadas para FLS y 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 personalizados permiten el control granular sobre interacciones de IA.

Diseñe el seguimiento del consentimiento utilizando la gestión del 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 consentir recomendaciones de productos Einstein pero rechazar 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, Puntuaje de prospectos 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 email)
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 ingresa 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 manteniendo al mismo tiempo los servicios principales
Active la integración de consentimiento de Marketing Cloud. Integre el consentimiento de Marketing Cloud con Perspectivas de Mensajería 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 de los usuarios 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 Usuario o Contacto para garantizar la coherencia entre canales (por ejemplo, web, móvil, teléfono y email). Consulte preferencias de forma coherente en todos los flujos de interacción para evitar que los usuarios necesiten 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 la implementación Einstein. Piense en esto como una puerta que es tan importante como las revisiones de seguridad.

Proporcione documentación de modelo. Almacene documentación de modelo en Salesforce utilizando un objeto Modelo personalizado o Salesforce Files 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 clientes como Einstein Discovery y Prediction Builder)
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 monitoreo de equidad y umbrales de alerta
Requisitos de supervisión humana y flujos de trabajo de aprobación
Revisar programaciones y partes responsables
Consideraciones regulatorias y posicionamiento de cumplimiento
Active Puertas de equidad previas a la implementación. Los modelos que no superan ninguna prueba de puerta no deben continuar con la producción. Trate las puertas de equidad con el mismo rigor que las puertas de seguridad. En otras palabras, tienen la autoridad para bloquear implementaciones. Antes de implementar predicciones Einstein en producción, debe:
Revise auditorías de datos de capacitació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 posibles daños entre las poblaciones afectadas.
Diseña 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. Se deben aprobar todos los artefactos de documentación de modelo requeridos.

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

Revise la composición del tablero. Incluya expertos técnicos (por ejemplo, arquitectos y científicos de datos), partes interesadas de negocio (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, los cuidados sanitarios 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 monitoreo o bloquear implementaciones que no cumplen con los estándares éticos. Las revisiones solo consultivas (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, preocupaciones planteadas, requisitos de mitigación y condiciones de aprobación.

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

Cree tableros de equidad de CRM Analytics. Cree tableros que realizan un seguimiento de mediciones de equidad utilizando los datos de decisiones de modelo predictivo que captura. Monitoree la paridad demográfica, la igualdad de oportunidades, los índices de impacto dispar y las mediciones de calidad de predicción 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 el monitoreo personalizado para señales de equidad. Cree monitoreos de equidad personalizados 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 desempeño 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 sustitución en el historial de aprobaciones, analizar comentarios de usuarios y sesgar reportes y validar que los controles de gobernanza siguen siendo efectivos.
Implemente la respuesta ante incidentes para fallos de equidad. Establezca procesos claros que estén documentados en Salesforce Knowledge detallando cómo responder cuando se detecta sesgo:
Inmediata: Evalúe la gravedad y el ámbito consultando los datos de decisiones del modelo predictivo en CRM Analytics. Si el incidente es grave, suspenda toda la toma de decisiones automatizada pendiente de una investigación.
A corto plazo: Implemente estrategias de mitigación temporales (por ejemplo, supervisión humana aumentada 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 ingresó 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 del 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, email o Experience Cloud.
Prevención: Procese los cambios para evitar que se repitan y documente los métodos de prevención en los 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 datos y equidad representacional

Haga que los campos sean opcionales donde un proceso puede 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 (email, SSN, dirección postal) no se excluyan.
Campos Nombre de arquitecto como un campo de nombre completo único o una estructura de múltiples partes flexible que acepta monónimos, secuencias de comandos no latinas, diacríticos y nombres largos, en vez de asumir el primer/último orden occidental.
Implemente la validación de direcciones permisiva que acepta formatos internacionales y de formato libre, almacenando direcciones como ingresadas 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 omnicanal (email, SMS, teléfono, correo postal, chat, voz) en vez de suponer que un único canal llega a todos los usuarios.
Recopile datos demográficos a través de la autoidentificación voluntaria con una opción “Preferir no responder”, almacenada por separado bajo OWD privada con FLS, agregada para la creación de reportes y monitoreada a través de Monitoreo de eventos Shield.
Audite 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.
Integre la exploración de accesibilidad sa11y o Lighthouse en oportunidades en curso de CI/CD que fallan crea 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 decisiones de automatización de procesos y flujos de auditoría para sesgos, documentando reglas y criterios de negocio 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 poblaciones o patrones de datos específicos.
Analice los diseños de territorios y segmentación para la correlación demográfica, documentando la justificación de negocio explícita y monitoreando 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.

Detección de equidad y sesgo de IA

Audite datos de Salesforce CRM para brechas de representación demográfica antes del entrenamiento 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 tableros 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 de proxy con características protegidas (por ejemplo, patrones de nombre de cuentas y territorios).
Programe auditorías de equidad integrales 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 una retención a largo plazo.
Exporte datos de Monitoreo de eventos a un SIEM externo (datos de Archivo de registro de eventos a través de la API y eventos de Monitoreo 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 automatización de Salesforce

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 interfaces Agentforce para respetar la agencia de usuario.
Requiera un seguimiento documentado de la justificación y el historial de aprobaciones para sustituciones Agentforce capturadas en campos personalizados.

No discriminación con controles de acceso a datos

Active Private OWD 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.
Monitoree eventos de acceso a nivel de objeto (exportaciones de reportes y consultas de API) para datos confidenciales a través de Monitoreo de eventos Shield, y analícelos para patrones de acceso anómalos.
Cree reportes 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 Usuario o Contacto para garantizar la coherencia entre canales (por ejemplo, web, móvil y teléfono).
Proporcione anulaciones de suscripción accesibles en configuración 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 de IA ética

Documente todos los modelos predictivos de producción, incluyendo mediciones de equidad y estrategias de mitigación; para modelos predictivos entrenados por clientes (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 bloquean 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 solicitudes de IA de alto riesgo.
Cree tableros de CRM Analytics para monitorear 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 sustitución y comentarios de usuarios para todos los sistemas de alto riesgo.

Comparta sus comentarios sobre el Marco de trabajo bien diseñado.