CEN: Начато публичное обсуждение стандарта prEN 9300-230 «LOTAR – Часть 230: Состояние «как построено» / «как сдано в эксплуатацию» / «как поддерживается»»

Как сообщил в начале августа 2026 года сайт Европейского комитета по стандартизации CEN (от фр. Comité Européen de Normalisation) и сайты органов по стандартизации стран Евросоюза, с 17 августа 2026 года начато публичное обсуждение проекта нового европейского стандарта prEN 9300-230 «Аэрокосмическая серия – LOTAR - Обеспечение долговременной сохранности и возможности использования электронной документации на технические продукты, такой как 3D-модели, данные САПР и PDM-систем – Часть 230: Состояние «как построено» /  «как сдано в эксплуатацию» / «как поддерживается»» (Aerospace series - LOTAR - LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data - Part 230: As-built/As-delivered/As-maintained), см. https://standards.cencenelec.eu/... 

Публичное обсуждение документа продлится до 15 октября 2026 года. Есть возможность до 29 сентября 2026 года индивидуально принять участие в публичном обсуждении данного стандарта на сайте Британского института стандартов (BSI) по адресу https://standardsdevelopment.bsigroup.com/projects/2026-02025 (при условии регистрации на сайте). 

Веб-страница публичного обсуждения на сайте BSI

Мой комментарий: Ранее на блоге я уже рассказывала о стандартах семейства LOTAR (от LOng Term Archiving and Retrieval of digital technical product documentation such as 3D, CAD and PDM data within the aerospace industry – «Обеспечение долговременной сохранности и возможности использования электронной документации на технические продукты, такой, как 3D-модели, данные САПР и PDM-систем, в аэрокосмической отрасли»), см. подборку постов https://rusrim.blogspot.com/search/label/LOTAR 

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

Стандарт подготовил комитет по стандартизации при Европейской ассоциации аэрокосмической и оборонной отраслей ASD-STAN (от AeroSpace and Defence Industries Association of Europe – Standardization, https://www.asd-stan.org/ ).

Во вводной части стандарта отмечается:

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

… Общее описание архивирования данных, относящихся к управлению жизненным циклом продукта, дано в стандарте EN 9300-200. Метод валидации свойств, применяемый в отношении этих архивированных данных, описан в стандарте EN 9300-205.

… Данный документ не применяется в отношении создания информационного пакета OAIS/LOTAR. В нём также не рассматриваются распространенные проблемы архивной работы, - такие, как выбор метода архивирования (с использованием «снимков» в определенный момент времени, либо метод инкрементального архивирования; данный выбор делается в ходе внедрения системы архивирования); взаимосвязи между информационными пакетами; или способ выявления надлежащих метаданных для архивного информационного пакета. Для интеграции метаданных управления жизненным циклом продукции (PLM) с другими предметными и общими метаданными см. стандарт EN 9300-021.

Мой комментарий: Здесь упоминаются следующие части стандарта EN 9300 (LOTAR):

• Часть 021 «Метаданные для архивных информационных пакетов» (Metadata for archival packages), см. https://standards.cencenelec.eu/... , а также мой пост http://rusrim.blogspot.com/2026/08/cen-pren-9300-021lotar-021.html 
  
  В данной части специфицированы требования к метаданным в составе архивных пакетов, предназначенных для долговременного архивирования информации о цифровых продуктах.
  
  
• Часть 200 «Общий подход к долговременной архивации и извлечению информации о структуре продукта» (Common concepts for Long term archiving and retrieval of product structure information), см. https://shop.bsigroup.com/ProductDetail?pid=000000000030329131 , а также мой пост http://rusrim.blogspot.com/2018/07/lotar.html 
  
  Данная часть охватывает долговременную архивацию (LTA and R) данных об управления продуктом и соответствующей информацией о взаимосвязанных процессах (например, требования к структуре продукта). 
  
  
• Часть 205 «Валидация структуры продукта» (Product structure validation), см. https://standards.cencenelec.eu/... , а также мой пост http://rusrim.blogspot.com/2026/01/pren-9300-205-lotar.html
  
  В данной части описана рекомендуемая практика валидации «структуры продукта» (принятая в LOTAR стандартизированная структура - т.е. формат сведений о продукте). Целью является валидация «структуры продукта» для данных, полученных, извлеченных или повторно используемых архивом.
  
  
• Часть 210 «Данные об управлении продуктами в представлении «как спроектировано»» (Product management data in an "as designed" view), см. https://standards.cencenelec.eu/... 
  
  Данная часть относится к используемым для сертификации данным о представлении «как спроектировано» и охватывает управленческую информацию; проектную документацию на изделие; управление изменениями; документы; применение метаданных, специфичных для управления данными об изделии (Product Data Management, PDM; см. стандарт EN 9300-021); определение специфичных для управления данными об изделии (PDM) метаданных для архивных информационных пакетов (AIP).

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

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

Данный документ также включает в себя применение метаданных, специфических для управления жизненным циклом продукции (PLM) (см. EN 9300-021), и определяет специфичные для PLM метаданные, используемые для архивных информационных пакетов (AIP).»

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

Европейское предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения 
4. Пояснение к диаграммам
5. Информация об управлении
6. Организация
7. Процесс создания продукта
8. Дополнения «как построено» к проекту продукта
9. Состояние «как поддерживается»
10. Управление изменениями
11. Документация
12. Безопасность доступа
13. Эффективность опций
14. Эффективность
Приложение A (справочное): Метаданные для архивных информационных пакетов
Библиография

Источники: сайт CEN / сайт BSI / сайт эстонского органа по стандартизации
https://standards.cencenelec.eu/ords/f?p=CEN:110:::::FSP_PROJECT,FSP_ORG_ID:81317,6378&cs=190CC7CDE2E449533CA66506F21713DB9 
https://standardsdevelopment.bsigroup.com/projects/2026-02025 
https://komport.evs.ee/Default.aspx?s=standardCommenting&doc=21149 

Судебная практика: Уведомление об увольнении было направлено на электронную почту, не указанную в трудовом договоре, часть 1

В ноябре 2023 года Останкинский районный суд города Москвы рассмотрел гражданское дело № 2-5169/23 (УИН 77RS0019-02-2023-010705-34) по иску гражданина к школе №1220 о восстановлении на работе, взыскании компенсации за время вынужденного прогула и компенсации морального вреда.

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

Суть спора

С июня 2022 года истец в соответствии с трудовым договором работал по совместительству в школе №1220 в должности специалиста. Трудовой договор был заключён на неопределённый срок. В соответствии с трудовом договором, работник обязался дистанционно выполнять все работы, обуславливаемые его должностью, а также устанавливаемыми работодателем трудовыми обязанностями и конкретными заданиями (поручениями), и должностной инструкцией в случае её наличия. 

Стороны согласовали следующий порядок обмена юридически значимыми документами (заявления работника, приказы и иные локальные нормативные акты работодателя, а также другие документы, предусмотренные Трудовым кодексом РФ): документы в электронной форме должны направляться на адрес: 

• работодателя: <Адрес A-1> 
  
  
• работника: <Адрес Б-1>  

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

Приказом работодателя в июле 202 3года действие трудового договора было прекращено, и работник уволен по статье 288 Трудового кодекса РФ в связи с приёмом на работу работника, для которого работа будет основной. Основанием к приказу работодателя было указано уведомление о предстоящем прекращении трудового договора. 

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

Позиция гражданина

Истец считал свое увольнение незаконным по следующим основаниям. 

• В нарушение пункта 7.1 трудового договора скан-копия (не электронный документ) приказа работодателя была направлена ответчиком с непредусмотренного адреса электронной почты: <Адрес Б-2> без использования электронной подписи. 
  
  
• В нарушение части 3 ст. 312.8 Трудового кодекса, ответчик в течение 3 дней со дня издания приказа работодателя не направил истцу по почте заказным письмом с уведомлением оформленную надлежащим образом копию указанного приказа на бумажном носителе. 
  
  
• В нарушение статьи 288 и части 2 статьи 312.3 Трудового кодекса, а даже пункта 7.1 трудового договора. ответчик в письменной форме (в форме электронного документа) не предупредил истца не менее чем за две недели до прекращения трудового договора с ним. 

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

Позиция Останкинского районного суда 

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

14 июля 2023 года ответчик направил истцу уведомление о прекращении трудового договора в электронном виде, что подтверждается скриншотом электронной почты школы. На этом основании суд сделал вывод о том, что согласно приказу, истец был уволен 31 июля 2023 года, соответственно о прекращении трудового договора он был уведомлен в срок, указанный ст. 288 Трудового кодекса РФ, т.е. за две недели.

Суд отметил, что ссылка истца на получение приказа об увольнении с электронного адреса школы, не указанного в трудовом договоре, не может быть принята во внимание, поскольку адрес электронной почты, указанный в п. 7.1 трудового договора, был указан для получения документов от работника, а не для отправления работнику. Электронный адрес <Адрес Б-2> является официальным электронным адресом ответчика, указанным на официальном сайте. Кроме того, о получении истцом приказа об увольнении свидетельствует копия приказа, приложенная к исковому заявлению гражданина.

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

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

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

При этом суд отметил, что при увольнении работника по ст. 288 ТК РФ достижение соглашения между работником и работодателем по вопросу увольнения не требуется. 

Суд пришел к выводу, что увольнение истца было произведено в соответствии с требованиями ст. 288 ТК РФ, а поэтому оснований для признания его незаконным, восстановлении на работе не имеется. 

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

Позиция Судебной коллегии по гражданским делам Московского городского суда

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

Так, из содержания статьи 165.1 Гражданского кодекса РФ следует, что заявления, уведомления, извещения, требования или иные юридически значимые сообщения, с которыми закон или сделка связывает гражданско-правовые последствия для другого лица, влекут для этого лица такие последствия с момента доставки соответствующего сообщения ему или его представителю. Юридически значимое сообщение считается доставленным и в тех случаях, когда оно поступило лицу, которому оно направлено, но по обстоятельствам, зависящим от него, не было ему вручено или адресат не ознакомился с ним (часть 1). Правила статьи 165.1 Гражданского кодекса РФ о юридически значимых сообщениях применяются, если иное не предусмотрено законом или условиями сделки либо не следует из обычая или из практики, установившейся во взаимоотношениях сторон (часть 2).

Соответственно, в данном случае предусмотренный статьей 288 Трудового кодекса РФ двухнедельный срок от уведомления истца до его увольнения, - с учетом получения уведомления на электронную почту, указанную в пункте 7.1 трудового договора, и неполучения почтового уведомления истцом, - свидетельствует о злоупотреблении работником своими правами при увольнении.

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

(Окончание следует)

Источник: сайт Останкинского районного суда / Судебные решения 
https://www.mos-gorsud.ru/rs/ostankinskij/cases/docs/content/a1b587b0-8e15-11ee-abd9-d7d755a2c445 
https://xn--90afdbaav0bd1afy6eub5d.xn--p1ai/decisions/05/a34fd280-094b-11f0-b14f-dd6a5d5aea05.doc 
https://судебныерешения.рф/92669902/extended 
https://судебныерешения.рф/93156867/extended
http://www.mos-gorsud.ru/rs/ostankinskij/services/cases/civil/details/f6ae2d30-a434-11f0-8afb-15d9d4b60a4e?docsDateFrom=08.10.2025&docsDateTo=08.10.2025&formType=fullForm 
https://www.mos-gorsud.ru/rs/ostankinskij/services/cases/civil/details/f6ae2d30-a434-11f0-8afb-15d9d4b60a4e?hearingRangeDateFrom=04.05.2026&hearingRangeDateTo=04.05.2026&formType=fullForm 

США: Национальный институт стандартов и технологий NIST опубликовал для общественного обсуждения «нулевой проект» руководства по документированию ИИ

Данная новость была опубликована в №15 за 2026 год новостного бюллетеня исследовательской группы по ИИ «Аккредитованного комитета по стандартизации X9».

Для справки: Организация «Аккредитованный комитет по стандартизации X9 «Стандарты финансовой отрасли» (Financial Industry Standards)»» - известная также как «комитет X9» – является лидером в разработке национальных и международных стандартов для отрасли финансовых услуг. Комитет X9 также организует работу технического комитета ИСО TC68, публикующего стандарты для глобальной индустрии финансовых услуг.

30 июля 2026 года американский Национальный институт стандартов и технологий (National Institute of Standards and Technology, NIST) опубликовал «первоначальный проект для публичного обсуждения» (initial public draft, IPD) под названием «Руководство и шаблоны для общедоступной документации по ИИ» (Guidance and Templates for Public-Facing AI Documentation). 

Авторы данного документа Разван Амиронесей (Razvan Amironesei) и Джесси Дуниец (Jesse Dunietz) подготовили этот проект в рамках пилотного проекта NIST разработки т.н. «нулевых проектов стандартов ИИ» (об этом проекте см. мой пост https://rusrim.blogspot.com/2026/03/nist-1.html - Н.Х.). 

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

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

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

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

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

Мой комментарий: Документ NIST AI 300-1 ipd «Руководство и шаблоны для общедоступной документации по ИИ» (Guidance and Templates for Public-Facing AI Documentation) объёмом 54 страницы доступен на сайте NIST по адресу https://doi.org/10.6028/NIST.AI.300-1.ipd .

Во вводной части документа отмечается:

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

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

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

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

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

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

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

Введение
1. Область применения
2. Термины и определения 
3. Аспекты потенциальных результатов процесса подготовки общедоступной документации 
4. Рекомендации по процессам и артефактам в рамках подготовки общедоступной документации
5. Шаблоны документации
6. Профили
Приложение A: Профили по умолчанию

Источник: сайт X9 / сайт centerconsulting.com / сайт NIST
https://x9.org/x9ai-study-group-newsletter/ 
https://www.centerconsulting.com/ai-library/milestones/2026-nist-public-facing-ai-documentation-zero-draft 
https://www.nist.gov/artificial-intelligence/nists-ai-standards-zero-drafts-pilot-project-accelerate-standardization 

Жизненный цикл документа - не спецификация программного обеспечения (и путаница в этом вопросе обойдётся Вам в миллионы), часть 2

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

Как решается эта проблема?

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

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

Чтобы ответить на этот вопрос, я использую то, что я называю «матрицей владения документами» (Matriz de Titularidad Documental, MTD): каждый процесс жизненного цикла имеет, согласно архитектуре, своего владельца, и [нежелательная, с точки зрения автора – Н.Х.] зависимость возникает именно в тот момент, когда какая-то система присваивает себе право владения, которое ей не принадлежит.

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

Преимущества «независимой» архитектуры

В числе преимуществ, обеспечиваемой «независимой» архитектурой, можно назвать следующие:

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

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

Давайте поразмышляем

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

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

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

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

Джон Гонсалес (Jhon Alexander González Flórez)

Источник: LinkedIn
https://es.linkedin.com/comm/pulse/el-ciclo-de-vida-documental-es-una-especificaci%C3%B3n-y-te-gonzalez-f--qmrge