平等

平等

在 Salesforce 結構中,公平表示建立可透過無障礙介面、偏差偵測和緩解、透明決策和道德管理公平為使用者提供服務的解決方案。Einstein 的預估會影響影響客戶和員工的成果,這表示結構設計師應設計可在整個人口統計群組中產生公平結果的系統,同時仍可供殘疾使用者存取。

Salesforce 提供針對公平性而打造的平台功能,我們努力符合 WCAG 2.2 AA。正確使用時,Salesforce Lightning Design System (SLDS) 會提供專為支援此目標而設計的元件。讓我們進一步瞭解每個元件。

  • Shield Platform Encryption 可保護敏感屬性 (例如人口統計資料),而「事件監視」可提供支援透明資料處理的稽核追蹤。
  • Einstein Trust 圖層 (ETL) 會針對監視與合規目的,針對生成式 AI 提示與回應,捕捉安全稽核追蹤。
  • Experience Cloud 包含無障礙控制。
  • 「欄位稽核追蹤」提供欄位級資料變更歷程記錄的長期保留,其支援在 AI 決策資料儲存在已追蹤欄位時的演算法責任。

這些功能有助於降低 Salesforce 公平性作法的營運成本。

在 Salesforce,公平會跨三個維度來提供解決方案。包容式設計有助於讓 Lightning Web 元件 (LWC)、Visualforce 頁面和 Experience Cloud 網站完全可供存取—具有流暢的鍵盤瀏覽、螢幕助讀程式相容性和認知設計容量。AI 公平性作法可協助 Einstein 預估使用偏差偵測、各種訓練資料和持續監視來產生公平成果。監管提供流程和控制,以在模型發展和使用個案擴展時維持公平性。

忽略公正會產生複雜風險。無法存取的 Experience Cloud 網站可能會將組織公開於「美國殘疾人法」(ADA) 訴訟中,對於聯邦機構及其承包商而言,也會違反 第 508 條規範。視系統的風險分類和新興演算法責任法規而定,偏差的 Einstein 預估可能會違反 歐盟 AI Act 要求。只有具有法律或類似顯著影響的 AI 驅動自動化決策,而缺乏關於決策邏輯的有意義資訊,可能會違反 GDPR 第 22 條和 第 15(1)(h) 條的資訊權利。

針對公平起見的組織可能會降低客戶、員工和受其系統影響的社群可能造成的損害。公平性的失敗可能會對受影響的個人造成明顯的實質傷害,包括經濟傷害、遭到拒絕的機會、情感困擾,以及加強系統歧視。監管協調的趨勢來自於適當地為受影響的個人提供服務。

使用這些原則來引導您的結構決策以確保平台上的公平性。

  • **適用於 Lightning 無障礙模式的設計。**建立時,請盡可能使用 Lightning Design System 和標準 Lightning Web 元件,這些元件的設計目的為支援 WCAG 2.2 AA 無障礙功能。使用 SLDS 建立時,您會利用無障礙為核心設計原則的文件庫。系統會檢查 SLDS 元件的鍵盤無障礙性和與輔助技術的相容性,許多元件都包含無障礙區段,其中包含開發人員祕訣。如果需要自訂元件,則必須透過輔助技術測試驗證明的「可存取的豐富網際網路應用程式」(WAI-ARIA) 實作、語意 HTML 和鍵盤瀏覽模式。
  • **使用適合每個模型類型的正確工具減少和監視偏差。**部署前,在生產環境中持續驗證 AI 輸出,以確保整個人口統計群組的公平成果。針對預測模型,請透過 Einstein Discovery 和自訂儀器來收集決策資料,並在 CRM Analytics 中進行分析以測量公平度量;針對生成式 AI 和 Agentforce 功能,請使用 Einstein Trust Layer (ETL) 提示與回應的稽核追蹤。記錄決策以符合法規透明度需求。
  • **用於資料保護控制的 Leverage Shield Platform Encryption。**針對需要完全符合查詢的敏感屬性,搭配決定性方式使用 Shield Platform Encryption,同時保護個人資料。「路由事件監視」會記錄至外部安全性資訊和事件管理 (SIEM) 系統,以支援可能遭到篡改的稽核追蹤—當 SIEM 強制執行超出所需法規所需 Salesforce 原生保留時間範圍的寫入一次儲存與存取區隔時。
  • **設計高利潤預估的檢閱工作流程。**在 Salesforce 流程中設定批准流程和檢閱機制,以確保影響後果決策的 Einstein 預估會收到適當的人類審查。在採取行動之前,請使用信賴值和業務規則來判斷預估何時需要驗證。
  • **套用組織範圍預設值 (OWD) 和欄位級安全性 (FLS),以防歧視。**使用 OWD 和 FLS 建立資料存取模式,以預設限制存取權,並僅使用共用規則授與每個角色需要的額外存取權。避免授與設定檔過度的存取權,這可能會顯示敏感屬性,並啟用歧視性決策。
  • **透過平台同意來啟用使用者代理程式。**透過「欄位稽核追蹤」使用 Data 360 或自訂同意物件中的同意管理功能,以追蹤每個使用個案的細微 AI 同意。讓使用者選擇退出 AI 驅動的功能,並在可能的情況下提供人類替代功能。

資料結構決策會決定在 Salesforce 系統中可見且不可見的族群。資料品質不佳不只是技術問題。當資料缺口系統地使特定人口統計群組不利時,這會成為公平性的問題。

  • **檢閱資料可用性的必要欄位。**當必要欄位假設資訊可用性在人口統計中有所不同時,資料完整性會變成歧視性。無法提供必要資訊的使用者在拒絕不完整記錄的系統中會變得不可見。
    • 要求電子郵件地址會排除沒有可靠網際網路存取權或個人電子郵件地址的人口。
    • 要求美國社會安全號碼 (SSN) 會排除尚未核發 SSN 的國際客戶和最近移民。
    • 要求街道地址會排除無家居人口以及具有非傳統地址的使用者。
  • **稽核必要欄位的業務理由。**針對每個必要欄位,記錄資訊為必要而非選擇性的原因十分重要。如果流程可以透過替代方法在沒有特定資料的情況下運作,請將這些欄位設為選擇性,並設計系統以順暢地處理遺漏值。這有助於確保無法提供此類資料的使用者不會排除。

遵循西部命名慣例的名稱欄位 (「名字」、「姓氏」) 可能會排除具有不同命名作法的文化。

許多文化都使用:

  • 單數名稱 (或不含姓氏的單數名稱)
  • 「姓氏」會依產生變更的姓氏系統
  • 多個指定的名稱或姓氏
  • 根據生活事件或社會內容變更的名稱
  • 「first」和「last」在文化上沒有意義的區別名稱

使用單一完整名稱欄位設計名稱結構,或採用常見命名慣例的彈性多組結構。避免假設名稱排序、繼承模式或文化規範。

使用多種國際名稱測試名稱結構,以確保名稱欄位接受:

  • 單字名稱 (例如,Sukarno、Cher 和 Teller)
  • 超出常用欄位長度限制的長名稱
  • 具有對號、分號、連字號和空格的名稱
  • 具有非拉丁指令檔的名稱 (例如阿拉伯文、中文、西里爾文和 Devanagari)

當名稱驗證拒絕使用者的合法名稱時,系統會根據其文化身分遭到拒絕。

地址驗證服務通常針對美國和西歐格式最佳化,且經常無法辨識:

  • 具有不同欄位排序的國際地址格式
  • 不含街道名稱的鄉村地址
  • 軍事地址 (例如 APO 和 FPO)
  • PO 方塊與其他遞送位置
  • 具有唯一地址系統的部落土地
  • 具有地址元件非拉丁指令檔的國家/地區

當地址驗證拒絕非傳統的地址格式時,會防止帳戶建立、寄送和服務提供給地址不符合驗證資料庫期望的使用者。

以下是設計無障礙地址驗證的一些方法:

  • 實作權限地址驗證。
  • 結構化驗證失敗時接受任意格式的地址項目。
  • 以使用者輸入的方式儲存地址,而非強制使用者進行無效的修正。
  • 使用地址驗證進行資料增強和重複偵測,而非驗證地址格式。

您可以將地址驗證建立在執行中重要之地址準確性的履行流程中,而不必事先封鎖資料。

特定通訊管道的通用存取假設會排除具有不同技術存取權或偏好設定的族群。

僅限電子郵件的通訊會排除:

  • 沒有可靠網際網路存取權的使用者
  • 使用電子郵件不滿意的老年人口
  • SMS 或傳訊應用程式作為主要通訊方法之區域中的使用者

僅限電話通訊不包括:

  • 無聲且難以聽的使用者
  • 沒有電話存取權的使用者或使用共用電話的使用者

設計可讓使用者控制管道偏好設定的 Omnichannel 通訊結構。將偏好的通訊方法儲存在「連絡人」記錄中,並持續遵循所有輸出通訊系統的偏好設定。提供各種通訊替代方式,而非假設單一管道方法可供廣泛使用。

收集人口統計資料以進行公平監視需要謹慎的結構以防止濫用。

收集和處理人口統計資料取決於司法管轄區,且受到法律限制 (在歐盟,GDPR 第 9 條將其視為需要特定法律依據的特殊種類資料;在美國,偏差監控通常依賴自願的 EEO 自我識別)。若存在合法基礎,組織會使用人口統計資料來:

  • 監視依受保護群組分層的公平度量
  • 偵測自動化和 AI 系統中的偏差
  • 示範法規遵循反歧視要求

收集人口統計資料會造成某些風險:

  • 如果存取控制失敗,資料可能會用於歧視目的
  • 使用者可能不信任收集方法並提供不準確的資料
  • 集合可能具有侵犯性或歧視性

使用下列資訊建立自願自我識別並設計人口統計資料集合:

  • 以透明的目的清楚說明 (例如,公平性監視或合規性報告)
  • 為自願,且包含隨時可用的「想要不回答」選項
  • 使用嚴格 FLS 與作業資料分開以防止不當存取
  • 針對報告和分析進行彙總,且未連結至個別決策
  • 透過 Shield 事件監視監視以進行存取模式稽核

在隱私權原則中記錄人口統計資料將如何使用與不會如何使用十分重要。透過未揭露的資料使用違反使用者 Trust 可能會嚴重損害可信度,難以從中復原。

將人口統計、公司統計或行為資料附加至 Salesforce 記錄的第三方資料增強可能會透過以下方式導致偏差:

  • 根據 stereotypes 的推斷不準確
  • 不完整的涵蓋範圍,與人口統計相關的差距
  • 使用未知公平性內容的專屬演算法
  • 來自偏差歷程記錄的資料

實作資料增強服務之前,請務必先稽核:

  • 廠商公平性測試和偏差緩解作法
  • 整個人口統計群組的資料涵蓋範圍和準確性
  • 用於建立預估的推斷方法與功能
  • 契約資料使用限制與保留原則

請記住,一旦第三方資料進入您的 Salesforce 組織,它可能會影響決策,從而建立廠商導入的偏差,這也會反映為貴組織中的偏差。

在 Salesforce 環境中,無障礙是指為身心障礙使用者設計 Lightning Web 元件、Visualforce 頁面和 Experience Cloud 網站。標準 Lightning 元件在正確使用時提供基準存取設定;不過,自訂開發和 Experience Cloud 組態需要明確的存取設定實作。

當 Lightning Design System 元件依照設計使用時,其設計目的為支援 WCAG 2.2 AA 規範。Salesforce 努力達成完全符合 (但未認證)。偏離 SLDS 模式或建立自訂元件而不考量無障礙功能,會為有身心障礙的使用者建立阻礙。

標準 Lightning Web 元件提供內建的無障礙功能。如 Lightning、Lightning、Lightning 和 Lightning 等元件會自動包含適當的 ARIA 屬性、標籤關聯、鍵盤瀏覽和焦點管理。盡可能使用標準元件,而非建立類似但可能缺少適當無障礙基礎結構的自訂替代項目。

  • **在自訂 Lightning Web 元件中使用語意 HTML。**建立自訂元件時,請使用語意 HTML 元素 (
    、
  • **在自訂元件中實作 ARIA。**當語意 HTML 無法傳達介面行為時,套用 ARIA 地標、角色和內容。動態內容更新需要 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 以下),大文字為 3:1 (一般文字為 18pt 或更大,粗體為 14pt 或更大) 和 UI 元件。使用瀏覽器開發人員工具或線上對比檢查器來驗證合規性。使用瀏覽器縮放至 200% 進行測試,以確保文字調整大小並不會遺失內容或功能。
  • **在瀏覽功能表中使用鍵盤瀏覽。**Experience Cloud 瀏覽元件必須支援僅限鍵盤作業,且不具有滑鼠相依性。使用者必須使用「索引標籤」、「Enter」、「逸出」和「方向鍵」來瀏覽至下拉式功能表、大型功能表和飛出瀏覽,而不含焦點陷阱。僅使用鍵盤測試所有瀏覽路徑以驗證無障礙功能。
  • **啟用 Experience Cloud 中的表單存取設定。**使用適當的標籤元素或 aria-labelledby 明確建立標籤與所有表單輸入的關聯。預留位置文字本身會失敗無障礙需求,因為文字會在資料輸入開始時消失,這會讓螢幕助讀程式使用者沒有足夠的永久內容。當使用必要的標籤屬性設定 Lightning 輸入元件時,會提供內建的標籤關聯。自訂 Visualforce 表單需要明確的標籤輸入關聯。
  • **使用輔助技術測試 Experience Cloud 網站。**啟動公用 Experience Cloud 網站之前,您必須先使用螢幕助讀程式、僅限鍵盤瀏覽和瀏覽器縮放來執行全方位的無障礙測試。在可用性測試中包含具有身心障礙的使用者,以顯示專家檢閱經常會遺漏的實際實際體驗阻礙十分重要。僅測試內部 Lightning 頁面,而不驗證外部 Experience Cloud 無障礙功能,會使公開網站容易受到無障礙功能的抱怨和訴訟。
  • **針對影像和圖示使用替代文字。**Experience Cloud 中的所有資訊性影像、圖示和圖形內容都需要替代文字。裝飾影像使用空白替代文字 (alt=”),讓螢幕助讀程式可以略過這些內容。資訊性影像提供描述內容與功能的有意義替代文字。當您撰寫圖示的替代文字時,請專注於圖示的動作或用途,而非其視覺外觀 (例如,替代文字應指出其功能公用程式,例如「搜尋網站」,而非將放大鏡圖示描述為「放大鏡」。管理影像時,CMS 必須提示內容作者輸入替代文字,或明確將影像標記為裝飾 (會設定 alt="")。這可確保無障礙功能,方法是避免遺失風格影像的替代文字和強制描述。

完整的鍵盤存取設定表示使用者可以使用鍵盤存取所有功能,而無須在任何時候使用滑鼠或觸控互動。

  • **在 Lightning 頁面中使用邏輯焦點順序。**確保焦點順序遵循視覺版面配置與互動流程。當使用者按下 Tab 鍵時,視覺焦點應依據視覺設計以使用者預期的順序在互動元素之間移動。Lightning 應用程式產生器和體驗產生器會根據元件的位置建立焦點順序。自訂元件需要明確的 Tabindex 管理,以確保邏輯焦點進度。
  • **使用可見的焦點指標以符合對比需求。**Lightning Design System 提供符合大多數元件 WCAG 需求的焦點樣式。自訂元件可能需要增強型焦點指標,才能滿足周圍內容的 3:1 對比需求。焦點指標必須清楚可見,才能讓視力不佳的使用者透過鍵盤瀏覽。永不使用 CSS 移除焦點指標 (大綱:none),而不提供替代可見焦點樣式。
  • **在強制回應和重疊中使用鍵盤陷阱緩解措施。**強制回應對話應在強制回應開啟時抓住焦點,進而防止鍵盤使用者到達隱藏的背景內容。重點陷阱應在強制回應關閉時釋出,並將焦點傳回至觸發元素。內嵌的內容 (包括 iframe 和第三方小工具) 無法在沒有逸出機制的情況下永久捕捉鍵盤焦點。
  • **使用快速鍵沒有衝突。**Lightning 提供 Salesforce 說明中記錄的標準鍵盤快速鍵。自訂鍵盤快速鍵必須設計為避免與標準瀏覽器控制項和螢幕助讀程式瀏覽指令衝突。根據 WCAG 成功條件,單一字元快速鍵 (例如,按下單一字母或標點符號) 不能觸發全域動作。它們必須將啟用限制為特定元件具有已啟用焦點時,或提供使用者關閉或完全重新對應捷徑的方式。

將無障礙驗證建立在 CI/CD 管道中,以在每個部署中自動尋找結構問題,而不是將無障礙視為定期手動稽核。

  • **使用 sa11y 進行 Lightning Web 元件無障礙測試。**Salesforce 的 sa11y 程式庫 (@sa11y/jest 封裝) 會封裝 Axe-core 無障礙引擎,以針對 Jest 單元測試新增 toBeAccessible() 比對器。自動撰寫無障礙測試以驗證適當的 ARIA 使用情況、標籤關聯、對比率和語意標記,作為單元測試的一部分。設定建立在偵測到重要無障礙問題時失敗。
  • **針對 Experience Cloud 使用 Lighthouse CI。**Google Lighthouse 會稽核網頁存取設定,包括 Experience Cloud 網站。將 Lighthouse CI 整合至部署管道,以掃描公開頁面是否有無障礙問題。在部署批准之前,請設定評分值以要求最低無障礙分數。
  • **使用無障礙代理程式,可透過 Salesforce DX MCP 封裝取得。**在 MCP 相容環境或 Agentforce Vibes 內,其會根據 WCAG 標準檢閱程式碼、呈現目標修正,並產生提取要求供工程師檢閱、驗證和合併。

在 AI 進入圖片之前,決定性 Salesforce 自動化已存在偏差。指派規則、流程決策、驗證規則和區域範圍設計會編碼人類判斷,這可能會使歧視持續。不同於 AI 偏差 (結構設計師會仔細檢查),自動化偏差通常會通過未經檢查,因為決定性邏輯感覺是客觀的。

  • **遵循商機與個案指派規則。**跨銷售和服務小組散佈工作。當指派邏輯使用與受保護特性相關聯的條件時,自動化會在服務品質和機會存取權中建立系統差異。
  • 使用區域範圍、郵遞區號或帳戶特性的指派規則可能會不成比例地將高價值機會路由至特定小組,同時將低價值工作路由至其他地方。如果區域範圍邊界與不同區域範圍的客戶人口統計和薪水結構相關聯,則指派自動化會導致經濟歧視。
  • **定期稽核指派規則結果。**計算依客戶人口統計分層的區域範圍和小組之間的指派分佈。如果企業帳戶集中在特定區域範圍中,而 SMB 帳戶分配在其他地方—如果企業區域範圍收到較佳的薪水或資源,則指派規則可能會產生不平等的成果,這意味著公平審查。
  • **檢閱 Omni-Channel 以技能為基礎的路由。**這可能會影響客戶族群的服務品質。如果路由邏輯隱含地假設某些技能與客戶價值或問題複雜度相關聯,則客戶可能會根據人口統計 Proxy 收到不同的服務成果。

請務必監視跨路由路徑的平均處理時間、第一連絡人解決方案,以及客戶滿意度。差異可能表示某些客戶區段是否會系統接收經驗較低的工作人員或路由選項較少。

  • **檢閱 Salesforce 流程自動化.**做出批准決策、資格決定或存取授與可能會透過看似無害的業務規則來編碼歧視邏輯。當條件與受保護的特性相關聯時,某些「流程」會建立間接歧視。
  • **請謹慎檢閱流程決策。**對於每個流程,其會做出影響使用者的後續決策,請務必詢問:
  • 不符合一般客戶設定檔的使用者會發生什麼狀況?
  • 決策條件是否與人口統計特性相關聯?
  • 例外狀況與極端個案是否均衡處理,還是會系統地使特定群組不利?

在結構決策記錄中記錄「流程」決策邏輯和公平性考量事項,並將高利潤流程視為 AI 系統的相同道德審查原則,十分重要。

  • **檢閱驗證規則。**防止資料輸入可能會從資訊不符合系統假設的使用者中排除有效資料。拒絕合法資料的驗證規則會建立不可見的人口。資料不符合驗證模式的使用者無法與某些系統互動。驗證失敗通常不會回報,因為使用者捨棄其要求而非回報技術錯誤。以下是數種常見的驗證偏差模式:
  • 需要拉丁字元的名稱驗證可能會排除具有對號和非拉丁指令碼的名稱。
  • 電話號碼驗證通常使用美國/西部格式,這不包括國際號碼和替代通訊方法。
  • 地址驗證無法識別非標準地址 (例如,PO 方塊、鄉村路線、部落土地和國際格式)。
  • 需要個人電子郵件地址的電子郵件驗證可能會對沒有個人電子郵件存取權的使用者造成劣勢。
  • **使用多樣資料測試驗證規則。**在驗證測試中包含國際地址、非西部名稱和其他電話格式。當驗證拒絕合法資料時,您必須展開驗證邏輯,以避免排除有效使用者。
  • **檢閱銷售區域範圍設計。**客戶區隔策略和銷售區域範圍設計會決定在客戶族群之間的資源配置。當區域範圍邊界或區隔條件與導致資源分配不平等的人口統計相關聯時,該分配可能會產生歧視的結果。由於住宅區隔模式,使用地理邊界的區域範圍設計通常與種族、族裔和經濟人口統計相關聯。如果不同區域範圍的薪資、員工等級或資源投資不同,則地理位置可能會成為歧視資源配置的機制。
  • **完成設計前先分析區域範圍人口。**對應建議區域範圍邊界的客戶人口統計。當人口統計集中情況出現時,評估資源分配是否在所有區域範圍之間均衡,無論人口統計組成為何。如果業務理由需要區域範圍之間的不同資源層級 (例如市場成熟度、競爭強度和成長潛力),請明確記錄該理由並監視成果,以確保缺乏服務的區域範圍會收到足夠的投資機會,以避免產生深度差異。
  • **保持自動化邏輯的透明度。**在 Salesforce Knowledge 或結構決策記錄中記錄業務規則、指派條件和流程決策邏輯。透明自動化可透過隱藏邏輯阻止的方式檢閱公平性。
  • **定期稽核成果。**排程每季稽核,以分析可依客戶人口統計分層的自動化成果。請記住,不一致會觸發調查和可能的補救措施。
  • 請務必追蹤:
  • 跨小組和區域範圍的指派分佈
  • 做出資格決定的流程批准率
  • 依資料模式的驗證規則拒絕率
  • 區域範圍績效與資源配置
  • **透過道德透鏡檢閱高利潤自動化。**主題流程和指派規則會影響員工、信用額度、服務存取權或其他對 AI 系統相同道德審查流程的後果結果。自動化偏差需要與演算法偏差相同的審查層級。

在 Salesforce,AI 公平性著重於使用 Einstein 驗證預估是否在所有人口統計群組中產生公平的成果。Einstein Discovery 和自訂儀器會收集預測模型決策資料,以啟用偏差偵測。CRM Analytics 顯示面板會追蹤公平度量。「欄位稽核追蹤」與「事件監視」會針對演算法的當責性,來收集決策資料。

影響後續決策 (例如商機評分、機會預測和客戶區隔) 的 Einstein 預估需要預先部署的公平性評估,以作為必要的等同步驟 (類似於安全性審查)。

使用統計方法分析所有預測模型功能,以瞭解與受保護特性的關聯性。移除或轉換 Proxy 功能後,評估其預測值是否在不論 Proxy 影響為何仍可包含。

  • **訓練前稽核 Salesforce CRM 資料。**Salesforce 組織包含以歷程記錄作法為基礎的數十年人類決策。如果過去的銷售小組排定特定人口統計的優先順序,則 Einstein 商機評分會瞭解這些模式並將其持續。在對歷程記錄資料訓練預測模型之前,請務必先稽核該資料,以瞭解整個客戶區段的人口統計表徵差異和測量不一致的情況。
  • **計算人口統計群組的公平度量。**在部署預測模型之前,請務必先計算受保護群組之間的人口統計相等性、機會相等性,以及不同的影響率,在此您擁有收集和處理必要人口統計資料的合法基礎。如果 Einstein 商機評分將高分數指派給「區段 A」的 50% 次,但只指派給「區段 B」的 30% 次,則 60% 比率會失敗於「四五分之五規則」(80%) 且需要調查和緩解。80% 的數字是篩選觸發,不是法律通過/失敗線:四分之五規則是美國的聯邦指令規則,用於選取就業機會,並且清除此規則並非安全港口 — 統計上顯著的差異可能需要以較高的比率進行審查,而其他制度則會以不同的方式衡量不良影響 (例如,歐盟間接歧視法會開啟某種作法是否會造成「特殊劣勢」,但沒有固定的值)。針對您作業所在的管轄範圍校正調查值並使用個案。
  • **用於偵測偏差的預測模型決策資料。**若要偵測在如「商機評分」和「機會評分」等預測模型中的偏差,請透過 Einstein Discovery 和自訂儀器處理決策資料:將預估輸入、輸出和模型版本儲存在追蹤的欄位中,並啟用「欄位稽核追蹤」。在 CRM Analytics 中分析該資料,以追蹤跨人口統計群組隨時間的決策模式,並建立顯示面板,以在人口統計相等或機會相等度量漂移超出可接受的值時警示。
  • **偵測預測模型中的 Proxy 功能。**與受保護特性相關聯的功能會啟用間接歧視,即使受保護特性從模型中排除也是如此。
    • Salesforce 資料通常包含 Proxy 功能:
  • 區域範圍或郵遞區號 (種族、族裔和收入的 Proxies)
  • 帳戶名稱模式 (組織規模和產業人口統計的 Proxies)
  • 通訊活動時間點 (時區、宗教和照護責任的 Proxy)
  • 「活動」資料中的裝置類型或瀏覽器 (收入層級的 Proxy)

當在 Einstein 預估中偵測到偏差時,您必須在適當的管道階段 (根據根本原因和技術限制) 套用緩解措施。

  • **模型訓練前的平衡資料。**透過在訓練預測模型之前,過度取樣呈現的客戶區段或過度取樣呈現的區段,以重新平衡 Salesforce CRM 資料。使用 Data 360 彙總多個組織的資料,以確保多元化的訓練集。合成資料產生可以補充稀有區段,同時透過不同的隱私權技術來保留隱私權。
  • **移除功能工程中的 Proxy。**識別 Proxy 功能後,請將其取代為提供預測能力的替代功能,而不含人口統計關聯。如果區域範圍作為人口統計 Proxy,請考慮產業分類或公司大小作為替代項目。如果帳戶名稱模式與人口統計相關聯,請改用 firmographic 屬性。
  • **在後續處理期間調整值。**調整每個人口統計區段的決策值,以在訓練模型後均衡成果率。對於與就業相關的決策,完全禁止:第七章 (1991 年《公民權利法案》) 禁止依受保護類別調整分數或使用不同的截止分數,而且沒有多少記錄的理由會使此作法成為合法。當預估告知自動化決策時,在不禁止的情況下,記錄具有商業理由且適用於差異處理的值值調整。
  • **使用更新的資料定期重新整理模型。**排程每季模型重新訓練 (或發生顯著資料散佈排班時)。重新訓練新資料會抓住新興的偏差模式,並修正原始公平基準的任何漂移。在生產部署前重新驗證每個模型版本的公平度量,以確保重新訓練不會導致新偏差。

Einstein Trust Layer 會針對生成式 AI 和 Agentforce 功能,針對生成式 AI 提供提示、回應和 Trust 訊號,以支援透明度和法規合規性。針對預測模型,透明度與決策歷程來自 Einstein Discovery 和模型管理員,其需要自訂儀器才能保留稽核資料。

從初始結構建立 Einstein 解決方案的可解釋性,而非在部署後將說明重新適配至不透明的系統。

  • **在決策點呈現 Einstein Discovery 說明。**Einstein Discovery 提供預估係數說明,顯示哪些變數對特定預估具有方向影響的影響最大。架構 Lightning 元件,在決定時向使用者顯示這些說明,而不需要瀏覽來分隔 CRM Analytics 顯示面板。當決策影響使用者時,其需要透明度,而不是抽象模型效能度量。
  • **不同受眾的層級說明。**提供適合每個受眾的說明深度:
  • 公司使用者:「由於年度收入超過 $1 百萬,且參與分數在前 10% 中,因此此商機評分高。」
  • **技術使用者:**提供具有功能加權、訓練資料特性和驗證度量的 Einstein Discovery 模型卡片。
  • 客戶:「此建議是根據您最近購買的產品,以及具有類似偏好設定的客戶。」
  • **稽核員:**提供 Einstein Discovery 和模型管理員 (模型版本、輸入值,以及推動預估的因素) 中的決策歷程,此歷程是透過自訂儀器所取得。
  • **適當地傳達信任。**以使用者適當的詞彙顯示預估信賴,並避免使用者可能誤解的原始機率分數。使用種類 (例如「高度信賴」、「仲裁信賴」和「需要檢閱」),以說明每個信賴等級對決策可靠性的意義,以及將會發生的其他檢閱,而不是顯示「73% 信賴」。

針對影響使用者的所有 AI 驅動決策,維護全方位且固定的稽核追蹤,以支援問責、除錯和法規合規性。

  • **使用正確的工具來捕捉預測稽核資料。**將預測模型稽核資料 (預估輸入、輸出和模型版本) 儲存在已啟用「欄位稽核追蹤」的追蹤欄位中。建立資料保留原則以符合法規需求,這會因行業和管轄區而有所不同:
    • 金融服務規則會根據法規設定保留 (例如,FINRA 規則 4511(b) 會針對「FINRA 規則」或「SEA 規則 17a-4」中未指定保留期間的記錄設定預設六年的保留期間)。
    • 醫療照護保留也受特定規則所管理 (例如,HIPAA 需要至少六年的合規性文件;個別州的法律會設定醫療記錄保留),而非廣泛的無限期保留要求。
  • **使用 CRM Analytics 分析預測模式決策資料。**您可以根據預測模型決策資料 (在追蹤欄位中的預估輸入、輸出和模型版本) 建立 CRM Analytics 顯示面板,以分析決策模式、公平度量和模型效能隨著時間的變化。建立透鏡,依信賴層級、人口統計區段和成果類型顯示預估分佈。設定 Einstein Discovery 情節以識別需要額外調查的異常模式。
  • **使用「欄位稽核追蹤」進行長期保留。**標準欄位歷程記錄會透過 UI 追蹤 18 個月變更,最多 24 個月的變更。「欄位稽核追蹤」可讓您無限期保留儲存 AI 決策資料之自訂物件的欄位歷程記錄。依預設會歸檔歷程記錄達 18 個月後,然後保留已歸檔的資料,直到您將其刪除為止。在包含同意記錄、覆寫決策和偏差報告的物件上啟用「欄位稽核追蹤」,以符合法規保留需求。
  • 針對 Agentforce 互動使用事件監視。「事件監視」會針對 Agentforce (例如動作和流程執行時) 來儲存叫用層級事件。將「事件監視」資料 (透過 API 的標準「事件記錄檔」資料,以及透過「平台事件」之事件的「即時事件監視」子集) 匯出至外部 SIEM,以儲存超過 Salesforce 原生保留期間。妨礙證據取決於強制執行寫入一次性儲存與存取區隔的特定 SIEM 行為。設定 SIEM 查詢以偵測在大量 Agentforce 互動之間的偏差模式。
  • 使用 Einstein Trust 圖層稽核 Agentforce 對話。「Einstein Trust 圖層」會收集儲存在 Data 360 中 Agentforce 對話提示與回應的稽核追蹤,提供文字記錄層級記錄以確保透明度與法規合規性。

讓我們進一步瞭解結構設計師透明度功能,其定位在多個管轄區中符合目前和新興 AI 法規。

  • **歐盟 AI Act 透明度需求。**根據「歐盟 AI 法案」,高風險 AI 系統需要透明度文件、技術文件、人力監督能力,以及準確度/公正度量。Einstein Trust Layer 稽核追蹤和 Einstein Discovery 模型卡提供這些需求的基礎。文件模型訓練資料人口統計、驗證方法,以及結構決策記錄的已知限制。
  • **GDPR 的解釋權。**GDPR 授與歐盟資料當該決策僅以自動化處理為基礎,且產生法律或類似顯著影響時,有關決策邏輯的有意義資訊的權利。此權利源自與考量事項 71 一起讀取的 第 15(1)(h) 和 第 22(3) 條,並由歐洲法院在 Dun & Bradstreet (2025) 案中澄清。設計可針對資料主體存取要求時間範圍內任何歷程記錄決策產生一致說明的系統,這會在 15 到 45 天之間改變 (視管轄區而定)。您收集的預測模型決策資料 (預估輸入、輸出、模型版本和 Einstein Discovery 描述因素) 可讓您在儲存解釋時重建解釋。
  • **演算法責任法則。**美國的州級演算法責任法令越來越需要自動化決策系統的影響評估和透明度報告。您收集的預測模型決策資料與 CRM Analytics 公平監視顯示面板提供這些報告的資料基礎。請先執行演算法影響評估,再將後續 AI 部署為主動合規,而非作為反應性回應給法規查詢。

OWD、共用規則和欄位級安全性 (FLS) 會塑造資料存取模式,以決定使用者可檢閱及使用哪些資訊來進行決策。適當的組態可防止對敏感屬性進行歧視的存取,同時確保公平服務。

設計 OWD 和欄位級安全性以依預設限制存取權。針對共用規則,請使用最低權限原則 (PoLP) 僅授與每個角色合法需要的額外存取權,進而防止根據受保護的特性做出歧視性決策。

  • **啟用限制 OWD 作為預設值。**針對包含敏感客戶資料的物件使用私人 OWD,並依角色階層與共用規則授與存取權。公用「讀取/寫入 OWD」可讓限制存取權稍後產生中斷 — 縮小預設值會觸發共用重新計算,並且只會在共用重新計算完成後生效,而非不可能。具有明確共用授與的私人 OWD 會建立可稽核的存取模式,以支援非歧視合規性。
  • **針對敏感屬性套用欄位級安全性。**隱藏包含受保護特性的敏感欄位 (例如,種族、宗教和身心障礙狀態),讓不需要存取權的使用者無法在合法業務上存取。設定 FLS 以移除大多數設定檔中敏感欄位的讀取存取權。當這些欄位需要用於特定目的時 (例如,多元性報告和合理的適配),請使用具有已記錄業務理由的權限集授與最低存取權。
  • **設計指派與共用規則以取得公平的成果。**您可以使用指派規則和 Omni-Channel 路由,在區域範圍、小組和服務工作人員之間平均分配工作。避免以特定使用者群組集中高價值機會或客戶的手動共用,而沒有經過記錄的業務理由。根據目標條件 (例如產業、地理位置和產品線) 設定自動共用規則,而非主觀經理自行決定,這可能會啟用偏差。
  • **提供暫時存取權的權限集。**透過權限集授與敏感資料的暫時存取權,而非修改設定檔,這會永久影響所有使用者。當使用者需要存取特定專案的人口統計資料 (例如多元性分析和住宿要求),請指派具有已記錄到期的權限集。「已排程流程」會在定義的期間後自動撤銷權限集。

使用「Shield 事件監視」和報告來偵測資料存取模式,這表示在資料使用情況中可能有差異或偏差。

  • **使用「Shield 事件監視」來稽核敏感資料的存取權。**使用「事件監視」來針對包含受保護特性或敏感性屬性的物件 (報告匯出、API 查詢和頁面檢視) 來捕捉物件級存取事件。設定這些事件的查詢來呈現存取物件的人員、時間和內容,並將異常模式 (例如突然高峰和非預期使用者存取) 視為調查的觸發。
  • **報告共用規則散佈。**建立報告以分析記錄在使用者、小組和區域範圍之間散佈的方式。依客戶人口統計計算分佈統計資料,以確保高價值帳戶和機會平均分配。識別特定使用者群組在沒有經過記錄的商業理由的情況下,收到對重要記錄不成比例存取權的集中情況。
  • **稽核 CRUD 與 FLS 違規。**檢閱「設定稽核追蹤」,瞭解 OWD 設定、共用規則、FLS 組態和權限集的變更。資料存取控制項的未經授權變更可能表示嘗試不當地存取敏感資料。使用「交易安全性」原則針對高風險的「即時事件監視」事件採取行動 (例如 API 活動異常、可疑登入,以及敏感資料的大型報告或清單檢視匯出)。由於「交易安全性」僅會針對這些執行階段事件運作,而非記錄層級的 DML 或 FLS 變更,因此您必須依賴「設定稽核追蹤」和 FLS 和共用變更的已記錄變更管理批准。

在 Salesforce,使用者代理程式表示客戶和員工可以保留對 AI 如何影響其體驗的有意義控制權。Salesforce 同意管理功能、Data 360 同意和自訂同意物件可讓您精確控制 AI 互動。

使用 Data 360 同意管理、Marketing Cloud 同意或使用 AI 特定同意需求之「欄位稽核追蹤」的自訂同意物件來設計同意追蹤。

  • **針對每個 AI 使用個案啟用細微同意。**啟用每個 AI 使用個案的同意,而非使用整體 AI 同意。客戶可能同意 Einstein 產品建議,但拒絕 AI 驅動的信用決策。針對「同意」物件啟用「欄位稽核追蹤」,以長期保留並符合法規需求。使用追蹤下列欄位設計自訂「同意」物件:
  • 同意目的 (例如 Einstein 商機評分、Einstein 回覆建議和 Einstein 建議產生器)
  • 同意授與日期與授與方法 (例如網頁表單、API、電話與電子郵件)
  • 同意撤銷日期 (若適用)
  • 相關使用者或連絡人識別碼
  • **使用 Data 360 同意進行個人化。**針對 Einstein 個人化功能使用 Data 360 同意管理。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 公告通知受影響的使用者。
  • **預防:**處理變更以防止重複,並在執行手冊中記錄預防方法。

在結構檢閱期間、生產部署前,並定期使用此檢查清單進行持續評估。

資料品質與表示公正性

  • 將欄位設為選用欄位,以便流程在沒有資料的情況下運作,並設計下游流程以處理遺漏值,以免排除無法提供資訊 (電子郵件、SSN、街道地址) 的使用者。
  • 「結構設計師名稱」欄位作為單一完整名稱欄位或彈性的多部分結構,可接受單一名稱、非拉丁語指令碼、對號和長名稱,而非假設為西部的第一/最後順序。
  • 實作接受自由格式和國際格式的權限地址驗證,以輸入的方式儲存地址,而非封鎖格式不相符的記錄建立。
  • 將通訊管道偏好設定儲存在「連絡人」記錄中,並支援 Omnichannel 替代項目 (電子郵件、SMS、電話、郵寄、聊天、語音),而不必假設單一管道能接觸到所有使用者。
  • 使用「偏好不要回答」選項透過自願自我識別收集人口統計資料,分別儲存在「私人 OWD」與 FLS 之下,彙總以供報告,並透過「Shield 事件監視」監視。
  • 在將人口統計或行為資料附加至記錄之前,請先稽核協力廠商的豐富測試、人口統計涵蓋範圍和推斷方法。

無障礙與包容設計

  • 使用 Lightning Design System 元件,其設計目的為支援 WCAG 2.2 AA 無障礙功能。請記住,Salesforce 努力達成合規性,但元件仍需要正確使用。
  • 使用螢幕助讀程式測試驗證自訂 Lightning Web 元件 (例如 JAWS、NVDA 和 VoiceOver)。
  • 確定 Lightning 頁面和 Experience Cloud 網站中沒有滑鼠相依性的完整鍵盤瀏覽。
  • 使用瀏覽器開發工具或對比檢查器,確認一般文字的對比率符合 4.5:1。
  • 將 sa11y 或 Lighthouse 無障礙掃描整合在對重大問題產生失敗的 CI/CD 管道中。
  • 在公開啟動前,使用輔助技術測試 Experience Cloud 網站。
  • 透過確認所有動態變更 (例如錯誤狀態、載入旋轉或展開功能表) 均已清楚公告,且說話內容符合 UI 的視覺意圖,來驗證聽覺回饋意見。

Salesforce 自動化中的公平性

  • 檢閱指派與路由規則是否與可在特定人口統計群組中集中有利或不利成果的受保護特性相關聯。
  • 針對偏差稽核流程和流程自動化決策邏輯,記錄 Salesforce Knowledge 或結構決策記錄中的業務規則和條件。
  • 評估拒絕率會對特定資料模式或人口造成不成比例的驗證規則。
  • 分析人口統計關聯的區域範圍和區隔設計,記錄明確的業務理由,並監視缺乏服務的區域範圍,以確保公平的資源配置。
  • 將高利潤流程和指派規則 (員工、信用額度、服務存取權) 視為與 AI 系統相同的道德審查流程,並排程依人口統計分層的自動化成果每季稽核。

AI 公平性和偏差偵測

  • 在預測模型訓練之前,請先稽核 Salesforce CRM 資料以瞭解人口統計表示差異。
  • 在部署前,計算每個人口統計群組的人口統計等同、機會等同和不同的影響率。
  • 實作公平性評估作為強制性部署門 (將此視為等同於安全性審查)。
  • 建立 CRM Analytics 顯示面板,以使用使用「欄位稽核追蹤」所取得的預測模式決策資料追蹤公平度量。
  • 分析預測模型功能,以瞭解 Proxy 與受保護特性的關聯 (例如,區域範圍和帳戶名稱模式)。
  • 為所有高利潤 AI 系統排程每季全面的公平性稽核。

透明度與稽核性

  • 在 Lightning 元件中的決策點上呈現 Einstein Discovery 預估說明。
  • 使用符合法規需求的保留方法來設定 Einstein Trust Layer 稽核摘要。
  • 在儲存 AI 決策資料以長期保留的所有自訂物件上啟用「欄位稽核追蹤」。
  • 將「事件監視」資料匯出至外部 SIEM—透過 API 的「事件記錄檔」資料,以及透過「平台事件」的「即時事件監視」事件—用於超出原生保留的儲存空間,以及 SIEM 端的寫入一次控制項,用於篡改證據。
  • 提供使用者適用的信賴溝通 (例如高、中、低),而非原始機率。

使用 Salesforce 自動化進行人力監督

  • 在「流程」中設定以信賴為基礎的升級值,並將低信賴預估路由至人類審查。
  • 針對需要多階段審查鏈的高利潤決策,使用 Salesforce 批准流程。
  • 整合 Agentforce 和 Omni-Channel 路由以啟用流暢升級至人力工作人員。
  • 在 Agentforce 介面中提供永久的「連線至 Human Agent」選項,以遵循使用者代理程式。
  • 針對在自訂欄位中收取的 Agentforce 覆寫,要求有記錄的邏輯與批准歷程記錄追蹤。

不含資料存取控制的歧視

  • 啟用「私人 OWD」,然後透過角色階層和共用規則授與其他存取權。
  • 設定欄位級安全性,以向不需要存取權的使用者隱藏敏感的人口統計欄位。
  • 透過「Shield 事件監視」監視敏感資料的物件級存取事件 (報告匯出和 API 查詢),並分析異常的存取模式。
  • 建立分析共用規則散佈的報告,以確保跨區域範圍的記錄配置公平。
  • 檢閱設定稽核追蹤是否有未經授權的 OWD、共用規則或 FLS 組態變更。

使用者代理程式和同意

  • 使用「欄位稽核追蹤」設計自訂「同意」物件,以追蹤細微的各使用個案 AI 同意。
  • 將 Data 360 或 Marketing Cloud 同意與 Einstein 個人化和 Agentforce 功能整合。
  • 將 AI 偏好設定儲存在「使用者」或「連絡人」記錄中,以確保管道之間的一致性 (例如 Web、行動和電話)。
  • 透過 Omni-Channel 路由在設定檔設定和人力替代項目中提供可存取的選擇退出。
  • 在 Einstein 預估或 Agentforce 參與影響使用者之前,查詢流程中的同意記錄。

道德 AI 管理

  • 記錄所有生產預測模型,包括公平度量和緩解策略;針對客戶訓練的預測模型 (例如 Einstein Discovery 和 Prediction Builder),也記錄訓練資料人口統計。
  • 建立強制性的預先部署公平性門,以封鎖部署直到符合所有公平性條件為止。
  • 建立「AI 道德審查委員會」作為所有高利潤 AI 應用程式的強制執行授權機構。
  • 建立 CRM Analytics 顯示面板,透過 CRM Analytics 警示以排程步調監視公平度量。
  • 針對公平性失敗定義事件回應程序,並在 Salesforce Knowledge 中記錄流程。
  • 排程每季的公平性稽核,以分析所有高利息系統的覆寫模式和使用者回饋意見。

分享您對良好架構的回饋意見。