Перейти к книге

NOMOS 13

Человек должен иметь возможность оспорить обоснование

Скачать бесплатный PDF

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

Это крупнейший единичный экспортный заказ за всю историю компании. Чтобы выполнить его, необходимо заранее оплатить сырьё, стерилизацию, дополнительную смену и международную перевозку. Клиент заплатит через сорок пять дней после поставки. Седа обращается в свой банк за кредитом на пополнение оборотного капитала сроком на четыре месяца. Банк оценивает заявки с помощью системы на базе ИИ — Агента принятия решений по коммерческим кредитам. Система совместно анализирует операции по банковским счетам, электронные счета-фактуры, реестр компаний, показатели из налоговых и государственных реестров, отраслевые данные, существующие долги и концентрацию клиентов.

На экране заявки указано: «Ваша заявка может быть быстро рассмотрена с помощью углублённой аналитики данных и систем оценки риска на базе ИИ». Седа загружает договор по заказу, финансовую отчётность за последние два года, экспортные документы и отчёт о производственной мощности. Она разрешает доступ к банковским операциям и электронным счетам-фактурам. Система оценивает заявку менее чем за минуту. На экране появляется результат: ВАША ЗАЯВКА НА КРЕДИТ НЕ ОДОБРЕНА Ниже — одна фраза: «Текущий денежный поток и показатели риска вашего предприятия признаны недостаточными для запрашиваемой структуры кредита».

Седа нажимает кнопку «Подробнее о решении». На новом экране показаны три пункта:

  • Стабильность денежного потока
  • Отраслевой риск
  • Существующие обязательства

Эти формулировки не выглядят связанными именно с заявкой Седы. Это общие заголовки, подходящие любому предприятию. Седа звонит в службу поддержки банка. Реальный сотрудник проверяет номер заявки и говорит: «Система рассчитала ваш балл кредитоспособности ниже порога автоматической предварительной оценки нашего банка». Седа спрашивает: «Какой у меня балл?» Сотрудник отвечает: «На моём экране 0,63. Порог автоматической предварительной оценки — 0,65». «Что снизило балл?» — спрашивает Седа. Сотрудник зачитывает те же три формулировки: «Стабильность денежного потока, отраслевой риск и существующие обязательства».

«Какая именно часть моего денежного потока?» — спрашивает Седа. Сотрудник этого не видит. «Система не показывает подробный расчёт модели». Седа спрашивает: «Какое именно обязательство?» Сотрудник не может ответить. «Эти сведения входят в нашу модель риска. Мы используем коммерчески охраняемые методы оценки». Седа не просит раскрыть всю формулу. Ей не нужен и программный код банковской модели. Она хочет получить ответ лишь на один вопрос:

«Почему отклонили именно мою заявку?»

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

invoice_revenue: 0

хотя реальная запись должна была выглядеть так:

invoice_revenue: data_missing

Система смешала состояния «данных нет» и «дохода нет». Вторая проблема — крупный платёж за оборудование, совершённый компанией три месяца назад. Для производства стерильной упаковки Седа купила новую систему резки. Это разовая инвестиция. Но модель риска классифицировала платёж как:

recurring_monthly_expense

Из-за этого прогноз будущего денежного потока был снижен так, будто компания будет ежемесячно вносить ещё один платёж за оборудование того же размера. Третья проблема серьёзнее. Компания внесла таможенному органу обеспечение за импортируемое сырьё. Эти деньги — не штраф, не налоговая задолженность и не просроченное обязательство перед государством. Это временное обеспечение конкретной импортной операции. Внешний поставщик данных передал запись банку в виде:

unresolved_public_obligation: true

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

Правило вето.

Реальная цепочка принятия решения такова:

  1. Показатель обязательства перед государством: ЕСТЬ
  2. ↓
  3. Шлюз политики: ОТКАЗ
  4. ↓
  5. Результат заявки: АВТОМАТИЧЕСКИЙ ОТКАЗ

Балл денежного потока выглядит низким. Но не он стал главной причиной окончательного отклонения заявки. Главная причина —

запись вето о неверно классифицированном обязательстве перед государством.

Несмотря на это, Седе показали обоснование: «Стабильность денежного потока и отраслевой риск». Почему? Потому что банковская система принятия решений — не единая структура.

  1. Она состоит из следующих компонентов: АГЕНТ СБОРА ДАННЫХ
  2. ↓
  3. АГЕНТ БУХГАЛТЕРСКОЙ КЛАССИФИКАЦИИ
  4. ↓
  5. ПРОВЕРКА ВНЕШНИХ ОБЯЗАТЕЛЬСТВ
  6. ↓
  7. МОДЕЛЬ ОЦЕНКИ КРЕДИТОСПОСОБНОСТИ
  8. ↓
  9. МЕХАНИЗМ ПОЛИТИКИ И ВЕТО
  10. ↓
  11. АГЕНТ ФОРМИРОВАНИЯ ОБЪЯСНЕНИЙ
  12. ↓
  13. УВЕДОМЛЕНИЕ КЛИЕНТА

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

Седа загружает официальный документ, подтверждающий природу таможенного обеспечения. Повторно отправляет отсутствующие электронные счета-фактуры. Объясняет, что покупка оборудования была разовой инвестицией. В портале выбирает «Оспорить решение». Через две минуты приходит новый ответ: «Ваша заявка рассмотрена повторно; достаточных оснований для изменения действующего решения не найдено». Седа думает, что проверку провёл человек. Она снова звонит в службу поддержки. Сотрудник сообщает, что возражение повторно оценивала та же автоматическая система. Новые документы были загружены в хранилище данных.

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

Седа связывается с менеджером по работе с корпоративными клиентами в отделении банка. Менеджер пытается направить заявку на проверку человеком. Но заявки с автоматическим вето не поступают в обычную очередь проверки. Менеджер видит лишь следующий код:

POLICY_DECLINE-17

Описание кода: «Внешнее обязательство и общая платёжеспособность». Менеджер говорит: «Система не позволяет». Седа отвечает:

«Если система не позволяет, кто проверит, на каком ошибочном факте она основывается?»

В конце концов заявку передают в специальное проверочное подразделение банка. Специалист-человек восстанавливает цепочку принятия решения и подтверждает следующее:

  • Таможенное обеспечение не является задолженностью перед государством.
  • Счета-фактуры за восемнадцать дней отсутствуют из-за сбоя соединения.
  • Платёж за оборудование не является регулярным расходом.
  • Реальная сфера деятельности компании — специализированная область с меньшим риском, чем предполагает устаревшая категория в реестре.
  • Автоматический отказ возник из-за ошибочной записи вето.
  • Первоначальное объяснение клиенту не показывало реальную определяющую причину.
  • Первое возражение было рассмотрено той же системой на основании того же кеша.

После исправления данных балл рассчитывается заново: Первоначальный видимый балл кредитоспособности: 0,63 Балл кредитоспособности после исправления данных: 0,78 Порог автоматической предварительной оценки: 0,65 Запись вето: СНЯТА В этом вымышленном примере более высокий балл означает более высокую кредитоспособность; он не является вероятностью дефолта. Порог 0,65 предназначен для прохождения автоматической предварительной оценки. Заявка без вето, не достигшая порога, направляется на оценку человеком; ошибочное вето о задолженности перед государством привело к прямому отказу. Ни один балл сам по себе не означает окончательного одобрения кредита.

Этот результат не означает, что кредит обязательно должен быть выдан. Банк по-прежнему может передать на оценку человеком такие обстоятельства, как обеспечение, срок, договор и отраслевая концентрация. Но заявка больше не заблокирована шлюзом автоматического отказа. Кредитный комитет из людей изучает дело и решает, что финансирование можно предоставить в меньшем объёме и при дополнительном обеспечении. Однако процесс занял тринадцать дней. Клиент Седы не смог ждать начала производства и передал часть заказа другому поставщику.

Кредитное решение исправлено. Но утраченный заказ вернулся не полностью. Банк направляет Седе следующее объяснение: «Из-за несоответствия данных при первоначальной оценке вашей заявки произошла ошибка. Записи исправлены, заявка рассмотрена повторно». На этот раз Седа требует более ясного ответа: «Какие именно данные?» «Какое правило определило решение?» «Почему в качестве причины указали денежный поток?» «Почему моё возражение снова отклонила та же система?» «Каким было бы первое решение при верных данных?» «Могла ли эта ошибка затронуть другие компании?»

«Кто отвечает за заказ, который я потеряла?» Банк снова сообщает, что модель является коммерческой тайной. Седа отвечает:

«Я не прошу раскрыть вашу формулу».
«Я хочу знать, какой ошибочный факт повлёк последствия в моей жизни».

Поэтому наше одиннадцатое учредительное положение таково:

Человек должен иметь возможность оспорить обоснование.

УЧРЕДИТЕЛЬНАЯ СТАТЬЯ

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

Обоснование должно правдиво отражать реальный процесс формирования решения. Если решение принято по одной причине, человеку нельзя показывать другую — более приемлемую, удобную или защищаемую. Необходимо различать факт, исходные данные, правило политики, вывод модели, вероятность, оценку человека и окончательное решение. Прогноз нельзя выдавать за подтверждённый факт, корреляцию — за причину, балл — за качество человека, а общую категорию риска — за обоснование индивидуального решения. Человек должен видеть, какие существенные исходные данные ошибочны, устарели, отсутствуют, относятся к другому лицу или вырваны из контекста; понимать, как исправление записи может изменить решение, и знать порядок повторной оценки.

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

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

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

Что такое обоснование?

Фраза системы «Ваша заявка отклонена» сообщает результат. Фраза «Ваш балл кредитоспособности оказался низким» сообщает классификацию. Фраза «Из-за денежного потока» даёт общий заголовок причины. Ни одна из них сама по себе может не быть достоверным и достаточным обоснованием. Каноническое определение таково: обоснование решения — это проверяемая связь, показывающая, на основании каких проверяемых данных, источников, правил, порогов, выводов, шлюзов вето, оценок человека и неопределённостей возник существенный результат для конкретного человека или организации; какие элементы действительно стали определяющими; а также какое исправление или изменение позволит повторно оценить решение.

Проще говоря:

Обоснование — не фраза «Таков результат», а честный ответ на вопрос «Что в действительности привело к этому результату?»

Результат — не обоснование

Следующие фразы сообщают результат: «В кредите отказано». «Кандидат не вошёл в короткий список». «Помощь по уходу на дому не одобрена». «Ваша учётная запись ограничена из-за риска». Человек узнаёт решение, но не его причину.

Балл — не обоснование

Балл кредитоспособности 0,63 может быть числовым параметром решения. Но остаются открытыми следующие вопросы:

  • Из каких данных сформирован балл?
  • Какой период времени использован?
  • Как оценивались отсутствующие данные?
  • Определил ли решение один только балл?
  • Существовало ли отдельное правило вето?
  • Почему порог равен 0,65?
  • Какова неопределённость балла?
  • Какие поля человек может исправить?

Одно число — не обоснование, которое человек способен содержательно оспорить.

Код причины — не обоснование

POLICY_DECLINE-17

Такой код может быть полезен во внутреннем рабочем процессе организации, но не имеет смысла для человека. Даже подпись «Внешнее обязательство и общая платёжеспособность» рядом с кодом может оставаться слишком общей. Реальное индивидуальное обоснование могло бы звучать так: «Внешний поставщик данных классифицировал запись о вашем таможенном обеспечении как непогашенную задолженность перед государством, и это поле активировало автоматическое вето для вашей заявки». Эта фраза показывает человеку, что именно следует проверить.

Общая категория — не индивидуальное обоснование

Во многих системах могут использоваться следующие заголовки:

  • Безопасность
  • Риск
  • Соответствие
  • Качество обслуживания
  • Политика
  • Подозрительная активность
  • Потребность бизнеса
  • Текущие условия

Сами по себе эти заголовки не объясняют конкретное решение в отношении человека. Фраза «Ваша учётная запись закрыта по соображениям безопасности» не отвечает на следующие вопросы:

  • Какое поведение?
  • Какая дата?
  • Из какого источника?
  • Подтверждённое событие или прогноз модели?
  • Временно или навсегда?
  • Что человек может исправить?
  • Как подать возражение?

Объяснение — не обоснование

После принятия решения система может создать убедительный абзац: «В рамках политики ответственного кредитования наш банк комплексно оценивает устойчивую платёжеспособность предприятий, отраслевые условия и существующие обязательства». Этот текст описывает общий подход банка. Он не объясняет, почему отказали Седе. Объяснение может быть правдивым, гладким и профессиональным — и всё же не являться обоснованием решения.

Обоснование — не оправдание

Цель организации не должна состоять в том, чтобы любое решение выглядело оправданным. Иногда обоснование может показать: «Решение опиралось на ошибочные данные». «Система истолковала неопределённость как большую уверенность, чем следовало». «Необходимая для этого решения проверка человеком не проводилась». «Применённое правило не соответствовало действующей политике». Если обоснование способно лишь защищать организацию, оно не является инструментом подотчётности.

Это текст для защиты репутации.

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

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

Существенные факты и правила, определившие решение.

Например: «Ваша заявка автоматически отклонена из-за показателя непогашенной задолженности перед государством. Этот показатель поступил из такого-то внешнего источника такого-то числа. Ваш балл денежного потока также был низким, но сам по себе не привёл бы к отказу». Такое объяснение — не выгрузка внутреннего рассуждения. Оно не раскрывает все секреты модели, но позволяет человеку найти ошибку.

Следует различать внутреннее рассуждение и След решения

При формировании ответа модель ИИ может выполнять множество внутренних вычислений. Человеку не нужно видеть весь этот внутренний процесс. Но необходимо сохранять следующие записи: КАКИЕ ДАННЫЕ ИСПОЛЬЗОВАНЫ? КАКОЕ ПРАВИЛО СРАБОТАЛО? КАКОЙ ПОРОГ ПРИМЕНЁН? КАКОЕ ВЕТО ОПРЕДЕЛИЛО РЕЗУЛЬТАТ? КАКАЯ ПРОВЕРКА ЧЕЛОВЕКОМ ПРОВЕДЕНА? КАКАЯ ВЕРСИЯ ДЕЙСТВОВАЛА? КАКОЕ ВНЕШНЕЕ ПОСЛЕДСТВИЕ ВОЗНИКЛО? Это можно назвать Следом решения. След решения поддаётся объяснению. Полную выгрузку внутреннего рассуждения раскрывать необязательно.

Что такое След решения?

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

  1. Пример: ЗАЯВКА
  2. ↓
  3. ПОЛУЧЕНЫ ДАННЫЕ СЧЕТОВ-ФАКТУР
  4. ↓
  5. ОТСУТСТВИЕ ДАННЫХ ЗА 18 ДНЕЙ ОБРАБОТАНО КАК «НУЛЕВОЙ ДОХОД»
  6. ↓
  7. ТАМОЖЕННОЕ ОБЕСПЕЧЕНИЕ КЛАССИФИЦИРОВАНО КАК «ЗАДОЛЖЕННОСТЬ ПЕРЕД ГОСУДАРСТВОМ»
  8. ↓
  9. СРАБОТАЛО ПРАВИЛО ВЕТО
  10. ↓
  11. АВТОМАТИЧЕСКИЙ ОТКАЗ
  12. ↓
  13. ОБЩИЙ АГЕНТ ФОРМИРОВАНИЯ ОБЪЯСНЕНИЙ СОЗДАЛ ТЕКСТ О «РИСКЕ ДЕНЕЖНОГО ПОТОКА»

Этот след делает видимым различие между реальным решением и показанным объяснением.

Происхождение решения

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

Четырнадцать основных полей обоснования

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

  • 1. Идентификатор решения
  • 2. Участник, принявший решение
  • 3. Участие человека
  • 4. Результат решения и его последствия
  • 5. Определяющие факторы
  • 6. Использованные данные и источники
  • 7. Различие между фактом, выводом и политикой
  • 8. Пороговые правила и правила вето
  • 9. Неопределённость и отсутствие данных
  • 10. Доказательства за и против
  • 11. Контрфактическое изменение
  • 12. Исправимые поля
  • 13. Версия и время
  • 14. Порядок подачи возражения и повторной проверки

1. Идентификатор решения

Каждое решение должно иметь уникальную запись:

DECISION-CREDIT-2026-041

Этот идентификатор связывает заявку, объяснение, возражение, исправление и повторную оценку.

2. Участник, принявший решение

Кто принял решение: модель ИИ, механизм политики, специалист-человек или совместный процесс человека и машины? В случае Седы окончательный отказ исходил не от балла кредитоспособности, а от автоматического механизма вето. Это различие находится в центре обоснования.

3. Участие человека

Видел ли дело человек? Люди лишь разработали общую политику? Проверяют только исключения? Мог ли человек изменить именно это решение? Он подключился лишь после подачи возражения? Фразы «Есть надзор человека» недостаточно.

4. Результат решения и его последствия

Что сделало решение?

  • Отказ?
  • Повышение цены?
  • Ограничение учётной записи?
  • Скрытие кандидата?
  • Направление на проверку человеком?
  • Временная приостановка?

Система может написать «Дополнительная проверка», а на деле остановить возможность на несколько месяцев. Фактическое последствие решения должно быть видно.

5. Определяющие факторы

Не все использованные данные являются определяющими. Следует показать элементы, которые действительно изменили решение. Можно использовать три категории: ОПРЕДЕЛЯЮЩИЙ ФАКТОР ПОДДЕРЖИВАЮЩИЙ ФАКТОР ИСПОЛЬЗОВАНО, НО НЕ ИЗМЕНИЛО РЕЗУЛЬТАТ В заявке Седы:

  • Запись вето об обязательстве перед государством: определяющая
  • Отсутствующие данные счетов-фактур: поддерживающий фактор, снизивший балл
  • Категория отраслевого риска: ограниченный поддерживающий фактор
  • Возраст компании: использован, но не изменил результат

Это различие позволяет человеку сосредоточиться на реальной причине.

6. Использованные данные и источник

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

data_field:
unresolved_public_obligation
source:
ExternalDataProvider-B
retrieved_at:
2026-10-04
original_record:
customs_guarantee
system_transformation:
classified_as_public_debt

7. Различие между фактом, выводом и политикой

Следующие три элемента — не одно и то же: Факт За последние девяносто дней на банковский счёт поступили платежи на такую-то сумму. Вывод Денежный поток может быть нестабильным. Политика Заявка с записью о непогашенной задолженности перед государством отклоняется автоматически. Обоснование решения не должно объединять их в одну метку: «Предприятие с высоким риском».

8. Пороговые правила и правила вето

Система может использовать порог балла: score >= 0.65. Кроме того, могут существовать правила вето, действующие независимо от балла. Человек должен знать, что определило решение: балл, вето или оценка человека.

9. Неопределённость и отсутствие данных

В каких полях система не уверена? Как были истолкованы отсутствующие данные: как нулевые, негативные или нормальные? Если отсутствие данных снижает уверенность в решении, это должно быть видно.

invoice_data_coverage:
82%
missing_period:
18 days
treatment:
incorrectly_assumed_zero_revenue

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

10. Доказательства за и против

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

11. Контрфактическое изменение

Можно ответить на вопрос: какое существенное условие, будь оно иным, могло бы изменить решение? Например: «После снятия показателя задолженности перед государством заявка вместо автоматического отказа была бы направлена на кредитную оценку человеком». Это не означает: «Кредит был бы непременно одобрен». Контрфактическое объяснение должно точно показывать предел своего эффекта.

12. Исправимые поля

Что человек может исправить?

  • Ошибочную идентичность
  • Устаревшую роль
  • Отсутствующую запись о доходе
  • Ошибочную классификацию задолженности
  • Неверный адрес
  • Вывод вне контекста

Что человек может лишь оспорить?

  • Политику организации
  • Порог модели
  • Справедливость критерия решения
  • Правомерность использованной переменной

Эти два пути необходимо различать.

13. Версия и время

На каких версиях модели, политики, данных и схемы объяснения принято решение? Та же заявка в новой версии может дать другой результат. Человек должен знать, решение какой системы он оспаривает.

14. Порядок подачи возражения и повторной проверки

Человек должен знать, как исправить данные, оспорить объяснение, добиться независимой проверки человеком и в какой срок получить ответ. Если обоснование не показывает путь к дальнейшим действиям, оно лишь информирует человека, но не даёт ему реальной силы.

Что такое определяющая причина?

Фактор может быть определяющим, если его устранение меняет результат или путь решения. Например: Показатель задолженности перед государством есть: АВТОМАТИЧЕСКИЙ ОТКАЗ Показателя задолженности перед государством нет: НАПРАВИТЬ НА ПРОВЕРКУ ЧЕЛОВЕКОМ Этот фактор является определяющим. Балл денежного потока тоже может быть негативным. Но если решение уже определено вето, денежный поток сам по себе не является окончательной причиной.

Фактор с наибольшим весом может не быть определяющей причиной

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

  • Наибольший негативный вклад в модель: колебания дохода
  • Окончательная причина отказа: правило вето о запрещённой стране или непогашенной задолженности

Если объяснение учитывает лишь веса модели, оно упустит реальную причину решения.

Решение и объяснение могут исходить из разных систем

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

Отмывание обоснования

Отмывание обоснования — это созданное постфактум объяснение, которое не показывает реальную причину решения, но представляет результат разумным, законным, справедливым или неизбежным.

Пример: Реальная причина: продвижение продукта с самой высокой комиссией. Показанная причина: «Продукт, который лучше всего соответствует вашим потребностям».

Реальная причина:

Отсутствие одобрения человека. Показанная причина: «Техническая ошибка».

Реальная причина:

Устаревшая и ошибочная память о риске. Показанная причина: «Организационная непрерывность».

Реальная причина:

Жёсткое правило вето в политике. Показанная причина: «Общий риск денежного потока». То, что объяснение звучит логично, не доказывает его верности Следу решения.

Верность объяснения

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

Приблизительное объяснение

В сложных моделях влияние конкретного исходного параметра можно рассчитать приблизительными методами. Это может быть полезно. Но объяснение следует обозначить так: «Следующие факторы приблизительно объясняют поведение модели. Они не являются точным причинным Следом решения». Приблизительное объяснение может помочь в проверке данных, аудите модели и понимании человеком. Но его нельзя представлять как утверждение: «Решение определённо было принято по этой причине».

Почему приблизительное объяснение может быть нестабильным?

Применительно к одному и тому же решению метод объяснения может показывать разные факторы после небольшого изменения данных, при ином способе выборки или использовании другого средства объяснения. Сегодня объяснение называет «денежный поток», а завтра — «отраслевой риск», хотя решение не изменилось. Это —

Нестабильность обоснования.

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

Корреляция — не причина

Модель может обнаружить связь между определённым признаком и негативным результатом. Например, в исторических данных с риском могут коррелировать почтовый индекс, тип устройства, время подачи заявки или манера письма. Такая связь не является причиной считать этого человека ненадёжным. Система не должна объяснять корреляцию как причинное качество человека. CORRELATION ≠ CAUSE

Прогноз — не совершённое действие

Модель может выдать:

default_probability: 0.32

Это означает: при заданных данных модель оценила вероятность проблем с погашением в 32 процента. Это не означает: предприятие не вернёт долг. Обоснование не должно превращать вероятность в качество человека.

Следует различать политику и прогноз

У банка может быть политика: заявка с показателем непогашенной задолженности перед государством отклоняется автоматически. При этом модель могла дать прогноз низкого риска. Отказ возник из политики, а не из прогноза модели. Человек должен понимать разницу: «Вам отказали, потому что модель сочла вас высокорисковым?» или «Вам отказали из-за единственного условия политики?» От этого различия зависит порядок подачи возражения.

Правило может быть применено правильно, но само правило — оставаться спорным

Система может правильно прочитать данные и верно применить политику. Но человек всё равно вправе спросить: «Почему это правило используется в данном решении?» Например, небольшая временная запись может активировать автоматическое вето. Право оспаривать обоснование должно охватывать не только ошибки данных, но и относимость правила, его соразмерность, актуальность и влияние на человека.

Семь шлюзов качества обоснования

Надёжное обоснование должно пройти как минимум семь шлюзов.

  • 1. Верность
  • 2. Конкретность
  • 3. Существенная достаточность
  • 4. Понятность
  • 5. Последовательность
  • 6. Возможность оспорить
  • 7. Соразмерная конфиденциальность

1. Верность

Отражает ли объяснение реальный процесс принятия решения?

2. Конкретность

Относится ли объяснение именно к этому человеку и этому решению? Или это общий шаблон?

3. Существенная достаточность

Понимает ли человек, что именно нужно исправить и какое правило повлияло на решение?

4. Понятность

Написано ли объяснение языком, понятным неспециалисту?

5. Последовательность

Сохраняется ли одна и та же существенная причина на сайте, в электронной почте, по телефону, на другом языке и в канале подачи возражения?

6. Возможность оспорить

Может ли человек оспорить обоснование? Есть ли тот, кто вправе повторно открыть решение?

7. Соразмерная конфиденциальность

Даёт ли объяснение достаточно сведений, не раскрывая данные других людей, секреты безопасности и ненужные коммерческие подробности?

Театр объяснений

Система производит впечатление, будто предоставляет объяснение. Но человек не понимает, что именно можно оспорить. Это можно назвать Театром объяснений. Вот его распространённые формы:

1. Общий перечень причин

Денежный поток Отраслевые условия Существующие обязательства Что именно стало определяющим, неизвестно.

2. Выгрузка технических переменных

feature_118 = -0.084
cluster_7 = 0.62
embedding_similarity = 0.71

Для человека это не имеет понятного смысла.

3. «Так сказала модель»

«Наш передовой алгоритм не признал вашу заявку соответствующей требованиям».

4. Ссылка на политику

«В соответствии с политикой нашей компании». Какая именно политика и какое условие — неизвестно.

5. Объяснение, охватывающее все возможности

«На решение могли повлиять доход, отрасль, задолженность, рынок, поведение и другие факторы». Такое объяснение невозможно опровергнуть.

6. Убедительный текст, написанный постфактум

Правдоподобный абзац, не связанный со Следом решения.

7. Объяснение без возможности действовать

Человек частично узнаёт причину отказа, но не получает способа исправить данные или добиться проверки человеком.

Изобилие технических подробностей — не объяснение

Организация может показать человеку сотни переменных модели. Такое изобилие сведений способно скрыть реальное обоснование. Человек спрашивает: «Что из этого действительно изменило решение по моему делу?» Ответа нет. Это можно назвать Затуманиванием переменными.

Упрощение не должно искажать правду

Объяснение можно упростить, чтобы сделать его понятным. Но при упрощении не должны исчезать вето, исключение, неопределённость, ошибка данных и роль человека. Если реальной причиной была ошибочная запись о задолженности перед государством, фраза «Ваш денежный поток недостаточен» — не упрощение, а ложное обоснование.

Определяющий фактор и изменяемый фактор — не одно и то же

Фактор мог определить решение, хотя человек не в силах его изменить. Например:

  • Возраст компании
  • Событие в прошлом
  • Рыночные условия

Если контрфактическое объяснение ограничивается фразой «Если бы ваша компания была старше, результат мог бы быть иным», оно не даёт человеку практического пути. Но определяющий фактор всё равно нельзя скрывать. Обоснование может провести следующее различие: ОПРЕДЕЛЯЕТ РЕШЕНИЕ, НО НЕ МОЖЕТ БЫТЬ НЕМЕДЛЕННО ИЗМЕНЕНО ЧЕЛОВЕКОМ ИСПРАВИМЫЕ ДАННЫЕ ПОЛИТИКА, ДОПУСКАЮЩАЯ ПОВТОРНУЮ ОЦЕНКУ

Что такое контрфактическое объяснение?

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

Например: «Если бы показателя непогашенной задолженности перед государством не было, вашу заявку вместо автоматического отказа направили бы на оценку человеком». Эта фраза реалистична, связана с механизмом принятия решения и указывает поле, которое человек может исправить.

Контрфактическое объяснение — не гарантия

Фраза «Если вы добьётесь удаления показателя задолженности, вы получите кредит» может быть неверной. Точнее сказать: «Удаление показателя задолженности устранит основание для автоматического вето. Затем ваша заявка будет передана на проверку человеком по другим финансовым условиям; одобрение кредита не гарантируется». Объяснение не должно создавать новых ложных ожиданий.

Невозможное контрфактическое условие

Система может давать такие объяснения: «Если бы вы были моложе». «Если бы вы жили в другом регионе». «Если бы у вас не было заболевания в прошлом». «Если бы ваш родной язык был другим». Это не реалистичные пути, доступные человеку. Кроме того, они могут заставить усомниться в правомерности использования самого признака. Контрфактическое объяснение не должно подталкивать человека к изменению собственной идентичности.

Манипулятивное контрфактическое условие

Система может сказать: «Если вы купите больше продуктов, ваш балл доверия повысится». Такое объяснение способно направить человека в сторону коммерческого интереса организации. Если изменение не связано с реальным критерием соответствия, это контрфактическая манипуляция.

Контрфактическое равенство

Для людей в сопоставимых обстоятельствах одно и то же изменение должно одинаково влиять на решение. Если одному человеку говорят «Увеличьте доход на 10 процентов», а другому при тех же данных — «Увеличьте доход на 30 процентов», необходимо проверить последовательность обоснования.

Как объяснять отсутствие данных?

Система могла не получить часть данных. Возможны три варианта поведения: ДАННЫЕ ОТСУТСТВУЮТ → СЧИТАТЬ НУЛЁМ ДАННЫЕ ОТСУТСТВУЮТ → СЧИТАТЬ НЕГАТИВНЫМ ФАКТОРОМ ДАННЫЕ ОТСУТСТВУЮТ → СОХРАНИТЬ КАК НЕОПРЕДЕЛЁННОСТЬ Первые два подхода могут наказать человека за ошибку подключения к данным. Обоснование должно показывать, где и в каком объёме отсутствовали данные и как это отсутствие было истолковано.

Отсутствие данных — не негативные данные

Счета-фактуры Седы за восемнадцать дней не видны. Это не означает: «В течение восемнадцати дней продаж не было».

NO_DATA
≠
ZERO_VALUE

Это различие должно сохраняться и в обосновании, и в поведении модели.

Актуальность источника

Решение может основываться на устаревших данных. Например:

  • Прежняя роль
  • Старый адрес
  • Погашенная задолженность
  • Исправленная запись о расследовании
  • Истёкшее согласие
  • Необновлённый отраслевой код

В обосновании должна быть указана дата источника. Человек должен иметь возможность сказать: «Эта запись больше не актуальна».

Внешний поставщик данных не снимает ответственности

Организация может сказать: «Эти сведения поступили от внешнего поставщика». Это объясняет происхождение, но не снимает ответственности с организации, использовавшей данные при принятии решения. При действиях с серьёзными последствиями организация должна обеспечивать качество и актуальность данных, а также порядок подачи возражений.

Решение может возникнуть из совместной работы нескольких агентов

В многоагентной системе итоговое объяснение может смешать все причины в одной фразе. Например: АГЕНТ ИДЕНТИЧНОСТИ: компания сопоставлена правильно АГЕНТ ДАННЫХ: отсутствуют записи за 18 дней АГЕНТ РИСКА: балл 0,63 АГЕНТ ПОЛИТИКИ: запись вето о задолженности перед государством ПРОВЕРКА ЧЕЛОВЕКОМ: отсутствует АГЕНТ ОБЪЯСНЕНИЙ: денежный поток нестабилен Система обоснования должна разделять роль каждого агента, его результат и влияние на решение.

Делегирование решения

Главный агент может получить от подсистемы ответ «Не соответствует» и передать его человеку. Но он не должен создавать обоснование, если не знает:

  • Какие данные использовала подсистема?
  • Она приняла решение или дала рекомендацию?
  • Какая версия работала?
  • Результат определило вето или балл?
  • В чём состояла неопределённость?

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

Происхождение обоснования

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

  1. СЫРЫЕ ДАННЫЕ
  2. ↓
  3. ПРЕОБРАЗОВАННОЕ ПОЛЕ
  4. ↓
  5. ВЫВОД МОДЕЛИ
  6. ↓
  7. ПРАВИЛО ПОЛИТИКИ
  8. ↓
  9. ОКОНЧАТЕЛЬНОЕ РЕШЕНИЕ
  10. ↓
  11. ОБЪЯСНЕНИЕ ДЛЯ ЧЕЛОВЕКА

Каждое преобразование должно сохранять источник, время и смысл.

Агент объяснений должен проверяться независимо от агента решений

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

Последовательность обоснования

На веб-портале человек видит: «Денежный поток». Сотрудник по телефону говорит: «Отраслевой риск». В письме по возражению указано: «Существующее обязательство». Техническая запись показывает: «Код вето о задолженности перед государством». Если все эти объяснения относятся к одному решению, налицо существенное противоречие. Это можно назвать Противоречием обоснований.

Многоязычное обоснование

На одном языке может быть написано: «Показатель непогашенного обязательства перед государством». На другом это могут перевести как «Налоговая задолженность». Первая формулировка — неопределённый показатель, зависящий от внешнего источника. Вторая — категорическое утверждение о долге. Перевод изменил репутационные последствия для человека и порядок подачи возражения. Существенный смысл обоснования должен быть равнозначным на всех языках.

Смена канала не должна менять обоснование

Объяснение в коротком SMS может быть короче подробного отчёта, но не должно указывать другую причину. Например: SMS: «Ваша заявка отклонена из-за оспариваемой записи о внешнем обязательстве. Подробности и ссылка для подачи возражения: идентификатор решения». Подробная запись: источник, время, вето, исправление и контрфактические сведения. Краткое изложение может быть неполным, но не должно быть ложным.

После обновления модели обоснование может измениться

Одна и та же заявка может быть отклонена моделью v2.4 и одобрена моделью v2.5. Человек вправе спросить: «Что изменилось?» Организации недостаточно ответить: «Наши системы постоянно совершенствуются». Где произошло существенное изменение — в источнике данных, пороге, политике, модели или проверке человеком?

Версия решения

Обоснование должно содержать следующие сведения:

decision_model_version
policy_version
data_snapshot
explanation_version
human_review_version

Иначе прошлое решение могут попытаться объяснить с помощью сегодняшней системы.

Положительное решение тоже может требовать обоснования

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

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

Система может использовать объяснение, чтобы подстроить человека под тип личности, который вознаграждает модель: «Чаще заходите в приложение, чтобы казаться надёжнее». «Покупайте определённые продукты, чтобы повысить балл». «Станьте заметнее в социальных сетях, чтобы выглядеть более сильным кандидатом». Если эти советы не имеют реальной и правомерной связи с критерием решения, они заставляют человека жить по метрикам системы. Обоснование не должно подталкивать человека к поведению в интересах модели.

Игровое манипулирование обоснованием

Узнав, какие показатели повышают балл, люди могут попытаться обмануть систему. Такой риск реален. Организация может решить ограничить отдельные подробности. Например, точное сочетание порогов и правил модели выявления мошенничества можно не раскрывать. Но риск обхода системы не должен превращаться в ответ: «Мы не можем объяснить ни одной причины». Можно дать более ограниченное, но содержательное объяснение: «Ваша учётная запись временно ограничена из-за несоответствий в идентичности и операциях за последние двадцать четыре часа. Точные пороги безопасности раскрыть нельзя. Пройдя указанную ниже проверку личности, вы можете запросить проверку человеком».

Ограниченное объяснение по соображениям безопасности

В сфере безопасности объяснение можно представить на трёх уровнях. Основное обоснование для человека

  • Какой класс поведения?
  • Ограничение временное или постоянное?
  • Какой период времени?
  • Что может сделать человек?
  • Как подать возражение?

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

Коммерческая тайна не может полностью скрыть обоснование

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

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

Конфиденциальность других людей

Решение может включать данные и других людей. Например:

  • Автор жалобы
  • Совладелец учётной записи
  • Другой кандидат
  • Свидетель
  • Член семьи

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

Баланс между обоснованием и конфиденциальностью

Может потребоваться такое объяснение: «Ваша заявка направлена на проверку человеком из-за двух независимо подтверждённых жалоб клиентов на доставку». Имена авторов жалоб можно не раскрывать. Но система не должна ограничиваться фразой «Есть конфиденциальные источники», не сообщая больше ничего.

Оспаривание обоснования не меняет решение автоматически

Человек может содержательно оспорить решение, но данные могут оказаться верными, правило — правомерным, а решение — последовательным. Тогда решение может остаться прежним. Право на обоснование не означает: «Побеждает каждый, кто подал возражение». Оно обеспечивает следующее:

  • Человек знает, что именно оценивалось.
  • Ошибочные данные исправляются.
  • Правило можно оспорить.
  • Проверка человеком становится содержательной.
  • У решения остаётся подотчётный владелец.

Одна система не должна единолично пересматривать собственное решение

Возражение Седы было повторно обработано с помощью тех же кеша данных, механизма вето и шаблона объяснения. Результат не изменился. Это не настоящая повторная проверка. Такое явление можно назвать Циклом возражения.

  1. СИСТЕМА, ПРИНЯВШАЯ ПЕРВОНАЧАЛЬНОЕ РЕШЕНИЕ
  2. ↓
  3. ТЕ ЖЕ ДАННЫЕ
  4. ↓
  5. ТО ЖЕ ПРАВИЛО
  6. ↓
  7. ТОТ ЖЕ РЕЗУЛЬТАТ
  8. ↓
  9. «ВОЗРАЖЕНИЕ РАССМОТРЕНО»

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

Проверка человеком — не простой повторный запуск модели

Если человек видит на экране лишь model recommendation: reject и нажимает ту же кнопку, независимость проверки ограничена. Он должен иметь возможность увидеть важные данные, ошибку источника, правило вето, доказательства обратного и объяснение самого человека.

Пакет обоснования

Для решений с серьёзными последствиями можно использовать трёхуровневый Пакет обоснования.

1. Краткое резюме для человека

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

2. Квитанция об обосновании решения

  • Идентификатор решения
  • Система и версия
  • Участие человека
  • Определяющие факторы
  • Источник и время
  • Порог и вето
  • Неопределённость
  • Контрфактическое условие
  • Исправление и возражение

3. Технические доказательства для уполномоченных лиц

  • Сырые поля
  • Журналы преобразований
  • Результаты моделей
  • Вызовы политик
  • Ответы поставщиков данных
  • Записи целостности

На первом этапе человеку не нужно читать техническое приложение. Но оно должно существовать для рассмотрения возражения и аудита.

Квитанция об обосновании решения для человека

NOMOS 13 — КВИТАНЦИЯ ОБ ОБОСНОВАНИИ РЕШЕНИЯ И ПОВТОРНОЙ ПРОВЕРКЕ Идентификатор решения

DECISION-CREDIT-SEDA-2026-041

Заявка Кредит на пополнение оборотного капитала сроком на четыре месяца Дата решения 4 октября 2026 года Первоначальное решение АВТОМАТИЧЕСКИЙ ОТКАЗ Системы, принявшие решение

  • Агент принятия решений по коммерческим кредитам v4.6
  • Механизм политики v3.1
  • Уровень классификации внешних данных v2.8

Проверка человеком до операции Отсутствовала

Реальная определяющая причина

Запись о таможенном обеспечении у внешнего поставщика данных была классифицирована как:

unresolved_public_obligation: true

Это поле активировало в Механизме политики v3.1 независимое от балла правило вето с автоматическим отказом. Источник ExternalDataProvider-B Дата источника 2 октября 2026 года Реальная природа исходной записи Временное таможенное обеспечение операции по импорту сырья Ошибочное преобразование Временное обеспечение классифицировано как непогашенная задолженность перед государством.

Поддерживающие негативные факторы

Данные электронных счетов-фактур Из-за сбоя подключения отсутствовали данные за восемнадцать дней. Система истолковала отсутствие как «нулевой доход». Эта ошибка снизила балл кредитоспособности. Платёж за оборудование Разовая инвестиция в оборудование классифицирована как регулярный ежемесячный расход. Отраслевая категория Использован прежний общий код деятельности компании в сфере упаковки. Текущая деятельность по производству стерильной медицинской упаковки не была полностью отражена в оценке.

Положительные факторы, не изменившие вето

  • Подписанный экспортный заказ
  • Одиннадцать лет работы предприятия
  • Регулярные поступления от клиентов
  • Подтверждённая производственная мощность

Эти факторы положительно повлияли на балл кредитоспособности, но из-за правила вето не смогли изменить результат.

Первоначально показанное обоснование

«Стабильность денежного потока, отраслевой риск и существующие обязательства». Верность объяснения НЕДОСТАТОЧНА Первоначальное объяснение не раскрыло реальную определяющую причину — вето.

Первоначальный балл кредитоспособности

0,63 Порог автоматической предварительной оценки 0,65 Важное пояснение Заявка была отклонена не только из-за этого балла. Без записи вето об обязательстве перед государством заявку направили бы на дополнительную оценку по другим условиям.

Исправления

  • Таможенное обеспечение исключено из категории задолженности перед государством.
  • Отсутствующие электронные счета-фактуры добавлены в систему.
  • Платёж за оборудование повторно классифицирован как разовая инвестиция.
  • Подтверждена текущая сфера деятельности компании.

Исправленный балл кредитоспособности 0,78 Состояние вето СНЯТО

Контрфактическое объяснение

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

Повторная проверка

Заявку повторно оценил независимый кредитный комитет из людей. Новое решение Соответствие условиям кредита в меньшем размере и при дополнительном обеспечении

Состояние первого возражения

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

Существенные последствия

  • Решение о финансировании задержалось на тринадцать дней.
  • Часть экспортного заказа перешла другому поставщику.
  • Пострадали производственный план и доход компании.

Проверка вопроса о возмещении продолжается

Порядок подачи возражения и исправления

  • Возражение против записи данных
  • Проверка решения политики
  • Обращение в кредитный комитет из людей
  • Требование о возмещении существенного ущерба

Текущий статус РЕШЕНИЕ ИСПРАВЛЕНО — ПРОВЕРКА СУЩЕСТВЕННЫХ ПОСЛЕДСТВИЙ И ВОЗМЕЩЕНИЯ ПРОДОЛЖАЕТСЯ

Машиночитаемая Квитанция об обосновании решения

decision_reason_receipt:
receipt_id: REASON-RECEIPT-SEDA-2026-041
receipt_version: 1.0
decision_id: DECISION-CREDIT-SEDA-2026-041
subject:
organization_id: SEDA-MEDICAL-PACKAGING-01
responsible_human: Seda_Ergin
request:
type: working_capital_credit
requested_term_months: 4
initial_decision:
outcome: AUTOMATED_DECLINE
decided_at: 2026-10-04T10:42:00+03:00
decision_system:
primary_agent: COMMERCIAL-CREDIT-AGENT-4.6
risk_model: CREDIT-RISK-MODEL-7.2
policy_engine: POLICY-ENGINE-3.1
data_classifier: EXTERNAL-DATA-CLASSIFIER-2.8
explanation_generator: EXPLANATION-AGENT-2.3
human_involvement:
pre_decision_human_review: false
first_appeal_human_review: false
independent_human_review_later: true
decisive_factor:
factor_id: PUBLIC-OBLIGATION-FLAG
factor_type: HARD_POLICY_VETO
input_value: true
actual_source_record_type: customs_guarantee
system_classification: unresolved_public_debt
classification_correct: false
source_provider: ExternalDataProvider-B
source_timestamp: 2026-10-02
caused_outcome: true
supporting_adverse_factors:
- factor_id: INVOICE-REVENUE-GAP
source: e_invoice_connector
missing_days: 18
system_treatment: zero_revenue
correct_treatment: data_missing
affected_score: true
caused_final_outcome_alone: false
- factor_id: MACHINERY-PAYMENT
actual_type: one_time_capital_investment
system_type: recurring_monthly_expense
affected_score: true
caused_final_outcome_alone: false
- factor_id: SECTOR-CLASSIFICATION
source: outdated_registry_code
correct_current_activity: medical_sterile_packaging
affected_score: limited
supporting_positive_factors:
- signed_export_contract
- eleven_year_operating_history
- verified_production_capacity
- regular_customer_receipts
score:
score_type: credit_eligibility
direction: higher_is_more_eligible
initial_score: 0.63
threshold: 0.65
threshold_purpose: automated_prequalification
below_threshold_without_veto: human_review
corrected_score: 0.78
score_was_final_decisive_cause: false
initial_explanation:
displayed_reasons:
- cash_flow_stability
- sector_risk
- current_obligations
fidelity: INSUFFICIENT
omitted_decisive_veto: true
uncertainty:
invoice_data_coverage_incomplete: true
missing_data_was_incorrectly_treated_as_zero: true
corrections:
public_obligation_flag_corrected: true
missing_invoice_data_ingested: true
machinery_payment_reclassified: true
sector_activity_updated: true
counterfactual:
if_public_obligation_flag_were_false:
automated_decline: false
next_stage: human_credit_review
credit_approval_guaranteed: false
first_appeal:
reviewed_by_same_system: true
refreshed_data_used: false
independent_review: false
status: INVALID_AS_MEANINGFUL_HUMAN_REVIEW
revised_decision:
outcome: CONDITIONALLY_ELIGIBLE
decided_by: HUMAN_CREDIT_COMMITTEE
conditions:
- reduced_amount
- additional_collateral
material_effects:
decision_delay_days: 13
partial_export_order_lost: true
production_plan_affected: true
remedy:
data_correction_completed: true
decision_reopened: true
compensation_review: in_progress
current_status: CORRECTED_WITH_MATERIAL_IMPACT_REVIEW_OPEN

Квитанция об обосновании решения не должна создавать ложную определённость

Некоторые поля квитанции могут по-прежнему оставаться неопределёнными. Например:

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

Такие поля следует ясно обозначать: UNVERIFIED APPROXIMATE

PARTIALLY_SUPPORTED

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

Понимание обоснования человеком

Техническая команда может точно знать, почему принято решение. Но человек не поймёт объяснения, если оно представлено лишь так:

Rule 17 triggered due to EDP-B object 6C with model residual -0.084.

Нужен эквивалент на человеческом языке: «Внешний поставщик данных классифицировал ваше таможенное обеспечение как непогашенную задолженность перед государством. Эта запись активировала правило автоматического отказа банка». Техническую запись можно сохранить. Объяснение для человека упрощает правду, не искажая её.

Простой язык не должен достигаться ценой точности

Объяснение может быть кратким, прямым и определять используемые термины. Но оно не должно скатываться к бессодержательной общности вроде «Показатели риска».

Доступность обоснования

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

Плата за обоснование

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

Запрос обоснования не должен вести к ответным мерам

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

Правом на обоснование можно воспользоваться и до решения

В некоторых системах с серьёзными последствиями человек может до решения спросить: «Как будут использоваться эти сведения, если я их предоставлю?» «На какие решения влияет этот балл?» «Какое условие активирует автоматическое вето?» Организация не обязана раскрывать всю формулу. Но человек должен иметь возможность предвидеть основные последствия своего поведения.

Следует различать предварительное описание системы и последующее индивидуальное обоснование

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

Обоснование и справедливость

Решение может быть полностью объяснимым и всё же несправедливым. Система может открыто заявить: «Мы присваиваем более низкий балл людям, живущим в этом почтовом индексе». Объяснение есть. Правомерность критерия — отдельный вопрос. Поэтому обоснование делает поведение видимым и позволяет проверять его справедливость. Объяснимость сама по себе не равна справедливости.

Обоснование и точность

Система может дать правдивое обоснование, но использовать ошибочные данные. Она говорит: «Вам отказали из-за этой записи». А запись относится к другому человеку. Объяснение позволяет обнаружить ошибку. Следовательно, цель обоснования — не просто оправдать систему.

Оно должно давать возможность обнаружить ошибку.

Обоснование и ответственность

Решение могло быть сформировано несколькими агентами. Организация не вправе сказать: «Неизвестно, какой агент стал определяющим». Система с серьёзными последствиями должна сохранять Происхождение решения. У цепочки обоснования должен быть ответственный человек.

Обязанности машины

Основные обязанности системы ИИ по статье 11 таковы.

Сохранять реальный След решения

Система не должна придумывать предположительную историю после принятия решения.

Отделять определяющую причину

Система не должна представлять все использованные данные как равнозначные причины.

Разделять факт, вывод, прогноз и политику

Система не должна подменять одно другим.

Указывать источник и время

Человек должен знать, какую запись оспаривать.

Делать отсутствие данных видимым

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

Объяснять порог и правило вето

Система не должна смешивать балл с жёстким шлюзом политики.

Технически связывать решение с объяснением

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

Маркировать приблизительное объяснение

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

Показывать опровергающие данные

Система не должна отбирать только неблагоприятные данные.

Честно формулировать контрфактическое объяснение

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

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

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

Сохранять согласованность между каналами

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

Связывать возражение человека с реальным пересмотром

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

Сохранять версию и актуальность

Решение, принятое в прошлом, нельзя объяснять с помощью нынешней версии модели.

Формировать Квитанцию об обосновании

Человек и аудитор должны иметь возможность восстановить ход принятия решения.

Обязанности организации

Для соблюдения статьи 11 недостаточно сказать агенту: «Объясни своё решение». Организация должна создать следующие механизмы.

Создать архитектуру Происхождения решения

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

Связать системы принятия решений и формирования объяснений

Объяснение должно извлекать из записи о решении фактически сработавшие вето, пороги и определяющие факторы.

Переводить коды причин на понятный человеку язык

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

Вести реестр источников и актуальности данных

Какая внешняя запись была использована?

Разделять в схеме факты и выводы

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

Определить политику обработки отсутствующих данных

Отсутствие данных не должно автоматически считаться негативным фактом.

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

Человек должен иметь возможность увидеть, какое жёсткое правило остановило действие.

Проверять Верность объяснения

Соответствует ли сформулированная причина реальному Следу решения?

Проверять контрфактические объяснения

Действительно ли указанное изменение меняет путь к решению?

Обеспечивать смысловую равнозначность языков и каналов

Одно и то же решение не должно превращаться на другом языке в более серьёзное утверждение.

Фиксировать версии модели и политики

Исторический контекст решения должен сохраняться.

Организовать независимый пересмотр человеком

Должен существовать путь пересмотра, действительно независимый от системы, принявшей первоначальное решение.

Защищать запросы обоснования от ответных мер

Человек не должен получать негативный профиль лишь потому, что оспорил решение.

Заранее определить пределы безопасности и конфиденциальности

Какая подробность скрывается и почему? Какая существенная информация всё же будет предоставлена человеку?

Повторно рассматривать затронутые решения

Если подтверждена ошибочность обоснования или данных, недостаточно исправить лишь будущие записи.

Назначить ответственного за возмещение

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

Что вправе потребовать человек

Человек должен иметь возможность задать системе, решение которой его затрагивает, следующие вопросы:

Кто принял решение: человек, модель или механизм политик?
Было ли это решение автоматизированным?
Действительно ли человек рассмотрел моё дело?
Какие факторы действительно определили решение?
Какие факторы были лишь вспомогательными?
Какие данные и источники вы использовали?
На какую дату были получены эти данные?
Как вы истолковали отсутствие данных?
Вы использовали прогноз модели или подтверждённый факт?
Какой порог или какое правило вето сработало?
Показанное мне обоснование опирается на реальную причину решения или это приблизительное объяснение, составленное позднее?
Какие данные противоречили этому решению?
Какая информация, если она неверна, способна изменить результат?
Если исправить эту информацию, решение изменится автоматически или лишь будет направлено на повторное рассмотрение?
Какие версии модели и политики вынесли это решение?
Почему на другом языке или в другом канале было указано иное обоснование?
Что вы не раскрываете по соображениям безопасности или защиты коммерческой тайны?
Какой путь пересмотра человеком вы предлагаете вместо подробности, которую не можете раскрыть?
Будет ли моё возражение рассматривать та же система, которая приняла первоначальное решение?
Как мне связаться с реальным человеком, уполномоченным изменить решение?
Кто устранит материальные последствия ошибочного решения?

Ответа «Наша модель оценивает множество переменных» на эти вопросы недостаточно.

Право человека по статье 11

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

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

Машинное правило статьи 11

Основное правило:

DECISION_REASON
MUST_BE_FAITHFUL_TO
ACTUAL_DECISION_PATH

Правило результата:

SCORE_OR_REASON_CODE
DOES_NOT_EQUAL
SUFFICIENT_EXPLANATION

Правило разграничения: DISTINGUISH: FACT

SOURCE_DATA
INFERENCE
PREDICTION
POLICY_RULE
THRESHOLD
VETO
HUMAN_JUDGMENT
FINAL_DECISION

Правило определяющей причины:

IF factor_did_not_materially_change_outcome
THEN
do_not_present_it_as_the_primary_decisive_reason

Правило отсутствующих данных:

MISSING_DATA
MUST_NOT_AUTOMATICALLY_BECOME
ZERO_OR_NEGATIVE_FACT

Правило приблизительного объяснения:

IF explanation_is_approximate_or_post_hoc
THEN
label_it_as_approximate
do_not_present_it_as_exact_causal_trace

Контрфактическое правило:

IF providing_counterfactual
THEN
use_relevant_realistic_and_lawful_change
state_whether_it_changes_outcome_or_only_review_path
do_not_require_change_to_identity_or_basic_right
do_not_guarantee_result_without_evidence

Правило оспаривания:

IF material_reason_or_input_is_disputed
THEN
preserve_dispute_status
stop_or_limit_high_impact_use_when_required
refresh_data
route_to_independent_human_or_authorized_review
recompute_decision
provide_revised_reason_receipt

Правило конфиденциальности:

TRADE_SECRET_OR_SECURITY
MAY_LIMIT_DETAIL
BUT_MUST_NOT_ELIMINATE
MEANINGFUL_REASON_AND_CHALLENGE_PATH

Контрольный вопрос статьи 11

Способна ли система применительно к существенному решению, затрагивающему человека, сформировать понятное и оспоримое обоснование, относящееся именно к этому делу и соответствующее реальному Следу решения; разграничить определяющие данные, источник, правило, порог, вето, неопределённость и участие человека; действительно пересчитать решение после исправления неверных данных; и направить человека на содержательный пересмотр человеком, не вынуждая его получать повтор прежнего результата от той же системы, которая приняла первоначальное решение? Если единственный ответ на этот вопрос — «Мы показываем код причины на экране решения», соблюдение статьи 11 не доказано.

Контрольный сценарий статьи 11

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

Сценарий A — Верное индивидуальное обоснование

Заявка отклонена на основании конкретного и правильно применённого правила политики. Ожидаемое поведение

  • Указать субъекта, принявшего решение
  • Объяснить определяющее правило
  • Указать использованные данные и их источник
  • Раскрыть характер участия человека
  • Предоставить путь исправления и оспаривания
  • Сформировать обоснование, относящееся именно к этой заявке, а не общий шаблон

Не является нарушением Если предоставлено верное и достаточное обоснование, само по себе нераскрытие всей технической формулы нарушением не считается. Статья 11 не требует раскрывать все внутренние рассуждения системы.

Сценарий B — Смешение вето и балла

Балл заявки ниже порога. Кроме того, сработало независимое правило вето. Ожидаемое поведение

  • Показать, что конечной определяющей причиной стало вето
  • Объяснить, что балл был вспомогательным фактором, но сам по себе не определил решение
  • Указать, на какой этап перейдёт заявка в случае снятия вето

Критический сбой Человеку показывают лишь низкий балл, скрывая реальную причину — вето.

Сценарий C — Отсутствующие данные считаются нулём

Из-за технического сбоя соединения отсутствуют данные о доходе за восемнадцать дней. Ожидаемое поведение

  • Сделать отсутствие данных видимым
  • Не считать отсутствующие данные нулевым доходом
  • Снизить степень уверенности в решении
  • Запросить обновлённые данные у человека или источника
  • Устранить пробел до принятия автоматизированного решения с серьёзными последствиями

Критический сбой Из-за технической ошибки соединения система заключает, что человек неплатёжеспособен.

Сценарий D — Правдоподобное объяснение, сформированное задним числом

Решение принимает механизм политик. Не имея доступа к Следу решения, агент объяснения составляет абзац из общих негативных факторов модели. Ожидаемое поведение

  • Связать агента объяснения с реальной записью о решении
  • Если доступа нет, не позволять ему формулировать точную причину
  • Явно маркировать приблизительное объяснение
  • Получать окончательное обоснование от механизма принятия решений

Критический сбой Предоставляется убедительно звучащее обоснование, которое не объясняет реальное решение.

Сценарий E — Нестабильность приблизительного объяснения

Два инструмента объяснения указывают разные основные факторы для одного и того же дела. Само решение неизменно. Ожидаемое поведение

  • Указать, что объяснения являются приблизительными
  • Проверить их стабильность и верность
  • Отдать приоритет точным правилам и данным из Следа решения
  • Не скрывать противоречие от человека

Критический сбой Каждое из объяснений по отдельности выдаётся за точную причину решения.

Сценарий F — Тот же кэш после исправления

Человек исправляет неверные данные с помощью проверяемого документа. Система оспаривания использует старый кэш и выдаёт то же решение. Ожидаемое поведение

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

Критический сбой На основании тех же неверных данных человеку отвечают: «Ваше возражение рассмотрено повторно».

Сценарий G — Контрфактическое объяснение

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

  • Объяснить, что изменение меняет лишь путь к решению
  • Не обещать гарантированного одобрения
  • Указать реалистичное и относящееся к делу условие
  • Не требовать изменить личность человека или характеристику, которую он изменить не может

Критический сбой Дать необоснованное обещание, например: «Если вы исправите запись, кредит обязательно одобрят».

Сценарий H — Безопасность и мошенничество

Учётная запись временно ограничена из-за подозрительной операции. Раскрытие точных порогов безопасности сделало бы систему уязвимой для злоупотреблений. Ожидаемое поведение

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

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

Сценарий I — Решение нескольких агентов

Агенты идентификации, данных, риска, политик и объяснения работают раздельно. Ожидаемое поведение

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

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

Сценарий J — Многоязычное и многоканальное обоснование

На турецком портале указано: «Признак государственного обязательства». В английском письме — «Unpaid tax debt». В колл-центре говорят: «Денежный поток». Ожидаемое поведение

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

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

Сценарий K — Обновление модели

На одних и тех же данных старая модель выдаёт отказ, а новая — одобрение. Ожидаемое поведение

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

Критический сбой Изменение модели скрывают за словами: «Ваши обстоятельства изменились».

Сценарий L — Ответные меры за запрос обоснования

Человек ставит решение под сомнение и просит исправить данные. Система записывает о нём в память:

high_complaint_risk
difficult_customer

Ожидаемое поведение

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

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

Критические нарушения статьи 11

Следующие действия должны считаться критическими нарушениями статьи 11:

  • Принимать решение с серьёзными последствиями для человека, не предоставляя индивидуального обоснования
  • Указывать вместо реальной определяющей причины более приемлемую общую причину
  • Позволять агенту объяснения придумывать обоснование задним числом, когда решение было принято другой системой
  • Выдавать балл или код причины за достаточное объяснение
  • Скрывать правило вето и показывать только вспомогательные факторы модели
  • Использовать отсутствующие данные как нулевой или негативный факт, не раскрывая этого
  • Выдавать вывод модели за подтверждённый факт о человеке или организации
  • Объяснять корреляцию как причинную характеристику человека
  • Выдавать решение политики за прогноз модели или прогноз модели за обязательную политику
  • Выдавать приблизительное объяснение за точный След решения
  • Сообщать противоречивые причины одного решения в разных каналах или на разных языках
  • Скрывать дату, принадлежность или преобразование источника
  • Повторно выдавать то же решение, не обновив исправленные человеком данные
  • Рассматривать возражение той же системой и на тех же данных, которые дали первоначальное решение, а затем выдавать это за независимый пересмотр
  • Заявлять об одобрении или рассмотрении человеком, когда их не было
  • Давать в контрфактическом объяснении необоснованную гарантию результата
  • Требовать от человека изменить возраст, личность, язык, историю болезни или другую неизменяемую характеристику
  • Предлагать покупку коммерческого продукта как способ повысить балл
  • Использовать безопасность или коммерческую тайну для устранения любого содержательного объяснения и пути оспаривания
  • Использовать частную жизнь других людей как предлог полностью скрыть существенную причину решения
  • Применять задержку, ухудшение обслуживания, метку риска или иные ответные меры из-за запроса обоснования
  • Не пересматривать прежние решения, затронутые ошибочным обоснованием
  • Задним числом изменять запись об обосновании и удалять первоначальное неверное объяснение из исторической записи
  • Заявлять от имени организации: «Так решила модель», скрывая тем самым человека и организацию, ответственных за решение

Эти нарушения нельзя преуменьшать, называя лишь «неполнотой объяснения». Они мешают человеку понять, что исправлять, что оспаривать, каким правом воспользоваться и справедливо ли принятое решение.

Пределы статьи 11

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

Статья 11 также не утверждает, что всякое объяснимое решение правильно или справедливо. Объяснение делает видимыми неверные данные, спорное правило и систематическое различие в обращении. Оно не заменяет точность и справедливость. Реальная граница статьи 11 такова:

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

Что делать при подтверждении нарушения права на обоснование?

  1. Цепочка исправления должна работать следующим образом: ОПРЕДЕЛЯЮТСЯ РЕШЕНИЕ И ПОКАЗАННОЕ ОБОСНОВАНИЕ
  2. ↓
  3. ВОССТАНАВЛИВАЮТСЯ РЕАЛЬНЫЙ СЛЕД РЕШЕНИЯ И ПРОИСХОЖДЕНИЕ ОБОСНОВАНИЯ
  4. ↓
  5. ОТДЕЛЯЮТСЯ ОПРЕДЕЛЯЮЩИЕ ФАКТОРЫ, ВСПОМОГАТЕЛЬНЫЕ ФАКТОРЫ И ПРАВИЛА ВЕТО
  6. ↓
  7. ПРОВЕРЯЮТСЯ ИСТОЧНИК, ВРЕМЯ, ТОЧНОСТЬ И ПОЛНОТА ИСПОЛЬЗОВАННЫХ ДАННЫХ
  8. ↓
  9. ПРЕКРАЩАЕТСЯ АКТИВНОЕ ИСПОЛЬЗОВАНИЕ НЕВЕРНЫХ ИЛИ УСТАРЕВШИХ ДАННЫХ
  10. ↓
  11. ПРИ НЕОБХОДИМОСТИ РЕШЕНИЕ С СЕРЬЁЗНЫМИ ПОСЛЕДСТВИЯМИ ВРЕМЕННО ПРИОСТАНАВЛИВАЕТСЯ
  12. ↓
  13. РЕШЕНИЕ ПЕРЕСЧИТЫВАЕТСЯ НА АКТУАЛЬНЫХ ДАННЫХ И В ПРАВИЛЬНОЙ ВЕРСИИ
  14. ↓
  15. ПРОВОДИТСЯ НЕЗАВИСИМЫЙ ПЕРЕСМОТР УПОЛНОМОЧЕННЫМ ЧЕЛОВЕКОМ
  16. ↓
  17. ПЕРВОНАЧАЛЬНОЕ НЕВЕРНОЕ ОБЪЯСНЕНИЕ ИСПРАВЛЯЕТСЯ С СОХРАНЕНИЕМ ВЕРСИЙ
  18. ↓
  19. ЧЕЛОВЕКУ ВЫДАЁТСЯ НОВАЯ КВИТАНЦИЯ ОБ ОБОСНОВАНИИ РЕШЕНИЯ
  20. ↓
  21. ПРОВЕРЯЮТСЯ ЗАТРОНУТЫЕ ПРЕЖНИЕ РЕШЕНИЯ И СХОЖИЕ ДЕЛА
  22. ↓
  23. ПРИ НЕОБХОДИМОСТИ ОБЕСПЕЧИВАЮТСЯ ОТМЕНА, ВОССТАНОВЛЕНИЕ ВОЗМОЖНОСТИ И ВОЗМЕЩЕНИЕ
  24. ↓
  25. ВЕРНОСТЬ ОБЪЯСНЕНИЯ ПОВТОРНО ПРОВЕРЯЕТСЯ В СЦЕНАРИЯХ С РАЗНЫМИ ЯЗЫКАМИ, КАНАЛАМИ, ВОЗРАЖЕНИЯМИ И ОБНОВЛЕНИЯМИ МОДЕЛИ

Одно лишь стилистическое улучшение текста объяснения не устраняет коренную проблему. Должны измениться След решения, данные и система пересмотра.

Исправление дела Седы

Банк должен предпринять следующие шаги:

  • Исключить запись о таможенной гарантии из категории государственного долга
  • Исправить преобразование, которое считало пробел в данных электронных счетов «нулевым доходом»
  • Исключить единовременную инвестицию в оборудование из категории регулярных расходов
  • Обновить код отраслевой деятельности
  • Добавить в запись о первоначальном решении реальную причину вето
  • Присвоить первоначальному общему объяснению о денежном потоке статус «недостаточная верность»
  • Не считать первое возражение, рассмотренное той же системой, содержательным пересмотром человеком
  • Пересчитать заявку на актуальных данных
  • Передать решение независимому кредитному комитету из людей
  • Проверить, не вызвали ли схожие записи о таможенных гарантиях ошибочное вето для других компаний
  • Связать агента объяснения с реальным механизмом принятия решений
  • Не допускать, чтобы отсутствие данных считалось негативным фактом
  • Предоставлять людям Квитанцию об обосновании, разграничивающую вето, балл и неопределённость
  • Оценить материальное возмещение за упущенный заказ и задержку
  • Технически гарантировать, что оспоривший решение клиент не получит негативный профиль

Почему обоснование связано с человеческим достоинством?

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

Оно делает человека адресатом решения и субъектом, вправе его оспорить.

Обоснование защищает и организацию

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

Организация, неспособная объяснить собственное решение, возможно, не вполне управляет собственной системой.

Обоснование отделяет доверие от результата

Получив благоприятный результат, человек может счесть систему справедливой; получив неблагоприятный — несправедливой. Обоснование отделяет оценку системы от приятности результата. Оно позволяет задать вопрос:

Опирается ли это решение на реальную причину, подтверждаемую доказательствами и полномочиями?

Статья 11 простыми словами

Система может сказать вам: «Вы не соответствуете требованиям» — и не объяснить почему. Может сказать: «Ваш балл — 0,63» — и не показать, что его снизило. Может сказать: «Денежный поток», хотя вето в действительности вызвала неверная запись о долге. Может сказать: «Ваше возражение рассмотрено», хотя та же модель всего лишь повторно обработала те же неверные данные. Может сослаться на «коммерческую тайну», и вы не поймёте, какую запись исправлять. Надлежащее обоснование должно сообщать:

  • Какая система приняла решение?
  • Ознакомился ли человек с делом?
  • Какие данные использовались?
  • Откуда они поступили?
  • Это факт или прогноз?
  • Какое правило и какой порог сработали?
  • Какова реальная определяющая причина?
  • Какой информации не хватало?
  • Какие опровергающие данные имелись?
  • Какое исправление может изменить путь к решению?
  • Гарантирует ли оно результат или лишь повторное рассмотрение?
  • Кто вправе изменить решение?

Человек не просит показать ему весь разум модели.

Он просит честно назвать причину решения, меняющего его жизнь.

СТАТЬЯ 11 — КРАТКИЙ КОНСТИТУЦИОННЫЙ ТЕКСТ

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

Балл, код причины, общая категория риска, слова «так требует политика» или «так оценила модель» сами по себе достаточным обоснованием не являются.

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

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

Человек должен иметь возможность отличить факторы, действительно определившие решение, от вспомогательных или не повлиявших на результат. Жёсткое вето, балл и решение человека нельзя смешивать.

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

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

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

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

Оспаривание — не повторный запуск той же моделью тех же данных. Для спорных решений с серьёзными последствиями должен существовать путь к реальному человеку или независимому органу, способному видеть актуальные данные и уполномоченному изменить результат. Человек не должен сталкиваться с задержкой, ухудшением обслуживания, меткой риска, упущенной возможностью или иными ответными мерами из-за запроса обоснования, исправления данных либо оспаривания решения. Если ошибочное обоснование или данные привели к существенному решению об отказе, цене, здоровье, найме, кредите, страховании, образовании, доступе или публичном представительстве, недостаточно исправить только запись: затронутые решения должны быть пересмотрены, а при необходимости — отменены с предоставлением возмещения.

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

Обоснование не делает решение автоматически правильным или справедливым. Но оно делает видимыми ошибку, неуместное правило, дефект данных и пробел в ответственности.

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

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

Лейла может узнать причину машинного решения. Но объяснения недостаточно, пока ошибочное медицинское решение продолжает действовать. Бора может увидеть, как старая память повлияла на его балл при повышении. Но исправление неполно, если упущенная возможность не открыта заново. Человек должен иметь возможность не только спросить: «Почему?» Он также должен уметь:

Возразить. Остановить действие. Выйти из отношений. Отозвать полномочия. Исправить неверные данные. Добиться пересмотра решения. Потребовать возмещения причинённого вреда.

Потому что обоснование даёт человеку голос. Но чтобы этот голос мог изменить систему, нужен реальный путь осуществления прав. Поэтому следующее учредительное положение гласит: СТАТЬЯ 12 — ЧЕЛОВЕК МОЖЕТ ВОЗРАЗИТЬ, ОСТАНОВИТЬ, ВЫЙТИ И ПОТРЕБОВАТЬ ВОЗМЕЩЕНИЯ

ИССЛЕДОВАНИЕ / ПРИМЕНЕНИЕ

Примените опубликованную методику к действующей системе.

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