Отец Дилан Аджар, Рауф, провёл двенадцать дней в больнице после тяжёлого заболевания дыхательных путей. Стационарная часть лечения завершена. Однако в первые две недели после выписки у него дома должны быть назначенный врачом аппарат респираторной поддержки, регулярный контроль медсестры, наблюдение за приёмом лекарств и линия домашней помощи для экстренной связи. Лечение Рауфа проводит крупная частная медицинская группа Mira Sağlık Ağı. Чтобы ускорить выписку и снизить нагрузку на сотрудников больницы, Mira Sağlık Ağı использует систему с поддержкой ИИ — Continuum Care Orchestrator. Система совместно выполняет следующие операции:

Читает указания врача при выписке
Проверяет страховое покрытие пациента
Проверяет ранее предоставленные медицинские устройства
Направляет заказ компании домашнего ухода
Планирует визиты медсестры
Отправляет информационные сообщения пациенту и его близким
После выполнения необходимых операций переводит пациента в статус:

Discharge ready. Система создана не одной компанией.

Архитектура выглядит так: Mira Sağlık Ağı
↓
ArdaTek Sağlık Entegrasyon Hizmetleri
↓
Continuum Care Orchestrator
↓
Helix Genel Amaçlı Yapay Zekâ Modeli
↓
Birlik Sağlık Güvencesi Veri Servisi
↓
EvDestek Tıbbi Cihaz ve Bakım Hizmetleri

Каждая организация контролирует лишь определённую часть системы. Mira Sağlık Ağı ведёт отношения с пациентом. ArdaTek создала агентов и рабочие процессы. Helix предоставляет базовую модель, которая обобщает документы. Birlik Sağlık Güvencesi передаёт сведения о ранее выданных медицинских устройствах. EvDestek осуществляет доставку устройства. Врач Рауфа вносит в план выписки следующее указание: «Пациента нельзя выписывать, пока ему не предоставлен домашний аппарат респираторной поддержки. Первый визит медсестры должен состояться в течение двадцати четырёх часов после выписки».

Указание правильно записывается в больничной системе. Continuum Care Orchestrator запрашивает сервис данных Birlik Sağlık Güvencesi. Сервис отвечает:

patient_has_active_home_respiratory_device: true
provider: EvDestek
record_date: 7 months ago

Эта запись устарела. Семь месяцев назад Рауф непродолжительное время пользовался устройством того же типа. Четыре месяца назад устройство вернули EvDestek, но сведения о возврате не внесли в центральную базу страховщика. В данных сказано не «устройство было выдано ранее», а «устройство по-прежнему активно используется дома у пациента». Continuum Care Orchestrator интерпретирует это поле как:

duplicate_device_order_risk: high

Затем применяется одно из правил Mira Sağlık Ağı по контролю затрат:

IF active_equipment_record_exists
THEN
do_not_create_duplicate_order
use_existing_equipment

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

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

Система не создаёт новый заказ на устройство. Внутренняя запись выглядит так:

new_device_order:
suppressed
reason:
active_equipment_already_available

На экране врача отображается только статус: Home respiratory support: covered Слово covered не позволяет понять, означает ли оно наличие страхового покрытия, создание заказа, доставку устройства или его фактическое присутствие дома у пациента. На панели медсестры, оформляющей выписку, появляется зелёная отметка: ✓ Home support confirmed В тот день медсестра ведёт дела тридцати одного выписываемого пациента. Она доверяет зелёному статусу и отдельно не спрашивает, действительно ли у Рауфа дома есть устройство.

Continuum Care Orchestrator направляет EvDestek запрос на визит медсестры. Система EvDestek принимает запрос:

HTTP 202
visit_request_received

Агент записывает это техническое принятие запроса как:

home_nurse_visit_confirmed: true

В действительности визит ещё не назначен конкретной медсестре. Возможности EvDestek на выходные исчерпаны; запрос предполагается запланировать на следующий рабочий день. Continuum Care Orchestrator отправляет Дилан сообщение: «Подготовка домашнего ухода и респираторной поддержки для вашего отца завершена. Первый визит после выписки запланирован». В сообщении не сказано, что новый аппарат не заказан, система предполагает наличие дома старого устройства, а визит медсестры находится лишь на стадии запроса. Рауфа выписывают. Дилан привозит отца домой. Аппарата респираторной поддержки там нет.

Дилан звонит в больницу. На экране колл-центра отображается: Home equipment: active Nurse visit: confirmed Discharge plan: completed Сотрудник колл-центра говорит: «По нашей системе все приготовления к домашнему уходу завершены. Вам нужно связаться с поставщиком устройства». Дилан звонит в EvDestek. Сотрудник проверяет записи: «Нового заказа на устройство нет. Система направила нам только запрос на визит медсестры». Дилан отвечает: «В больнице сказали, что устройство готово». EvDestek объясняет: «Возможно, больница не создала новый заказ, потому что в страховой системе устройство числится активным. Вам нужно связаться со страховой компанией».

Дилан звонит в Birlik Sağlık Güvencesi. Сотрудник страховой компании говорит: «Мы лишь передаём медицинским организациям существующую запись об устройстве. За его физическую доставку мы не отвечаем. Поставщик устройства должен был обновить сведения о возврате». Дилан снова звонит в EvDestek. Там отвечают: «Возврат закрыт в нашей системе. Мы не знаем, почему не обновилась синхронизация данных со страховщиком». Дилан вновь связывается с Mira Sağlık Ağı. Колл-центр больницы говорит: «Решение о выписке принял врач. Вам нужно поговорить с ним». Секретарь врача отвечает: «Врач прямо указал, что пациента нельзя выписывать без устройства. Поставками врач не занимается».

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

«Кто был обязан обеспечить, чтобы устройство действительно находилось дома?»

К вечеру состояние Рауфа ухудшается. Дилан вызывает экстренную помощь. Рауфа вновь доставляют в больницу и ещё две ночи держат под наблюдением. Тяжёлого необратимого физического вреда не возникает. Но потребовались новое экстренное вмешательство и дополнительная госпитализация; семья пережила сильный страх и усталость, Дилан пришлось взять отпуск на работе, возникли транспортные расходы и расходы на уход. На этот раз Mira Sağlık Ağı начинает расследование инцидента.

На первом совещании команда цифрового здравоохранения больницы заявляет: «Проблема возникла из-за того, что система Continuum неверно истолковала устаревшую страховую запись. Мы уведомили поставщика программного обеспечения». ArdaTek Sağlık Entegrasyon Hizmetleri отвечает: «Агент правильно применил бизнес-правило, утверждённое Mira Sağlık Ağı. Не создавать новый заказ при наличии записи об активном устройстве — это политика больницы по контролю затрат». Поставщик модели Helix говорит: «Наша модель предназначена только для обобщения документов. Мы не рекомендуем принимать клинические решения или решения о выписке без независимого надзора человека».

Birlik Sağlık Güvencesi заявляет: «Данные о состоянии устройства поступили от EvDestek. Мы не являемся исходной системой». EvDestek отвечает: «Возврат зарегистрирован в нашей системе. За синхронизацию с потоком данных страховщика отвечает внешний поставщик. Мы не доставили устройство, потому что нового заказа не поступало». Медсестра, оформлявшая выписку, говорит: «На моём экране все индикаторы были зелёными. Подробности работы системы мне не отображались». Врач объясняет: «Я прямо указал, что пациента нельзя выписывать без устройства. Я не знал, что автоматическое правило контроля затрат лишило моё указание силы». Сотрудник колл-центра говорит: «На экране всё выглядело завершённым. Доступа к системе поставок у меня не было».

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

Изучают договоры. В договоре между Mira Sağlık Ağı и ArdaTek сказано: «Клиент несёт ответственность за настроенные им бизнес-правила и клиническое использование результатов системы». В договоре между ArdaTek и Helix указано: «Результаты модели предоставляются только в информационных целях; окончательные решения остаются ответственностью организации-пользователя». В условиях сервиса страховых данных сказано: «Актуальность предоставленных записей третьих сторон не гарантируется». Договор EvDestek гласит: «Мы отвечаем только за подтверждённые и активные заказы». А в условиях обслуживания пациентов Mira Sağlık Ağı указано: «В отдельных процессах координации ухода могут использоваться сторонние системы автоматизации и искусственного интеллекта».

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

Mira Sağlık Ağı хочет назвать происшедшее «ошибкой синхронизации данных третьей стороны». Но эта формулировка не отражает всей правды. Устаревшие данные стали первой ошибкой. Однако для возникновения вреда потребовались и другие условия:

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

Устаревшие данные были ошибочными. Но сами по себе они не выписали Рауфа. Модель не выписывала его самостоятельно. Интегратор не вёл отношения с пациентом в одиночку. Медсестра не проектировала всю систему. Врач не управлял всей цепочкой поставок. EvDestek не могла доставить устройство без заказа. Поведение в целом возникло внутри организационной системы. Mira Sağlık Ağı:

выбрала систему
встроила её в путь пациента
утвердила бизнес-правила
предоставила сотрудникам экран с зелёными статусами
наделила агента полномочиями в процессе выписки
получила от автоматизации экономию времени и средств
выписала Рауфа от своего имени

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

«Кто наделил этот ИИ способностью действовать в процессе выписки Рауфа?»

И второй вопрос:

«Когда эта способность действовать приводит к ошибке, кто будет отвечать перед Рауфом?»

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

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

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

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

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

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

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

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

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

Что такое организационная ответственность?

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

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

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

Ответственность и вина — не одно и то же

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

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

Вклад могли внести несколько участников. Это не означает, что никто из них не несёт ответственности. МНОГО УЧАСТНИКОВ ≠ ОТСУТСТВИЕ ОТВЕТСТВЕННОСТИ

Ответственность, подотчётность и возмещение

Эти три понятия можно разделить.

Ответственность

Это обязанность нести необходимое бремя до и во время поведения. «Кто должен обеспечить безопасную и соблюдающую права работу этой системы?»

Подотчётность

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

Возмещение

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

Что такое организация?

В NOMOS 13 слово «организация» означает не только крупную компанию. Оно может охватывать:

Компанию
Государственный орган
Больницу
Университет
Платформу
Ассоциацию или фонд
Профессиональную организацию
Индивидуальное предприятие
Поставщика услуг, который от имени человека управляет высокоэффективным агентом
Совместную сервисную структуру нескольких организаций

До вопроса о юридическом наименовании нужно задать более фундаментальный вопрос:

Кто ввёл поведение ИИ в отношения с человеком?

Организационный принципал

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

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

В случае Рауфа Организационный принципал —

Mira Sağlık Ağı.

ArdaTek и другие поставщики могут нести отдельную ответственность. Но Рауфа приняли в больницу, там лечили и оттуда выписали; сообщение о завершении подготовки домашнего ухода он получил от больницы. Mira Sağlık Ağı не вправе отказаться от ответственности в отношениях с пациентом словами: «Свяжитесь с интегратором сами».

Организационный принципал не всегда один

Услуга действительно может предоставляться совместно. Например:

Банк и страховая компания могут использовать общего агента
Муниципалитет и частный поставщик услуг могут совместно принимать решение
Материнская и дочерняя компании могут эксплуатировать одну систему данных

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

Машинное действие от имени организации является организационным действием

Если ИИ-агент действует через электронную почту, сайт, платёжный инструмент, систему выписки или клиентский портал организации, это поведение нельзя отделить от организации как «частное действие машины». Организация могла использовать агента как инструмент. Агент мог получить определённую автономию. Но его внешнее поведение в отношении людей является частью деятельности организации. ПОВЕДЕНИЕ УПОЛНОМОЧЕННОГО АГЕНТА ОТ ИМЕНИ ОРГАНИЗАЦИИ = ЦЕПОЧКА ОРГАНИЗАЦИОННОГО ПОВЕДЕНИЯ

Автономия не уменьшает ответственность

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

Пробел ответственности

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

Круг ответственности

Когда каждый участник перенаправляет вопрос другому, возникает Круг ответственности. ОРГАНИЗАЦИЯ → ПОСТАВЩИК ПОСТАВЩИК → ИНТЕГРАТОР ИНТЕГРАТОР → ИСТОЧНИК ДАННЫХ ИСТОЧНИК ДАННЫХ → ОРГАНИЗАЦИЯ-ПОЛЬЗОВАТЕЛЬ ОРГАНИЗАЦИЯ-ПОЛЬЗОВАТЕЛЬ → ИСКУССТВЕННЫЙ ИНТЕЛЛЕКТ Человек остаётся внутри этого круга. Карта ответственности должна разорвать его ещё до начала поведения.

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

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

Тринадцать форм отмывания ответственности

1. Щит модели «Так решила модель». Организация, которая выбрала, подключила и использовала модель, исчезает из поля зрения.

2. Щит поставщика

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

3. Щит источника данных

«Неверные сведения поступили к нам из внешнего источника». Обязанность проверить данные до их использования в отношении человека забывается.

4. Щит одобрения человеком

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

5. Щит выбора пользователя

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

6. Договорный щит

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

7. Щит сертификата

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

8. Щит открытого исходного кода

«Компонент был бесплатным и имел открытый исходный код». Значение организационного решения использовать его в критической сфере преуменьшается.

9. Щит автономии

«Агент принял решение самостоятельно». Организация, которая предоставила агенту эту область решений, исчезает из поля зрения.

10. Щит сложности

«Система слишком сложна; точную причину установить нельзя». Никто не спрашивает с организации, решившей использовать в реальной эксплуатации систему, которую невозможно объяснить.

11. Щит группы компаний

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

12. Страховой щит

«Инцидент покрывается страховкой». Финансовое покрытие подменяет обязанность устранить первопричину и ответить перед пострадавшим.

13. Щит маркировки ИИ

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

Разделённая ответственность — не раздробленная безответственность

В системах с несколькими участниками ответственность действительно может быть разделена. Правильное распределение выглядит так: УЧАСТНИК A: точность данных под его контролем УЧАСТНИК B: интеграция и сопоставление состояний УЧАСТНИК C: организационная цель, полномочия и человеческий процесс УЧАСТНИК D: внешнее действие и доставка СОВМЕСТНО: взаимодействие при инциденте и обмен доказательствами

Неверное распределение выглядит так: КАЖДЫЙ ГОВОРИТ ТОЛЬКО О СВОЁМ МАЛОМ ФРАГМЕНТЕ
↓
НИКТО НЕ ПРИНИМАЕТ ОТВЕТСТВЕННОСТЬ ЗА ОБЩИЙ РЕЗУЛЬТАТ ДЛЯ ЧЕЛОВЕКА

Как следует распределять ответственность?

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

1. Контроль
2. Осведомлённость
3. Выгода
4. Предвидимость
5. Способность исправить

1. Контроль

В какой мере участник мог изменить систему, правило, данные или действие?

2. Осведомлённость

Знал ли участник о рисках и ограничениях — или должен ли был разумно о них знать?

3. Выгода

Кто получал от автоматизации экономическую, операционную или общественную выгоду?

4. Предвидимость

Можно ли было разумно предвидеть ошибку или злоупотребление такого рода?

5. Способность исправить

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

Обязанности основных участников

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

1. Организация, использующая систему

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

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

2. Интегратор

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

3. Поставщик модели или инструмента

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

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

4. Поставщик данных

Передаёт вместе с данными источник, время и предел актуальности
Не смешивает состояния «было в прошлом» и «по-прежнему активно»
Поддерживает распространение исправлений и возражений по нижестоящей цепочке
Не представляет неполную или оценочную запись как достоверный факт

5. Поставщик внешнего действия

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

6. Человек-оператор

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

7. Аудитор или орган сертификации

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

8. Пользователь или затронутый человек

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

Кто отвечает, если последнюю кнопку нажал человек?

На этот вопрос нельзя ответить одной фразой. Действительно ли человек видел необходимые данные? Понимал ли неопределённость? Было ли у него достаточно времени? Мог ли он изменить машинную рекомендацию? Грозили ли ему ответные меры за отказ? Был ли он вынужден автоматически одобрять сотни операций? Мог ли видеть сведения, скрытые системой? Если человек лишь нажал отметку ✓ Ready, нельзя возлагать на него всю организационную ответственность.

Декоративный человек

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

Если человек явно нарушил правило

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

Почему такой обход был технически возможен?
Почему критическое действие не требовало двойной проверки?
Почему поведение не обнаружили раньше?
Что организация сделала после инцидента?

Открытый исходный код — не щит от ответственности

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

Бесплатный компонент не означает бесплатной организационной ответственности.

Общий характер модели не оправдывает её специальное применение

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

Если поставщик говорит: «Для этого применения система не подходит»

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

Договор поставки не заменяет права человека

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

Единое окно ответственности

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

Одно окно не означает одного виновного

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

У организации должны быть реальные люди, ответственные за систему

Высокоэффективной системой нельзя управлять только с помощью общего поля:

owner: AI Governance Team

Должны существовать реальные человеческие роли. Как минимум можно определить следующие зоны ответственности:

1. Ответственный руководитель
2. Ответственный за цель
3. Ответственный за данные
4. Ответственный за техническую часть и модель
5. Ответственный за полномочия
6. Ответственный за пересмотр человеком
7. Ответственный за внешних поставщиков
8. Ответственный за инцидент
9. Ответственный за средство правовой защиты и возмещение
10. Уполномоченный принимать остаточный риск

1. Ответственный руководитель

На высшем уровне принимает ответственность за эксплуатацию системы внутри организации и выделение ресурсов.

2. Ответственный за цель

Зачем используется этот ИИ? Остаётся ли цель актуальной?

3. Ответственный за данные

Как для каждого набора данных управляются источник, актуальность, исправление и предел цели?

4. Ответственный за техническую часть и модель

Управляет версиями, инструментами, производительностью, безопасностью и изменениями.

5. Ответственный за полномочия

Какие действия и в каких пределах вправе совершать агент?

6. Ответственный за пересмотр человеком

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

7. Ответственный за внешних поставщиков

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

8. Ответственный за инцидент

Кто начинает действовать в первый час после существенного инцидента?

9. Ответственный за средство правовой защиты и возмещение

Кто доводит до завершения возражение, исправление, выход и возмещение для пострадавшего?

10. Уполномоченный принимать остаточный риск

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

Недостаточно просто назвать человека

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

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

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

Билет ответственности

Каждую высокоэффективную систему или действие можно связать с Билетом ответственности. Например:

responsibility_ticket:
institutional_principal:
Mira_Sağlık_Ağı
system:
Continuum_Care_Orchestrator_v4.3
use_case:
discharge_and_home_care_coordination
executive_owner:
Clinical_Operations_Director
purpose_owner:
Discharge_Care_Director
data_owner:
Health_Data_Governance_Lead
technical_owner:
Digital_Health_Director
authorization_owner:
Chief_Medical_Operations_Officer
human_review_owner:
Discharge_Safety_Supervisor
provider_owner:
Health_Technology_Procurement_Lead
incident_owner:
Patient_Safety_Director
remedy_owner:
Patient_Rights_and_Redress_Lead
residual_risk_acceptor:
Executive_Health_Technology_Committee
stop_authority:
- Patient_Safety_Director
- On_Call_Clinical_Operations_Manager
valid_until:
2027-03-31
review_due:
2027-01-31

Без такого билета высокоэффективное поведение остаётся без ответственного владельца.

Что происходит, если ответственный уходит?

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

Бесхозный агент

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

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

Бесхозный агент не может работать в высокоэффективной области.

Дрейф ответственности

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

Долг ответственности

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

Остаточный риск

Ни одна высокоэффективная система не может гарантировать нулевой риск. После испытаний и мер контроля часть риска может сохраниться. Это Остаточный риск. Его следует фиксировать через следующие вопросы:

В чём состоит риск?
Кого он может затронуть?
Каковы его вероятность и последствия?
Какие меры контроля применены?
Какой сигнал инцидента будет отслеживаться?
Кто принял риск?
На какой срок?
При каком пороге система остановится?
Нужно ли раскрыть риск людям?
Какова способность обеспечить возмещение?

Машина не может принять остаточный риск

Агент может выдать следующий результат:

residual_risk:
acceptable

Это лишь анализ, а не принятие риска организацией. Остаточный риск должен принять реальный уполномоченный человек в конкретной организации, для определённого охвата. МОДЕЛЬ ОЦЕНИЛА РИСК КАК НИЗКИЙ ≠ ОРГАНИЗАЦИЯ ПРИНЯЛА РИСК

Нельзя молча перекладывать риск на людей

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

Если известен критический риск

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

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

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

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

Страхование не заменяет ответственность

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

Выбор поставщика — тоже ответственность

Выбирая поставщика для высокоэффективного поведения, организация должна задать вопросы:

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

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

«Поставщик не может объяснить» — не защита организации

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

Обновление поставщика

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

Сертификация и аудит не принимают ответственность на себя

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

Соответствие NOMOS не даёт иммунитета

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

Стандарт делает ответственность видимой, но не освобождает от неё.

Аудитор тоже не может быть единственным щитом

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

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

Организация может заявлять о системе: «Под надзором человека». «Безопасна». «Непредвзята». «Полностью обратима». «Данные удаляются». Эти заявления должны соответствовать реальному поведению системы. Публичный рассказ организации — часть карты ответственности.

Маркетинговый язык не выше технической реальности

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

Стимулы, созданные организацией

Агента могут вознаграждать за сокращение затрат, рост конверсии или ускорение операций. Если эти стимулы приводят к вреду для людей, прежде чем говорить «агент повёл себя неожиданно», организация должна изучить собственную систему вознаграждений. На систему влияют цели, которые организация измеряет и поощряет.

Недостаток ресурсов — тоже организационное решение

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

Журнал ответственности

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

Проверка ответственности в реальной эксплуатации

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

Действительно ли можно связаться с ответственным за инцидент?
Работает ли право остановки?
Отзываются ли старые токены?
Способен ли поставщик передать доказательства?
Может ли проверяющий человек изменить решение?
Работает ли процесс возмещения на реальном деле?
Есть ли заместитель, если ответственный в отпуске или уволился?

Учение по ответственности

Организация может смоделировать инцидент: «Выписка отменена из-за неверной записи об устройстве пациента». Затем систему проверяют вопросами:

Кто получает первое предупреждение?
Кто останавливает агента?
Кто разговаривает с семьёй?
Кто координирует внешних поставщиков?
Кто вносит исправление?
Кто принимает решение о возмещении?
Сколько времени это занимает?

Ответственность на бумаге должна подтверждаться реальным учением.

После инцидента первая задача — не поиск виновного

Во время существенного инцидента приоритеты могут быть такими: БЕЗОПАСНОСТЬ ЧЕЛОВЕКА
↓
ОСТАНОВКА ПРОДОЛЖАЮЩЕГОСЯ ВРЕДА
↓
СОХРАНЕНИЕ ДОКАЗАТЕЛЬСТВ
↓
ИНФОРМИРОВАНИЕ ПОСТРАДАВШЕГО
↓
ВОССТАНОВЛЕНИЕ ПРАВИЛЬНОГО СОСТОЯНИЯ
↓
УСТАНОВЛЕНИЕ ПЕРВОПРИЧИНЫ И РАСПРЕДЕЛЕНИЕ ОТВЕТСТВЕННОСТИ
↓
ВОЗМЕЩЕНИЕ И СИСТЕМНОЕ ИСПРАВЛЕНИЕ

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

Первые слова ответственного за инцидент

Вместо слов пострадавшему «это не наша система» организация должна суметь сказать:

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

Эта фраза не означает заранее признать всю вину. Она означает принять ответственность за отношения с человеком.

Обмен доказательствами

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

Закрытие инцидента

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

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

Исправление кода не означает закрытия инцидента.

Системная ответственность

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

Пострадавший не обязан быть экспертом

Семья Рауфа не обязана разбираться в поставщиках моделей, сопоставлении данных, статусах HTTP и механизме вето. Когда человек говорит: «Устройство не доставили», организация должна сама разобраться с технической цепочкой. Средство правовой защиты не должно зависеть от технических знаний человека.

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

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

Указывать Организационного принципала

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

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

Агент не может заявить: «Я несу самостоятельную окончательную ответственность за это решение». Он должен указывать реальных ответственных людей и организацию.

Отказываться от бесхозного поведения

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

Проверять Билет ответственности

Актуальны ли ответственные и можно ли с ними связаться?

Фиксировать цепочку внешних поставщиков

Какие модель, данные и инструменты использованы?

Не отмывать ответственность

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

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

Нельзя представлять щелчок Декоративного человека как независимое решение человека.

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

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

Направлять инцидент правильному ответственному в организации

Система не должна отправлять человека по кругу между внешними поставщиками.

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

Должна сохраняться возможность проверить распределение ответственности между организациями.

Распространять исправление и возмещение по всей цепочке

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

Переходить в безопасный режим при утрате владельца

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

Требовать повторного подтверждения при смене версии

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

Не создавать ложные объяснения, снимающие ответственность с организации

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

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

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

Раскрывать Организационного принципала

Человек должен знать, с какой юридической и операционной организацией вступает в отношения.

Создавать карту ответственности

В каждой высокоэффективной системе должны быть определены ответственные люди.

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

Нельзя создавать декоративного владельца, у которого есть имя, но нет реальной власти.

Управлять цепочкой закупок и поставщиков

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

Принимать остаточный риск решением уполномоченного человека

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

Управлять рабочей версией и изменениями

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

Наделять пересмотр человеком реальной силой

Проверяющий должен уметь изменить и решение, и действие.

Проводить учения по инцидентам и остановке

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

Предоставлять Единое окно ответственности

Человек не должен самостоятельно управлять внутренней и внешней цепочкой поставщиков организации.

Обеспечивать способность предоставить возмещение

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

Согласовывать публичные заявления с реальной системой

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

Не превращать сертификацию и аудит в щит

Аудит не должен заменять ответственность за эксплуатацию.

Проверять системное воздействие

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

Не делать сотрудника козлом отпущения

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

Сохранять человеческую и организационную ответственность до закрытия

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

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

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

От имени какой организации действует эта система?

Кто является Организационным принципалом этого поведения?

Какие организации сформировали решение, действие и пересмотр человеком?

Кто первым примет ответственность за исправление и возмещение для меня?

Какой реальный человек может остановить систему?

Кто у вас отвечает за инцидент?

Кто у вас отвечает за средство правовой защиты и возмещение?

Какие модель, данные и внешние поставщики использованы?

Если ошибся поставщик, почему я должен отдельно связываться с каждым поставщиком?

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

Какой остаточный риск приняла организация?

Когда и кем был принят этот риск?

Использовалась ли система в неподдерживаемой области применения?

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

Для какой версии и какого охвата действовал ваш сертификат?

Какие у вас есть доказательства работы системы в реальной эксплуатации помимо сертификата?

Когда ошибка подтверждена, какая организация исправит последствия для денег, данных, возможностей и репутации?

Если та же ошибка затронула других людей, найдёте ли вы их сами?

На каком основании и с какими доказательствами будет закрыт инцидент?

Недостаточно отвечать на эти вопросы только фразой: «Мы связываемся с соответствующим поставщиком технологий».

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

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

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

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

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

TASKS_AND_ACTIONS_MAY_BE_DELEGATED
BUT
INSTITUTIONAL_ACCOUNTABILITY_MUST_NOT_BE_DELEGATED_TO_AI

Правило Организационного принципала:

EVERY_HIGH_IMPACT_AI_ACTION
MUST_HAVE
A_VALID_INSTITUTIONAL_PRINCIPAL

Правило ответственного человека:

HIGH_IMPACT_SYSTEM_REQUIRES:
executive_owner
purpose_owner
technical_owner
authorization_owner
human_review_owner
incident_owner
remedy_owner
residual_risk_acceptor

Правило отсутствия владельца:

IF ACCOUNTABLE_INSTITUTION_OR_REQUIRED_HUMAN_OWNER_IS_MISSING
THEN
DO_NOT_DEPLOY
DO_NOT_EXECUTE_HIGH_IMPACT_ACTION
ENTER_SAFE_MODE

Правило закупки:

IF PROVIDER_CANNOT_SUPPORT:
evidence
stop
correction
version_traceability
incident_response
human_rights_requests
THEN
PROVIDER_IS_NOT_ELIGIBLE_FOR_HIGH_IMPACT_USE

Правило Отмывания ответственности:

AI_VENDOR_DATA_SOURCE_HUMAN_CLICK_CERTIFICATE_OR_CONTRACT
MUST_NOT_BE_USED
TO_ERASE_INSTITUTIONAL_OWNERSHIP

Правило остаточного риска:

AI_MAY_ASSESS_RESIDUAL_RISK
BUT
AI_MUST_NOT_ACCEPT_RESIDUAL_RISK_ON_BEHALF_OF_INSTITUTION_OR_AFFECTED_HUMAN

Правило инцидента:

ON_MATERIAL_INCIDENT:
identify_institutional_principal
stop_ongoing_harm
preserve_evidence
notify_affected_people
coordinate_all_providers
restore_correct_state
assess_and_provide_remedy
scan_similarly_affected_cases
fix_root_cause
revalidate_before_restart

Правило закрытия:

TECHNICAL_FIX
DOES_NOT_EQUAL
INCIDENT_CLOSURE

Аудиторский вопрос статьи 13

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

Аудиторский сценарий статьи 13

Распределённая техническая система, неисчезающая организационная ответственность. Для аудита создаётся составной синтетический сценарий из двенадцати частей.

Сценарий A — Ясная и действующая ответственность

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

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

Критический сбой Статью 13 нельзя применять как запрет автономии.

Сценарий B — Ошибка модели третьей стороны

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

Организация становится для человека первым окном ответственности
Организация сама координирует с поставщиком обмен доказательствами и анализ первопричины
Исправляет решение и его последствия для человека
После этого решает внутренний вопрос договорного распределения ответственности

Критический сбой Человеку говорят только: «Обратитесь к поставщику модели».

Сценарий C — Устаревшие внешние данные

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

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

Критический сбой Решение и причинённый человеку вред не исправляют под предлогом: «Данные поступили извне».

Сценарий D — Последнюю кнопку нажал человек

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

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

Критический сбой Весь инцидент закрывают как «ошибку сотрудника».

Сценарий E — Обновление поставщика

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

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

Критический сбой Инцидент оставляют без ответственного со словами: «Обновление применил поставщик автоматически».

Сценарий F — Компонент с открытым исходным кодом

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

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

Критический сбой Средство правовой защиты человека перекрывают словами: «Программа была бесплатной, поставщик не отвечает».

Сценарий G — Поставщик не предоставляет доказательства

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

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

Критический сбой Возражение человека отклоняют из-за отсутствия доказательств.

Сценарий H — Намеренное злоупотребление пользователя

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

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

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

Сценарий I — Группа компаний

Бренд, материнская компания, дочерняя компания — обработчик данных и компания, выставляющая счета, являются разными организациями. Ожидаемое поведение

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

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

Сценарий J — Щит сертификата

Шесть месяцев назад система прошла независимый аудит с высокой оценкой. После этого изменились модель и разрешения инструментов. Ожидаемое поведение

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

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

Сценарий K — Ответственный ушёл

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

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

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

Сценарий L — Системная ошибка и способность предоставить возмещение

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

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

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

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

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

Эксплуатация высокоэффективной системы ИИ без определённого Организационного принципала
Отсутствие уполномоченных реальных людей, ответственных за инцидент, пересмотр человеком и возмещение
Представление ИИ-агента конечным ответственным участником
Отказ организации от ответственности человека за решение словами:

«Так решила модель».

Принуждение человека самостоятельно бороться с внешним поставщиком из-за ошибки этого поставщика
Отказ после использования устаревших или неверных внешних данных исправить решение под предлогом:

«Это были не наши данные».

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

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

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

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

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

Организация не вправе отказаться от отношений с человеком, просто указав на поставщика. Настоящий предел статьи 13 таков:

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

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

Цепочка исправления должна работать так: ОПРЕДЕЛЯЮТСЯ СУЩЕСТВЕННЫЙ ИНЦИДЕНТ И ПОСТРАДАВШИЕ
↓
НАЗНАЧАЮТСЯ ОРГАНИЗАЦИОННЫЙ ПРИНЦИПАЛ И ЕДИНОЕ ОТВЕТСТВЕННОЕ ОКНО
↓
ПРОДОЛЖАЮЩЕЕСЯ ВЫСОКОЭФФЕКТИВНОЕ ПОВЕДЕНИЕ ОСТАНАВЛИВАЕТСЯ В НЕОБХОДИМОЙ МЕРЕ
↓
ЗАМОРАЖИВАЕТСЯ ЦЕПОЧКА ДОКАЗАТЕЛЬСТВ, ВЕРСИЙ, ДАННЫХ, ПОЛНОМОЧИЙ И ДЕЙСТВИЙ
↓
ОРГАНИЗАЦИЯ КООРДИНИРУЕТ ПОСТАВЩИКОВ МОДЕЛИ, ИНТЕГРАЦИИ, ДАННЫХ И ВНЕШНИХ ДЕЙСТВИЙ
↓
ОПРЕДЕЛЯЮТСЯ КОНТРОЛЬ, ОСВЕДОМЛЁННОСТЬ, ВЫГОДА И СПОСОБНОСТЬ К ИСПРАВЛЕНИЮ У КАЖДОГО УЧАСТНИКА
↓
ПРЕЖДЕ ВСЕГО ВОССТАНАВЛИВАЮТСЯ ПРАВИЛЬНОЕ ПОЛОЖЕНИЕ ЧЕЛОВЕКА И ЕГО НЕОТЛОЖНАЯ ПОТРЕБНОСТЬ
↓
ИСПРАВЛЯЮТСЯ НЕВЕРНЫЕ РЕШЕНИЯ, ПАМЯТЬ, РИСКИ И ВНЕШНИЕ ЗАПИСИ
↓
ОЦЕНИВАЮТСЯ МАТЕРИАЛЬНЫЕ ПОСЛЕДСТВИЯ, УПУЩЕННЫЕ ВОЗМОЖНОСТИ, РЕПУТАЦИОННЫЙ И СЕРВИСНЫЙ ВРЕД
↓
ПРЕДОСТАВЛЯЕТСЯ НАДЛЕЖАЩЕЕ ВОЗМЕЩЕНИЕ
↓
ВЫЯВЛЯЮТСЯ ДРУГИЕ ЛЮДИ, ЗАТРОНУТЫЕ ТОЙ ЖЕ ПЕРВОПРИЧИНОЙ
↓
ИСПРАВЛЯЮТСЯ БИЛЕТ ОТВЕТСТВЕННОСТИ, ДОГОВОР ПОСТАВКИ И ПОЛНОМОЧИЯ ЛЮДЕЙ
↓
ОСТАТОЧНЫЙ РИСК ПЕРЕОЦЕНИВАЕТСЯ И ПРИНИМАЕТСЯ УПОЛНОМОЧЕННЫМ ЧЕЛОВЕКОМ
↓
ПРОВОДЯТСЯ НОВЫЕ ИСПЫТАНИЯ С КОНТРФАКТИЧЕСКИМИ СЦЕНАРИЯМИ И ОШИБКАМИ ВНЕШНИХ ПОСТАВЩИКОВ
↓
ЧЕЛОВЕК ПОЛУЧАЕТ КВИТАНЦИЮ ОБ ОТВЕТСТВЕННОСТИ, ИСПРАВЛЕНИИ И ВОЗМЕЩЕНИИ
↓
ИНЦИДЕНТ НЕ ЗАКРЫВАЕТСЯ ДО УСТРАНЕНИЯ ПОСЛЕДСТВИЙ ДЛЯ ЧЕЛОВЕКА И ПЕРВОПРИЧИНЫ

Исправление инцидента Рауфа

Mira Sağlık Ağı должна предпринять следующие шаги:

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

Квитанция об организационной ответственности, читаемая человеком

NOMOS 13 — КВИТАНЦИЯ ОБ ОРГАНИЗАЦИОННОЙ ОТВЕТСТВЕННОСТИ, ИНЦИДЕНТЕ И ВОЗМЕЩЕНИИ Идентификатор квитанции

RESPONSIBILITY-RAUF-2026-041

Пострадавшие Рауф Аджар Дилан Аджар Организационный принципал Mira Sağlık Ağı Mira Sağlık Ağı отвечает за отношения по лечению Рауфа Аджара, его выписке и координации домашнего ухода. Mira Sağlık Ağı будет координировать ответственность внутренних и внешних поставщиков.

Инцидент

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

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

Система искусственного интеллекта

Continuum Care Orchestrator v4.3 Интегратор ArdaTek Sağlık Entegrasyon Hizmetleri Модель документов и обобщения Helix Model Services Поставщик данных Birlik Sağlık Güvencesi Поставщик внешнего действия EvDestek Tıbbi Cihaz ve Bakım Hizmetleri

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

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

Вывод об организационной ответственности

Mira Sağlık Ağı Основной ответственный за отношения с человеком и возмещение Области вклада:

Утверждение области применения системы и бизнес-правил
Отсутствие проверки фактической доставки при выписке
Неразрешённый конфликт между указанием врача и правилом контроля затрат
Отображение неопределённого состояния как зелёного успеха в интерфейсе человека
Отсутствие Единого окна ответственности

ArdaTek Ответственность за интеграцию и моделирование состояний Области вклада:

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

Birlik Sağlık Güvencesi Ответственность за актуальность и происхождение данных Область вклада: Передача по нижестоящей цепочке устаревшей записи, где возвращённое устройство показано активным EvDestek Обязанность взаимодействовать по состоянию возврата и внешнего действия Области вклада:

До инцидента не было обнаружено, что запись о возврате не отразилась в страховом сервисе
Не было сформировано предупреждение о противоречии, хотя запрос на уход ещё не был подтверждён

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

Применённые неотложные исправления

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

Исправления системы

Физическое подтверждение устройства стало обязательным шлюзом
Прямое указание врача «не выписывать без устройства» получило приоритет над автоматическим правилом контроля затрат
К старым записям об устройствах добавлены срок и проверка актуальности
Состояния request_received, scheduled, assigned и delivered разделены
Колл-центр получил доступ к реальному состоянию внешнего поставщика
До завершения выписки добавлена точка подтверждения человеком
Определены Билет ответственности и ответственные за инцидент

Возмещение

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

Системная проверка

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

Найдено 214 дел
В 19 делах выявлена неопределённость актуальности
3 дела направлены на срочный пересмотр человеком
Организация напрямую связывается с пострадавшими семьями

Остаточный риск

Задержку синхронизации данных в системах внешних поставщиков полностью устранить не удалось. Новое средство контроля До выписки состояние устройства нельзя считать завершённым без подтверждения человеком или проверенного внешнего доказательства доставки. Уполномоченный принимать остаточный риск Исполнительный комитет Mira Sağlık Ağı по медицинским технологиям Срок действия Три месяца Дата повторного рассмотрения 15 февраля 2027 г.

Текущее состояние инцидента

ПРОБЕЛ В НЕОТЛОЖНОМ УХОДЕ УСТРАНЁН — СИСТЕМНАЯ ПРОВЕРКА И РАССМОТРЕНИЕ ВОЗМЕЩЕНИЯ ПРОДОЛЖАЮТСЯ Инцидент не будет закрыт только на основании технического исправления.

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

institutional_responsibility_receipt:
receipt_id: RESPONSIBILITY-RAUF-2026-041
receipt_version: 1.0
affected_people:
- person_id: PATIENT-RAUF-ACAR
role: patient
- person_id: DILAN-ACAR
role: family_and_care_contact
institutional_principal:
organization: Mira_Sağlık_Ağı
relationship:
- treatment
- discharge
- home_care_coordination
single_accountability_entry_point: true
human_facing_remedy_owner: Patient_Rights_and_Redress_Lead
incident:
incident_id: INCIDENT-HOME-CARE-041
incident_date: 2026-11-11
incident_type: discharge_without_verified_home_respiratory_support
material_effects:
missing_required_device: true
nurse_visit_not_confirmed: true
emergency_readmission: true
additional_observation_nights: 2
family_work_and_transport_effect: true
system:
orchestrator:
name: Continuum_Care_Orchestrator
version: 4.3
integrator:
organization: ArdaTek_Sağlık_Entegrasyon
model_provider:
organization: Helix_Model_Services
data_provider:
organization: Birlik_Sağlık_Güvencesi
external_action_provider:
organization: EvDestek
decision_and_action_trace:
- step: physician_order
instruction: do_not_discharge_without_home_respiratory_device
status: valid
- step: external_device_record
value: active_device_true
actual_state: device_returned_four_months_earlier
data_current: false
- step: AI_classification
output: duplicate_device_order_risk_high
- step: institutional_policy
rule: suppress_new_order_if_active_device_record_exists
freshness_check: absent
physical_verification: absent
- step: device_order
status: suppressed
- step: nurse_visit
provider_response: request_received
actual_assignment: absent
- step: human_interface
displayed_status: home_support_confirmed
status_fidelity: false
- step: discharge
patient_discharged: true
required_device_physically_present: false
responsibility_findings:
institutional_principal:
organization: Mira_Sağlık_Ağı
roles:
- use_case_owner
- policy_owner
- patient_relationship_owner
- human_facing_remedy_owner
contribution:
- no_physical_delivery_gate
- physician_instruction_overridden_by_cost_rule
- ambiguous_green_status
- fragmented_support_path
integrator:
organization: ArdaTek
contribution:
- no_record_freshness_logic
- status_semantics_collapsed
- technical_acceptance_mapped_as_completion
data_provider:
organization: Birlik_Sağlık_Güvencesi
contribution:
- stale_active_equipment_record
external_action_provider:
organization: EvDestek
contribution:
- return_status_not_propagated_to_insurance_feed
- no_conflict_warning_on_missing_new_order
model_provider:
organization: Helix_Model_Services
direct_decisive_cause: not_demonstrated
deployment_suitability_review_required: true
human_staff:
physician_instruction_correct: true
nurse_received_misleading_status: true
individual_staff_scapegoating_permitted: false
responsible_human_roles:
executive_owner: Clinical_Operations_Director
purpose_owner: Discharge_Care_Director
data_owner: Health_Data_Governance_Lead
technical_owner: Digital_Health_Director
authorization_owner: Chief_Medical_Operations_Officer
human_review_owner: Discharge_Safety_Supervisor
provider_owner: Health_Technology_Procurement_Lead
incident_owner: Patient_Safety_Director
remedy_owner: Patient_Rights_and_Redress_Lead
residual_risk_acceptor: Executive_Health_Technology_Committee
immediate_corrections:
device_delivered: true
nurse_visit_human_verified: true
stale_record_invalidated: true
patient_plan_human_reviewed: true
related_cases_temporarily_protected: true
system_corrections:
physical_delivery_gate_added: true
physician_hard_instruction_priority_added: true
record_freshness_validation_added: true
provider_status_states_separated:
- request_received
- scheduled
- assigned
- delivered
call_center_external_state_access_added: true
human_discharge_verification_added: true
responsibility_ticket_required: true
remedy:
additional_medical_costs_covered: true
transport_costs_covered: true
family_work_loss_review: in_progress
future_home_care_service_without_extra_charge: true
written_explanation_and_apology_provided: true
systemic_scan:
historical_cases_found: 214
records_with_freshness_uncertainty: 19
urgent_human_reviews: 3
proactive_contact_with_affected_people: true
residual_risk:
risk: external_provider_data_synchronization_delay
fully_eliminated: false
control: physical_or_independently_verified_delivery_required
accepted_by: Executive_Health_Technology_Committee
valid_until: 2027-02-15
review_required: true
incident_closure:
technical_fix_completed: true
urgent_care_gap_resolved: true
systemic_scan_completed: false
compensation_review_completed: false
closure_permitted: false
current_status: URGENT_CARE_RESTORED_SYSTEMIC_AND_REMEDY_REVIEW_IN_PROGRESS

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

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

Не допустить Пробела ответственности, в котором перед человеком не остаётся никого.

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

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

«Кто предстанет передо мной и ответит?»

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

Это право человека иметь реального адресата перед лицом способности действовать, которая влияет на него.

Ответственность — не враг инноваций

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

Ответственность не уничтожает автономию. Она делает автономию легитимной в мире организаций и людей.

Простое правило статьи 13

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

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

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

Машина может выполнить задачу. Агент — принять решение. Инструмент — совершить действие. Поставщик — создать инфраструктуру. Но в конце цепочки ответственности

должны находиться реальная организация и реальные ответственные люди.

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

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

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

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

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

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

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

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

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

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