公平性

公平

在 Salesforce 架构中，公平性意味着构建解决方案，通过可访问的界面、偏见检测和缓解、透明的决策和道德治理来公平服务于用户。Einstein 的预测会影响影响客户和员工的结果，这意味着架构师应该设计的系统能够在不同的人口群体之间产生公平的结果，同时保持对残疾用户的可访问性。

Salesforce 提供专为公平性而构建的平台功能，我们努力遵守 WCAG 2.2 AA。在正确使用时，Salesforce Lightning 设计系统 (SLDS) 会提供旨在支持此目标的组件。让我们仔细看看每个组件。

  • Shield Platform Encryption 保护敏感属性，例如人口统计数据，Event Monitoring 提供支持透明数据处理的审计跟踪。
  • Einstein Trust 层 (ETL) 捕获生成式 AI 提示和响应的安全审计跟踪，用于监控和合规目的。
  • Experience Cloud 包含可访问性控制。
  • 字段审计跟踪提供了字段级数据更改历史的长期保留，当 AI 决策数据存储在被跟踪字段中时，这将支持算法问责制。

这些功能有助于降低 Salesforce 公平实践的运营成本。

在 Salesforce，公平性在三个维度上运作，以提供解决方案。包容性设计有助于使 Lightning Web 组件 (LWC)、Visualforce 页面和 Experience Cloud 站点完全可访问 — 具有无缝键盘导航、屏幕阅读器兼容性和认知设计适应性。AI 公平实践使用偏见检测、多样的训练数据和持续监控帮助 Einstein 预测产生公平的结果。随着模型的发展和用例的扩展，治理提供了保持公平的流程和控制。

忽视公平会产生复合风险。无法访问的 Experience Cloud 站点可能会使组织面临 Americans Disabled Act (ADA) 诉讼，对于联邦机构及其承包商来说，也会面临违反 Section 508 合规的行为。根据系统的风险分类和新出现的算法问责法,有偏见的 Einstein 预测可能违反欧盟 AI 法的要求。仅由 AI 驱动的具有法律效力或类似重大影响的决策，如果缺乏关于决策逻辑的有意义信息，可能会违反 GDPR 第 22 条和第 15(1)(h) 条的信息权。

追求公平的组织倾向于减少对受其系统影响的客户、员工和社区可预见的伤害。公平失败会对受影响的个人造成有形的物质伤害，包括经济伤害、被剥夺机会、情绪困扰和系统性歧视的强化。监管的一致性往往来自为受影响的个人服务。

使用这些原则来指导您的架构决策，以实现平台上的公平性。

  • **设计 Lightning 可访问性模式。**在构建时，尽可能使用旨在支持 WCAG 2.2 AA 可访问性的 Lightning 设计系统和标准 Lightning Web 组件。当您使用 SLDS 构建时，您正在利用可访问性是核心设计原则的库。SLDS 组件会检查键盘可访问性和与辅助技术的兼容性，许多组件包含带有开发人员提示的可访问性部分。如果需要自定义组件，必须通过辅助技术测试来验证显式可访问富互联网应用程序 (WAI-ARIA) 实施、语义 HTML 和键盘导航模式。
  • **使用每种模型类型的正确工具减少和监控偏差。**在部署前和生产中持续验证 AI 输出，以实现跨人口群体的公平结果。对于预测模型，通过 Einstein Discovery 和自定义仪器捕获决策数据，并在 CRM Analytics 中进行分析，以衡量公平性度量；对于生成式 AI 和 Agentforce 功能，使用提示和响应的 Einstein Trust 层 (ETL) 审计跟踪。记录决策，以满足监管透明度要求。
  • **利用 Shield Platform Encryption 进行数据保护控制。**对于需要精确匹配查询的敏感属性，将 Shield Platform Encryption 与确定性方案一起使用，同时保护个人数据。将 Event Monitoring 日志路由到外部安全信息和事件管理 (SIEM) 系统，以支持防篡改的审计跟踪 — 当 SIEM 强制执行超过所需法规的 Salesforce 本地保留窗口的一次性写入存储和访问隔离时。
  • **为高风险预测设计审查工作流。**在 Salesforce 流中配置审批流程和审查机制，以确保影响后续决策的 Einstein 预测得到适当的人工审核。使用置信度阈值和业务规则来确定在采取行动之前预测何时需要验证。
  • **应用组织范围的默认值 (OWD) 和字段级安全性 (FLS) 实现不歧视。**使用 OWD 和 FLS 构建数据访问模式，以默认限制访问，并仅授予每个角色使用共享规则所需的额外访问权限。避免授予简档过度访问权限，因为这可能会暴露敏感属性并促成歧视性决策。
  • **通过平台同意启用用户代理。**使用 Data 360 中的同意管理功能或通过字段审计跟踪自定义同意对象，跟踪每个用例的精细 AI 同意。使用户能够选择退出 AI 驱动的功能，并提供人工替代（如果可能）。

数据架构决策决定了 Salesforce 系统中可见和不可见的人群。数据质量差不仅仅是一个技术问题。当数据差距有系统地使特定人口群体处于不利地位时，这便成为一个公平问题。

  • **查看数据可用性的必填字段。**当必填字段假设信息可用性因人口统计而异时，数据完整性就会具有歧视性。无法提供所需信息的用户在拒绝不完整记录的系统中不可见。
    • 需要电子邮件地址的人群不包括没有可靠的互联网接入或个人电子邮件地址的人群。
    • 需要美国社会保险号码 (SSN) 会排除尚未获得 SSN 的国际客户和最近移民。
    • 需要街道地址会排除无家可归者和拥有非传统地址的用户。
  • **必填字段的审计业务理由。**对于每个必填字段，记录为什么信息是必填项而不是可选项非常重要。如果进程可以通过其他方法在没有特定数据的情况下运行，使这些字段成为可选字段，并设计系统来优雅地处理缺失的值。这有助于确保无法提供此类数据的用户不会被排除在外。

遵循西方命名约定（名字、姓氏）的名称字段可能会排除具有不同命名习惯的文化。

许多文化使用：

  • 不带姓氏的单名或单名
  • “姓氏”会生成更改的守护系统
  • 多个给定名称或家庭名称
  • 根据生活事件或社交上下文更改的名称
  • 名称中的“第一个”和“最后一个”是文化上没有意义的区分

使用单个全名字段或适应常见命名约定的灵活多部分结构设计名称架构。避免对名称顺序、继承模式或文化规范进行假设。

使用不同的国际名称测试名称架构，以确保名称字段接受：

  • 单词名称（例如，Sukarno、Cher 和 Teller）
  • 超过常用字段长度限制的长名称
  • 带有反义词、撇号、连字符和空格的名称
  • 非拉丁字母的名称（例如，阿拉伯语、中文、西里尔文和梵文）

当名称验证拒绝用户的合法名称时，他们会遇到基于其文化身份的系统拒绝。

地址验证服务通常针对美国和西欧格式进行优化，并且经常无法识别：

  • 具有不同字段顺序的国际地址格式
  • 没有街道名称的农村地址
  • 军事地址（例如，APO 和 FPO）
  • 邮政信箱和其他交货地点
  • 具有独特地址系统的部落土地
  • 地址组件使用非拉丁字母的国家/地区

当地址验证拒绝非传统地址格式时，它会阻止地址与验证数据库预期不匹配的用户创建、发货和服务交付。

以下是一些在考虑可访问性的情况下设计地址验证的方法：

  • 实施允许的地址验证。
  • 当结构验证失败时，接受自由形式的地址输入。
  • 在用户输入时存储地址，而不是强迫用户进行无效更正。
  • 使用地址验证进行数据丰富和重复检测，而不是验证地址格式。

与其前期阻止数据捕获，不如在履行过程中构建地址验证，因为地址的准确性在运营上很重要。

特定通信渠道的通用访问假设排除了具有不同技术访问或首选项的人群。

仅电子邮件通信不包括：

  • 没有可靠互联网接入的用户
  • 不太习惯使用电子邮件的老年人口
  • 在短信或消息传递应用程序为主要通信方法的区域的用户

仅限电话的通信不包括：

  • 耳聋和听力障碍的用户
  • 没有电话访问权限的用户或使用共享电话的用户

设计全方位通信架构，允许用户控制渠道首选项。在联系人记录中存储首选通信方法，并始终遵守所有出站通信系统的首选项。提供各种通信替代方案，而不是假设单渠道方法普遍适用。

收集人口统计数据进行公平性监控需要谨慎的架构来防止滥用。

收集和处理人口统计数据依赖于司法管辖区,并且受到法律限制(在欧盟,GDPR 第 9 条将其视为需要特定法律依据的特殊类别数据;在美国,偏见监测通常依赖于自愿的 EEO 自我认同 ) 。如果存在合法基础，组织会使用人口统计数据来：

  • 监控按受保护组分层的公平度量
  • 检测自动化和 AI 系统中的偏见
  • 证明监管符合反歧视要求

收集人口统计数据会产生某些风险：

  • 如果访问控制失败，数据可能被用于歧视性目的
  • 用户可能不信任收集方法，并提供不准确的数据
  • 收集可能感觉有侵犯性或歧视性

使用以下信息构建自愿自我认同并设计人口统计数据收集：

  • 以透明的目的明确解释（例如，公平性监控或合规报告）
  • 自愿，并包含始终可用的“宁愿不回答”选项
  • 通过严格的 FLS 与运营数据分开，以防止不当访问
  • 用于报告和分析的聚合，不与单个决策相关联
  • 通过 Shield Event Monitoring 进行监控，以进行访问模式审计

在隐私政策中准确记录人口统计数据将如何使用和不会使用非常重要。通过未披露的数据使用违反用户 Trust 可能会严重损害可信度，而可信度很难恢复。

将人口统计、公司统计或行为数据附加到 Salesforce 记录的第三方数据丰富可能会通过以下方式引入偏见：

  • 基于陈规定型观念的推理不准确
  • 覆盖范围不完整，存在与人口统计相关的差距
  • 使用未知公平属性的专有算法
  • 来自有偏见的历史记录的数据

在实施数据丰富服务之前，重要的是审核：

  • 供应商公平性测试和偏见缓解实践
  • 跨人口统计组的数据覆盖率和准确性
  • 用于创建预测的推理方法和功能
  • 合同数据使用限制和保留策略

请记住，一旦第三方数据进入您的 Salesforce 组织，它可能会影响决策，并产生供应商引入的偏见，这也反映在您的组织中。

在 Salesforce 上下文中，可访问性是指为残疾用户构建 Lightning Web 组件、Visualforce 页面和 Experience Cloud 站点。标准 Lightning 组件在正确使用时提供基准可访问性；但是，自定义开发和 Experience Cloud 配置需要明确的可访问性实施。

Lightning 设计系统组件旨在支持 WCAG 2.2 AA 一致性。Salesforce 力求完全合规，但不进行认证。偏离 SLDS 模式或构建没有可访问性的自定义组件会对残疾用户造成障碍。

标准 Lightning Web 组件提供内置可访问性。Lightning、Lightningcombobox、Lightningdatatable 和 Lightning 等组件会自动包含适当的 ARIA 属性、标签关联、键盘导航和焦点管理。在可能时，使用标准组件，而不是构建外观相似但可能缺乏适当可访问性基础设施的自定义替代项。

  • **在自定义 Lightning Web 组件中使用语义 HTML。**在构建自定义组件时，使用语义 HTML 元素（
    、
  • **在自定义组件中实施 ARIA。**当语义 HTML 无法传达界面行为时，应用 ARIA 地标、角色和属性。动态内容更新需要向屏幕阅读器宣布更改的咏叹调实时区域。自定义交互式组件需要与其行为相匹配的明确角色定义。Lightning 基础组件会自动处理 ARIA；但是，自定义组件需要通过屏幕阅读器测试手动验证 ARIA。
  • **使用辅助技术进行测试：**使用实际屏幕阅读器验证 Lightning 组件（例如，适用于 Windows 的 JAWS 和 NVDA、适用于 macOS 和 iOS 的 VoiceOver 以及适用于 Android 的 TalkBack）。根据 Deque 的大规模研究，像 axe-core 这样的自动化工具可以捕获大约 57% 的可访问性问题。其余问题需要了解屏幕阅读器导航模式的人员使用辅助技术进行手动测试。
  • **在 Lightning 流程中使用焦点管理。**当模态打开、动态内容加载或用户完成多步骤流时，您应以编程方式管理焦点，以指导键盘用户找到新内容。Lightning 模态和弹出窗口组件提供基本的焦点管理，但复杂的流需要明确的焦点逻辑，以便在内容更改时适当移动焦点。

Experience Cloud 站点为外部用户(包括客户、合作伙伴和公共受众)提供服务,这些用户需要满足 ADA、第 508 节和/或欧洲无障碍法案要求的无障碍设计(取决于辖区、受众和组织类型 ) 。

  • **使用可访问的模板。**使用 Lightning Web Runtime (LWR) 构建的 Experience Cloud 模板包含基准可访问性。标准模板（例如客户帐户入口网站和帮助中心）在正确配置时提供 WCAG 2.2 AA 基础。自定义模板需要明确的可访问性实施，包括语义标记、键盘导航和屏幕阅读器兼容性。
  • **验证主题中的 WCAG 合规性。**自定义主题和品牌站点需要颜色对比度验证。体验生成器的主题设置控制颜色、排印和间距。确保所有文本满足正常文本的 4.5:1 对比度（常规文本低于 18pt，粗体文本低于 14pt），以及大文本（常规文本低于 18pt 或更大，粗体文本低于 14pt）和 UI 组件的 3:1 对比度。使用浏览器开发人员工具或在线对比度检查器来验证合规性。使用浏览器缩放到 200% 进行测试，以确保文本在不丢失内容或功能的情况下缩放。
  • **在导航菜单中使用键盘导航。**Experience Cloud 导航组件必须支持仅键盘操作，而不依赖于鼠标。用户必须使用 Tab、Enter、Escape 和箭头键导航下拉菜单、超大菜单和弹出导航，而无需焦点陷阱。仅使用键盘测试所有导航路径，以验证可访问性。
  • **在 Experience Cloud 中启用表单可访问性。**使用适当的标签元素或 aria-labeledby，明确关联标签与所有表单输入。占位符文本本身不符合可访问性要求，因为文本会在数据输入开始时消失，这使得屏幕阅读器用户没有足够的持久上下文。Lightning 输入组件在使用所需的标签属性进行配置时提供内置的标签关联。自定义 Visualforce 表单需要明确的标签-输入关联。
  • **使用辅助技术测试 Experience Cloud 站点。**在启动面向公众的 Experience Cloud 站点之前，您必须使用屏幕阅读器、仅键盘导航和浏览器缩放进行全面的可访问性测试。重要的是让残疾用户参与可用性测试，以揭示专家审查可能经常错过的实际、真实体验障碍。仅测试内部 Lightning 页面而不验证外部 Experience Cloud 可访问性会使面向公众的站点容易受到可访问性投诉和诉讼。
  • **为图像和图标使用替代文本。**Experience Cloud 中的所有信息性图像、图标和图形内容都需要替换文本。装饰图像使用空替换文本 (alt="")，这允许屏幕阅读器跳过它们。信息性图像提供有意义的替代文本，描述内容和功能。当您为图标编写替换文本时，请关注图标的操作或目的，而不是其视觉外观（例如，不要将放大镜图标描述为“放大镜”，替换文本应说明其功能实用程序，例如“搜索站点”）。在管理图像时，CMS 必须提示内容作者输入替换文本或明确将图像标记为装饰性（这将设置 alt=""）。通过防止丢失替换文本和强制描述美学图像，确保可访问性。

完整的键盘可访问性意味着用户可以使用键盘访问所有功能，而无需鼠标或触摸交互。

  • **在 Lightning 页面中使用逻辑焦点顺序。**确保焦点顺序遵循可视布局和交互流。当用户按下 Tab 键时，可视焦点应按照用户基于可视设计的预期顺序在交互元素中移动。Lightning 应用程序生成器和体验生成器根据组件位置确定焦点顺序。自定义组件需要显式选项卡索引管理，以确保逻辑焦点进度。
  • **使用可见的焦点指示器来满足对比度要求。**Lightning 设计系统提供聚焦样式，以满足大多数组件的 WCAG 要求。自定义组件可能需要增强的焦点指示器，以满足周围内容的 3:1 对比度要求。焦点指示器必须清晰可见，以允许弱视用户通过键盘导航。在没有提供其他可见焦点样式的情况下，请勿使用 CSS 移除焦点指示器（概述：无）。
  • **在模态和叠加中使用键盘陷阱缓解。**模态对话框应在打开时将焦点困在模态中，这可防止键盘用户触及模糊的背景内容。焦点陷阱应在模态关闭时释放，并将焦点返回到触发器元素。如果没有转义机制，嵌入内容（包括 iframe 和第三方小部件）不能永久捕获键盘焦点。
  • **使用没有冲突的快捷键。**Lightning 提供 Salesforce 帮助中记录的标准键盘快捷方式。自定义键盘快捷方式的设计必须防止与标准浏览器控制和屏幕阅读器导航命令冲突。按照 WCAG 成功条件，单字符快捷方式（例如，按单个字母或标点符号）不得触发全局操作。他们必须将激活限制在特定组件具有活动焦点时，或为用户提供完全关闭或重新映射快捷方式的方法。

将可访问性验证构建到 CI/CD 漏斗中，以便在每次部署时自动查找结构问题，而不是将可访问性视为定期的手动审计。

  • **使用 sa11y 进行 Lightning Web 组件可访问性测试。**Salesforce 的 sa11y 库（@sa11y/jest 软件包）封装了轴核心可访问性引擎，以便为 Jest 单元测试添加 toBeAccessible() 匹配器。编写可访问性测试，作为单元测试的一部分，自动验证正确的 ARIA 使用情况、标签关联、对比度和语义标记。将生成配置为在检测到关键的可访问性问题时失败。
  • **将 Lighthouse CI 用于 Experience Cloud。**Google Lighthouse 会审核网页可访问性，包括 Experience Cloud 站点。将 Lighthouse CI 集成到部署漏斗中，以扫描面向公众的页面是否存在可访问性问题。配置分数阈值，以在部署批准前要求最低可访问性分数。
  • **使用通过 Salesforce DX MCP 软件包提供的无障碍代理。**在兼容 MCP 的环境中或 Agentforce 环境中，它根据 WCAG 标准审查代码，显示有针对性的修复，并可以生成拉取请求，供工程师审查、验证和合并。

在 AI 进入图像之前，偏见早就存在于确定性 Salesforce 自动化中。分配规则、流决策、验证规则和区域设计编码人类判断，这可能会使歧视永久化。与架构师广泛审查的 AI 偏见不同，自动化偏见通常未经审查，因为确定性逻辑感觉客观。

  • **遵循潜在客户和个案分配规则。**在销售和服务团队之间分配工作。当分配逻辑使用与受保护特征相关的标准时，自动化会在服务质量和业务机会访问方面产生系统性差异。
  • 使用区域、邮政编码或客户特征的分配规则可能会将高价值业务机会不成比例地路由到特定团队，而将低价值工作路由到其他地方。如果区域边界与不同区域的客户人口统计和报酬结构相关，分配自动化会产生经济歧视。
  • **定期审计分配规则结果。**计算按客户人口统计分层的区域和团队之间的分配。如果企业客户集中在特定的区域，而 SMB 客户分布在其他地方，并且如果企业区域得到更好的补偿或资源，那么分配规则可能会产生不公平的结果，需要公平审查。
  • **查看基于技能的全方位路由。**这会影响客户群的服务质量。如果路由逻辑隐式假设某些技能与客户价值或问题复杂性相关，那么客户可能会收到基于人口统计代理的不同服务结果。

重要的是监控平均处理时间、首次联系解决率和路由路径中的客户满意度。差异可能表明某些客户群是否系统地接收了经验较少的客服人员或更少的路由选项。

  • **查看 Salesforce 流自动化。**做出批准决定、资格确定或访问权限授予可能通过看似无害的业务规则编码歧视性逻辑。当标准与受保护的特征相关时，某些流会产生间接歧视。
  • **考虑公平性，审查流决策。**对于做出影响用户的相应决策的每个流，重要的是要问：
  • 不符合典型客户简档的用户会怎样？
  • 决策标准是否与人口统计特征相关？
  • 异常和边缘个案是否得到公平处理，或者它们是否系统地使特定群体处于不利地位？

重要的是在架构决策记录中记录流决策逻辑和公平性注意事项，并将高风险流置于与 AI 系统相同的道德审查策略之下。

  • **查看验证规则。**阻止数据输入可能会将有效数据从信息与系统假设不匹配的用户中排除。拒绝合法数据的验证规则会产生不可见的人群。数据不符合验证模式的用户无法使用某些系统。验证失败通常不会报告，因为用户放弃他们的请求，而不是报告技术错误。以下是几种常见的验证偏差模式：
  • 需要拉丁字符的名称验证可能会排除带有变音符和非拉丁字母的名称。
  • 电话号码验证通常使用美国/西方格式，不包括国际号码和其他通信方法。
  • 地址验证无法识别非标准地址（例如，邮政信箱、乡村路线、部落土地和国际格式）。
  • 需要个人电子邮件地址的电子邮件验证可能会对没有个人电子邮件访问权限的用户造成不利的影响。
  • **使用不同的数据测试验证规则。**在验证测试中包括国际地址、非西方名称和其他电话格式。当验证拒绝合法数据时，您必须扩展验证逻辑以避免排除有效用户。
  • **审查销售区域设计。**客户细分策略和销售区域设计决定了客户群之间的资源分配。当区域边界或细分标准与导致资源分配不平等的人口统计相关时，这种分配会产生歧视性结果。由于住宅隔离模式，使用地理边界的区域设计通常与种族、族裔和经济人口统计相关。如果各地区的薪酬、人员配备水平或资源投资不同，地理位置会成为歧视性资源分配的机制。
  • **在最终确定设计之前，分析区域人口统计数据。**跨建议的区域边界映射客户人口统计。在出现人口集中时，评估资源分配是否在所有区域间公平，而不论人口组成如何。如果业务理由要求各区域的资源水平不同（例如，市场成熟度、竞争强度和增长潜力），请明确记录该理由并监控结果，以确保服务不足的区域获得足够的投资机会，防止根深蒂固的差异。
  • **保持自动化逻辑的透明度。**在 Salesforce Knowledge 或架构决策记录中记录业务规则、分配条件和流决策逻辑。透明自动化能够以隐藏逻辑阻止的方式审查公平性。
  • **定期审计结果。**计划季度审计，以分析可能按客户人口统计分层的自动化结果。请记住，差异会触发调查和潜在的补救。
  • 重要的是跟踪：
  • 团队和区域之间的分配
  • 做出资格决定的流的批准率
  • 按数据模式划分的验证规则拒绝率
  • 区域绩效和资源分配
  • **通过道德镜头查看高风险自动化。**影响就业、信用、服务访问或与 AI 系统相同的道德审查流程的其他结果的主题流和分配规则。自动化偏见需要与算法偏见相同的审查级别。

在 Salesforce 中，AI 公平性侧重于使用 Einstein 来验证预测是否在所有人口群体中产生公平的结果。Einstein Discovery 和自定义仪器可以捕获预测模型决策数据，从而实现偏见检测。CRM Analytics 仪表板会跟踪公平度量。Field Audit Trail 和 Event Monitoring 捕获算法问责的决策数据。

影响相应决策的 Einstein 预测(例如潜在客户评分、业务机会预测和客户细分)需要部署前公平性评估，作为强制等效步骤(类似于安全审查)。

使用统计方法分析所有预测模型特征与受保护特征的相关性。在评估代理功能的预测值是否证明尽管有代理影响仍应包含后，移除或转换代理功能。

  • **在培训前审核 Salesforce CRM 数据。**Salesforce 组织包含基于历史实践的数十年人类决策。如果过去的销售团队优先考虑某些人口统计，那么 Einstein 潜在客户得分会学习这些模式并将其永久化。在对历史数据进行预测模型训练之前，重要的是要审核这些数据，以了解不同客户细分之间的人口统计表征差距和测量不一致。
  • **计算跨人口统计组的公平度量。**在部署预测模型之前，计算受保护群体之间的人口均等、平等机会和不同影响率非常重要，因为您可以在这些群体中收集和处理所需的人口统计数据。如果 Einstein 潜在客户得分在 50% 的时间内将高分分配给分段 A，但只有 30% 的时间分配给分段 B，那么 60% 的比例不符合五分之四规则 (80%)，需要进行调查和缓解。80% 的数字是筛选触发器，而不是法律通过/失败线：五分之四规则是美国联邦就业选择的经验法则，排除它不是一个安全港 — — 在更高的比率下，统计上的重大差异值得仔细审查，而其他制度衡量负面影响的方式也不同（例如，欧盟间接歧视法开启了一个实践是否造成“特别不利”的问题，没有固定的阈值 ） 。将调查阈值校准到您操作的管辖区和用例。
  • **捕获预测模型决策数据，用于偏见检测。**要检测潜在客户评分和业务机会评分等预测模型中的偏见，请通过 Einstein Discovery 和自定义仪器捕获决策数据：在跟踪字段中存储预测输入、输出和模型版本，并启用字段审计跟踪。在 CRM Analytics 中分析这些数据，以随着时间的推移跟踪人口统计组的决策模式，并构建仪表板，以便在人口统计均等或平等机会度量偏离可接受的阈值时发出警报。
  • **检测预测模型中的代理特征。**与受保护特征相关的特征支持间接识别，即使受保护特征被排除在模型之外。
    • Salesforce 数据通常包含代理功能：
  • 地区或邮政编码（种族、族裔和收入的代理）
  • 客户名称模式（组织规模和行业人口统计的代理）
  • 通信活动时间（时区、宗教和护理责任的代理）
  • 活动数据中的设备类型或浏览器（收入级别的代理）

在 Einstein 预测中检测到偏差时，您必须在适当的漏斗阶段应用缓解措施（基于根本原因和技术约束）。

  • **模型训练前的余额数据。**在训练预测模型之前，通过过度抽样代表性不足的客户细分或过度抽样代表性不足的细分来重新平衡 Salesforce CRM 数据。使用 Data 360 在多个组织中聚合数据，以确保不同的训练集。合成数据生成可以通过不同的隐私技术来补充稀疏细分，同时保护隐私。
  • **删除功能工程中的代理。**在识别代理功能时，使用提供预测功能的替代功能进行替换，而无需人口统计相关性。如果区域用作人口统计代理，则考虑行业分类或公司规模作为替代。如果客户名称模式与人口统计相关，请改用公司历史属性。
  • **在后处理期间调整阈值。**调整每个人口细分的决策阈值，以平衡训练模型后的结果率。对于与就业相关的决定,直接禁止:第七章(1991年民权法)禁止按受保护阶级调整分数或使用不同的截止分数,而且没有多少书面理由使这种做法合法。在未禁止的情况下，记录阈值调整，并在预测为自动决策提供信息时说明区别对待的业务理由。
  • **使用更新的数据定期重新训练模型。**每季度计划一次模型再培训（或当发生重要的数据分发轮班时）。对新数据进行重新训练会捕捉新出现的偏见模式，并纠正任何偏离原始公平基线的情况。在生产部署之前，重新验证每个模型版本的公平性度量，以确保重新培训不会引入新的偏见。

Einstein Trust 层捕获生成式 AI 和 Agentforce 功能的提示、响应和 Trust 信号，支持生成式 AI 的透明度和合规性。对于预测模型，透明度和决策谱系来自 Einstein Discovery 和模型管理器，这需要自定义仪器来保留审计数据。

从初始架构到 Einstein 解决方案构建可解释性，而不是在部署后将解释重新构建到不透明的系统上。

  • **在决策点展示 Einstein Discovery 解释。**Einstein Discovery 提供预测因素解释，显示哪些变量对具有方向性影响的特定预测影响最大。架构师 Lightning 组件，在决策点向用户显示这些解释，而不是需要导航来分离 CRM Analytics 仪表板。当决策影响用户时，他们需要透明度，而不是抽象的模型性能度量。
  • **不同受众的分层解释。**提供适合每个受众的解释深度：
  • **业务用户：**该潜在客户得分很高，因为年收入超过 100 万美元，参与度得分排名前 10% 。 ”
  • **技术用户：**提供 Einstein Discovery 模型卡，其中包含功能权重、训练数据特征和验证度量。
  • 客户：“此推荐基于您最近的购买和具有相似首选项的客户。”
  • **审核员：**提供通过自定义仪器捕获的 Einstein Discovery 和模型管理器的决策谱系（模型版本、输入值和推动预测的因素）。
  • **适当沟通信心。**以用户适当的术语显示预测置信度，并避免用户可能误解的原始概率分数。与其显示“73% 的置信度”，不如使用类别（例如，高置信度、中等置信度和需求审查）来传达这一点，并解释每个置信度级别对决策可靠性意味着什么，以及将进行哪些额外的审查。

维护全面、不可变的审计跟踪，支持对影响用户的所有 AI 驱动的决策进行问责、调试和监管合规。

  • **使用正确的工具捕获预测性审计数据。**在启用了字段审计跟踪的被跟踪字段中存储预测模型审计数据（预测输入、输出和模型版本）。构建数据保留策略，以满足因行业和司法管辖区而异的监管要求：
    • 金融服务规则根据条例设置保留期(例如,FINRA 规则 4511(b) 为根据 FINRA 规则或 SEA 规则 17a-4 没有指定保留期的记录设置默认六年保留期 ) 。
    • 医疗保健保留也受特定规则的约束(例如,HIPAA 要求合规文档至少保留 6 年;病历保留由各州法律制定 ) , 而不是一揽子无限期保留规定。
  • **使用 CRM Analytics 分析预测模型决策数据。**根据您捕获的预测模型决策数据（被跟踪字段中的预测输入、输出和模型版本）构建 CRM Analytics 仪表板，以分析决策模式、公平度量和模型随时间的变化。创建按置信度、人口细分和结果类型显示预测分布的镜头。配置 Einstein Discovery 数据趋势图，识别需要进一步调查的异常模式。
  • **使用字段审计跟踪进行长期保留。**标准字段历史会在 UI 中跟踪 18 个月的变化，并通过 API 跟踪最多 24 个月的变化。字段审计跟踪允许您无限期地保留存储 AI 决策数据的自定义对象的字段历史。默认情况下，它会在最多 18 个月后归档历史，然后保留归档的数据，直到您将其删除。对包含同意记录、覆盖决策和偏见报表的对象启用字段审计跟踪，以满足监管保留要求。
  • **使用 Event Monitoring for Agentforce interaction.**Event Monitoring 会捕获 Agentforce 的调用级事件，例如在操作和流运行时。将 Event Monitoring 数据导出到外部 SIEM（通过 API 导出标准事件日志文件数据，通过平台事件导出实时 Event Monitoring 事件子集），以便存储超过 Salesforce 本地保留窗口。篡改证据取决于强制实施一次写入存储和访问隔离的特定 SIEM 行为。配置 SIEM 查询，以检测大量 Agentforce 交互中的偏见模式。
  • **审核 Agentforce 与 Einstein Trust 层的对话。**Einstein Trust 层捕获存储在 Data 360 中的 Agentforce 对话提示和响应的审计跟踪，为实现透明度和法规遵从性提供脚本级记录。

让我们仔细看看架构师的透明度功能，这些功能旨在遵守跨多个司法管辖区的当前和新兴 AI 法规。

  • 欧盟 AI 法案透明度要求。欧盟 AI 法案下的高风险 AI 系统需要透明度文档、技术文档、人员监督能力和准确性/公平性度量。Einstein Trust 层审计跟踪和 Einstein Discovery 模型卡为这些要求提供了基础。记录模型训练数据人口统计、验证方法和架构决策记录中的已知限制。
  • **GDPR 解释权。**GDPR 赋予欧盟数据主体权利，当决策完全基于自动化处理并产生法律或类似重大影响时，有权获取有关决策逻辑的有意义信息。这项权利源自第15(1)(h)和第22(3)条,与建议71一并解读,并由欧洲法院在Dun & Bradstreet (2025)中澄清。设计系统，以便在数据主体访问请求时间范围内按需对任何历史决策生成一致的解释，该时间范围在 15 到 45 天之间（取决于司法管辖区）。您捕获的预测模型决策数据 — 预测输入、输出、模型版本和 Einstein Discovery 解释因素 — 使您能够在存储时以足够的保留重新构建解释。
  • **算法问责法。**美国州级算法问责法越来越多地要求自动化决策系统提供影响评估和透明度报告。您捕获的预测模型决策数据和 CRM Analytics 公平性监控仪表板为这些报表提供了数据基础。在将后续 AI 部署为主动合规而不是对监管查询的反应性响应之前，请执行算法影响评估。

OWD、共享规则和字段级安全性 (FLS) 塑造了数据访问模式，决定了用户可以查看和使用哪些信息来做出决策。正确的配置可以防止对敏感属性的歧视性访问，同时确保公平的服务。

设计 OWD 和字段级安全性，以默认限制访问权限。对于共享规则，使用最小特权 (PoLP) 原则，仅授予每个角色合法需要的额外访问权限，这将防止基于受保护特征的歧视性决策。

  • **默认启用限制性 OWD。**对包含敏感客户数据的对象使用专用 OWD，并按角色层次结构和共享规则授予访问权限。公共读/写 OWD 使稍后限制访问具有破坏性 — 收紧默认设置会触发共享重新计算，并且仅在完成后生效 — 而不是不可能。具有明确共享拨款的私有 OWD 创建了支持不歧视合规的可审计访问模式。
  • **对敏感属性应用字段级安全性。**对于出于合法商业目的不需要访问权限的用户，隐藏包含受保护特征（例如，种族、宗教和残疾状态）的敏感字段。配置 FLS，以删除大部分简档中敏感字段的读取权限。当这些字段出于特定目的（例如，多样性报告和合理便利）需要时，使用具有记录的业务理由的权限集授予最低访问权限。
  • **设计公平结果的分配和共享规则。**使用分配规则、队列和全方位路由，以在区域、团队和服务客服人员之间公平分配工作。避免在没有书面业务理由的情况下，将高价值业务机会或客户集中在特定用户群的手动共享。根据客观标准（例如，行业、地理位置和产品线）配置自动共享规则，而不是主观的经理酌处权，这可能会导致偏见。
  • **提供临时访问权限集。**通过权限集授予对敏感数据的临时访问权限，而不是修改简档，这将永久影响所有用户。当用户需要访问特定项目的人口统计数据时（例如，多样性分析和住宿请求），分配具有记录到期时间的权限集。计划的流可以在定义的期间后自动撤销权限集。

使用 Shield Event Monitoring 和报表来检测表明数据使用中潜在歧视或偏见的数据访问模式。

  • **使用 Shield Event Monitoring 审核对敏感数据的访问权限。**使用 Event Monitoring 捕获包含受保护特征或敏感属性的对象上的对象级访问事件（报表导出、API 查询和页面视图）。配置对这些事件的查询，以显示谁、何时以及在什么上下文中访问该对象，并将异常模式（例如，突然峰值和意外用户的访问）视为调查的触发器。
  • **共享规则分配的报表。**构建报表，分析记录如何在用户、团队和区域之间分发。按客户人口统计计算分配统计数据，以确保高价值客户和业务机会得到公平分配。确定特定用户组在没有记录的业务理由的情况下获得对宝贵记录的过度访问的集合。
  • **审计 CRUD 和 FLS 违规。**查看设置审计跟踪，了解对 OWD 设置、共享规则、FLS 配置和权限集的更改。对数据访问控制的未授权更改可能表示有人试图不适当地访问敏感数据。使用事务安全性策略对高风险实时 Event Monitoring 事件采取行动（例如，异常 API 活动、可疑登录和敏感数据的大报表或列表视图导出）。由于事务安全性仅对这些运行时事件进行操作，而不是对记录级 DML 或 FLS 更改进行操作，因此您必须依赖设置审计跟踪和 FLS 和共享更改的文档化更改管理批准。

在 Salesforce，用户代理意味着客户和员工对 AI 如何影响他们的体验保持有意义的控制。Salesforce 同意管理功能、Data 360 同意和自定义同意对象支持对 AI 交互进行精细控制。

使用 Data 360 同意管理、Marketing Cloud 同意或使用特定于 AI 的同意要求的字段审计跟踪的自定义同意对象来设计同意跟踪。

  • **为每个 AI 用例启用粒度同意。**启用每个 AI 用例的同意，而不是使用一揽子 AI 同意。客户可能同意 Einstein 产品推荐，但拒绝 AI 驱动的信用决策。启用同意对象的字段审计跟踪，以便长期保留并满足监管要求。使用跟踪以下字段设计自定义同意对象：
  • 同意目的（例如 Einstein 潜在客户评分、Einstein 回复推荐和 Einstein 推荐生成器）
  • 同意授予日期和授予方法（例如，Web 表单、API、电话和电子邮件）
  • 同意撤销日期（如果适用）
  • 相关用户或联系人 ID
  • **使用 Data 360 同意进行个性化。**将 Data 360 同意管理用于 Einstein 个性化功能。Data 360 通过映射到隐私数据模型的连接器从上游系统接收和存储同意首选项，这允许您在细分和激活时将这些同意属性用作筛选条件。将同意属性映射到特定的 AI 用例，使用户能够选择退出个性化，同时还能维护核心服务
  • **启用 Marketing Cloud 同意集成。**将 Marketing Cloud 同意与 Einstein 消息传递见解和 AI 驱动的市场营销功能集成。在所有 AI 驱动的通信中，尊重 Marketing Cloud 订阅状态和同意。

通过质量相当的人工替代方案，通过尊重用户首选项的可访问控制，从 AI 驱动的功能中提供有意义的退出。

  • **在简档设置中提供可访问的选择退出。**使用户能够通过 Experience Cloud 简档设置中的可访问首选项控制或内部应用程序中的“我的设置”选择退出 AI 驱动的交互。清楚地描述每个选择退出的含义，以及用户在选择退出时将收到的替代体验。在用户或联系人记录中存储首选项。
  • **跨渠道提供持久首选项选项。**在用户或联系人记录中存储 AI 首选项，以确保渠道之间的一致性（例如，Web、手机、电话和电子邮件）。在所有交互流中一致地查询首选项，以防止用户需要在不同渠道中重复声明首选项。

符合道德的 AI 治理提供了组织结构，有助于确保公平性随着模型的发展、数据转移和用例的扩展而持续存在。如果没有治理，最初的公平努力会随着组织注意力的转移而恶化。

在部署 Einstein 之前，建立强制文档并检查检查点。将其视为与安全审查同样重要的大门。

  • **提供模型文档。**使用自定义模型对象或附加到项目的 Salesforce Files，在 Salesforce 中存储模型文档，以实现可搜索性和版本控制。使用以下内容记录每个生产预测模型：
  • 训练数据人口统计和已知表征差距（适用于客户训练的预测模型，例如 Einstein Discovery 和预测生成器）
  • 按人口统计组计算的部署前公平度量
  • 预期用例和已知不当使用
  • 开发期间应用的偏见缓解策略
  • 公平性监测方法和警报阈值
  • 人员监督要求和审批工作流
  • 审查时间表和责任方
  • 监管注意事项和合规定位
  • **启用部署前公平大门。**未通过任何网关测试的模型不得继续生产。将公平门视为与安全门相同的严格程度。换句话说，它们拥有阻止部署的权限。在将 Einstein 预测部署到生产之前，您必须：
  • **审查培训数据审计。**必须分析和记录所有代表性差距。
  • 审查公平度量(例如,必须计算并确认人口统计均等、平等机会和差别性影响,以满足阈值 ) 。
  • **审查影响评估。**评估受影响人群的潜在伤害。
  • **设计要有人工监督。**所有升级模式、批准工作流和覆盖机制必须经过适当的设计和测试。
  • **完成透明度审查。**必须验证所有决策类型的解释功能。
  • **完整文档。**所有必需的模型文档工件必须获得批准。

为高风险 AI 应用程序建立审查流程，提供跨职能监督并拥有执法权限。

  • **审核委员会组成。**包括技术专家（例如，架构师和数据科学家）、业务利益相关者（例如，产品所有者和运营人员）、法律顾问、隐私专家和受影响社区的代表（如果可能）。请谨记，不同视角会暴露出同质群体经常忽略的公平问题。
  • **查看需要道德委员会批准的所有触发器。**定义哪些 AI 用例需要在部署前进行道德审查：
  • 影响就业、信贷、住房、医疗保健或法律权利的决定
  • 每年影响超过 10,000 个用户或交易的自动化系统
  • 使用敏感个人数据的 AI 应用程序，包括健康、财务或人口统计数据
  • 没有既定组织先例的新用例
  • 潜在偏见可能对个人或群体造成重大伤害的系统
  • **查看并确定谁有权阻止部署。**道德审查委员会应有权要求更改、强制实施监控条件或阻止不符合道德标准的部署。仅提供咨询的审查（没有强制执行的权力）可能会限制治理过程的有效性。记录 Salesforce 自定义对象中跟踪的所有审核：申请名称、审核日期、提出的顾虑、缓解要求和批准条件。

公平性监控是一个持续的过程，需要持续关注，以随着数据分布的变化和用户群体的变化检测偏差。

  • **创建 CRM Analytics 公平仪表板。**使用您捕获的预测模型决策数据构建跟踪公平度量的仪表板。按客户细分监控人口统计均等、业务机会平等、不同影响比率和预测质量度量。配置 CRM Analytics 警报，这些警报会在公平度量违反定义的阈值并需要调查时触发。
  • **启用公平信号的自定义监控。**构建自定义公平性监控来检测信号（例如，按人口统计组划分的决策分布的突变、与偏见相关的个案记录的峰值或特定人群的模型性能下降）。
  • **计划公平性审计。**对高风险的 AI 系统（例如，信贷、就业和医疗保健）进行全面的季度公平审计，对低风险的系统（例如，推荐和个性化）进行半年期审计。审计应检查当前的公平度量，审查批准历史中的覆盖模式，分析用户反馈和偏见报表，并验证治理控制是否仍然有效。
  • **对公平失败实施事件响应。**建立清晰的流程，这些流程在 Salesforce Knowledge 中记录，详细描述了在检测到偏见时如何响应：
  • **即时：**通过在 CRM Analytics 中查询预测模型决策数据，评估严重性和范围。如果事件严重，在调查前暂停所有自动决策。
  • **短期：**实施临时缓解策略（例如，通过调整置信度阈值、禁用功能或完全暂停客服人员来增加人员监督）。
  • **调查：**完成根本原因分析 (RCA)，以确定偏见如何进入系统或演变。在 RCA 期间，通过现场审计跟踪分析培训数据、模型版本和配置更改。
  • **补救：**通过数据更正、模型重新训练或流程更改实施永久修复。
  • **通信：**通过个案、电子邮件或 Experience Cloud 公告通知受影响的用户。
  • **预防：**处理更改以防止重复发生，并在 Runbook 中记录预防方法。

在架构审查期间、生产部署之前，使用此核对清单，并定期进行持续评估。

数据质量和代表性公平性

  • 在进程可以运行而没有数据的情况下，使字段成为可选字段，并设计下游进程来处理缺失的值，这样无法提供信息（电子邮件、SSN、街道地址）的用户就不会被排除在外。
  • 架构师姓名字段作为单个全名字段或灵活的多部分结构，接受单名、非拉丁字母、变音符和长名称，而不是假设西方的首尾顺序。
  • 实施允许的地址验证，接受自由格式和国际格式，存储输入的地址，而不是在格式不匹配时阻止创建记录。
  • 在联系人记录中存储通信渠道首选项，并支持全方位替代（电子邮件、短信、电话、邮寄、聊天、语音），而不是假设一个渠道可以联系到所有用户。
  • 通过带有“宁愿不回答”选项的自愿自我识别收集人口统计数据，单独存储在带有 FLS 的专用 OWD 下，汇总用于报告，并通过 Shield Event Monitoring 进行监控。
  • 在将人口统计或行为数据附加到记录之前，审核第三方丰富供应商的公平性测试、人口统计覆盖率和推理方法。

可访问性和包容性设计

  • 使用 Lightning 设计系统组件，这些组件旨在支持 WCAG 2.2 AA 可访问性。请谨记，Salesforce 力求合规，但组件仍需要正确使用。
  • 通过屏幕阅读器测试（例如 JAWS、NVDA 和 VoiceOver），验证自定义 Lightning Web 组件。
  • 确保 Lightning 页面和 Experience Cloud 站点中存在完整的键盘导航，而不依赖于鼠标。
  • 使用浏览器开发工具或对比度检查器，验证正常文本的对比度是否达到 4.5:1。
  • 在失败的 CI/CD 漏斗中集成 sa11y 或 Lighthouse 可访问性扫描，构建关键问题。
  • 在公开发布前，使用辅助技术测试 Experience Cloud 站点。
  • 通过确认所有动态更改（例如，错误状态、加载微调器或展开菜单）都已明确宣布，并且口语内容与 UI 的视觉意图相匹配，来验证听觉反馈。

Salesforce 自动化的公平性

  • 查看分配和路由规则，了解与受保护特征的相关性，这些特征可以将有利或不利的结果集中在特定的人口统计组中。
  • 审核流和流程自动化决策逻辑是否存在偏见，在 Salesforce Knowledge 或架构决策记录中记录业务规则和标准。
  • 评估不成比例地影响特定数据模式或人群的拒绝率的验证规则。
  • 分析区域和细分设计的人口统计相关性，记录明确的业务理由，并监控服务不足的区域，以实现公平的资源分配。
  • 将高风险流和分配规则（就业、信贷、服务访问）置于与 AI 系统相同的道德审查流程中，并计划按人口统计分层的自动化结果的季度审计。

AI 公平和偏见检测

  • 在预测模型训练之前，审核 Salesforce CRM 数据中人口统计表征的差距。
  • 在部署前，计算每个人口统计组的人口统计均等、平等机会和不同影响率。
  • 实施公平性评估作为强制部署网关（将此视为相当于安全审查）。
  • 使用通过字段审计跟踪捕获的预测模型决策数据，构建跟踪公平度量的 CRM Analytics 仪表板。
  • 分析预测模型功能，了解代理与受保护特征的相关性（例如，区域和客户名称模式）。
  • 为所有高风险 AI 系统安排全面的季度公平性审计。

透明度和可审计性

  • 在 Lightning 组件的决策点显示 Einstein Discovery 预测解释。
  • 使用满足监管要求的保留方法配置 Einstein Trust 层审计捕获。
  • 在存储 AI 决策数据以便长期保留的所有自定义对象上启用字段审计跟踪。
  • 将 Event Monitoring 数据导出到外部 SIEM（通过 API 导出事件日志文件数据，通过平台事件导出实时 Event Monitoring 事件），以便存储超过本地保留，SIEM 侧的一次性写入控制用于篡改证据。
  • 提供适合用户的置信度通信（例如，高、中和低），而不是原始概率。

使用 Salesforce 自动化进行人工监督

  • 在流中配置基于置信度的升级阈值，并将低置信度预测路由到人工审核。
  • 将 Salesforce 审批流程用于需要多阶段审查链的高风险决策。
  • 集成 Agentforce 和全方位路由，支持无缝升级到人工客服人员。
  • 在 Agentforce 界面中提供持续的“连接到人工客服人员”选项，以尊重用户代理。
  • 对于在自定义字段中捕获的 Agentforce 覆盖，需要记录的理由和批准历史跟踪。

通过数据访问控制实现不歧视

  • 启用专用 OWD，然后通过角色层次结构和共享规则授予其他访问权限。
  • 配置字段级安全性，以对不需要访问权限的用户隐藏敏感人口统计字段。
  • 通过 Shield Event Monitoring 监控敏感数据的对象级访问事件（报表导出和 API 查询），并分析异常访问模式。
  • 构建分析共享规则分配的报表，以确保跨区域的公平记录分配。
  • 查看设置审计跟踪，了解未经授权的 OWD、共享规则或 FLS 配置更改。

用户代理和同意

  • 使用字段审计跟踪设计自定义同意对象，以跟踪每个用例的 AI 同意。
  • 将 Data 360 或 Marketing Cloud 同意与 Einstein 个性化和 Agentforce 功能集成。
  • 在用户或联系人记录中存储 AI 首选项，以确保渠道之间的一致性（例如，Web、手机和手机）。
  • 通过全方位路由，在简档设置和人工替代项中提供可访问的选择退出。
  • 在 Einstein 预测或 Agentforce 参与影响用户之前，在流中查询同意记录。

符合道德的 AI 治理

  • 记录所有生产预测模型，包括公平度量和缓解策略；对于客户训练的预测模型（例如 Einstein Discovery 和预测生成器），还要记录训练数据人口统计数据。
  • 建立强制部署前公平大门，阻止部署，直到满足所有公平标准。
  • 创建 AI 道德审查委员会，作为所有高风险 AI 应用程序的强制执行机构。
  • 构建 CRM Analytics 仪表板，以通过 CRM Analytics 警报按计划节奏监控公平度量。
  • 为公平失败定义事件响应程序，并在 Salesforce Knowledge 中记录该过程。
  • 安排季度公平审计，分析所有高风险系统的覆盖模式和用户反馈。

分享您对良好架构框架的反馈。