AI Ethics and Governance - Patterns
Learn more about Well-Architected Fairness → Practice Ethical AI Governance
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein | Training Data | ✅ Salesforce CRM data is audited for demographic representation gaps and measurement inconsistencies before training predictive models |
| Einstein | Training Data | ✅ Historical conversion data is analyzed by customer demographics to identify underrepresented segments requiring oversampling or additional data collection |
| Einstein | Deployment | ✅ Fairness evaluation is treated as mandatory gate equivalent to security review before predictive models reach production |
| Einstein | Deployment | ✅ Demographic parity, equal opportunity, and disparate impact ratios are calculated across protected groups before deployment |
| Einstein | Deployment | ✅ Fairness metrics are evaluated against the four-fifths rule (80% threshold) as a screening trigger—not a legal pass/fail line—for all customer segments before model deployment |
| Einstein Discovery | Instrumentation | ✅ Predictive-model decision data—prediction inputs, outputs, and model versions—is captured through Einstein Discovery and custom instrumentation enabling bias detection |
| CRM Analytics | Monitoring | ✅ CRM Analytics dashboards analyze captured predictive-model decision data for decision patterns across demographic groups over time |
| CRM Analytics | Monitoring | ✅ CRM Analytics alerts trigger when demographic parity or equal opportunity metrics drift beyond acceptable thresholds |
| Einstein | Feature Engineering | ✅ All predictive model features are analyzed for correlation with protected characteristics using statistical methods |
| Einstein | Feature Engineering | ✅ Proxy features (territory, zip code, account name patterns, activity timing, device type) are identified and evaluated for demographic correlation |
| Einstein | Feature Engineering | ✅ Proxy features are removed or transformed after evaluating whether predictive value justifies inclusion despite proxy effects |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Einstein | Training Data | ⚠️ Lead scoring is trained on 10 years of historical data without examining demographic representation or service quality differences |
| Einstein | Training Data | ⚠️ Historical conversion data is used directly without auditing whether different demographics received different treatment |
| Einstein | Deployment | ⚠️ Einstein features are deployed based solely on overall accuracy metrics without fairness evaluation |
| Einstein | Deployment | ⚠️ Demographic parity or disparate impact ratios are not calculated before production deployment |
| Einstein | Trust Layer | ⚠️ Agentforce interactions are deployed without enabling Trust Layer audit capture for bias detection |
| CRM Analytics | Monitoring | ⚠️ Decision patterns are not tracked by demographic groups over time; bias drift goes undetected |
| Einstein | Feature Engineering | ⚠️ Protected characteristics are removed from training data assuming this automatically eliminates bias |
| Einstein | Feature Engineering | ⚠️ Territory, zip code, and account name patterns are used as features without proxy correlation analysis |
| Einstein | Feature Engineering | ⚠️ Proxy features serving as perfect demographic proxies are retained without evaluating alternatives |
Patterns
| Where to look | What good looks like |
|---|---|
| Agentforce | Analytics | ✅ CRM Analytics dashboards track Agentforce decision outcomes by customer demographics using Einstein Trust Layer audit data |
| Agentforce | Analytics | ✅ Approval rates, service response times, escalation rates, and satisfaction scores are monitored stratified by demographic group |
| Agentforce | Analytics | ✅ CRM Analytics alerts are configured triggering when fairness metrics breach defined thresholds requiring investigation |
| Agentforce | Event Monitoring | ✅ Event Monitoring logs are routed to external SIEM for long-term retention exceeding native retention limits |
| Agentforce | Event Monitoring | ✅ SIEM queries identify anomalous concentrations of negative outcomes for specific user populations |
| Agentforce | Field Audit Trail | ✅ Field Audit Trail is enabled on custom objects storing Agentforce decision data, retaining archived history indefinitely until deleted |
| Agentforce | Field Audit Trail | ✅ Field Audit Trail supports long-term fairness audits and regulatory investigations requiring reconstruction of historical AI decisions |
| CRM Analytics | Monitoring | ✅ CRM Analytics dashboards track fairness signals: sudden changes in decision distributions, spikes in bias-related Cases, performance degradation for specific populations |
| CRM Analytics | Monitoring | ✅ Alerts trigger when approval rates for any customer segment drop more than 15% week-over-week requiring fairness investigation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Agentforce | Analytics | ⚠️ Decision outcomes are not tracked by demographics; bias drift goes undetected as data distributions shift |
| Agentforce | Analytics | ⚠️ Service quality metrics are not stratified by demographic group; disparate outcomes remain invisible |
| Agentforce | Event Monitoring | ⚠️ Event Monitoring logs rely on native retention limits without external SIEM for long-term fairness audits |
| Agentforce | Event Monitoring | ⚠️ Decision patterns are not analyzed across large volumes of interactions; anomalous concentrations are missed |
| Agentforce | Field Audit Trail | ⚠️ Field Audit Trail is not enabled; historical AI decisions cannot be reconstructed for regulatory investigations |
| CRM Analytics | Monitoring | ⚠️ Fairness signals are not monitored; sudden changes in decision distributions go unnoticed |
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein | Training Data | ✅ Salesforce CRM data is rebalanced through oversampling underrepresented segments or undersampling overrepresented segments before training |
| Data 360 | Architecture | ✅ Data 360 aggregates data across multiple orgs ensuring diverse training sets for predictive models |
| Einstein | Training Data | ✅ Synthetic data generation supplements sparse segments while preserving privacy through differential privacy techniques |
| Einstein | Feature Engineering | ✅ Proxy features are replaced with alternative features providing predictive power without demographic correlation |
| Einstein | Feature Engineering | ✅ Industry classification or company size are used instead of territory when territory serves as demographic proxy |
| Einstein | Feature Engineering | ✅ Firmographic attributes are used instead of account name patterns when names correlate with demographics |
| Agentforce | Post-Processing | ✅ Decision thresholds are adjusted per demographic segment to equalize outcome rates after model training, except that, in the United States, Title VII (Civil Rights Act of 1991) prohibits adjusting scores or cutoffs by protected class for employment-related decisions, and other jurisdictions impose their own constraints |
| Agentforce | Post-Processing | ✅ Different confidence thresholds are used for different contexts achieving equitable approval rates while using the same underlying predictive model |
| Agentforce | Post-Processing | ✅ Threshold adjustments are documented with business justification for differential treatment, recognizing that in the United States, no documentation makes per-group score or cutoff adjustment lawful for employment-related decisions under Title VII |
| Einstein | Model Retraining | ✅ Quarterly or event-driven retraining schedule is established catching emerging bias patterns and correcting drift from original fairness baselines |
| Einstein | Model Retraining | ✅ Fairness metrics are revalidated on every model version before production deployment ensuring retraining did not introduce new bias |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Einstein | Training Data | ⚠️ Training data is used directly without rebalancing underrepresented or overrepresented segments |
| Einstein | Training Data | ⚠️ Sparse demographic segments are not supplemented with synthetic data or cross-org aggregation |
| Einstein | Feature Engineering | ⚠️ Proxy features are retained without evaluating alternative features providing predictive power without demographic correlation |
| Agentforce | Post-Processing | ⚠️ Same confidence thresholds are applied to all demographic segments without equalizing outcome rates |
| Agentforce | Post-Processing | ⚠️ Differential treatment through threshold adjustments lacks documented business justification, or, in the United States, is applied to employment-related decisions at all, where Title VII prohibits adjusting scores or cutoffs by protected class regardless of documentation |
| Einstein | Model Retraining | ⚠️ Models are deployed and never retrained; emerging bias patterns and drift go uncorrected |
| Einstein | Model Retraining | ⚠️ Retraining happens without revalidating fairness metrics; new bias is introduced silently |
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein Discovery | UX | ✅ Einstein Discovery explanations showing prediction factors are surfaced in Lightning components at the point of decision |
| Einstein Discovery | UX | ✅ Explanations show which variables most influenced specific predictions with directional impact for users at decision points |
| Einstein Discovery | UX | ✅ Explanations are layered for different audiences: business users, technical users, customers, and auditors |
| Einstein Discovery | UX | ✅ Business users see “This lead scored high because annual revenue exceeds $1M and engagement score is in top 10%“ |
| Einstein Discovery | UX | ✅ Technical users see model cards with feature weights, training data characteristics, and validation metrics |
| Einstein Discovery | UX | ✅ Customers see “This recommendation is based on your recent purchases and customers with similar preferences” |
| Einstein Discovery | UX | ✅ Auditors see complete decision lineage from Einstein Discovery and Model Manager with model version, input values, and the factors that drove the prediction |
| Einstein Discovery | UX | ✅ Prediction confidence is displayed in user-appropriate terms as categories (High Confidence, Moderate Confidence, Needs Review) with explanations |
| Einstein Discovery | UX | ✅ Confidence categories explain what confidence level means for decision reliability and what additional review will occur |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Einstein Discovery | UX | ⚠️ Explanations are retrofitted onto opaque systems after deployment instead of building explainability into the architecture from the start |
| Einstein Discovery | UX | ⚠️ Prediction explanations require navigation to separate CRM Analytics dashboards instead of displaying at decision points |
| Einstein Discovery | UX | ⚠️ Users see abstract model performance metrics instead of transparent explanations when decisions affect them |
| Einstein Discovery | UX | ⚠️ Explanations do not vary by audience; technical model cards are shown to customers or business users |
| Einstein Discovery | UX | ⚠️ Raw prediction scores (0.73) are displayed with no explanation of what the number means or which factors drove prediction |
| Einstein Discovery | UX | ⚠️ Confidence is shown as probability percentages users misinterpret without context about reliability or review |
Patterns
| Where to look | What good looks like |
|---|---|
| Einstein | Trust Layer | ✅ Einstein Trust Layer logs prompts, responses, grounding sources, and trust signals automatically without custom instrumentation |
| Einstein | Trust Layer | ✅ Data retention policies are architected meeting regulatory requirements varying by industry and jurisdiction (for example, FINRA Rule 4511(b) sets a default six-year retention period, and HIPAA requires a minimum of six years for compliance documentation) |
| CRM Analytics | Monitoring | ✅ CRM Analytics dashboards analyze captured predictive-model decision data for decision patterns, fairness metrics, and model performance over time |
| CRM Analytics | Monitoring | ✅ CRM Analytics lenses show prediction distributions by confidence level, demographic segment, and outcome type |
| CRM Analytics | Monitoring | ✅ Einstein Discovery stories identify anomalous patterns requiring investigation |
| Platform | Field Audit Trail | ✅ Field Audit Trail is enabled on custom objects storing AI decision data, retaining archived history indefinitely until deleted for consent records, override decisions, and bias reports |
| Platform | Event Monitoring | ✅ Event Monitoring captures Agentforce conversation transcripts, tool invocations, and decision points |
| Platform | Event Monitoring | ✅ Event Monitoring logs are routed to external SIEM via Platform Events for tamper-evident storage |
| Platform | Event Monitoring | ✅ SIEM queries detect bias patterns across large volumes of Agentforce interactions |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Einstein | Trust Layer | ⚠️ Agentforce interactions are deployed without enabling Trust Layer audit capture or defining retention policies |
| Einstein | Trust Layer | ⚠️ Retention policies do not account for industry-specific regulatory requirements (financial services, healthcare) |
| CRM Analytics | Monitoring | ⚠️ Captured predictive-model decision data is not analyzed; decision patterns and fairness metrics are not tracked over time |
| Platform | Field Audit Trail | ⚠️ Standard 18-month field history is relied upon for AI decision audit trails without considering regulatory retention requirements |
| Platform | Field Audit Trail | ⚠️ Field Audit Trail is not enabled on objects with consent records, override decisions, and bias reports |
| Platform | Event Monitoring | ⚠️ Event Monitoring logs rely on native retention limits without external SIEM for tamper-evident long-term storage |
| Platform | Event Monitoring | ⚠️ Agentforce interaction logs are not analyzed for bias patterns across large volumes |
Patterns
| Where to look | What good looks like |
|---|---|
| Governance | EU AI Act | ✅ High-risk AI systems are documented with transparency documentation, technical documentation, human oversight capabilities, and accuracy/fairness metrics |
| Governance | EU AI Act | ✅ Einstein Trust Layer audit trails and Discovery model cards provide foundations for EU AI Act transparency requirements |
| Governance | EU AI Act | ✅ Model training data demographics, validation approaches, and known limitations are documented in architecture decision records |
| Governance | GDPR | ✅ Systems generate coherent explanations for any historical decision on demand within data subject access request timeframes (which vary by jurisdiction, between 15 and 45 days) |
| Governance | GDPR | ✅ Captured predictive-model decision data and Einstein Discovery explanation factors are stored with sufficient retention enabling explanation reconstruction for GDPR right to explanation |
| Governance | Algorithmic Accountability | ✅ Algorithmic impact assessments are conducted before deploying consequential AI as proactive compliance rather than reactive response |
| Governance | Algorithmic Accountability | ✅ Captured predictive-model decision data and CRM Analytics fairness-monitoring dashboards provide data foundations for algorithmic accountability reporting |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Governance | EU AI Act | ⚠️ High-risk AI systems are deployed without transparency documentation, human oversight capabilities, or fairness metrics |
| Governance | EU AI Act | ⚠️ Model training data demographics and known limitations are not documented in architecture decision records |
| Governance | GDPR | ⚠️ Systems cannot generate coherent explanations for historical decisions within GDPR data subject access request timeframes |
| Governance | GDPR | ⚠️ Captured predictive-model decision data retention is insufficient to support explanation reconstruction for past decisions |
| Governance | Algorithmic Accountability | ⚠️ Algorithmic impact assessments are not conducted before consequential AI deployment; compliance is reactive after regulatory inquiry |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | OWD | ✅ Private Organization-Wide Defaults are established for objects containing sensitive customer data with access granted through role hierarchy and sharing rules |
| Platform | OWD | ✅ Private OWDs with explicit sharing grants create auditable access patterns supporting non-discrimination compliance |
| Platform | Field-Level Security | ✅ Sensitive fields containing protected characteristics (ethnicity, religion, disability status) are hidden via FLS from users without legitimate business need |
| Platform | Field-Level Security | ✅ Read access to sensitive fields is removed via FLS for most profiles; access is granted minimally through permission sets with documented justification |
| Platform | Assignment & Routing | ✅ Assignment rules, queues, and Omni-Channel routing distribute work equitably across territories, teams, and service agents based on objective criteria |
| Platform | Sharing Rules | ✅ Automatic sharing rules are based on objective criteria (industry, geography, product line) rather than subjective manager discretion |
| Platform | Permission Sets | ✅ Temporary access to sensitive data is granted through permission sets with documented expiration rather than permanent profile modifications |
| Platform | Permission Sets | ✅ Scheduled Flow revokes permission sets automatically after defined periods when access to demographic data is needed for specific projects |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | OWD | ⚠️ Public Read/Write OWDs make restricting access later disruptive (tightening the default triggers a sharing recalculation); auditable access patterns do not exist |
| Platform | OWD | ⚠️ Account OWD is set to Public Read/Write with unprotected demographic fields visible to all users enabling subjective bias |
| Platform | Field-Level Security | ⚠️ Sensitive demographic fields are visible to all profiles without FLS restrictions; discriminatory data usage is not prevented |
| Platform | Sharing Rules | ⚠️ Manual sharing concentrates high-value opportunities with specific user groups without documented business justification |
| Platform | Sharing Rules | ⚠️ Sharing rules rely on subjective manager discretion rather than objective criteria enabling bias |
| Platform | Permission Sets | ⚠️ Profiles are modified permanently affecting all users instead of granting temporary access through permission sets |
| Platform | Permission Sets | ⚠️ Permission sets granting sensitive data access do not expire automatically; access remains indefinitely after project completion |
Patterns
| Where to look | What good looks like |
|---|---|
| Shield | Event Monitoring | ✅ Shield Event Monitoring tracks access to fields containing protected characteristics or sensitive attributes |
| Shield | Event Monitoring | ✅ Event Monitoring queries track who accesses demographic fields, when, and in what context detecting anomalous patterns |
| Shield | Event Monitoring | ✅ Anomalous access patterns (sudden spikes, access by unexpected users) trigger investigation for potential misuse |
| Platform | Reporting | ✅ Reports analyze how sharing rules distribute records across users, teams, and territories calculating distribution statistics by customer demographics |
| Platform | Reporting | ✅ Reports identify concentrations where specific user groups receive disproportionate access to valuable records without documented justification |
| Platform | Setup Audit Trail | ✅ Setup Audit Trail is reviewed for changes to OWD settings, sharing rules, FLS configurations, and permission sets detecting unauthorized changes |
| Platform | Transaction Security | ✅ Transaction Security policies act on high-risk Real-Time Event Monitoring events (anomalous API activity, suspicious logins, large exports of sensitive data); FLS and sharing changes rely on Setup Audit Trail and documented change-management approvals |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Shield | Event Monitoring | ⚠️ Access to sensitive demographic fields is not monitored; potential misuse goes undetected |
| Shield | Event Monitoring | ⚠️ Anomalous access patterns (spikes, unexpected users) are not tracked or investigated |
| Platform | Reporting | ⚠️ Sharing rule distributions are not analyzed; disproportionate access to valuable records remains invisible |
| Platform | Reporting | ⚠️ Concentrations of high-value accounts with specific user groups lack documented business justification |
| Platform | Setup Audit Trail | ⚠️ Setup Audit Trail is not reviewed; unauthorized changes to data access controls enabling sensitive data access are not detected |
| Platform | Transaction Security | ⚠️ High-risk Real-Time Event Monitoring events (anomalous API activity, large exports of sensitive data) are not acted on with Transaction Security policies |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Custom Objects | ✅ Granular consent per AI use case is enabled through custom Consent object tracking purpose, grant date/method, withdrawal date, and related User/Contact ID |
| Platform | Custom Objects | ✅ Customers consent to Einstein product recommendations while declining AI-driven credit decisions through separate consent records per use case |
| Platform | Field Audit Trail | ✅ Field Audit Trail is enabled on Consent object for long-term retention meeting regulatory requirements |
| Data 360 | Consent | ✅ Data 360 consent management is used for Einstein personalization features, ingesting and storing consent preferences via connectors mapped to the Privacy Data Model and using them as filter criteria in segmentation and at activation |
| Data 360 | Consent | ✅ Consent categories map to specific AI use cases enabling users to opt out of personalization while maintaining core service |
| Marketing Cloud | Consent | ✅ Marketing Cloud consent integrates with Einstein Messaging Insights and Agentforce marketing agents respecting subscription status |
| Marketing Cloud | Consent | ✅ Marketing Cloud consent status is queried before Agentforce initiates automated outreach preventing unwanted contact with users who opted out |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Custom Objects | ⚠️ AI consent is tracked in spreadsheets or relies on login as implicit blanket consent without explicit records |
| Platform | Custom Objects | ⚠️ Blanket AI consent is used instead of granular per-use-case consent; users cannot opt out of specific AI features |
| Platform | Field Audit Trail | ⚠️ Field Audit Trail is not enabled on Consent object; long-term retention meeting regulatory requirements is not maintained |
| Data 360 | Consent | ⚠️ Data 360 consent is not used for Einstein personalization; consent categories do not map to specific use cases |
| Marketing Cloud | Consent | ⚠️ Marketing Cloud consent is not integrated with Einstein or Agentforce; subscription status is not respected in automated outreach |
Patterns
| Where to look | What good looks like |
|---|---|
| Experience Cloud | Profile Settings | ✅ Users opt out of Agentforce interactions through accessible preference controls in Experience Cloud profile settings or My Settings with clear descriptions |
| Platform | User/Contact Records | ✅ AI preferences are stored in User or Contact records enabling query in Flow and Agentforce decision logic |
| Agentforce | Omni-Channel | ✅ Users who opt out of Agentforce are routed to human agents via Omni-Channel rather than receiving degraded service |
| Agentforce | Flow | ✅ Flow checks consent and preference fields before Agentforce engagement; if user opted out, work record is created and routed to human queue |
| Agentforce | Omni-Channel | ✅ Human queue staffing provides comparable wait times to automated service for users who opted out |
| Platform | User/Contact Records | ✅ AI preferences are stored in User or Contact records ensuring consistency across channels (web, mobile, phone, email) |
| Platform | Flow | ✅ Preference is queried consistently in all interaction flows preventing users from needing to re-assert preferences repeatedly on each channel |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Experience Cloud | Profile Settings | ⚠️ Opt-out is available only through email to support team; accessible preference controls do not exist |
| Platform | User/Contact Records | ⚠️ AI preferences are not stored in User or Contact records; preferences cannot be queried in Flow or Agentforce logic |
| Agentforce | Omni-Channel | ⚠️ Users who opt out receive degraded service as implicit pressure to accept AI instead of routing to human agents |
| Agentforce | Flow | ⚠️ Flow does not check consent or preference fields before Agentforce engagement; opt-out preferences are ignored |
| Platform | User/Contact Records | ⚠️ Preferences are not consistent across channels; users must re-assert opt-out on web, mobile, phone, and email separately |
Patterns
| Where to look | What good looks like |
|---|---|
| Governance | Documentation | ✅ Every production predictive model is documented with training data demographics, fairness metrics, intended use cases, bias mitigation strategies, and monitoring approaches |
| Governance | Documentation | ✅ Model documentation includes the fairness-monitoring approach, alert thresholds, human oversight requirements, review schedule, and regulatory considerations |
| Platform | Custom Objects | ✅ Model documentation is stored in Salesforce using custom Model object or Salesforce Files attached to Projects enabling searchability and version control |
| Governance | Deployment Gates | ✅ Pre-deployment fairness gates require training data audit, fairness metrics calculation, impact assessment, human oversight design, and transparency review before production |
| Governance | Deployment Gates | ✅ Training data representation gaps are analyzed and documented as mandatory deployment gate |
| Governance | Deployment Gates | ✅ Demographic parity, equal opportunity, and disparate impact are calculated meeting thresholds as mandatory gate |
| Governance | Deployment Gates | ✅ Impact assessment evaluates potential harms across affected populations as mandatory gate |
| Governance | Deployment Gates | ✅ Human oversight design including escalation patterns, approval workflows, and override mechanisms are designed and tested as mandatory gate |
| Governance | Deployment Gates | ✅ Explanation capabilities are validated for all decision types as mandatory gate |
| Governance | Deployment Gates | ✅ Fairness gates are treated with same rigor as security gates with authority to block deployments failing any gate |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Governance | Documentation | ⚠️ Einstein features are deployed without documenting training data, fairness metrics, bias mitigation, or monitoring approaches |
| Governance | Documentation | ⚠️ Model documentation does not include the fairness-monitoring approach, human oversight requirements, or regulatory considerations |
| Platform | Custom Objects | ⚠️ Model documentation is stored in spreadsheets or wikis without searchability or version control |
| Governance | Deployment Gates | ⚠️ Einstein features proceed to production without fairness gates; deployment is based solely on overall accuracy metrics |
| Governance | Deployment Gates | ⚠️ Training data audit, fairness metrics calculation, or impact assessment are skipped before production deployment |
| Governance | Deployment Gates | ⚠️ Human oversight design, transparency review, or explanation validation are not performed before production |
| Governance | Deployment Gates | ⚠️ Fairness gates are advisory-only without authority to block deployments; models proceed despite failing fairness criteria |
Patterns
| Where to look | What good looks like |
|---|---|
| Governance | Review Board | ✅ Review board includes technical experts (architects, data scientists), business stakeholders, legal counsel, privacy specialists, and representatives from affected communities |
| Governance | Review Board | ✅ Diverse perspectives surface fairness issues homogeneous groups miss during ethics review |
| Governance | Review Triggers | ✅ Review triggers are defined: decisions affecting employment/credit/housing/healthcare/legal rights, systems affecting >10K users annually, novel use cases, significant harm risk |
| Governance | Review Triggers | ✅ AI applications using sensitive personal data (health, financial, demographic) require ethics review before deployment |
| Governance | Review Authority | ✅ Ethics review board has authority to require changes, impose monitoring conditions, or block deployments failing ethical standards |
| Platform | Custom Objects | ✅ All reviews are documented in Salesforce custom object tracking application name, review date, concerns raised, mitigation requirements, and approval conditions |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Governance | Review Board | ⚠️ Review board lacks diversity (only technical experts); homogeneous groups miss fairness issues affecting different populations |
| Governance | Review Board | ⚠️ Representatives from affected communities are not included; blind spots in fairness considerations result |
| Governance | Review Triggers | ⚠️ Review triggers are not defined; high-risk AI applications proceed without ethics review before deployment |
| Governance | Review Authority | ⚠️ Ethics review is advisory-only without enforcement; deployments proceed despite failing ethical standards (accountability theater) |
| Platform | Custom Objects | ⚠️ Reviews are not documented systematically; historical review decisions, concerns, and mitigations are not tracked |
Patterns
| Where to look | What good looks like |
|---|---|
| CRM Analytics | Monitoring | ✅ CRM Analytics dashboards track Einstein and Agentforce fairness metrics from captured decision data and Trust Layer audit data on a scheduled cadence |
| CRM Analytics | Monitoring | ✅ Demographic parity, equal opportunity, disparate impact ratios, and service quality metrics are monitored by customer segment |
| CRM Analytics | Monitoring | ✅ CRM Analytics alerts are configured triggering when fairness metrics breach defined thresholds requiring investigation |
| CRM Analytics | Monitoring | ✅ CRM Analytics dashboards track fairness signals: sudden changes in decision distributions, spikes in bias-related Cases, performance degradation for specific populations |
| CRM Analytics | Monitoring | ✅ Alerts trigger for Einstein Opportunity Scoring when approval rates for any segment drop more than 15% week-over-week requiring fairness investigation |
| Governance | Scheduled Audits | ✅ Comprehensive fairness audits are conducted quarterly for high-stakes AI (credit, employment, healthcare) or semi-annually for lower-stakes systems |
| Governance | Scheduled Audits | ✅ Audits examine current fairness metrics, review override patterns, analyze user feedback and bias reports, and validate governance controls remain effective |
| Governance | Incident Response | ✅ Clear incident response processes are documented in Salesforce Knowledge for responding when bias is detected |
| Governance | Incident Response | ✅ Immediate severity assessment by querying predictive-model decision data in CRM Analytics; severe bias suspends automated decision-making pending investigation |
| Governance | Incident Response | ✅ Temporary mitigation implements increased human oversight via adjusted confidence thresholds, feature disablement, or complete agent suspension |
| Governance | Incident Response | ✅ Root cause analysis identifies how bias entered or evolved; training data, model versions, and configuration changes are analyzed via Field Audit Trail |
| Governance | Incident Response | ✅ Permanent remediation implements data correction, model retraining, or process changes with appropriate communication to affected users |
| Governance | Incident Response | ✅ Prevention measures are documented in runbooks preventing recurrence of bias incidents |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| CRM Analytics | Monitoring | ⚠️ Fairness metrics are not tracked on any scheduled cadence from captured decision data or Trust Layer audit data; bias drift goes undetected as data distributions change |
| CRM Analytics | Monitoring | ⚠️ CRM Analytics alerts are not configured; fairness metric breaches requiring investigation are not triggered |
| CRM Analytics | Monitoring | ⚠️ Fairness signals are not monitored; sudden changes in decision distributions are not detected |
| Governance | Scheduled Audits | ⚠️ Comprehensive fairness audits are not conducted on any schedule; governance controls drift and become ineffective |
| Governance | Scheduled Audits | ⚠️ Override patterns, user feedback, and bias reports are not systematically analyzed during audits |
| Governance | Incident Response | ⚠️ Clear incident response processes are not documented; bias detection leads to ad hoc responses without systematic approach |
| Governance | Incident Response | ⚠️ Temporary mitigation or permanent remediation are not implemented systematically; bias persists affecting users |
| Governance | Incident Response | ⚠️ Root cause analysis is not conducted; how bias entered or evolved remains unknown |
| Governance | Incident Response | ⚠️ Prevention measures are not documented; recurrence is not prevented |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Required Fields | ✅ Every required field carries a documented business justification for why the data is mandatory rather than optional; fields a process can function without are made optional with downstream handling for missing values |
| Platform | Required Fields | ✅ Email is optional with alternative communication methods (SMS, phone, postal mail) so users without reliable internet or personal email are not excluded from account creation |
| Platform | Name Fields | ✅ Name architecture uses a single full-name field or flexible multi-part structure that accommodates mononyms, patronymic systems, and multiple given or family names without assuming order or inheritance |
| Platform | Name Fields | ✅ Name fields are tested with diverse international names, accepting single-word names, long names, diacritics, apostrophes, hyphens, and non-Latin scripts (Arabic, Chinese, Cyrillic, Devanagari) |
| Platform | Address Validation | ✅ Permissive address validation accepts free-form entry when structured validation fails and stores addresses as users enter them rather than forcing invalid corrections |
| Platform | Address Validation | ✅ Address verification is built into fulfillment processes where accuracy matters operationally rather than blocking data capture upfront |
| Platform | Communication Preferences | ✅ Preferred communication methods are stored on Contact records and respected consistently across all outbound systems, offering omnichannel alternatives rather than single-channel assumptions |
| Custom Object | Demographic Data | ✅ Voluntary demographic data is collected through a separate survey with a “Prefer not to answer” option, stored in a custom object with Private OWD, restricted by FLS, and used only for aggregate fairness analytics |
| Shield | Event Monitoring | ✅ Shield Event Monitoring logs access events (report exports, API object queries) on demographic data to audit access patterns |
| Platform | Third-Party Enrichment | ✅ Third-party enrichment vendors are audited for fairness testing, demographic coverage and accuracy, inference methodology, and contractual data-usage restrictions before implementation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Required Fields | ⚠️ Email is required for account creation with no alternative, and phone or address validation rejects non-US formats, PO boxes, and rural routes, excluding users who cannot provide the data |
| Platform | Required Fields | ⚠️ Fields are marked required without documenting whether the process could function without the data, creating invisible populations from rejected incomplete records |
| Platform | Name Fields | ⚠️ Name fields enforce Western First/Last conventions and reject mononyms, diacritics, or non-Latin scripts, subjecting users to system rejection based on cultural identity |
| Platform | Address Validation | ⚠️ Address validation requires US postal format and fails to recognize international addresses, PO boxes, military (APO/FPO), or tribal-land addresses, blocking account creation and service delivery |
| Platform | Communication Preferences | ⚠️ A single communication channel is assumed universal (email-only or phone-only), excluding users without internet, without phone access, or who are deaf or hard-of-hearing |
| Custom Object | Demographic Data | ⚠️ Demographic data is inferred from names or locations without user knowledge, stored in standard Contact fields visible to all users, and used in lead scoring or forecasting without disclosure |
| Platform | Third-Party Enrichment | ⚠️ Third-party data is appended without auditing vendor fairness practices or demographic coverage, importing vendor-introduced bias into org decisions |
Patterns
| Where to look | What good looks like |
|---|---|
| Platform | Assignment & Routing | ✅ Assignment and routing rules use objective criteria (product lines, SLAs, language requirements) and assignment distributions are audited quarterly, stratified by customer demographics, to ensure no concentration patterns emerge |
| Platform | Omni-Channel | ✅ Average time-to-handle, first-contact resolution, and customer satisfaction are monitored across routing paths to detect whether customer segments systematically receive less experienced agents |
| Platform | Flow | ✅ Flows making consequential decisions are reviewed for criteria that correlate with protected characteristics (account tenure, channel preference, purchase history, business hours) and their decision logic is documented in architecture decision records |
| Platform | Flow | ✅ High-stakes Flows affecting employment, credit, or service access are subject to the same ethics review process as AI systems |
| Platform | Validation Rules | ✅ Validation rules are tested with diverse data (international addresses, non-Western names, alternative phone formats) and expanded whenever they reject legitimate data; Name fields accept Unicode and all scripts |
| Platform | Territory Design | ✅ Customer demographics are mapped across proposed territory boundaries before designs are finalized; where concentrations emerge, resource allocation is evaluated for equity and business justification is documented and monitored |
| Platform | Auditing | ✅ Automation logic (business rules, assignment criteria, Flow decisions) is documented in Salesforce Knowledge or ADRs, and outcomes are audited quarterly stratified by demographics — assignment distributions, Flow approval rates, validation rejection rates, and territory resource allocation |
Anti-Patterns
| Where to look | What bad looks like |
|---|---|
| Platform | Assignment & Routing | ⚠️ Assignment rules prioritize leads from certain zip codes to “top performers” based on historical win rates without examining whether that success reflects skill or demographic advantage |
| Platform | Omni-Channel | ⚠️ Routing quality metrics are not monitored across customer segments, so disparities in agent experience or resolution go undetected |
| Platform | Flow | ⚠️ Flow decision criteria correlate with protected characteristics (tenure, channel, purchase volume, time zone) and are treated as objective because deterministic logic feels neutral |
| Platform | Flow | ⚠️ High-stakes Flows make consequential decisions without ethics review, ADR documentation, or handling for users outside the typical customer profile |
| Platform | Validation Rules | ⚠️ Name validation is restricted to A-Z and rejects diacritics or non-Latin scripts, and address validation requires US postal format — legitimate data is rejected and users abandon requests unreported |
| Platform | Territory Design | ⚠️ Territory boundaries follow geography that correlates with demographics, with differing compensation or staffing across territories and no analysis of demographic concentration |
| Platform | Auditing | ⚠️ Automation logic is undocumented and outcomes are never audited, so discriminatory patterns in assignment, approvals, validation, or territory allocation remain invisible |