среда, 6 мая 2026 г.

Право на удаление в европейском законе GDPR о защите ПДн: Убирайте лишнее из оперативной деятельности и храните необходимое в архиве с ограниченным доступом (2)

(Окончание, начало см. https://rusrim.blogspot.com/2026/05/gdpr-1.html )

Что представляет собой архив с ограниченным доступом

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

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

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

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

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

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

  • Строгие контроль и управление доступом (управление доступом на основе ролей и на основе атрибутов),

  • Обеспечение возможности аудита (с экспортом подтверждающих документов),

  • Управление сроками хранения по видам документов (экспертиза ценности),

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

  • Доказательства проведения уничтожения по истечении срока хранения (акт об уничтожении),

  • Возможность извлечения необходимых материалов без восстановления устаревших оперативных систем (сохранение контекста).

Как автоматизировать этот процесс, не создавая беспорядка

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

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

1. Определите категории имеющихся у Вас документов

Для каждой категории определите:

  • назначение архивных документов,

  • правовое основание,

  • необходимые для поиска и извлечения метаданные, 

  • доказательства, которые должны быть сохранены,

  • срок хранения и действия по его истечении,

  • событие-триггер для уничтожения документов.

2. Архивируйте меньше, а не больше

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

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

3. Сделайте свой архив доказательно защитимым

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

Обычно это означает некую комбинацию следующих сведений:

  • манифесты,

  • хеши или иные доказательства целостности,

  • лог-файлы (протоколы) загрузки и экспорта,

  • события, связанные с установлением и отслеживанием сроков хранения,

  • доказательства уничтожения.

4. Автоматизируйте действия по окончания срока хранения

В этом вопросе терпят неудачу многие, во всём остальном неплохие подходы.

Архив не является постоянным оправданием для бессрочного хранения персональных данных. Если срок хранения истекает и не осталось применимых исключений [из требований закона GDPR – Н.Х.], то документ должен быть уничтожен, и само это уничтожение должно быть доказуемо.

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

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

Неправильно спрашивать:

Можем ли мы хранить персональные данные после получения требования об их уничтожении [от субъекта ПДн – Н.Х.]?

Более корректным будет вопрос:

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

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

С чего начать?

Не начинайте со всех документов сразу. Выберите 3-5 категорий документов и тщательно проработайте их. Для каждой из категорий следует подтвердить:

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

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

  • почему эти материалы могут остаться,

  • в течение какого срока,

  • при каких ограничениях доступа,

  • и что произойдёт по окончании срока хранения.

Правильно отвечающие на эти вопросы организации – нередко совсем не те, что располагают самыми модными инструментами. Это те организации, что сначала проделали работу по стратегическому управлению.

Ссылки на законодательство

Основные ссылки: статьи 5, 17 и 32, а также пункт 39 преамбулы закона GDPR.

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

Фредерик Россель (Frederik Rosseel)

Источник: сайт LinkedIn
https://www.linkedin.com/pulse/gdpr-right-erasure-delete-what-you-should-from-keep-must-rosseel-2gfdc/ 

Уточнены «Правила направления документов в уполномоченные на выдачу разрешений на строительство и (или) разрешений на ввод объекта в эксплуатацию»

Правительство Российской Федерации постановлением от 6 апреля 2026 года №376 утвердило изменения в «Правилах направления документов в уполномоченные на выдачу разрешений на строительство и (или) разрешений на ввод объекта в эксплуатацию федеральные органы исполнительной власти, органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления, Государственную корпорацию по атомной энергии «Росатом», Государственную корпорацию по космической деятельности «Роскосмос» в электронной форме», утвержденных постановлением Правительства РФ от 7 октября 2019 г. №1294. Постановление вступило в силу 6 апреля 2026 года.

Признан утратившим силу пункт 3 «Правил»:

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

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

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

Пункт 7 «Правил» дополнен абзацем следующего содержания:

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

Мой комментарий: Постановление вносит два изменения в Правила №1294:

1) Признание утратившим силу пункта 3 (межведомственное взаимодействие):

Было (до 06.04.2026): «Разрешительный орган обязан был самостоятельно запрашивать документы (копии, сведения) в рамках межведомственного взаимодействия, если застройщик их не представил;»

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

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

Федеральный закон от 27.07.2010 №210-ФЗ «Об организации предоставления государственных и муниципальных услуг» включает две статьи, которые регулируют этот вопрос.

  • Статья 7.1 «Требования к межведомственному информационному взаимодействию при предоставлении государственных и муниципальных услуг»

  • Статья 7.2 «Межведомственный запрос о представлении документов и информации, необходимых для предоставления государственных и муниципальных услуг, в рамках межведомственного информационного взаимодействия»

На практике это может привести к несогласованной правоприменительной практике.

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

Для застройщика (юридического или физического лица) это означает, что теперь необходимо подавать полный и самостоятельный пакет документов, предусмотренный ст. 51, 55 Градостроительный кодекс Российской Федерации (ГрК РФ). Не полагаться на то, что орган запросит их сам.

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

2) Теперь физическое лицо - представитель ИП, юрлица или физлица - может подписывать документы при подаче заявления в электронной форме с использованием электронных подписей разных видов.

Формулировка «возможно подписание … УНЭП … при условии организации взаимодействия с такой инфраструктурой с применением … средств защиты информации» выглядит довольно туманной. С моей точки зрения, положение об использовании УНЭП пока неработоспособно «для массового применения».

Источник: Консультант Плюс
https://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=530911


вторник, 5 мая 2026 г.

Право на удаление в европейском законе GDPR о защите ПДн: Убирайте лишнее из оперативной деятельности и храните необходимое в архиве с ограниченным доступом (1)

Данный пост генерального директора бельгийской компании Docbyte Фредерика Росселя (Frederik Rosseel) был опубликован 18 марта 2026 года в социальной сети LinkedIn.

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

Мой комментарий: Речь идёт о европейском законе о защите персональных данных - об «Общих правилах защиты персональных данных» (Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)), см. https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1532348683434&uri=CELEX:02016R0679-20160504 

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

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

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


Это различие имеет большое значение - очень большое.

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

  • то, что по-прежнему необходимо для оперативной работы,

  • то, что необходимо сохранить в качестве доказательств, и

  • то, что просто следует удалить?

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

Право на удаление ПДн не является абсолютным

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

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

  • Те случаи, когда сохранение ПДн необходимо для исполнения законодательно-нормативных требований;

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

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

Именно такой подход является защитимым

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

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

  • или мы удаляем всё,

  • или мы храним всё на всякий случай.

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

  • Сократить или удалить персональные данные из оперативных систем,

  • Сохранять в ином месте только минимально необходимые доказательства,

  • Разместить эти доказательства в архиве с ограниченным доступом и с более строгими мерами контроля и управления,

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

  • Автоматически удалять документы по истечении срока их хранения.

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

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

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


Этот подход гораздо ближе к логике самого закона GDPR.

Закон GDPR построен на идеях ограничения целей обработки, минимизации ПДн ограничении длительности хранения ПДн и обеспечения подотчетности. Это означает, что не следует хранить ПДн в эксплуатационной среде только потому, что они могут когда-нибудь пригодиться. Но это также означает, что не следует уничтожать доказательства, которые по закону Вы по-прежнему обязаны хранить.

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

(Окончание следует, см. http://rusrim.blogspot.com/2026/05/gdpr-2.html )

Фредерик Россель (Frederik Rosseel)

Источник: сайт LinkedIn
https://www.linkedin.com/pulse/gdpr-right-erasure-delete-what-you-should-from-keep-must-rosseel-2gfdc/ 

ИСО и МЭК: Продолжается работа над проектом технических спецификаций в 3-х частях ISO/IEC CD TS 22440 «Искусственный интеллект – Функциональная безопасность и системы ИИ»

Как сообщил сайт Международной организации по стандартизации (ИСО), 10 апреля 2026 года завершилось голосование по «проекту комитета» технических спецификаций в 3-х частях ISO/IEC CD TS 22440 «Искусственный интеллект – Функциональная безопасность и системы ИИ» (Artificial intelligence - Functional safety and AI systems), над которыми работает технический подкомитет ИСО/МЭК JTC1/SC42 «Искусственный интеллект». Можно сказать, что работа над данным проектом уже приближается к завершению.

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

В документе широко используется аббревиатура AI-SCS, означающая «система контроля и управления ИИ, связанной с обеспечением функциональной безопасности» (AI Safety-related Control System). Также широко используется аббревиатура AUL (от Application Usage Level) для обозначения степени критичности ошибок при использовании компоненты программного обеспечения системы ИИ.
 
В аннотации ко всей серии отмечается:

«Целью данной серии технических спецификаций является преодоление разрыва между традиционными практиками обеспечения функциональной безопасности, основанными на существующих стандартах, и уникальными проблемами в области искусственного интеллекта (ИИ). Серия призвана помочь в проектировании продуктов, которые отдают приоритет физической безопасности и предотвращают потенциальный вред как с помощью функциональных возможностей безопасности на основе ИИ, так и с помощью инструментов разработки на основе ИИ. Документы в составе серии могут использоваться при установлении в общих чертах требований по безопасности как для систем безопасности, включающих ИИ-компоненты, так и для инструментов на основе ИИ.

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

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

Данная серия технических спецификаций предлагает всестороннюю концептуальную основу для решения связанных с ИИ уникальных проблем в критически важных для безопасности системах. В этих документах признается необходимость непрерывного проведения оценки и управления на протяжении всего жизненного цикла системы, с учётом таких факторов, как дрейф модели (model drift) и деградация производительности. Эта концептуальная структура использует многофасетный подход, принимая во внимание как технические, так и организационные аспекты разработки и внедрения ИИ.

Концептуальная структура предлагает методологии для:

  • Выявления и классификации специфических ошибок и сбоев ИИ,

  • Оценки их влияния на функции безопасности,

  • Внедрения адекватных мер по снижению рисков, и

  • Непрерывного ведения мониторинга и оценки.

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

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

Если не указано иное, эта серия документов применима ко всем типам технологий ИИ. Она включает в себя конкретные сведения о машинном обучении (МО).»

Серия технических спецификаций ISO/IEC CD TS 22440 состоит из 3 частей:

ISO/IEC CD TS 22440-1 «Искусственный интеллект – Функциональная безопасность и системы ИИ – Часть 1: Требования»
(Artificial intelligence — Functional safety and AI systems - Part 1: Requirements) объёмом 71 страница, см. https://www.iso.org/standard/89535.html

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

Содержание данной части следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Схема классификации систем ИИ и их компонентов
6. Вопросы жизненного цикла системы контроля и управления ИИ, связанной с функциональной безопасностью (AI Safety-related Control System, AI-SCS)
7. Анализ ошибок ИИ
8. Снижение рисков, связанных с ошибками ИИ
9. Тестирование системы контроля и управления ИИ, связанной с функциональной безопасностью (AI Safety-related Control System, AI-SCS)
Приложение A (нормативное): Меры по смягчению рисков, связанных с ошибками ИИ
Приложение B (нормативное): Методы тестирования AI-SCS
Приложение C (нормативное): Программные инструменты на основе ИИ
Приложение D (справочное): Вопросы архитектуры AI-SCS
Библиография

ISO/IEC CD TS 22440-2 «Искусственный интеллект – Функциональная безопасность и системы ИИ – Часть 2: Рекомендации» (Artificial intelligence — Functional safety and AI systems - Part 2: Guidance) объёмом 73 страницы, см. https://www.iso.org/standard/89536.html 

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

Содержание данной части следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Рекомендации по диаграммам архитектуры «степеней использования приложения» (Application Usage Level, AUL) 
6. Рекомендации по вопросам жизненного цикла системы контроля и управления ИИ, связанной с функциональной безопасностью (AI Safety-related Control System, AI-SCS)
7. Рекомендации по анализу ошибок ИИ
8. Рекомендации по смягчению последствий ошибок ИИ
9. Рекомендации по тестированию системы контроля и управления ИИ, связанной с функциональной безопасностью (AI Safety-related Control System, AI-SCS)
Приложение A (справочное): Применимость к программному обеспечению с классом технологии I (Software Technology Class I, SWTC-I) стандарта IEC 61508-3:2010«Функциональная безопасность электрических / электронных / программируемых электронных систем, связанные с безопасностью - Часть 3. Требования к программному обеспечению» (Functional safety of electrical / electronic / programmable electronic safety-related systems - Part 3: Software requirements)
Приложение B (справочное): Возможные процессы и полезные технологии для верификации и валидации 
Приложение C (справочное): Соображения в отношении других стандартов безопасности
Приложение D (справочное): Соображения по компиляторам графов машинного обучения
Приложение E (справочное): Количественная оценка вероятности ошибки для ИИ
Библиография

ISO/IEC CD TS 22440-3 «Искусственный интеллект – Функциональная безопасность и системы ИИ – Часть 3: Примеры применения» (Artificial intelligence — Functional safety and AI systems - Part 3: Examples of application) объёмом 50 страниц, см. https://www.iso.org/standard/89537.html 

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

Содержание данной части следующее:

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Сокращения
5. Введение
6. Система слежения за людьми с помощью ИИ-камеры
7. Нейронная сеть для калибровки гелиостатов на солнечных электростанциях башенного типа
8. Использование инструментов на основе ИИ/машинного обучения в технологиях мониторинга процессов
9. Навигация беспилотных летательных аппаратов в городской среде во время посадки
10. Использование инструментов на основе ИИ/машинного обучения для подтверждения заявлений о безопасности
11. Использование цифрового двойника для анализа безопасности
Библиография

Источник: сайт ИСО
https://www.iso.org/standard/89535.html 
https://www.iso.org/standard/89536.html 
https://www.iso.org/standard/89537.html