客服人员企业的公平性

客服人员企业的公平性

当自主客服人员做出影响客户、员工和社区的决策时，公平性成为区分负责任自动化和有害自动化的架构质量。Agentforce 客服人员在有限的人力监督下运作,以前所未有的规模延续和放大偏见,将个人歧视模式转化为系统性的不平等。代理系统中的公平性是 Salesforce 平台上的一流架构问题，该平台将 AI 公平性、可访问性、人工监督、算法问责制和道德治理整合到统一的架构支柱中。

此页面解决代理架构特有的公平性挑战。核心公平原则、无障碍要求和道德治理框架在公平支柱中涵盖。在这里，我们重点关注自主客服人员的注意事项：针对做出相应决策的客服人员的偏见检测和监督模式，旨在使问责成为实质性而非名义性的；透明度，允许受影响的用户质疑决策；平台功能，例如 Einstein Trust 层，通过数据控制和审计日志记录支持负责任的 AI 实践。

Agentforce 客服人员从训练数据、检索源和真实交互中学习模式。当这些来源包含反映历史歧视或人口统计不平衡的偏见时，客服人员会在人类检测到模式之前，以算法效率影响成千上万用户来延续这种偏见。

  • **基础模型偏差：**大型语言模型 (LLM) 使用包含种族、性别、年龄、残疾和其他受保护特征的社会偏见的互联网规模数据进行训练。这些偏见出现在客服人员的回复中，即使没有明确的歧视性说明，也不太可能仅通过即时工程或测试完全解决；它们反映了互联网规模培训数据的部分固有模式。例如，Agentforce 招聘客服人员可能会使用阳性语言模式描述领导角色。或者，服务代理可能会对名称表示非多数族裔或性别的客户做出不同回应，这是一个代表质量问题，可能会影响客户的体验，而与任何决策结果无关。

使用代表受保护群体的不同角色，系统地测试客服人员的人口统计偏见。生成相同的请求，仅更改人口统计信号，例如姓名、位置或通信风格。比较客服人员在角色间的回复，以了解质量差异、语气变化和结果差异。

  • **训练数据表示差距：**如果贵组织的历史客户关系管理 (CRM) 数据未充分反映某些客户细分，则接受过该数据培训或基础训练的 Agentforce 客服人员在这些细分中的表现将不佳。一位接受过十年业务机会数据培训的潜在客户评分员系统地低估了来自销售团队历史上取消优先级的地理区域的潜在客户，从而形成了一个反馈循环，算法偏见加剧了人为偏见。

在使用 Salesforce 数据进行客服人员培训或检索扩充生成 (RAG) 基础训练之前，请审核人口统计表示。确定代表性不足的群体，并评估代表性差距是否反映了合法的商业差异或历史歧视。在部署客服人员之前，通过数据扩充或明确减少偏差来减少不平衡；一些残余偏差往往仍然存在，通常通过下游监控和监督来管理，而不是在部署前解决。

  • **RAG 系统中的检索偏差：**Agentforce 客服人员在 Knowledge 库、Data 360 细分和 Salesforce 记录中使用 RAG 地面响应。当这些检索源包含有偏见的内容或不同人口统计组之间存在质量差异时，部署的客服人员可以将这种偏见带到受影响用户的体验中。为了降低这种风险，作为最佳实践，请在生产之前审核检索源。服务代理检索 Knowledge 文章，为企业客户提供详细的故障排除，但只为小型企业客户提供通用响应，这将使服务质量差异永久化，这在客户层与受保护的特征相关时是一个公平问题。

审计 Knowledge 库和检索源，以了解人口统计代表性差距和质量差异。对于难以弥合的差距，将这些限制视为客服人员适合的护栏。确保文档质量、完整性和准确性在所有客户群中具有可比性。在内容示例中包括不同的表示，而不是默认使用疏远代表不足的用户的多数文化引用。

  • **交互模式偏差：**客服人员可以根据与受保护特征相关的对话提示来调整行为。即使在部署后，监控这种模式也是常见的做法，因为一些交互动态来自训练数据中没有的用户行为。沟通风格、语言复杂性和时间模式可以发出人口统计信息的信号。客服人员对待正式沟通风格的方式不同于临时风格，这可能无意中基于文化背景、教育程度或母语状态进行歧视。

监控客服人员跨人口统计组的互动，以了解行为一致性。分析回复长度、详细信息级别、礼貌标记和按用户特征分层的解决方案质量。差异表明存在交互偏见,需要进行调查。

  • **反馈循环放大：**影响自己未来培训数据的客服人员会产生自我强化的偏见。例如，将较少高价值业务机会分配到特定销售区域的路由客服人员会为这些区域生成较少的成功数据。这反过来又降低了他们的预测成功概率，从而进一步减少了未来向他们路由的业务机会。如果没有干预，这种最初的偏见会随着时间的推移而加剧。

通过监控决策分配随时间的变化来检测反馈循环。当某些人口统计群体系统性地收到较少的积极结果时，调查客服人员的决策是否造成了差异，从而有理由做出未来的不利决策。通过人工审核边缘个案和定期重新平衡打破循环。

当多个 Agentforce 客服人员在编排链中一起工作时，一个客服人员的偏见会成为下游客服人员的输入，从而产生复合效应，其中初始的微小偏见会放大为显著的歧视性结果。

  • **顺序客服人员链：**当客服人员 A 的输出成为客服人员 B 的输入时，客服人员 A 有偏见的决策会以一种永久或放大歧视的方式约束客服人员 B 的选择。

考虑潜在客户资格编排：

  1. 研究客服人员从 Web 源和 CRM 历史记录收集客户智能。
  2. 评分客服人员根据研究客服人员的调查结果分配潜在客户分数。
  3. 路由客服人员根据得分将潜在客户分配到区域。
  4. 参与客服人员根据所有先前的客服人员输出个性化拓展。

当研究客服人员系统地检索某些客户人口统计的不太全面的数据时（由于训练数据缺口或检索偏差），评分客服人员会将不完整的信息解释为消极信号。然后，路由客服人员会分配到优先级较低的区域，参与客服人员会提供个性化程度较低的拓展。复合效应产生的服务质量差异远远超过任何单个客服人员的偏见。

  • **并行客服人员共识：**当客服人员共享训练数据或基础模型时，多个客服人员独立分析相同输入并汇总结果的模式提供了偏见放大机会。

如果 5 个客服人员分别对潜在客户进行评分，但他们都共享有偏见的训练数据或基础模型偏见，则共识不会纠正偏见，只会验证偏见。当所有五个客服人员都具有相同的系统偏见时，“五个客服人员达成一致”会对歧视性结果产生错误的信心。

编排偏差的缓解策略：

  • **每个阶段的客服人员输出审计：**记录编配链中每个客服人员的完整输入和输出。当在最终结果中检测到偏差时，通过链向后追溯，以识别哪个客服人员引入了偏差，以及在哪个阶段发生了放大。

构建 CRM Analytics 仪表板，显示按人口统计细分的每个编排阶段的决策分配。确定差距在链中出现或扩大的位置。

  • 客服人员培训和提示的多样性减少了相关误差，降低了偏差放大的可能性。在使用多客服人员共识模式时，最大化多样性：
  • 在商业上可行和支持的情况下的不同基础模型，例如通过自带 LLM (BYOLLM) 配置
  • 客服人员之间的不同检索源
  • 不同的提示工程方法
  • 不同的置信度阈值校准
  • **拐点处的人工审核：**确定决策显著缩小下游选项的编排阶段。在这些转折点插入人工审核，即使单个客服人员的置信度很高。编排会创建单个客服人员置信度得分无法捕捉的紧急效果。
  • **每个编排阶段的公平性度量：**不要只衡量最终结果的公平性。计算人口统计均等、平等机会和价值链每个阶段的差异性影响。

如果阶段 1 显示 90% 的人口统计均等，阶段 2 显示 85%，阶段 3 显示 78%，阶段 4 显示 70%，则每个阶段单独显示可以接受，但复合到无法接受的最终差异。在产生歧视性结果之前，阶段度量会捕获复合。

  • 编配失败的断路器 - 配置编配逻辑，以在以下情况停止并升级为人工：
  • 任何客服人员的置信度低于阈值，即使下游客服人员有信心
  • 编配阶段之间的输出分配显著变化
  • 决策链遇到未在训练或验证集中表示的数据
  • 用户明确质疑或质疑中间决策

多客服人员编配支持复杂的推理，但会产生不透明的决策链，问责会扩散，偏见会加剧。从架构上关注分阶段的公平监控和战略性的人力监督，可以防止编配成为偏见放大机制。

在部署任何 Agentforce 客服人员对用户做出相应决策之前，请计算人口统计组之间的公平性度量。使公平性评估成为强制部署网关，其权限相当于安全审查。

  • **人口均等：**受保护人口群体之间的阳性结果率必须大致相等。如果客服人员以 60% 的速度批准 A 组的服务请求，但以 40% 的速度批准 B 组，则违反人口统计对等。当没有正当理由导致各组之间的结果率差异时，人口统计均等是适当的。

通过将人口划分为人口细分、衡量每个细分的阳性结果率和比较细分之间的比率来计算人口均等。记录指定批准人和理由的奇偶性差距。

  • **平等机会：**真阳性率在各组之间保持可比性。无论人口统计特征如何，客服人员都能同样准确地识别合格的个人。当基础信用度相似时，预测模型会以相似的比率在受保护群体中识别有信用的申请人。

平等机会往往是比人口统计均等更合适的指标,用于决定个人资格,而基本费率可能合法地不同。监控客服人员是否系统地错过了代表性不足小组的合格候选人。如果缓解后仍存在差异，客服人员可能不适合此用例。

  • **等概率：**真阳性率和假阳性率在小组中相等。这是一个严格的定义，它限制了人口统计中的真阳性和假阳性率。平均机率可以防止错过的业务机会集中在特定小组，以及虚假指控集中在特定小组。

实现平均化概率通常需要每个人口统计组单独的决策阈值。在美国,对于与就业相关的决定,第七章(1964 年民权法)禁止按受保护阶级调整分数或设定不同的截止分数,因此在招聘中不能以这种方式追求均等化。在其他情况下,在其他法域,这会产生关于明确差别待遇的法律问题,因此在执行特定群体门槛值之前,请咨询法律顾问。

  • 不同的影响率：五分之四规则提供了筛选阈值：如果任何小组的阳性结果低于表现最佳的小组的 80%，请调查偏见。75% 的比例(例如,45% 的批准率与 60% 的批准率)低于五分之四的阈值,表明存在潜在的歧视,需要说明理由或减轻歧视。

差别性影响分析是就业法的标准，并越来越多地应用于人工智能系统。当定额低于 80% 时，记录调查和补救步骤；当补救没有提高比率时，团队可能会得出结论，用例不适合。

  • **个人公平性：**无论小组成员如何，类似的个人都会收到类似的预测。两个具有相同信用度、购买历史和参与的客户会收到类似的信用额度建议，而不论人口统计差异如何。

个人公平在哲学上很重要，但在操作上具有挑战性，因为“相似性”是主观的，并且依赖于上下文。将个人公平性用作指导功能选择和测试的设计原则，而不是严格的数学约束。

两个平台功能可以捕获偏见检测的数据。Einstein Trust 层记录每个 Agentforce 交互的生成式 AI 审计跟踪：发送到模型的提示、返回的响应、使用的基础源以及毒性分数等 Trust 信号。Agentforce 会话跟踪记录每个决策背后的逐步推理。它们共同提供的数据支持偏见检测和公平性监测；对这些数据的解释是人为的工作，通常需要经过培训的审查者和专门的时间。

  • **响应日志记录：**Trust 层记录每个生成式交互的提示、模型响应和 Trust 信号。使用此数据分析人口统计组的预测分布。构建 CRM Analytics 仪表板，按客户细分比较批准率、推荐模式和风险分数。

定期查询 Trust 层日志:使用以下提示：向我显示过去 30 天内按客户行业、地区和客户规模分组的所有高价值业务机会预测。预测在细分之间的分布是否一致，或者某些细分是否系统地得分更高/更低？”

  • **跟踪捕获的原因：**对于 Agentforce 客服人员，Agentforce 会话跟踪记录客服人员如何作出决定，而 Trust 层审计跟踪捕获提示、响应和基础来源，包括检索哪些 Knowledge 文章和 Salesforce 记录。当用户报告偏见时，查看两者，以了解哪些数据源、检索模式或推理步骤可能引入了偏见。

与传统系统相比，推理跟踪使临时公平性审计更加精细，更容易执行。按人口统计组分层的 100 个客服人员决策示例，并让审核人员评估推理质量是否在组之间具有可比性。

  • **异常检测：**在客服人员决策模式显著偏离基准时配置警报。如果特定客户群的批准率每周下降 20%，将触发调查。突然的分布轮班可能表示数据质量问题、模型偏差或需要立即注意的新偏差。

构建自定义监控，以提醒公平信号：“当 Agentforce 服务代理连续三天的平均对话长度超过总平均值的 1.5 倍时，将发出通知。”长度差异可能表明某些群体得到的服务效果较差。

  • **公平仪表板模板：**构建可重复使用的 CRM Analytics 仪表板模板，跟踪常见客服人员用例的公平性度量。包括人口统计均等计算、平等机会度量、不同影响比率和显示度量随时间演变的趋势图。在客服人员开发团队之间共享模板，标准化公平性监控。

在检测到偏见时，根据根本原因在适当阶段应用缓解措施。

  • **预处理数据干预：**在客服人员培训或 RAG 索引之前，请纠正数据级别的偏差。对培训数据中代表性不足的人口群体进行过度抽样，确保代表性平衡。在真实数据不足时，使用合成少数过度抽样技术 (SMOTE) 等技术，为代表性不足的群体合成其他数据。请注意，SMOTE 会内插数字、列表式特征，因此它适用于结构化 CRM 训练数据，而不是用于 RAG 基础训练的非结构化文本。

在使用 Salesforce CRM 数据进行模型训练之前，审核其人口统计差距。如果历史业务机会数据过度表示某些客户类型，请重新平衡训练集或使用抽样权重，以防止客服人员将过度表示作为决策信号。

  • **正在处理的算法约束：**在模型训练期间应用公平约束，同时优化准确性和公平性。这可能会降低原始准确性 2-3%，同时显著提高组之间的公平性。在您控制模型训练的地方，公平约束的训练通常是最有效的缓解方法。

对于使用基础模型的 Agentforce 客服人员（您无法修改培训），请通过系统提示约束客服人员行为：“以同等的专业精神和细节对待所有客户人口统计。无论客户沟通风格或背景如何，都要提供长度和质量相当的解释 。 ”

  • **后处理阈值调整：**在合法的情况下，调整每个人口组的决策阈值可以均衡模型训练后的结果率。例如，批准客服人员可能对一个组应用 80% 的置信度阈值，而对另一个组应用 75% 的置信度阈值，以抵消潜在的模型偏差。反歧视法严重限制了这一手段,一些司法管辖区对某些决定直接禁止(见下文)。

阈值调整具有争议性,因为它明确以不同方式对待群体,而许多法域的反歧视法限制或禁止它。在美国，对于与就业相关的决定，直接禁止：第七编(1964年民权法)禁止按受保护阶级调整分数或使用不同的截止分数,而且无论有多少书面理由都使这种做法合法化。其他司法管辖区会强加自己的约束，因此请确认适用于用户的规则。在允许的情况下，在实施特定于群体的阈值时记录法律理由，并验证阈值是否提高了公平性，而不会造成其他歧视性影响。

  • **代理功能检测和移除：**识别与受保护特征相关的特征，并作为间接识别机制。常见代理包括：
  • 种族、族裔和收入水平的邮政编码代理
  • 性别和种族的名称模式代理
  • 宗教和护理责任的沟通时间代理
  • 收入级别的设备类型代理
  • 区域分配可以代表人口组成

计算所有模型特征与受保护特征之间的相关系数。对于高度相关的特征，评估合法的预测值是否有理由包含，或者替代特征是否可以在没有代理效应的情况下提供类似的预测。

Agentforce 客服人员可以在人工监督下操作，旨在使审查具有实质性，而不是名义性。适当的监督级别取决于决策风险、可撤销性和监管要求。

在执行前，通过人工审核路由相应的决策。决策是否风险高到足以进行人工审核是基于风险的判断：权衡潜在伤害的严重性和伤害发生的可能性。结果决策通常出现在监管领域，例如医疗保健、金融服务和公共部门，但它们也出现在监管领域之外。常见的高风险上下文包括：

  • 雇用决策 - 雇用、晋升、解雇、报酬、绩效审查
  • 信贷和金融服务 - 信贷审批、限额变更、账户关闭、定价
  • 医疗保健 - 诊断建议、治疗建议、承保范围决策
  • 法律权利----合同解释、争议解决、获得服务
  • 住房 - 租户筛选、租赁批准、驱逐建议

在这些上下文中设计 Agentforce 客服人员来分析、推荐和准备决策，同时在执行之前需要人工批准。将客服人员定位为增强人类判断力的决策支持工具，而不是取代人类的自主决策者。

配置基于客服人员不确定性触发人工审核的置信度阈值：

  • 高置信度 (>90%) - 客服人员自动处理完整审计日志
  • 适度自信 (70-90%) - 客服人员在操作前进行人工审核后推荐
  • 低置信度 (<70%) - 客服人员完全服从上下文摘要

使用生产数据校准阈值。“70% 置信度”预测在验证时成功了大约 70% 的时间。校准错误的置信度分数会破坏对升级机制的Trust。

通过在每个置信区间抽样客服人员决策并计算实际成功率来测试校准。如果“高置信度”决策仅在 75% 的时间内成功，请重新校准阈值或改进模型置信度估计。

如果 Agentforce 无法在定义的限制内解决请求，请升级为人工。检查升级目标是否有容量提供帮助 - 路由到超载的队列不会减少危害。

设置升级触发器：

  • 对话轮次 – 在 5-7 次轮次未解决后，升级
  • 经过的时间 – 在 10 分钟没有解决后，升级
  • 用户情绪 – 当用户表示沮丧时，升级
  • 重复检测 – 当客服人员重复相同的响应时，上报

配置全方位，将升级的个案路由到具有完整对话上下文的适当基于技能的队列。培训人工客服人员高效处理升级，而无需用户重复已向客服人员提供的信息。

使授权人员能够随时使用记录的理由覆盖任何 Agentforce 决定。覆盖具有多种目的：

  • **纠错：**人工更正客服人员可能伤害用户或违反策略的错误。覆盖功能为在边缘情况不可避免的复杂环境中运行的自主系统提供安全阀。
  • **偏见检测：**如果人员覆盖某些人口统计的 Agentforce 拒绝次数比其他人员更频繁，请调查这两种可能性：客服人员可能系统地使该群体处于不利地位，人员可能正在纠正它，或者覆盖者可能引入了新的偏见。第一个模式指向审查客服人员；第二个模式指向审查人员培训。
  • **客服人员改进：**带有理由的覆盖将成为客服人员改进的训练数据。示例覆盖的决策，并分析人类与客服人员意见不一致的原因。将覆盖模式纳入快速细化或模型重新训练。
  • **问责制：**覆盖会分配责任。覆盖客服人员决策的人员对决策的结果负责。明确的问责制防止在每个人都认为 AI 是负责任的、没有人当家作主的情况下分散责任。

在部署前而不是事件发生后分配责任：

  • **模型所有者：**数据科学主管负责模型公平性、准确性和行为。批准部署，响应公平警报，授权更新。模型所有者是架构决策记录中记录的命名个人。
  • **决策所有人：**产品所有者负责为特定用例选择部署 AI，并负责对客户的真实影响。决策所有者不能将责任委托给 AI 系统。
  • **上诉机构：**道德审查委员会或指定团队处理来自认为客服人员决定不公平的用户的申诉。上诉流程必须可访问、及时，并有权撤销客服人员的决定。
  • **审计机构：**定期审计验证客服人员的合规团队在公平性参数范围内运行，并可以在补救前暂停未达标的客服人员。

记录所有角色的名称，而不仅仅是头衔，确保通过组织变革来保持问责制。

当 Agentforce 客服人员做出影响用户的决策时，这些用户应该得到与决策影响相称的可以理解的解释。

构建服务于不同受众的多个解释层：

  • **面向用户的解释：**无需技术专业知识即可理解的纯语言推理。“您的服务请求需要经理批准，因为请求的金额 (12,000 美元) 超出了您的授权限制 (10,000 美元)。经理批准通常在 24 小时内完成，或在商定的服务级别协议 (SLA) 内完成。
  • **业务解释：**运营用户可以看到业务上下文中的关键决策因素。“潜在客户得分：73/100.主要积极因素：公司规模（500 名员工）、活跃的网站参与度（30 天内 12 次访问）、行业匹配 (SaaS)。主要负面因素：没有 MQL 参与，在目标区域之外。”
  • **技术解释：**数据科学家可以查看模型详细信息：特征权重、置信度校准、模型版本、训练日期、输入分布。技术解释支持调试和偏见调查。
  • **审计解释：**合规团队可以看到完整的决策跟踪：模型版本、决策时的确切输入值、咨询的所有数据源、推理跟踪、配置状态。审计解释支持需要精确重建的监管调查和公平性审计。

Agentforce 会话跟踪记录客服人员决策背后的逐步推理，而 Einstein Trust 层捕获提示和响应审计跟踪，包括基础来源。它们共同允许您在适当的详细信息级别提供透明度：

  • **实时透明度：**Agentforce 做出决定时，向用户显示汇总推理：“我根据您的购买历史(3 次类似购买)、当前促销(8 折)和库存可用性(库存、明天发货)推荐了产品 A。”
  • **按需详细解释：**提供“您为何推荐此？”链接，使用户能够查看完整的推理，包括检索的所有 Knowledge 文章、咨询的 Salesforce 记录和决策逻辑。详细的解释建立Trust，使用户能够识别错误或偏见。
  • **历史重建：**当用户在几周或几个月后质疑过去的决策时，检索会话推理跟踪和 Trust 层审计历史，以便精确解释历史决策。历史重建支持上诉和监管调查。
  • **聚合模式分析：**按人口统计组分层的示例推理跟踪，分析决策质量是否一致。查看来自每个客户细分的 100 个跟踪，并评估推理深度、源质量和逻辑是否在小组之间具有可比性。

以用户适当的术语显示预测置信度，避免用户误解原始概率分数。

而不是“73% 的置信度”，将置信度传达为：

  • 高置信度 – ” 我相信基于类似个案的建议是合适的”
  • 适度自信 – ” 此推荐可能合适，但建议经理审核”
  • 信心不足 – ” 这种情况不同寻常。我要升级为专家，提供更好的指导”

解释置信度级别对可靠性的含义：“基于历史验证，高置信度推荐在大约 95% 的时间内是正确的。”

对于中等或低置信度决策，解释将进行哪些额外审查：“由于此请求超出了我们的标准参数,因此将由高级专家审核,批准通常在 24 小时内完成,或者在您商定的服务级别协议 (SLA) 内完成。”

在适当时，向用户显示什么会改变结果。反事实使用户能够通过具体行动改善结果，而不仅仅是通知他们已经做出的决定。

例如：“您的潜在客户得分会随着已验证就业信息（+8 分）和额外的信用参考（+5 分）而增加。提供此文档会将申请移到优先级审查队列 。 ”

反事实是一种强大的透明机制，但需要仔细设计。避免提供鼓励系统博弈或无意中揭示受保护特征作为决策因素的反事实。“如果你年轻10岁，你的申请分数会更高”是非法的歧视，无助于透明度。

在一些司法管辖区，明确披露用户正在与机器人交互是一项法律要求，而不仅仅是设计最佳实践。明确指示用户何时与 Agentforce 客服人员交互，而不是与人工客服人员交互。披露必须突出和持续，不能在服务中隐藏，或者在交互开始时只显示一次。

显示持续可视指示符：

  • 客服人员头像明确标记为“AI 助手”
  • 显示“您正与 Agentforce 服务代理聊天”的标题
  • “与人工客服人员联系”选项在整个对话中可见

披露尊重用户自主权，允许对交互模式进行知情选择。喜欢人际互动的用户必须拥有该选项，而不会受到摩擦或服务质量处罚。

Salesforce 平台功能，例如 Event Monitoring 和 Field Audit Trail，早于客服人员 AI，将算法问责制扩展到单个客服人员的决策。

  • **客服人员操作的事件监控：**Event Monitoring 通过 Salesforce 控制的完整性捕获客服人员数据访问、API 调用和系统更改。将 Event Monitoring 日志流式传输到外部 SIEM，以便长期保留和篡改证据，从而满足相应决策的监管要求。

配置 Event Monitoring 以跟踪：

  • 显示客服人员系统交互的 API 事件日志
  • 客服人员服务帐户的登录事件
  • 客服人员访问批量数据时的报表导出
  • **AI 影响数据的字段审计跟踪：**标准字段历史记录将数据更改保留 18 个月（通过 API 保留 24 个月）。字段审计跟踪允许您无限期地保留字段历史 — 最多在 18 个月后归档，然后保留归档的数据，直到您将其删除 — 支持长期的公平审计和监管调查。在存储客服人员决策或受客服人员决策影响的对象上启用字段审计跟踪，从标准对象字段审计跟踪支持以及任何启用了字段历史跟踪的自定义对象中进行选择（每个对象最多 200 个字段）。

对于信贷决策、就业决策和其他高风险用例，多年保留可能是监管要求。保留期因制度而异。确认用例的适用要求。

  • **为最高风险屏蔽 Event Monitoring：**Shield Event Monitoring 通过结构化事件字段提供了增强的审计功能，并与合规报告工具集成。事件日志文件数据默认为 Event Monitoring 和 Shield 客户保留一年。对于审计跟踪完整性至关重要的最高风险客服人员决策，使用 Shield。

存储足够的信息来精确重建任何历史客服人员决策：

  • **模型版本：**记录每个决策的模型版本（基础模型、提示版本、微调模型 ID）。模型版本经常变化，并产生不同的输出。精确的版本跟踪可在发现偏差时进行根本原因分析。
  • **输入功能值：**在决策时存储准确的输入值，而不是可能已更改的当前值。输入快照允许您测试决策是否与当前数据不同，或者根据当时可用的信息确认原始决策是否正确。
  • **配置状态：**记录阈值、业务规则和参数设置在决策时处于活动状态。配置更改会影响结果。配置历史允许确定决策偏差是反映模型变化还是配置变化。
  • **环境背景：**捕获相关上下文：用户身份、时间戳、对话历史、会话上下文。上下文会影响客服人员行为，必须保留上下文才能准确重建。

偏见检测必须是连续的，而不是在部署前的一次性验证。客服人员通过提示更新、基础模型版本更改和转移数据分配进行发展。

  • **公平度量仪表板：**构建 CRM Analytics 仪表板，从 Einstein Trust 层日志中跟踪公平度量。持续监控人口统计均等、平等机会和差别性影响率。在度量违反定义的阈值时配置警报。

创建仪表板，显示：

  • 按客户人口细分的决策分布（条形图）
  • 一段时间内的公平性度量（带有警报阈值的趋势线）
  • 具有五分之四规则指标的不同影响率计算
  • 有助于决策的热门预测因素，其中基础模型揭示了这些因素
  • 按人口统计组的覆盖率
  • **分布轮班检测：**监控客服人员的输入分配，了解指示潜在公平问题的更改。如果接收客服人员决策的用户的人口统计组成与训练数据人口统计显著不同，模型公平性可能会下降。

在输入分配更改时提醒：Agentforce 潜在客户路由的客户细分分布在过去 30 天内向企业转移了 15%。查看路由逻辑是否对现在接受不同服务模式的 SMB 客户公平 。 ”

  • **用户反馈集成：**使用户能够通过可访问的机制报告感知的偏见。用户报表显示定量度量缺失的定性问题。

将“报告关注”选项添加到 Agentforce 聊天界面。将报表路由到具有完整对话上下文的道德审查委员会。通过所需的调查工作流和文档化的解决方案，跟踪自定义对象中的报表。

设计客服人员架构，期待监管机构、民权组织或需要算法问责演示的客户进行外部审计。

  • **导出功能：**构建导出功能，使合规团队能够提取具有人口统计分层的完整决策数据集，供外部审计员审查。出口商必须遵守数据隐私条例，同时为公平性验证提供足够的透明度。
  • **审计文档：**维护当前文档：
  • 客服人员目的和预期用例
  • 训练数据人口统计和已知限制
  • 部署前和生产中计算的公平性度量
  • 应用的偏见缓解策略
  • 人员监督配置
  • 监控方法和警报阈值
  • 责任分配（模型所有人、决策所有人、上诉机构）
  • **算法影响评估：**在部署客服人员做出相应决策之前，请进行影响评估，以评估利益相关者群体的潜在积极和消极影响。影响评估显示了监管机构重视的尽职调查和主动风险管理。

用户保留对 Agentforce 如何影响体验的有效控制。

  • **选择加入相应客服人员：**做出对用户有重大影响的决策的客服人员需要明确选择加入，而不是默认启用。信用决策客服人员、就业筛选客服人员和服务资格客服人员仅在用户同意后激活，并清楚地了解客服人员将如何影响他们。
  • **粒度同意：**启用每个客服人员用例的同意，而不是全面 AI 同意。客户可能会同意 Agentforce 服务客服人员，同时拒绝 Agentforce 销售客服人员。支持用例级同意跟踪的架构是一个输入；测试和定期审计强制逻辑有助于确认同意门在实践中成立。
  • **新功能的动态同意：**在部署影响现有用户的新的 Agentforce 功能时，请主动征求新用例的同意，而不是依赖没有考虑特定应用程序的原始同意。影响用户的每项全新客服人员功能都会触发同意检查，并附上明确解释。
  • **同意撤回并立即生效：**使用户能够立即停止客服人员处理，随时撤销同意。撤销同意必须像批准同意一样容易，不需要支持联系人或官僚程序。
  • **首选项管理：**使用户能够在定义的范围内配置客服人员行为：
    • 沟通风格（简洁与详细解释）
    • 主动性级别（仅在询问时响应，而非主动建议）
    • 升级首选项（优先使用 AI 分辨率，而非快速使用人工）

在用户记录自定义字段中存储首选项。客服人员系统提示中的引用首选项：“用户更喜欢详细的解释。通过支持推理提供全面的回答 。 ”

  • **按需手动切换：**在整个 Agentforce 交互中，提供持续的“与人工客服人员联系”选项，而无需用户完成客服人员交互或解释他们为何更喜欢人工。

配置即时切换路由：当用户选择“人工客服人员”时，路由到全方位，带有完整的对话上下文和指示用户首选项的优先级标志。选择人工交互不会降低服务或等待时间处罚。

  • **透明度指标：**使用持续可视标志清楚地标记客服人员交互，使用户能够保持对交互模式的认识。忘记与客服人员交互的用户可能会有不切实际的期望，或者在出现限制时感到欺骗。

设计客服人员，通过有意的架构选择，在受保护的人口群体中产生公平的结果。

做出相应决定的客服人员不得基于受保护特征（包括种族、性别、年龄、残疾、宗教、国籍或性取向）进行歧视，除非出于特定目的（例如残疾便利）具有法律正当理由。

  • **功能审计：**查看客服人员推理中用于受保护特征内容的所有数据源。CRM 数据、Data 360 细分和 Knowledge 库可能包含客服人员在某些决策中不应考虑的人口统计信息。

当这些特征在法律上对决策类型不成立时，从客服人员输入中删除或屏蔽受保护的特征。对于信用决策，排除残疾状态，因为这无关紧要。对于残疾住宿请求，残疾状况至关重要，必须包括在内。

  • **不歧视的提示工程：**在客服人员系统提示中包含明确的不歧视说明：

“您是客户服务代理。以同等的专业精神对待所有客户，无论他们的姓名、位置、沟通风格或任何其他特征如何。向所有客户提供同等质量和细节的推荐。不要根据人口统计特征对客户进行假设 。 ”

  • **使用人口统计角色进行测试：**在生产部署之前，测试客服人员，他们具有代表受保护小组的不同角色。生成相同的请求，仅改变人口统计信号（包括表示不同种族的名称、表示不同区域的位置，以及表示不同教育程度的通信风格）。

比较客服人员在角色间的回复，以了解质量、长度、专业性和结果。差异表明偏见需要缓解。

跨客户人口统计监控 Agentforce 服务质量，确保体验可比性：

  • **按细分的解决率：**计算按客户细分划分的首次接触解决率。如果 Enterprise 客户达到 75% 的解决率，而 SMB 客户达到 55% 的解决率，请调查 Knowledge 库质量、客服人员培训或产品功能是否因细分而异。
  • **按细分的响应质量：**跨细分的客服人员对话示例，并让审核人员评估一致的维度上的回复质量：准确性、完整性、专业性、帮助性。评级人之间的可靠性测试确保评审人应用一致的标准。
  • **按细分的升级率：**跟踪客服人员升级为按客户人口统计分层的人员的频率。某些细分的升级率越高，客服人员对这些用户的效果越差，从而造成服务质量差异。
  • **按细分的满意度：**调查所有人口统计组中的用户，并比较满意度分数。总体满意度高可能会掩盖少数群体被多数人满意度淹没的不良经历。

Agentforce 界面必须为符合 WCAG 2.2 AA 标准的残疾用户访问。参考 Salesforce Lightning 设计系统组件和模式库，了解可重复使用、可访问的 Agentforce 组件和设计模式。这些模式使客服人员体验可访问、一致和可学习。

  • **屏幕阅读器兼容性：**提供 Agentforce 聊天界面的 Lightning 消息传递组件在按设计使用时包括基准可访问性。自定义聊天实施需要手动无障碍实施：
  • 具有正确标记的语义 HTML 结构
  • ARIA 实时区域宣布新消息
  • 键盘导航消息历史记录
  • 明确交互式元素的重点指标

在整个开发过程中，使用 JAWS、NVDA 和 VoiceOver 屏幕阅读器辅助技术进行测试，而不仅仅是自动扫描。

  • **认知可访问性：**客服人员回复对一般受众使用简单的语言。避免使用行话，并为不可避免的技术术语提供词汇表。使用标题构建长回复，并酌情使用项目符号或编号列表来帮助理解。
  • **语言公平性：**Agentforce 通过基础模型多语言功能支持多种语言。通过母语者评估，而不仅仅是缺少文化细微差别的自动化度量，验证回复质量在不同语言之间具有可比性。

对于为不同语言群体提供服务的关键业务用例，配置特定于语言的处理（语言变量、本地化提示和按语言筛选 Knowledge 文章）并验证每种语言的质量，而不是仅仅依赖基础模型跨语言转移，这可能会使资源较少的语言的质量下降。

在与客服人员部署成熟度一致的阶段中，为 Agentforce 实施公平性。

阶段 1：基础（在任何生产客服人员之前）

  • 建立具有执法权限的道德审查委员会
  • 文档责任分配（模型所有人、决策所有人、上诉机构）
  • 启用 Einstein Trust 层审计捕获
  • 为客服人员操作配置 Event Monitoring
  • 在 CRM Analytics 中创建基线公平性监控仪表板
  • 定义强制部署网关：数据审计、公平度量、影响评估

阶段 2：第一个生产客服人员

  • 对用例进行全面影响评估
  • 对人口统计代表性的审计培训/RAG 数据
  • 跨人口统计组计算公平度量
  • 实施人工监督模式（人工在环、信任升级或有时限的）
  • 为用户配置偏见报告机制
  • 文档模型版本、配置和决策重建方法

阶段 3：持续监控

  • 每周监控公平仪表板，在 24 小时内调查阈值违规（或贵组织的商定响应 SLA）
  • 每月进行覆盖模式分析，找出系统问题
  • 每周查看用户偏见报告，其中包含记录的调查结果
  • 为高风险客服人员执行季度全面公平审计
  • 随着客服人员的发展，通过提示更新或模型更改更新文档

阶段 4：规模和治理

  • 为常见客服人员类型创建可重复使用的公平仪表板模板
  • 构建客服人员决策重建工具，支持合规团队自助服务
  • 标准化所有新客服人员的同意管理模式
  • 在 CI/CD 漏斗中实施自动公平回归测试
  • 安排第三方每半年进行一次外部公平审计
  • 保持监管监控并适应积极和新出现的义务，包括欧盟 AI 法案(逐步实施到 2025-2027 年 ) 、 州法律和行业法规

公平性是 Salesforce 平台上代理系统的核心架构问题。将 Agentforce 设计为一流架构的组织将自己定位在法规要求之前，同时构建所有用户可以Trust和有效使用的解决方案。存在平台功能。问题是架构师是否会使用它们。

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