Запись лекции

Чтобы охватить надежность «воплощенных» ИИ-систем с разных сторон, нужно разобраться в четырех областях:

1. Системная безопасность / теория надежности

2. Кибербезопасность

3. Машинное обучение / искуственный интеллект

4. Человеко-машинное взаимодействие (Human-Computer Interaction, HCI)

Ключевые вопросы:

1. Что такое допустимый/приемлемый риск?

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

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

Люди совершают ошибки, но и компьютеры тоже
Концепты системной безопасности

1. Задача — снижение рисков. Нужны методы...

Определения угроз и рисков
Снижение рисков и валидации принятых мер

2. Технологисекие аспекты

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

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

Анализ рисков
Риск = Частота * Тяжесть_последствий

Просатя таблица рисков 2х2, которую используют для подобного анализа:

1. Низкая частотность × Легкие посоедствия = Низкий риск

2. Высокая частость × Тяжелые последствия = Высокий риск

3. Высокая частость × Легкие посоедствия = Средний риск

4. Низкая частотность × Тяжелые последствия = ???

Для кейса #4 сложно математически рассчитать уровень риска, т. к. тут дело не в сухих цифрах, а в социальной приемлимости.

Safety Integrity Level (SIL) — это уровень полноты безопасности, стандартизированный показатель, который количественно оценивает надёжность систем, предотвращающих аварийные ситуации.

SIL задаёт, насколько вероятно, что система безопасности выполнит требуемую функцию в заданный момент времени — и тем самым предотвратит опасный отказ. Чем выше уровень SIL, тем строже требования к надёжности (в т.ч. технические) и тем ниже допустимая вероятность сбоя.

SIL и требуемые меры проработаны во многих промышленных стандартах, но они только формируются для робототехнических / «вопрощенных» систем.

Вызов №1 — только негативные случаи имеют значение
Метрики надежности могут выглдяеть как:

«99.999.999 vs. 99.999.998 км без инцидентов»
«1 vs. 2 инцедента на 100.000.000 км»
Первый и второй подход к показателям имеют разный акцент. В первом варианте системы практически идентичны, во втором — разница в два раза.

Метрики надежности формируются исходя из второго подхода.

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

Вызов №2 — редкие и тяжкие события
Какой уровень риска у событий с околонулевой вероятностью, но тяжелейшими последствиями?

zero probabilty * infinity cost = ???
Аргументы с т.з. экономики, будут подталкивать оценить риск как низкий. Социальные и медийные аргументы будут подталкивать оценить риск как высокий.

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

Один из ярких инцедентов в 2023г привел к закрытию бизнес-направления (см. дело Cruise https://en.wikipedia.org/wiki/Cruise_(autonomous_vehicle) )

Тем не менее, в 2025-м году General Motors возобонил проект и нанимает команду
https://www.bloomberg.com/news/articles/2025-08-11/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle
https://www.businessinsider.com/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12

Кибербезопасность

1. Целостность и доступность

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

2. Вредоносные ошибки

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

3. Физический доступ к устройству

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

ML

1. Обучается по примерам и отталкивается от статистики, вероятностей, частотности

Модели не закладывают фундаментальные законы работы мира
[прим. АМ] для роботехники разрабатываются специальные модели, которые имеют представление о законах физики и причинно-следственных связей, но на уровне научных исследований
Машинное обучение несовместимо с Vee-моделью создания надежных технических систем.

Тестирование — это не про доказательство корректности работы системы, а про проверку реализованных шагов при проектировании системы и адекватность процесса разработки.

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

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

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

—-

Human & eAI Safety
Человек плохо подходит для рутинной задачи контроля почти идеального автопилота

1. Perception-Response Time (PRT)

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

2. Ирония автоматизации удленяет PRT

больше автоматизации ведет к меньшей практике людьми => во время отказа системы, у оператора может не хватить квалификации для своевременного принятия верного решения
предвзятость в пользу автоматизации (automation bias) — люди склонны доверять решению специализированной системы, а не себе. особенно, если система долгое время работает корректно
чем дольше система работает корректно, тем больше человек ей доверяет и тем сложнее быстро вмешаться, когда что-то идет не так
Ирония: чем эффективнее автоматика тем менее эффективен процесс контроля за ней со стороны людей
Этическая и юридическая проблема

1. Кто отвественен за некорректное поведение eAI системы?

2. Перекладывание отвественности на человека, не делает систему надежнее и безопаснее.

Moral crumple zone («моральная зона смятия») — концепция, описывающая ситуацию, когда человек становится «буфером ответственности» в сбоях сложных автоматизированных или автономных систем.

Суть явления

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

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

Понятие предложил исследователь Мэдлин Клэр Элиш (Madeleine Clare Elish) в работе «Moral Crumple Zones: Cautionary Tales in Human‑Robot Interaction» (2019). Она показала, как медиа и юридические системы часто упрощают причинно‑следственные связи, делая человека «удобным» виновником.

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

1. Ложные срабатывания систем безопасности автомобиля

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

2. Непредсказуемость работы системы

Какие гарантии, что система поведет себя точно так же в такой ситуации? Зачастую поведение недетрменировано, а ситуации хоть чуть-чутьт да различаются.
Сколько раз система должна пройти тестовый сценарий, чтобы убедиться в корректности работы? Хватит ли одного раза? Десяти? Тысячи? Миллиона?

3. Статистический подход при работе с надежностью

Технические метрики для ML-систем в районе 90%-99% это супер-круто
Но в задачах надежности нужны 99.9999999...% . Какие подходы могут добиться этих значений при обучении моделей?

4. «Длинный (бескончный) хвост» редких и необычных случаев

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

Безопасность — это не только про травмы и смерти, но и про неадекватное (рисковое) поведение. Например, Cruise заезжай на стройплощадки и не был готов к ситуациям, когда территория огорена подручными средствами.

Социальные риски из будущего

1. АТ может быть в среднем безопаснее, но иметь явный паттерн рискового поведения. Это ОК или НеОК?

2. АТ приоритезириует безопасность людей в салоне относительно людей на улице.

3. АТ может быть законопослушным, но что если другой участник движения нарушил ПДД и это сподвигает АТ нарушить ПДД, чтобы избежать рисковой ситуации? (механизм компенсации)

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

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

Юридические аспекты
Duty of Care for Human (осторожное поведение / забота)

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

2. Пренебрежение этих норм можно описать как халатное поведение

Duty of Care for Computers

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

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

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

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

Запутывающий слоган
Обратная сторона тезиса «автопилоты спасают жизни». Нужны другие слоганы

1. Чтобы это доказать надо миллиарды киллометров

2. Медийка не даст времени, чтобы это доказать.

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