Справедливость

Справедливость

В архитектурах Salesforce справедливость означает создание решений, которые одинаково обслуживают пользователей посредством доступных интерфейсов, обнаружения и смягчения предвзятости, прозрачных решений и этического управления. Прогнозы Einstein влияют на результаты, влияющие на заказчиков и сотрудников, а это значит, что архитекторы должны проектировать системы, которые дают справедливые результаты по всем демографическим группам, но при этом остаются доступными для пользователей с ограниченными возможностями.

Salesforce предоставляет возможности платформы, специально созданные для справедливости, и мы стремимся соответствовать WCAG 2.2 AA. При корректном использовании Salesforce Lightning Design System (SLDS) предоставляет компоненты, которые созданы для поддержки этой цели. Рассмотрим подробнее каждый компонент.

  • Shield Platform Encryption защищает конфиденциальные атрибуты, например, демографические данные, а Event Monitoring предоставляет контрольные журналы, поддерживающие прозрачную обработку данных.
  • Einstein Trust Layer (ETL) собирает безопасный контрольный журнал для генерирующих подсказок на основе искусственного интеллекта и ответов с целью мониторинга и соответствия.
  • Experience Cloud содержит элементы управления доступностью.
  • Контрольный журнал поля предоставляет долгосрочное сохранение журнала изменений данных поля, поддерживающего алгоритмическую подотчетность при хранении данных решений на основе искусственного интеллекта в отслеживаемых полях.

Эти возможности помогают снизить операционные затраты на практики добросовестности Salesforce.

В Salesforce справедливость действует в трех измерениях для предоставления решений. Инклюзивный дизайн помогает сделать веб-компоненты Lightning (LWC), страницы Visualforce и сайты Experience Cloud полностью доступными — с безупречной навигацией с клавиатуры, совместимостью экранного диктора и когнитивными приспособлениями дизайна. Практика справедливости на основе искусственного интеллекта помогает прогнозам Einstein получать справедливые результаты, используя обнаружение предвзятости, разнообразные данные обучения и постоянный мониторинг. Управление предоставляет процессы и элементы управления для поддержания справедливости по мере развития моделей и расширения способов использования.

Пренебрежение справедливостью создает дополнительный риск. Недоступные сайты Experience Cloud могут подвергать организации судебному разбирательству в связи с Законом об американцах-инвалидах, а для федеральных учреждений и их подрядчиков - нарушениям статьи 508. В зависимости от классификации рисков системы и новых законов об алгоритмической подотчетности предвзятые прогнозы Einstein могут нарушать требования Закона ЕС об искусственном интеллекте. Исключительно автоматизированные решения на основе искусственного интеллекта, имеющие юридические или аналогичные последствия, которые не содержат значимой информации о логике принятия решений, могут нарушать права информации, закрепленные в статье 22 ГДР и статье 15(1)(h).

Организации, создающие проект для обеспечения справедливости, обычно уменьшают прогнозируемый ущерб клиентам, сотрудникам и сообществам, на которые влияют их системы. Нарушения справедливости могут причинить ощутимый материальный ущерб пострадавшим лицам, включая экономический ущерб, отказ в возможностях, эмоциональный стресс и усиление системной дискриминации. Согласование нормативных положений, как правило, является следствием хорошего обслуживания затрагиваемых лиц.

Используйте эти принципы для руководства архитектурными решениями для справедливости на платформе.

  • Разработайте схемы доступности Lightning. При создании используйте Lightning Design System и стандартные веб-компоненты Lightning, которые созданы для поддержки доступности WCAG 2.2 AA при любой возможности. При создании с помощью SLDS вы используете библиотеку, где доступность является основным принципом дизайна. Компоненты SLDS проверяются на доступность клавиатуры и совместимость с вспомогательными технологиями, а многие содержат раздел доступности с подсказками разработчика. Если настраиваемый компонент обязателен, то внедрение четких доступных приложений обогащенного интернета (WAI-ARIA), семантические схемы HTML и клавиатуры-навигации должны быть проверены посредством тестирования вспомогательных технологий.
  • Уменьшите и отслеживайте предвзятость с помощью соответствующих инструментов для каждого типа модели. Проверьте результаты на основе искусственного интеллекта для достижения справедливых результатов в демографических группах перед развертыванием и постоянно в производстве. В прогнозируемых моделях собирайте данные решений посредством Einstein Discovery и настраиваемой аппаратуры и анализируйте их в CRM Analytics для измерения показателей справедливости; для генеративных функций искусственного интеллекта и Agentforce используйте контрольный журнал подсказок и ответов Einstein Trust Layer (ETL). Документируйте решения в соответствии с требованиями прозрачности регулирования.
  • Leverage Shield Platform Encryption для элементов управления защитой данных. Используйте Shield Platform Encryption с детерминистскими схемами для конфиденциальных атрибутов, требующих точного совпадения запросов, одновременно защищая личные данные. Перенаправляйте журналы мониторинга событий во внешнюю систему управления информацией о безопасности и событиями (SIEM) для поддержки контрольных журналов с подделкой - когда SIEM внедряет разделение хранения и доступа с записью, превышающее собственные окна сохранности Salesforce для необходимых правил.
  • Разработайте бизнес-правила проверки для прогнозов с высокими ставками. Настройте процессы утверждения и механизмы проверки в Salesforce Flow, чтобы прогнозы Einstein, влияющие на последующие решения, получали соответствующую проверку человеком. Используйте пороги надежности и бизнес-правила, чтобы определить, когда прогнозы требуют проверки, прежде чем предпринимать действия.
  • Применение единых стандартных параметров (OWD) и параметров безопасности на местах (FLS) для недопущения дискриминации. Архитектура схем доступа к данным посредством OWD и FLS для ограничения доступа по умолчанию и предоставления дополнительного доступа, необходимого каждой роли, только посредством правил общего доступа. Избегайте предоставления профилям чрезмерного доступа, который может раскрыть конфиденциальные атрибуты и включить принятие дискриминационных решений.
  • Включение функции управления пользователями посредством согласия платформы. Используйте возможности управления согласием в Data 360 или настраиваемые объекты согласия с контрольным журналом поля для отслеживания детального согласия на основе искусственного интеллекта на сценарий использования. Предоставьте пользователям возможность отказаться от функций на основе искусственного интеллекта и предоставить человеческие альтернативы (при возможности).

Решения по архитектуре данных определяют совокупности, которые становятся видимыми и невидимыми в системах Salesforce. Низкое качество данных - это не только техническая проблема. Проблема справедливости возникает, когда пробелы в данных систематически ставят в неблагоприятное положение конкретные демографические группы.

  • Просмотрите обязательные поля на наличие данных. Если обязательные поля предполагают наличие информации, различающейся в демографии, полнота данных становится дискриминационной. Пользователи, которые не могут предоставить требуемую информацию, становятся невидимыми в системах, отклоняющих неполные записи.
    • Требование адресов эл. почты исключает группы населения, не имеющие надежного доступа к Интернету или личных адресов эл. почты.
    • Требование номеров социального обеспечения США (SSN) исключает международных клиентов и недавних иммигрантов, которым еще не выдан SSN.
    • Требование адресов улиц исключает бездомных и пользователей с нетрадиционными адресами.
  • Аудит бизнес-обоснований обязательных полей. Для каждого обязательного поля важно документировать, почему сведения являются обязательными, а не дополнительными. Если процессы могут функционировать без определенных данных посредством альтернативных подходов, сделайте эти поля необязательными и создайте системы для изящной обработки отсутствующих значений. Это помогает предотвратить исключение пользователей, которые не могут предоставить такие данные.

Поля имен, соответствующие западным правилам наименования (Личное имя, Фамилия), могут исключать культуры с разными практиками наименования.

Многие культуры используют:

  • Единые имена (или мононимы) без фамилий
  • Патронимические системы, где "фамилия" меняется поколенчес
  • Несколько имен или фамилий
  • Имена, изменяемые в зависимости от событий из жизни или социального контекста
  • Имена, где «первое» и «последнее» являются культурно бессмысленными различиями

Создайте архитектуру имени с помощью одного полного поля или гибкой многокомпонентной структуры, учитывающей распространенные правила наименования. Избегайте создания предположений об упорядочении имен, схемах наследования или культурных нормах.

Протестируйте архитектуру имен, используя разные международные имена, чтобы обеспечить принятие полей имен:

  • Однословные имена (например, Sukarno, Cher и Teller)
  • Длинные имена, превышающие распространенные ограничения длины полей
  • Имена с диакритикой, апострофами, дефисами и пробелами
  • Имена с нелатинской письменностью (например, арабский, китайский, кириллица и деванагари)

Когда проверка имени отклоняет законное имя пользователя, система отклоняет его на основе культурной самобытности.

Службы проверки адресов часто оптимизированы для форматов США и Западной Европы и часто не распознают:

  • Международные форматы адресов с разным порядком полей
  • Сельские адреса без названий улиц
  • Военные адреса (например, APO и FPO)
  • Коробки ОУ и альтернативные места доставки
  • Племенные земли с уникальными системами адресов
  • Страны с нелатинскими буквами для компонентов адреса

Когда проверки адресов отклоняют нетрадиционные форматы адресов, это предотвращает создание организаций, отправку и предоставление услуг пользователям, чьи адреса не соответствуют ожиданиям базы данных проверки.

Ниже указаны несколько способов создания проверок адресов с учетом доступности:

  • Внедрите проверку адреса.
  • Примите ввод адреса в свободной форме, если структурированные проверки не выполняются.
  • Храните адреса в том виде, в котором они введены пользователями, а не заставляйте пользователей вносить недопустимые исправления.
  • Используйте проверку адреса для пополнения данных и обнаружения дублирования, а не для проверки форматирования адреса.

Вместо блокировки сбора данных заранее, встройте проверку адреса в процессы выполнения, где точность адреса имеет оперативное значение.

Предположения универсального доступа для определенных каналов связи исключают группы населения с разным доступом к технологиям или предпочтениями.

Сообщение только электронной почты исключает:

  • Пользователи без надежного доступа к Интернету
  • Пожилые люди, которым неудобно пользоваться электронной почтой
  • Пользователи в регионах, где приложения SMS или службы сообщений являются основным методом связи

Телефонная связь исключает:

  • Глухие и слабослышащие пользователи
  • Пользователи без доступа к телефону или пользователи с общими телефонами

Создайте архитектуру мультиканала связи, позволяющую пользователям управлять параметрами канала. Сохраните предпочтительные методы связи в записях контактов и последовательно соблюдайте параметры во всех исходящих системах связи. Предоставьте разные альтернативы связи вместо предположения, что методы одного канала работают универсально.

Сбор демографических данных для мониторинга справедливости требует тщательной архитектуры для предотвращения неправильного использования.

Сбор и обработка демографических данных зависят от юрисдикции и юридически ограничены (в ЕС в статье 9 GDPR они рассматриваются как данные специальной категории, требующие наличия конкретной правовой основы; в США мониторинг предвзятости обычно основывается на добровольной самоидентификации РВЗ). При наличии законных оснований организации используют демографические данные для:

  • Мониторинг показателей справедливости, стратифицированных защищенными группами
  • Обнаружение предвзятости в системах автоматизации и искусственного интеллекта
  • Подтверждение соответствия нормативных положений антидискриминационным требованиям

Сбор демографических данных создает определенные риски:

  • Данные могут использоваться в дискриминационных целях при сбое управления доступом
  • Пользователи могут не доверять методам сбора и предоставлять неточные данные
  • Сбор может показаться инвазивным или дискриминационным

Архитектура добровольной самоидентификации и разработка сбора демографических данных с использованием информации, которая:

  • Четкое объяснение с прозрачной целью (например, мониторинг справедливости или отчетность по соблюдению)
  • «Добровольно» и содержит параметр «Предпочтение не отвечать», который всегда доступен
  • Отделено от операционных данных с помощью строгой FLS для предотвращения неправильного доступа
  • Агрегация для составления отчетов и аналитики и отсутствие привязки к отдельным решениям
  • Мониторинг посредством мониторинга событий Shield для аудита схемы доступа

Важно задокументировать в политиках конфиденциальности, как именно будут использоваться и не будут использоваться демографические данные. Нарушение user Trust посредством использования нераскрытых данных может серьезно подорвать доверие, восстановить которое бывает сложно.

Стороннее пополнение данных, дополняющее записи Salesforce демографическими, фирмографическими или поведенческими данными, может привести к предвзятости посредством:

  • Неверные выводы, основанные на стереотипах
  • Неполное покрытие с пробелами, коррелирующими с демографией
  • Собственные алгоритмы, использующие неизвестные свойства справедливости
  • Данные, полученные из предвзятых архивных записей

Прежде чем внедрить службы пополнения данных, важно выполнить аудит:

  • Тестирование на добросовестность поставщиков и практика уменьшения предвзятости
  • Охват и точность данных по демографическим группам
  • Методологии и функции вывода, используемые для создания прогнозов
  • Ограничения на использование контрактных данных и политики сохранности

Помните, что как только сторонние данные попадают в вашу организацию Salesforce, это может повлиять на решения, создавая введенную поставщиком предвзятость, которая также отражается как предвзятость в вашей организации.

В контекстах Salesforce доступность обозначает архитектурирование веб-компонентов Lightning, страниц Visualforce и сайтов Experience Cloud, работающих для пользователей с ограниченными возможностями. Стандартные компоненты Lightning предоставляют базовую доступность при правильном использовании; однако настраиваемая разработка и конфигурация Experience Cloud требуют явной реализации доступности.

Компоненты Lightning Design System созданы для поддержки соответствия WCAG 2.2 AA при их использовании по назначению. Salesforce стремится к полному соответствию, но не сертифицирует его. Отход от схем SLDS или создание настраиваемых компонентов без учета доступности создает препятствия для пользователей-инвалидов.

Стандартные веб-компоненты Lightning предоставляют встроенную доступность. Такие компоненты, как Lightning-input, Lightning-combobox, Lightning-datatable и Lightning-card автоматически содержат соответствующие атрибуты ARIA, связи с метками, навигацию с клавиатуры и управление фокусом. При возможности используйте стандартные компоненты, а не создавайте настраиваемые альтернативы, которые выглядят так же, но могут не иметь соответствующей инфраструктуры доступности.

  • Использовать семантический HTML в настраиваемых веб- компонентах Lightning. При создании настраиваемых компонентов используйте семантические HTML-элементы (
    ,
  • Внедрите ARIA в настраиваемые компоненты. Применяйте ориентиры, роли и свойства ARIA, если семантический HTML не может передать поведение интерфейса. Динамические обновления содержимого требуют областей в реальном времени арии, объявляющих об изменении программ чтения экрана. Настраиваемым интерактивным компонентам нужны четкие определения ролей, соответствующие их алгоритму. Базовые компоненты Lightning обрабатывают ARIA автоматически, однако настраиваемые компоненты требуют проверки ARIA вручную посредством тестирования экранного диктора.
  • Тестирование с помощью вспомогательных технологий: Проверьте компоненты Lightning с помощью фактических программ для чтения экрана (например, JAWS и NVDA для Windows, VoiceOver для macOS и iOS и TalkBack для Android). Судя по масштабному исследованию Deque, автоматизированные инструменты, например, ядро топора, набирают примерно 57% проблем доступности по объему. Остальные проблемы требуют ручного тестирования с помощью вспомогательных технологий людьми, которые понимают схемы навигации экранного диктора.
  • Используйте управление фокусом в потоках Lightning. Когда модалы открываются, динамическое содержимое загружается или пользователи выполняют многоэтапные потоки, вы должны программным способом управлять фокусом, чтобы направлять пользователей клавиатуры к новому содержимому. Модальные и всплывающие компоненты Lightning предоставляют базовое управление фокусом, но сложные потоки нуждаются в явной логике фокуса, чтобы правильно перемещать фокус по мере изменения содержимого.

Сайты Experience Cloud обслуживают внешних пользователей, включая клиентов, партнеров и общедоступную аудиторию, которым требуется доступный дизайн, соответствующий требованиям раздела 508 ADA и/или Европейского закона о доступности (в зависимости от юрисдикции, аудитории и типа организации).

  • Использовать доступные шаблоны. Шаблоны Experience Cloud, созданные с помощью Lightning Web Runtime (LWR), содержат базовую доступность. Стандартные шаблоны, например, Customer Account Portal и Help Center, предоставляют основы WCAG 2.2 AA при правильной настройке. Настраиваемые шаблоны требуют четкой реализации доступности, включительно с семантической разметкой, навигацией с клавиатуры и совместимостью экранного диктора.
  • Проверьте соответствие WCAG темам. Настраиваемые темы и фирменные сайты требуют цветовой контрастной проверки. Параметры темы конструктора взаимодействий управляют цветами, типографикой и интервалами. Убедитесь, что весь текст соответствует контрасту 4,5:1 для обычного текста (до 18пт для обычного или до 14пт для жирного) и 3:1 для большого текста (18пт или больше для обычного или 14пт или больше для жирного) и компонентов пользовательского интерфейса. Используйте инструменты разработчика обозревателя или интерактивные средства проверки контраста для проверки соответствия. Протестируйте масштабирование посредством обозревателя до 200%, чтобы обеспечить масштабирование текста без потери содержимого или функций.
  • Использовать клавиатуру в меню навигации. Компоненты навигации Experience Cloud должны поддерживать работу только с клавиатурой без зависимости от мыши. Пользователи должны входить и выходить из раскрывающихся меню, мегаменю и навигации по вылету с помощью клавиш Tab, Enter, Escape и стрелок без фокус-ловушек. Протестируйте все пути навигации, используя только клавиатуру, чтобы проверить доступность.
  • Включите доступность формы в Experience Cloud. Свяжите метки со всеми вводными данными формы посредством соответствующих элементов метки или меток арии. Текст структурного нуля сам по себе не соответствует требованиям доступности, поскольку текст исчезает сразу после начала ввода данных, что оставляет пользователей экранного диктора без достаточного постоянного контекста. Компоненты ввода Lightning предоставляют встроенное связывание меток, когда они настроены с помощью обязательных атрибутов меток. Настраиваемые формы Visualforce требуют четкого связывания метки и ввода.
  • Тестирование сайтов Experience Cloud посредством вспомогательных технологий. Прежде чем запустить общедоступные сайты Experience Cloud, необходимо выполнить комплексное тестирование доступности посредством программ для чтения экрана, навигации только с клавиатуры и увеличения обозревателя. Важно добавить пользователей с ограниченными возможностями в тестирование на удобство использования, чтобы выявить практические препятствия, которые часто могут пропустить эксперты. Тестирование только внутренних страниц Lightning без проверки внешней доступности Experience Cloud делает общедоступные сайты уязвимыми перед жалобами и судебными разбирательствами по поводу доступности.
  • Использовать альтернативный текст для изображений и значков. Все информативные изображения, значки и графическое содержимое в Experience Cloud требуют альтернативного текста. Декоративные изображения используют пустой альтернативный текст (alt=""), что позволяет экранным дикторам их пропустить. Информативные изображения предоставляют содержательный альтернативный текст, описывающий содержимое и функции. При написании альтернативного текста для значков сосредоточьтесь на действии или цели значка, а не на его визуальном отображении (например, вместо описания значка лупы как «лупа», альтернативный текст должен содержать функциональную полезность, например, «Поиск сайта»). При управлении изображениями CMS должна предложить авторам содержимого ввести альтернативный текст или четко обозначить изображение декоративным (что устанавливает alt=""). Это обеспечивает доступность, предотвращая отсутствие альтернативного текста и принудительных описаний для эстетических изображений.

Полная доступность клавиатуры означает, что пользователи могут получать доступ ко всем функциям посредством клавиатуры, не требуя взаимодействия мыши или касания в любой момент.

  • Использовать логический порядок фокусировки на страницах Lightning. Убедитесь, что порядок фокусировки соответствует визуальному макету и потоку взаимодействия. При нажатии кнопки «Вкладка» визуальный фокус должен перемещаться по интерактивным элементам в порядке, ожидаемом пользователями на основе визуального дизайна. Конструктор приложений Lightning и конструктор взаимодействий устанавливают порядок фокусировки на основе размещения компонентов. Настраиваемые компоненты требуют четкого управления табуляцией для обеспечения логического продвижения фокуса.
  • Используйте отображаемые индикаторы фокуса для соответствия требованиям контраста. Lightning Design System предоставляет стили фокуса в соответствии с требованиями WCAG для большинства компонентов. Настраиваемым компонентам могут понадобиться дополнительные индикаторы фокуса, чтобы соответствовать требованиям контраста 3:1 по сравнению с окружающим содержимым. Индикаторы фокуса должны быть хорошо видны, чтобы пользователи с плохим зрением могли перемещаться по клавиатуре. Никогда не удаляйте индикаторы фокуса с помощью CSS (обзор: нет) без предоставления альтернативного стиля с видимым фокусом.
  • Используйте смягчение последствий клавиатуры в модалях и наложениях. Модальные диалоги должны задерживать фокус в модале, пока он открыт, что предотвращает доступ пользователей клавиатуры к неясному фоновому содержимому. Фокус-ловушка должна быть отпущена после модального закрытия и возврата фокуса в триггерный элемент. Встроенное содержимое, включительно с iframe и сторонними виджетами, не должно постоянно сохранять фокус клавиатуры без механизма восстановления.
  • Использовать клавиши быстрого доступа без конфликтов. Lightning предоставляет стандартные клавиши быстрого доступа, которые задокументированы в справке Salesforce. Настраиваемые клавиши быстрого доступа должны быть созданы для предотвращения конфликтов со стандартными элементами управления обозревателя и командами навигации экранного диктора. В соответствии с критериями успеха WCAG сочетания клавиш с одним символом (например, нажатие одной буквы или знака препинания) не должны инициировать глобальные действия. Они должны либо ограничить активацию активным фокусом определенного компонента, либо предоставить пользователям способ выключения или повторного соотнесения клавиш быстрого доступа полностью.

Встройте проверку доступности в ожидаемые продажи CI/CD, чтобы автоматически находить структурные проблемы при каждом развертывании, а не рассматривать доступность как периодические проверки вручную.

  • Используйте sa11y для тестирования доступности веб- компонента Lightning. Библиотеки sa11y Salesforce (пакет @sa11y/jest) дополняют механизм базовой доступности для добавления соответствий toBeAccessible() для тестов единицы шута. Напишите тесты доступности, проверяющие правильное использование ARIA, связи с метками, коэффициенты контрастности и семантические разметки автоматически в рамках тестирования единицы измерения. Настройте сборки на сбой при обнаружении критических проблем доступности.
  • Используйте Lighthouse CI для Experience Cloud. Google Lighthouse проверяет доступность веб-страниц, включая сайты Experience Cloud. Интегрируйте Lighthouse CI в ожидаемые продажи развертывания для сканирования общедоступных страниц на наличие проблем доступности. Настройте пороговые значения рейтингов, чтобы требовать минимальные оценки доступности до утверждения развертывания.
  • Используйте агент доступности, доступный посредством пакета Salesforce DX MCP. В средах, совместимых с MCP, или в Agentforce Vibes он проверяет код по стандартам WCAG, публикует целевые исправления и может создать запрос на извлечение для инженера для проверки, проверки и объединения.

Предвзятость существовала в детерминистской автоматизации Salesforce задолго до появления искусственного интеллекта. Правила назначения, решения потока, правила проверки и дизайн территории кодируют человеческое мнение, которое может сохранить дискриминацию. В отличие от предвзятости на основе искусственного интеллекта, которую архитекторы тщательно изучают, предвзятость автоматизации часто проходит через неизученную, поскольку детерминистская логика кажется объективной.

  • Следуйте правилам назначения интересов и обращений. Распределение работы между группами сбыта и обслуживания. Если логика назначения использует критерии, коррелирующие с защищенными характеристиками, автоматизация создает систематическое неравенство в качестве обслуживания и доступе к возможностям.
  • Правила назначения, использующие характеристики территории, почтового индекса или организации, могут перенаправлять ценные возможности непропорционально определенным группам, перенаправляя менее ценные работы в другие области. Если границы территорий коррелируют с демографическими показателями клиентов и структурами компенсации, которые отличаются между территориями, автоматизация назначения создает экономическую дискриминацию.
  • Регулярно проверяйте результаты правил назначения. Вычислите распределения назначений между территориями и группами, которые стратифицированы по демографии клиентов. Если организации предприятия сосредоточены в определенных территориях, в то время как организации SMB распространяются в других местах, и если территории предприятия получают лучшие компенсации или ресурсы, правила назначения могут привести к несправедливым результатам, которые требуют проверки справедливости.
  • Просмотрите маршрутизацию на основе навыков мультиканала. Это может повлиять на качество обслуживания клиентов. Если логика маршрутизации подразумевает, что определенные навыки коррелируют с ценностью клиента или сложностью проблемы, клиенты могут получать разные результаты обслуживания на основе демографических прокси.

Важно отслеживать среднее время обработки, разрешающую способность при первом контакте и качество обслуживания клиентов в путях маршрутизации. Неравенство может указывать, получают ли определенные клиентские сегменты систематически менее опытных агентов или меньше вариантов маршрутизации.

  • Просмотрите автоматизации потока Salesforce. Принятие решений об утверждении, определения права на участие или предоставление доступа может зашифровать дискриминационную логику посредством безобидных бизнес-правил. Некоторые потоки создают косвенную дискриминацию, если критерии соотносятся с защищенными характеристиками.
  • Просмотрите решения потока с учетом справедливости. Для каждого потока, который принимает последующие решения, влияющие на пользователей, важно задать следующие вопросы:
  • Что происходит с пользователями, которые не подходят под типичный профиль клиента?
  • Коррелируют ли критерии принятия решений с демографическими характеристиками?
  • Обрабатываются ли исключения и краевые обращения на справедливой основе или они систематически ставят в невыгодное положение определенные группы?

Важно задокументировать логику решений потока и рекомендации по справедливости в записях решений архитектуры и подчинить потоки с высокими ставками тем же политикам проверки этики, что и системы искусственного интеллекта.

  • Просмотр правил проверки. Запрет ввода данных может исключить действительные данные пользователей, сведения которых не соответствуют предположениям системы. Правила проверки, отклоняющие законные данные, создают невидимые совокупности. Пользователи, чьи данные не соответствуют схемам проверки, не могут работать с определенными системами. О сбоях проверки часто не сообщается, поскольку пользователи отказываются от запросов, а не сообщают о технических ошибках. Ниже указаны несколько распространенных схем смещения проверки:
  • Проверки имен, требующие латинских символов, могут исключать имена с диакритикой и нелатинскими буквами.
  • Проверка номера телефона часто использует форматы «США/Запад», исключая международные номера и альтернативные методы связи.
  • Проверки адресов не распознают нестандартные адреса (например, поля PO, сельские маршруты, племенные земли и международные форматы).
  • Проверки электронной почты, требующие личных адресов эл. почты, могут привести к ухудшению положения пользователей, не имеющих личного доступа к эл. почте.
  • Тестирование правил проверки посредством разных данных. Добавьте международные адреса, незападные имена и альтернативные форматы телефонов в тестирование проверки. Если проверка отклоняет законные данные, необходимо развернуть логику проверки, чтобы избежать исключения действительных пользователей.
  • Просмотр дизайнов торговых территорий. Стратегии сегментации клиентов и дизайны территорий продаж определяют распределение ресурсов по группам клиентов. Если границы территории или критерии сегментации коррелируют с демографическими показателями, что приводит к неравномерному распределению ресурсов, такое распределение может привести к дискриминационным результатам. Проекты территорий, использующие географические границы, часто коррелируют с расовой, этнической и экономической демографией из-за схем сегрегации по месту жительства. Если компенсации, уровни укомплектования или инвестиции ресурсов отличаются на разных территориях, географическое положение может стать механизмом дискриминационного распределения ресурсов.
  • Проанализируйте демографические данные территории перед завершением проектирования. Соотнесите демографию клиентов в границах предложенной территории. При возникновении демографической концентрации оцените, является ли распределение ресурсов справедливым на всех территориях, вне зависимости от демографического состава. Если бизнес-обоснование требует разных уровней ресурсов на территориях (например, зрелость рынка, интенсивность конкуренции и потенциал роста), задокументируйте это обоснование четко и отслеживайте результаты, чтобы обеспечить получение недостаточно обслуживаемыми территориями адекватных инвестиционных возможностей для предотвращения укоренившегося неравенства.
  • Поддерживать прозрачность логики автоматизации. Бизнес-правила документа, критерии назначения и логика решений потока в записях решений Salesforce Knowledge или архитектуры. Прозрачная автоматизация позволяет проверять справедливость таким образом, чтобы предотвратить скрытую логику.
  • Регулярно проверяйте результаты. Запланируйте ежеквартальные проверки для анализа результатов автоматизации, которые могут быть стратифицированы по демографии клиентов. Помните, что различия инициируют расследования и потенциальное исправление.
  • Важно отслеживать:
  • Распределения назначений между группами и территориями
  • Уровень утверждения для потоков, принимающих решения о праве на участие
  • Доля отклоненных правил проверки по схеме данных
  • Производительность территории и распределение ресурсов
  • Просмотрите автоматизацию с высокими ставками посредством этического представления Lens. Потоки темы и правила назначения, влияющие на занятость, кредит, доступ к обслуживанию или другие последующие результаты процесса проверки этики, как и системы искусственного интеллекта. Ошибка автоматизации требует такого же уровня проверки, как и алгоритмическая.

В Salesforce справедливость на основе искусственного интеллекта фокусируется на использовании Einstein для проверки того, что прогнозы дают справедливые результаты во всех демографических группах. Einstein Discovery и настраиваемые приборы собирают данные решений прогнозируемой модели, которые включают обнаружение предвзятости. Панели мониторинга CRM Analytics отслеживают показатели справедливости. Контрольный журнал поля и мониторинг событий собирают данные решений для алгоритмической подотчетности.

Прогнозы Einstein, влияющие на последующие решения (например, оценка интересов, прогнозирование возможностей и сегментация клиентов), требуют оценок справедливости перед развертыванием, которые функционируют как обязательный эквивалентный этап (подобно проверкам безопасности).

Проанализируйте все функции прогнозируемой модели на наличие корреляции с защищенными характеристиками посредством статистических методов. Удалите или трансформируйте прокси-функции после оценки того, оправдывает ли их прогнозируемое значение включение, несмотря на прокси-эффекты.

  • Проверьте данные Salesforce CRM перед обучением. Организации Salesforce содержат десятилетия человеческих решений, основанных на архивных практиках. Если прошлые группы сбыта ставили во главу угла определенную демографию, то Einstein Lead Scoring изучает эти схемы и закрепляет их. Прежде чем обучать прогнозируемые модели архивным данным, важно проверить данные для пробелов в демографическом представлении и несоответствий измерений в сегментах клиентов.
  • Расчет показателей справедливости в демографических группах. Прежде чем развертывать прогнозируемые модели, важно рассчитать демографический паритет, равные возможности и коэффициенты неравномерного влияния в защищенных группах, где у вас есть законная основа для сбора и обработки требуемых демографических данных. Если функция «Определение рейтингов интересов Einstein» назначает высокие оценки сегменту А в 50% случаев, но только в 30% случаев сегменту Б, соотношение 60% не выполняет правило четырех пятых (80%) и требует изучения и смягчения. Цифра 80% является триггером проверки, а не легальной линией пропуска/сбоя: правило «четыре пятых» — это федеральное правило США для выбора работы, и его устранение не является безопасной гаванью — статистически значимое неравенство может требовать проверки при более высоких коэффициентах, а другие режимы оценивают отрицательное воздействие по-другому (например, закон ЕС о косвенной дискриминации включает определение того, создает ли практика «особый недостаток», без фиксированного порога). Откалибруйте пороги расследования в соответствии с юрисдикциями и сценариями использования.
  • Сбор данных решений прогнозируемой модели для обнаружения предвзятости. Чтобы обнаружить предвзятость в прогнозируемых моделях, например, «Определение рейтингов интересов» и «Определение рейтингов возможностей», собирайте данные решений посредством Einstein Discovery и настраиваемых инструментов: хранить вводные данные прогноза, выводы и версии модели в отслеживаемых полях и включить контрольный журнал поля. Проанализируйте данные в CRM Analytics, чтобы отслеживать схемы принятия решений в демографических группах в динамике, и создайте панели мониторинга, предупреждающие о выходе показателей демографического паритета или равных возможностей за пределы допустимых порогов.
  • Обнаружение прокси-функций в прогнозируемых моделях. Функции, коррелирующие с защищенными характеристиками, позволяют осуществлять косвенную дискриминацию, даже если защищенные характеристики исключены из моделей.
    • Данные Salesforce обычно содержат прокси-функции:
  • Территория или почтовый индекс (прокси-серверы для расы, этнической принадлежности и дохода)
  • Шаблоны имен организаций (прокси-серверы для размера организации и демографических показателей отрасли)
  • Время коммуникационных действий (прокси-серверы для часовых поясов, религии и обязанностей по уходу)
  • Тип устройства или обозреватель из данных действия (прокси-серверы для уровня дохода)

При обнаружении предвзятости в прогнозах Einstein необходимо применить смягчение на соответствующем этапе ожидаемых продаж (на основе первопричины и технических ограничений).

  • Сбалансируйте данные перед обучением модели. Измените баланс данных Salesforce CRM посредством перебора недопредставленных клиентских сегментов или недопредставленных сегментов перед обучением прогнозируемых моделей. Используйте Data 360 для агрегации данных в нескольких организациях, чтобы обеспечить разные наборы обучения. Создание синтетических данных может дополнить скудные сегменты, сохраняя конфиденциальность посредством методов дифференцированной конфиденциальности.
  • Удаление прокси-серверов в создании функций. При определении прокси-функций замените их альтернативными функциями, предоставляющими прогнозируемую силу без демографической корреляции. Если территория служит демографическим прокси-сервером, рассмотрите классификацию отрасли или размер компании в качестве альтернативы. Если схемы имен организаций коррелируют с демографией, используйте вместо этого фирменные атрибуты.
  • Настройка порогов во время последующей обработки. Настройте пороги решений для демографического сегмента, чтобы выровнять уровни результатов после моделей обучения. Для решений, связанных с занятостью, это прямо запрещено: В разделе VII (Закон о гражданских правах 1991 года) запрещается корректировка оценок или использование различных контрольных показателей по защищенному классу, и никакие документальные обоснования не делают эту практику законной. Если это не запрещено, документируйте поправки порога с бизнес-обоснованием дифференцированного режима, когда прогнозы информируют автоматические решения.
  • Периодически переучивайте модели посредством обновленных данных. Планируйте переобучение модели ежеквартально (или при значительных смещениях распределения данных). Повторное обучение по новым данным фиксирует возникающие схемы предвзятости и исправляет любое отклонение от исходных базовых показателей справедливости. Проверьте показатели справедливости в каждой версии модели перед развертыванием в производственной среде, чтобы убедиться, что переобучение не внесло новых ошибок.

Слой Einstein Trust собирает напоминания, ответы и сигналы Trust для генеративных функций искусственного интеллекта и Agentforce, поддерживая прозрачность и соответствие регламенту для генеративного искусственного интеллекта. В прогнозируемых моделях прозрачность и родословная решений поступают от Einstein Discovery и Model Manager, которым требуется настраиваемая аппаратура для сохранения данных аудита.

Встройте объяснимость в решения Einstein из исходной архитектуры вместо переоснащения пояснений в непрозрачные системы после развертывания.

  • Появите объяснения Einstein Discovery в точках принятия решения. Einstein Discovery предоставляет объяснения факторов прогноза, которые показывают, какие переменные наиболее повлияли на конкретные прогнозы с направленным влиянием. Компоненты Architect Lightning, отображающие данные пояснения пользователям в момент принятия решения, а не требующие навигации для разделения панелей мониторинга CRM Analytics. Когда решения влияют на пользователей, им нужна прозрачность, а не абстрактные показатели производительности модели.
  • Пояснения слоя для разных аудиторий. Предоставьте глубину объяснения, соответствующую каждой аудитории:
  • Бизнес-пользователи: "Этот интерес получил высокую оценку, потому что годовой доход превышает $1M, а рейтинг занятости находится в топ-10%."
  • Технические пользователи: Поставьте карту модели Einstein Discovery с весами функций, характеристиками данных обучения и показателями проверки.
  • Клиенты: "Эта рекомендация основана на ваших недавних покупках и клиентах с похожими предпочтениями."
  • Ревизоры: Предоставьте родословную решений из Einstein Discovery и менеджера моделей — версию модели, значения ввода и факторы, повлиявшие на прогноз, собранные посредством настраиваемой аппаратуры.
  • Должным образом донести уверенность. Отображение уверенности в прогнозе в соответствующих терминах и избежание исходных рейтингов вероятности, которые могут быть неправильно истолкованы пользователями. Вместо отображения «73% надежности» сообщите об этом посредством категорий (например, «Высокая надежность», «Модерирование надежности» и «Проверка потребностей») с объяснениями, что каждый уровень надежности означает для надежности решений, а также какие дополнительные проверки будут происходить.

Поддерживайте всеобъемлющие неизменяемые контрольные журналы, поддерживающие подотчетность, отладку и соответствие регламентам для всех решений на основе искусственного интеллекта, влияющих на пользователей.

  • Сбор прогнозируемых данных аудита с помощью соответствующих инструментов. Храните данные аудита прогнозируемой модели (вводные данные прогноза, выводы и версии модели) в отслеживаемых полях с включенным контрольным журналом поля. Политики сохранности данных архитектора в соответствии с нормативными требованиями, которые отличаются в зависимости от отрасли и юрисдикции:
    • Правила финансовых услуг устанавливают порядок хранения (например, правило FINRA 4511(b) устанавливает шестилетний срок хранения по умолчанию для записей, которые в ином случае не имеют конкретного срока хранения согласно правилам FINRA или правилу 17a-4 МОРЯ).
    • Сохранность медицинских услуг также регулируется конкретными правилами (например, ЗПИМС требует наличия документации о соответствии требованиям минимум шести лет; хранение медицинской документации устанавливается законами отдельных штатов), а не общими мандатами на бессрочное хранение.
  • Анализируйте данные решений прогнозируемой модели посредством CRM Analytics. Создайте панели мониторинга CRM Analytics на основе собираемых данных решений прогнозируемой модели (вводные данные прогноза, выводы и версии модели в отслеживаемых полях) для анализа схем решений, показателей справедливости и производительности модели в динамике. Создайте представления Lens, отображающие распределения прогнозов по уровню надежности, демографическому сегменту и типу результата. Настройте истории Einstein Discovery, определяющие аномалии, требующие дополнительного исследования.
  • Используйте контрольный журнал поля для долгосрочного хранения. Стандартный журнал поля отслеживает изменения за 18 месяцев в пользовательском интерфейсе и до 24 месяцев посредством API. Контрольный журнал поля позволяет хранить журнал поля неопределенно долго для настраиваемых объектов, хранящих данные решений на основе искусственного интеллекта. По умолчанию журнал архивируется через 18 месяцев, затем архивные данные сохраняются до их удаления. Включите «Контрольный журнал поля» для объектов, содержащих записи согласия, решения переопределения и отчеты по предвзятости, чтобы соответствовать нормативным требованиям сохранности.
  • Использовать Event Monitoring для взаимодействий Agentforce. Отслеживание событий собирает события уровня вызова для Agentforce, например, при выполнении действий и потоков. Экспортируйте данные мониторинга событий во внешний SIEM — стандартные данные файла журнала событий посредством API и поднабор событий мониторинга событий в реальном времени посредством событий платформы — для хранилища, превышающего собственное окно сохранности Salesforce. Подделка доказательств зависит от конкретного алгоритма SIEM, внедряющего разделение хранилища записи и доступа. Настройте запросы SIEM для обнаружения схем предвзятости в больших объемах взаимодействий Agentforce.
  • Проверка разговоров Agentforce со слоем Einstein Trust. Слой Einstein Trust собирает контрольный журнал напоминаний и ответов на разговоры Agentforce, сохраненный в Data 360, предоставляя запись уровня транскрипта для прозрачности и соответствия регламенту.

Рассмотрим возможности прозрачности «Архитектор», расположенные на соответствие текущим и формирующимся регламентам на основе искусственного интеллекта в нескольких юрисдикциях.

  • Требования к прозрачности Закона ЕС об искусственном интеллекте. Системы искусственного интеллекта высокого риска, предусмотренные Законом ЕС об искусственном интеллекте, требуют наличия документации о прозрачности, технической документации, возможностей надзора со стороны человека и показателей точности/справедливости. Контрольные журналы Einstein Trust Layer и карты модели Einstein Discovery служат основой для этих требований. Демографические данные обучения модели документа, методы проверки и известные ограничения в записях решений архитектуры.
  • Право ГДР на объяснение. GDPR предоставляет субъектам данных ЕС право на получение значимой информации о логике принятия решения, если это решение основано исключительно на автоматизированной обработке и имеет юридические или аналогичные последствия. Это право вытекает из статей 15(1) h) и 22(3) в сочетании с пунктом 71 и было разъяснено ЦЕС в деле Дан энд Брэдстрит (2025). Разработайте системы, которые создают согласованные объяснения по запросу любого архивного решения в пределах временных промежутков запроса доступа к субъекту данных, которые варьируются (в зависимости от юрисдикции) от 15 до 45 дней. Собранные данные решений прогнозируемой модели — вводные данные прогноза, выходные данные, версии модели и коэффициенты объяснения Einstein Discovery — позволяют восстанавливать объяснения при их достаточном сохранении.
  • Законы об алгоритмической подотчетности. Законы об алгоритмической подотчетности на уровне штатов США все чаще требуют оценок воздействия и отчетности по прозрачности для автоматических систем принятия решений. Собранные данные решений прогнозируемой модели и панели мониторинга CRM Analytics для мониторинга справедливости предоставляют основы данных для этих отчетов. Выполните алгоритмические оценки влияния перед развертыванием последующего искусственного интеллекта в качестве активного соответствия, а не в качестве реактивного ответа на запросы регулирующих органов.

Схемы доступа к данным, определяющие сведения, которые пользователи могут просматривать и использовать для принятия решений, определяются OWD, правилами общего доступа и параметрами безопасности поля (FLS). Правильная конфигурация предотвращает дискриминационный доступ к конфиденциальным атрибутам, обеспечивая при этом справедливое обслуживание.

Создайте OWD и безопасность поля, чтобы ограничить доступ по умолчанию. В правилах общего доступа используйте принцип наименьших привилегий (PoLP) для предоставления только дополнительного доступа, законно необходимого каждой роли, что предотвращает принятие дискриминационных решений на основе защищенных характеристик.

  • Включить строгий OWD по умолчанию. Используйте Private OWD для объектов, содержащих конфиденциальные данные клиентов, и предоставьте доступ по иерархии ролей и правилам общего доступа. Общедоступные OWD для чтения и записи делают ограничение доступа позже дезорганизующим — ужесточение стандартного параметра инициирует пересчет общего доступа и вступает в силу только после завершения — а не невозможным. Частные ОВД с четкими грантами на общий доступ создают проверяемые схемы доступа, поддерживающие соблюдение недискриминации.
  • Применить безопасность поля к конфиденциальным атрибутам. Скрыть конфиденциальные поля, содержащие защищенные характеристики (например, этническая принадлежность, религия и статус нетрудоспособности) от пользователей, которым не нужен доступ для законных бизнес-целей. Настройте FLS, чтобы удалить доступ для чтения конфиденциальных полей в большинстве профилей. Если эти поля обязательны для определенных целей (например, составление отчетов по разнообразию и разумное приспособление), предоставьте минимальный доступ посредством наборов полномочий с документированным бизнес-обоснованием.
  • Разработайте правила назначения и общего доступа для справедливых результатов. Используйте правила назначения, очереди и маршрутизацию мультиканала для распределения работы поровну между территориями, группами и агентами службы поддержки. Избегайте ручного общего доступа, концентрирующего ценные возможности или клиентов с определенными группами пользователей без документированного бизнес-обоснования. Настройте автоматические правила общего доступа на основе объективных критериев (например, отрасль, география и линейка продуктов), а не на основе субъективного усмотрения менеджера, что может включить предвзятость.
  • Предоставьте наборы полномочий для временного доступа. Предоставьте временный доступ к конфиденциальным данным посредством наборов полномочий, а не путем изменения профилей, что влияет на всех пользователей на постоянной основе. Когда пользователям нужен доступ к демографическим данным для определенных проектов (например, анализ разнообразия и запросы размещения), назначьте наборы полномочий с документированным истечением срока действия. Запланированные потоки могут автоматически отзывать наборы полномочий после определенных периодов.

Используйте мониторинг событий Shield и отчеты для обнаружения схем доступа к данным, указывающих на возможную дискриминацию или предвзятость в использовании данных.

  • Используйте мониторинг событий Shield для проверки доступа к конфиденциальным данным. Используйте мониторинг событий для сбора событий доступа на уровне объекта (экспорты отчетов, запросы API и просмотры страниц) в объектах, содержащих защищенные характеристики или конфиденциальные атрибуты. Настройте запросы по этим событиям для отображения, кто, когда и в каком контексте имел доступ к объекту, и обрабатывайте аномалии (например, резкие всплески и доступ непредвиденных пользователей) как триггеры для исследования.
  • Отчет по распространениям правил общего доступа. Создайте отчеты, анализирующие распределение записей между пользователями, рабочими группами и территориями. Рассчитывайте статистику распространения по демографии клиентов, чтобы обеспечить справедливое распределение дорогостоящих организаций и возможностей. Определите концентрации, где определенные группы пользователей получают несоразмерный доступ к ценным записям без документированного бизнес-обоснования.
  • Проверка нарушений CRUD и FLS. Просмотрите контрольный журнал настройки на наличие изменений в параметрах OWD, правилах общего доступа, конфигурациях FLS и наборах полномочий. Несанкционированные изменения в элементах управления доступом к данным могут свидетельствовать о попытках неправомерного доступа к конфиденциальным данным. Используйте политики безопасности транзакций для действий в отношении событий мониторинга событий высокого риска в реальном времени (например, аномальное действие API, подозрительные входы и экспорты больших отчетов или списковых представлений конфиденциальных данных). Поскольку безопасность транзакций работает только с этими событиями среды выполнения, а не с изменениями уровня записи DML или FLS, необходимо использовать контрольный журнал настройки и задокументированные утверждения управления изменениями для FLS и изменений общего доступа.

В Salesforce пользовательское агентство означает, что клиенты и сотрудники сохраняют значимый контроль над влиянием искусственного интеллекта на взаимодействие. Возможности управления согласием Salesforce, согласие Data 360 и настраиваемые объекты согласия включают детализацию управления взаимодействиями на основе искусственного интеллекта.

Создайте отслеживание согласия посредством управления согласием Data 360, согласия Marketing Cloud или настраиваемых объектов согласия, использующих контрольный журнал поля для требований согласия на основе искусственного интеллекта.

  • Включить детализацию согласия на сценарий использования искусственного интеллекта. Включите согласие на сценарий использования искусственного интеллекта вместо использования общего согласия на искусственный интеллект. Клиенты могут согласиться с рекомендациями продуктов Einstein, но отклонить кредитные решения на основе искусственного интеллекта. Включите контрольный журнал поля в объектах согласия для долгосрочного хранения и соответствия нормативным требованиям. Создайте настраиваемые объекты согласия с полями, отслеживающими:
  • Цель согласия (например, определение рейтингов интересов Einstein, рекомендации ответов Einstein и конструктор рекомендаций Einstein)
  • Дата предоставления согласия и метод предоставления (например, веб-форма, API, телефон и электронная почта)
  • Дата отзыва согласия (если применимо)
  • Код связанного пользователя или контакта
  • Используйте согласие Data 360 для персонализации. Используйте управление согласием Data 360 для функций персонализации Einstein. Data 360 принимает и сохраняет параметры согласия из систем в верхнем звене посредством коннекторов, соотнесенных с моделью данных конфиденциальности, что позволяет использовать эти атрибуты согласия в качестве критериев фильтрации при сегментации и активации. Соотнесите атрибуты согласия с определенными сценариями использования искусственного интеллекта, чтобы позволить пользователям отказаться от персонализации, сохранив базовые службы
  • Включите интеграцию согласия Marketing Cloud. Интегрируйте согласие Marketing Cloud с важными данными службы сообщений Einstein и маркетинговыми функциями на основе искусственного интеллекта. Соблюдайте статус подписки Marketing Cloud и согласие во всех коммуникациях на основе искусственного интеллекта.

Предоставьте значимые отказы от функций, управляемых искусственным интеллектом, с доступными элементами управления, учитывающими предпочтения пользователей посредством человеческих альтернатив сопоставимого качества.

  • Предоставьте доступные отказы в параметрах профиля. Разрешите пользователям отказаться от взаимодействий на основе искусственного интеллекта посредством доступных элементов управления параметрами в параметрах профиля Experience Cloud или «Мои параметры» во внутренних приложениях. Предоставьте четкое описание значения каждого отказа и альтернативного взаимодействия, которое получат пользователи после отказа. Сохраните настройки в записях пользователя или контакта.
  • Предоставьте постоянные параметры предпочтений в каналах. Сохраните параметры искусственного интеллекта в записях пользователя или контакта, чтобы обеспечить согласованность в каналах (например, веб, мобильный, телефон и электронная почта). Запросите параметры последовательно во всех потоках взаимодействия, чтобы предотвратить необходимость повторного утверждения параметров в разных каналах.

Этическое управление на основе искусственного интеллекта предоставляет организационные структуры, которые помогают обеспечить сохранение справедливости по мере развития моделей, смен данных и расширения способов использования. Без управления первоначальные усилия по обеспечению справедливости ухудшаются по мере переключения внимания организации.

Установите обязательную документацию и просмотрите контрольные точки перед развертыванием Einstein. Считайте, что это ворота, которые так же важны, как и проверки безопасности.

  • Предоставить документацию модели. Храните документацию модели в Salesforce посредством настраиваемого объекта «Модель» или Salesforce Files, вложенных в проекты для включения функции поиска и управления версиями. Задокументируйте каждую производственную прогнозируемую модель посредством:
  • Демография данных обучения и известные пробелы в представлении (для обученных клиентов прогнозируемых моделей, например, Einstein Discovery и конструктора прогнозов)
  • Показатели справедливости перед развертыванием, вычисляемые по демографической группе
  • Предполагаемые сценарии использования и известные случаи ненадлежащего использования
  • Стратегии уменьшения предвзятости, применяемые в ходе разработки
  • Подход к мониторингу справедливости и пороговые значения предупреждений
  • Требования к надзору за людьми и бизнес-правила утверждения
  • Проверка расписаний и ответственных лиц
  • Рекомендации по регулированию и позиционирование соответствия
  • Включить ворота справедливости перед развертыванием. Модели, не прошедшие тестирование ворот, не должны переходить в производство. Относитесь к воротам справедливости с той же строгостью, что и к воротам безопасности. Другими словами, они обладают полномочиями блокировки развертываний. Перед развертыванием прогнозов Einstein в производстве необходимо:
  • Просмотрите проверки данных обучения. Все пробелы в представлении должны быть проанализированы и задокументированы.
  • Просмотр показателей справедливости (например, демографический паритет, равные возможности и неравномерное влияние должны быть рассчитаны и подтверждены для достижения пороговых значений).
  • Просмотр оценок влияния. Оцените потенциальный вред для затронутых групп населения.
  • Создание под надзором человека. Все схемы расширения, бизнес-правила утверждения и механизмы переопределения должны быть разработаны и протестированы надлежащим образом.
  • Завершите проверку прозрачности. Возможности объяснения должны быть проверены для всех типов решений.
  • Заполнить документацию. Все обязательные артефакты документации модели должны быть утверждены.

Создайте процессы проверки для заявок на основе искусственного интеллекта с высокой долей участия, которые обеспечивают межфункциональный надзор и имеют полномочия на применение.

  • Просмотр состава комиссии. Привлекайте технических экспертов (например, архитекторов и специалистов по обработке данных), заинтересованных лиц (например, ответственных за продукты и операционный персонал), юристов, специалистов по конфиденциальности и представителей затрагиваемых сообществ (при возможности). Помните, что разные точки зрения приводят к проблемам справедливости, которые часто пропускаются однородными группами.
  • Просмотрите все триггеры, требующие утверждения советом по этике. Определите, какие сценарии использования искусственного интеллекта требуют проверки этики перед развертыванием:
  • Решения, касающиеся занятости, кредитов, жилья, здравоохранения или юридических прав
  • Автоматические системы, влияющие на более 10 000 пользователей или транзакций в год
  • Приложения на основе искусственного интеллекта, использующие конфиденциальные личные данные, включая медицинские, финансовые или демографические данные
  • Новые сценарии использования, не имеющие установленного организационного прецедента
  • Системы, в которых потенциальная предвзятость может причинить значительный ущерб отдельным лицам или группам
  • Просмотрите и определите, кто имеет полномочия блокировать развертывания. Комиссии по проверке этики должны иметь полномочия требовать изменений, устанавливать условия мониторинга или блокировать развертывания, не соответствующие этическим стандартам. Проверки, проводимые только на основе консультаций (без правоприменительных полномочий), могут ограничить эффективность процесса управления. Задокументируйте все проверки в настраиваемых объектах Salesforce, отслеживающих: имя заявки, дата рассмотрения, поднятые проблемы, требования к смягчению и условия утверждения.

Мониторинг справедливости - это непрерывный процесс, требующий постоянного внимания для обнаружения отклонения по мере смещения распределения данных и изменения заполняемости пользователей.

  • Создание панелей мониторинга справедливости CRM Analytics. Создайте панели мониторинга, отслеживающие показатели справедливости, используя данные решений прогнозируемой модели, которые вы собираете. Отслеживайте демографический паритет, равные возможности, коэффициенты неравномерного влияния и показатели качества прогноза по сегментам клиентов. Настройте предупреждения CRM Analytics, которые запускаются, когда показатели справедливости нарушают определенные пороги и требуют исследования.
  • Включить настраиваемый мониторинг для сигналов справедливости. Создайте настраиваемый мониторинг справедливости для обнаружения сигналов (например, внезапные изменения в распределении решений по демографическим группам, всплески связанных с предвзятостью записей обращений или ухудшение производительности модели для определенных групп населения).
  • Запланируйте проверки справедливости. Выполняйте комплексные ежеквартальные проверки справедливости для систем искусственного интеллекта с высокими ставками (например, кредиты, занятость и здравоохранение) и полугодовые проверки для систем с низкими ставками (например, рекомендации и персонализация). Аудиты должны изучить текущие показатели справедливости, проанализировать схемы переопределения в журнале утверждений, проанализировать отзывы пользователей и отчеты о предвзятости и убедиться, что механизмы управления остаются эффективными.
  • Внедрите реакцию на инциденты для ошибок справедливости. Установите четкие процессы, которые документируются в Salesforce Knowledge, подробно описывая, как реагировать при обнаружении предвзятости:
  • Немедленно: Оцените серьезность и масштаб, запросив данные решения прогнозируемой модели в CRM Analytics. Если инцидент серьезный, приостановите все автоматическое принятие решений до завершения расследования.
  • Краткосрочно: Внедрите временные стратегии смягчения последствий (например, усиление надзора человека посредством скорректированных порогов надежности, отключения функций или полной приостановки агента).
  • Расследование: Выполните анализ первопричины (RCA), чтобы определить, как предвзятость вошла в систему или эволюционировала. Во время RCA анализируйте данные обучения, версии модели и изменения конфигурации посредством контрольного журнала поля.
  • Исправление: Внедрите необратимое исправление посредством исправления данных, переобучения модели или изменений процесса.
  • Связь: Уведомление соответствующих пользователей посредством обращений, электронной почты или объявлений Experience Cloud.
  • Профилактика: Обработайте изменения для предотвращения повторения и задокументируйте методы предотвращения в запусках.

Используйте этот контрольный список во время проверок архитектуры, перед развертыванием производственной среды и периодически для текущей оценки.

Качество данных и репрезентативная справедливость

  • Сделайте поля необязательными, где процесс может функционировать без данных, и создайте последующие процессы для обработки отсутствующих значений, чтобы не исключить пользователей, которые не могут предоставить информацию (электронная почта, SSN, адрес улицы).
  • Поля «Имя архитектора» представляют собой единое поле полного имени или гибкую многокомпонентную структуру, принимающую мононимы, нелатинскую письменность, диакритику и длинные имена, а не западный порядок отображения имени и фамилии.
  • Внедрите проверку адреса, принимающую форматы свободного формата и международные форматы, сохраняя адреса как введенные, а не блокируя создание записи из-за несоответствия формата.
  • Сохраняйте параметры канала связи в записях контактов и поддерживайте альтернативы мультиканала (электронная почта, SMS-сообщения, телефон, почтовая связь, чат, голосовой режим), а не предполагайте охват всех пользователей одним каналом.
  • Собирайте демографические данные посредством добровольной самоидентификации с параметром «Предпочтение не отвечать», хранимые отдельно в разделе Private OWD с FLS, агрегированные для составления отчетов и отслеживаемые посредством мониторинга событий Shield.
  • Проверьте сторонних поставщиков обогащения на наличие проверки справедливости, демографического покрытия и методологии вывода, прежде чем добавлять демографические или поведенческие данные к записям.

Доступность и инклюзивный дизайн

  • Используйте компоненты Lightning Design System, предназначенные для поддержки доступности WCAG 2.2 AA. Помните, что Salesforce стремится к соответствию, но компоненты требуют правильного использования.
  • Проверьте настраиваемые веб-компоненты Lightning посредством тестирования программы для чтения экрана (например, JAWS, NVDA и VoiceOver).
  • Убедитесь в наличии полной навигации по клавиатуре на страницах Lightning и сайтах Experience Cloud без зависимости от мыши.
  • Проверьте соответствие коэффициентов контрастности 4,5:1 для обычного текста посредством инструментов разработки обозревателя или средств проверки контрастности.
  • Интегрируйте сканирование доступности sa11y или Lighthouse в ожидаемые продажи CI/CD, которые не выполняются, исходя из критических проблем.
  • Протестируйте сайты Experience Cloud с помощью вспомогательных технологий перед общедоступным запуском.
  • Проверьте слуховую обратную связь, подтвердив, что все динамические изменения (например, состояния ошибок, загрузка спиннеров или развертывание меню) четко объявлены, а произнесенное содержимое соответствует визуальному намерению пользовательского интерфейса.

Справедливость в автоматизации Salesforce

  • Просмотрите правила назначения и маршрутизации на наличие корреляции с защищенными характеристиками, которые могут сконцентрировать благоприятные или неблагоприятные результаты в определенных демографических группах.
  • Аудит потока и логики решений автоматизации процесса на наличие предвзятости, документирование бизнес-правил и критериев в записях решений Salesforce Knowledge или архитектуры.
  • Оцените правила проверки для уровней отклонения, которые непропорционально влияют на определенные схемы данных или совокупности.
  • Анализ структур территорий и сегментации на наличие демографической корреляции, документирование четкого бизнес-обоснования и мониторинг недостаточно обслуживаемых территорий на предмет справедливого распределения ресурсов.
  • Подчините потоки с высокими ставками и правила назначения (занятость, кредит, доступ к обслуживанию) тому же процессу проверки этики, что и системы искусственного интеллекта, и запланируйте ежеквартальные проверки результатов автоматизации, стратифицированных по демографии.

Обнаружение справедливости и предвзятости на основе искусственного интеллекта

  • Проверьте данные Salesforce CRM на наличие пробелов в демографическом представлении до обучения прогнозируемой модели.
  • Рассчитайте демографический паритет, равные возможности и коэффициенты неравномерного влияния на демографическую группу перед развертыванием.
  • Внедрите оценки справедливости в качестве обязательных ворот развертывания (думайте, что это эквивалентно проверке безопасности).
  • Создайте панели мониторинга CRM Analytics, отслеживающие показатели справедливости посредством данных решений прогнозируемой модели, собранных посредством контрольного журнала поля.
  • Проанализируйте функции прогнозируемой модели на наличие прокси-корреляции с защищенными характеристиками (например, схемы имен территорий и организаций).
  • Запланируйте комплексные ежеквартальные проверки справедливости для всех систем искусственного интеллекта с высокими ставками.

Транспарентность и проверяемость

  • Появите объяснения прогноза Einstein Discovery в точках принятия решений в компонентах Lightning.
  • Настройте сборы аудита слоя Einstein Trust посредством методов сохранности, соответствующих нормативным требованиям.
  • Включите контрольный журнал поля для всех настраиваемых объектов, хранящих данные решений на основе искусственного интеллекта для их долгосрочного хранения.
  • Экспортируйте данные Event Monitoring во внешний SIEM — данные файла журнала событий посредством API и события мониторинга событий в реальном времени посредством событий платформы — для хранения, превышающего собственное сохранение, с помощью управления записью на стороне SIEM для подделки доказательств.
  • Предоставьте соответствующую пользователю надежную связь (например, высокая, средняя и низкая), а не исходные вероятности.

Надзор человека с помощью автоматизации Salesforce

  • Настройте пороги расширения на основе надежности в потоке и перенаправьте прогнозы с низкой надежностью на проверку человеком.
  • Используйте процессы утверждения Salesforce для принятия важных решений, требующих многоэтапных цепочек проверки.
  • Интегрируйте маршрутизацию Agentforce и мультиканала, чтобы включить беспрепятственное распространение на агентов-людей.
  • Предоставьте постоянный параметр «Подключиться к агенту-человеку» в интерфейсах Agentforce для уважения агента пользователя.
  • Требуйте документированного обоснования и отслеживания журнала утверждений для переопределений Agentforce, собранных в настраиваемых полях.

Недискриминация с помощью элементов управления доступом к данным

  • Включите Private OWD, а потом предоставьте дополнительный доступ посредством иерархии ролей и правил общего доступа.
  • Настройте параметры безопасности поля, чтобы скрыть конфиденциальные демографические поля от пользователей, которым не нужен доступ.
  • Отслеживайте события доступа объекта (экспорты отчетов и запросы API) на наличие конфиденциальных данных посредством мониторинга событий Shield и анализируйте их на наличие аномальных схем доступа.
  • Создайте отчеты, анализирующие распределения правил общего доступа для обеспечения справедливого распределения записей между территориями.
  • Просмотрите контрольный журнал настройки на наличие несанкционированных изменений конфигурации OWD, правила общего доступа или FLS.

Агентство пользователя и согласие

  • Создайте настраиваемые объекты согласия посредством контрольного журнала поля для отслеживания детального согласия на использование на основе искусственного интеллекта.
  • Интегрируйте согласие Data 360 или Marketing Cloud с персонализацией Einstein и функциями Agentforce.
  • Сохраните параметры искусственного интеллекта в записях пользователя или контакта, чтобы обеспечить согласованность в каналах (например, веб, мобильный и телефон).
  • Предоставьте доступные отказы в параметрах профиля и человеческих альтернативах посредством маршрутизации мультиканала.
  • Запрос записей согласия в потоке до того, как прогнозы Einstein или занятость Agentforce повлияют на пользователей.

Этическое управление на основе искусственного интеллекта

  • Задокументируйте все производственные прогнозируемые модели, включительно с показателями справедливости и стратегиями смягчения; для обученных клиентов прогнозируемых моделей (например, Einstein Discovery и конструктор прогнозов) также задокументируйте демографию обучения-данных.
  • Установите обязательные ворота справедливости перед развертыванием, блокирующие развертывание до выполнения всех критериев справедливости.
  • Создайте Совет по проверке этики искусственного интеллекта в качестве органа по обеспечению применения всех важных приложений на основе искусственного интеллекта.
  • Создайте панели мониторинга CRM Analytics для мониторинга показателей справедливости в запланированной каденции посредством предупреждений CRM Analytics.
  • Определите процедуры реагирования на инциденты для ошибок справедливости и задокументируйте процесс в Salesforce Knowledge.
  • Запланируйте ежеквартальные проверки справедливости, которые анализируют схемы переопределения и отзывы пользователей для всех систем с высокими ставками.

Опубликуйте отзыв о инфраструктуре с хорошей архитектурой.