суббота, 18 июля 2026 г.

Росстандарт: Опубликован стандарт ГОСТ Р 72664-2026 «Модель качества для систем искусственного интеллекта»

На сайте Федерального агентства по техническому регулированию и метрологии ( http://www.gost.ru/ ) в июньском 2026 года разделе ( https://protect.gost.ru/default.aspx?control=6&month=6&year=2026 ) был выложен новый национальный стандарт ГОСТ Р 72664-2026 (ИСО/МЭК 25059:2023) «Программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модель качества для систем искусственного интеллекта» объёмом 20 страниц, вступающий в силу 01.08.2026 года, см. https://protect.gost.ru/gost/details/aaa722f8-00bd-498b-a667-c3d31f9bf696 .

Стандарт подготовлен Ассоциацией по сертификации «Русский Регистр» на основе выполненного Российским институтом стандартизации» перевода на русский язык международного стандарта ISO/IEC 25059:2023 «Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) – Модель качества для систем искусственного интеллекта» (Software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Quality model for AI systems, см. https://www.iso.org/standard/80655.html и https://www.iso.org/obp/ui/en/#!iso:std:80655:en , а также мой пост http://rusrim.blogspot.com/2023/07/isoiec-250592023.html . Стандарт внесён Техническим комитетом по стандартизации ТК 164 «Искусственный интеллект».

Стандарт заменит предстандарт ПНСТ 842-2023 (ИСО/МЭК 25059:2023) «Программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модель качества для систем искусственного интеллекта» объёмом 20 страниц, действующий до 01.01.2027 года (см. https://protect.gost.ru/gost/details/fc6438b8-1d2d-4027-833b-5e9df0af0cde , а также мой пост http://rusrim.blogspot.com/2023/12/842-2023.html ).

Следует отметить, что Международная организация по стандартизации (ИСО) в настоящее время завершает работу над новой, второй редакцией стандарта в рамках проекта ISO/IEC DIS 25059, см. https://www.iso.org/standard/88234.html и https://www.iso.org/obp/ui/en/#!iso:std:88234:en .

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

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

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

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения
4. Модель качества продукта
5. Модель качества при использовании системы ИИ
Приложение А (справочное): Требования к качеству систем и программного обеспечения SQuaRE
Приложение В (справочное): Производительность
Приложение С (справочное): Сравнение риск-ориентированного подхода с качество-ориентированным подходом и с моделями качества
Приложение ДА (справочное): Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте
Приложение ДБ (справочное): Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта
Библиография

Источник: сайт Росстандарта
https://protect.gost.ru/gost/details/aaa722f8-00bd-498b-a667-c3d31f9bf696 

ИСО и МЭК: Начато публичное обсуждение проекта стандарта ISO/IEC DIS 42102 «Концепция характеризации методов и возможностей систем ИИ»

Сайт Международной организации по стандартизации (ИСО) 15 июня 2026 года сообщил о начале публичного обсуждения проекта стандарта ISO/IEC DIS 42102 «Информационные технологии – Искусственный интеллект – Концепция характеризации методов и возможностей систем ИИ» (Information technology — Artificial intelligence — Framework for characterizing AI system methods and capabilities) объёмом 41 страница основного текста, см. https://www.iso.org/standard/86898.html и https://www.iso.org/obp/ui/en/#!iso:std:86898:en . Публичное обсуждение продлится до середины августа 2026 года.

Над документом работает подкомитет SC42 «Искусственный интеллект» (Artificial intelligence), входящий в состав Объединенного технического комитета JTC1 «Информационные технологии» Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК). 

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


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

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

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

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

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

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

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

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

Предисловие
Введение
1. Область применения
2. Нормативные ссылки
3. Термины и определения 
4. Принципы характеризации систем ИИ на основе методов и возможностей
5. Аспект методов систем ИИ
6. Аспект возможностей систем ИИ
7. Концептуальная структура для характеризации методов и возможностей систем ИИ
Приложение A: Аспекты наблюдения
Приложение B: Применение настоящего документа
Приложение C: Свойства методов машинного обучения
Приложение D: Парадигмы ИИ
Библиография

Источники: сайт ИСО / сайт BSI
https://www.iso.org/standard/86898.html   
https://www.iso.org/obp/ui/en/#!iso:std:86898:en 
https://standardsdevelopment.bsigroup.com/projects/2023-02004 


пятница, 17 июля 2026 г.

Размещение документа в классификационной схеме не означает его понимание

Данный пост колумбийского специалиста Джона Александра Гонсалеса Флореса (Jhon Alexander González Flórez, или Jhon A. Gonzalez F. – на фото), сотрудника управления проектов электронного документооборота в компании Grupo IB Consulting SAS, был опубликован 6 мая 2026 года в социальной сети LinkedIn.

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

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

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

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

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

Проблема заключается в убеждении, что сразу же проведенная классификация равнозначна пониманию документа - а это не одно и то же.

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

Регистрация - это не то же самое, что понимание. И слишком ранняя классификация также является ошибкой.

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

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

На что я в первую очередь хочу обратить внимание


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

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

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

  • аутентичность, подтвержденная усиленной или усиленной квалифицированной электронной подписью, соответствующей таким стандартам, как XAdES, CAdES или PAdES; 

  • его непрерывная цепочка ответственного хранения от момента получения до конечного хранилища; и 

  • его метаданные, касающиеся его создания, передачи и получения, отслеживаемые в соответствии со стандартизированными схемами, такими как «Дублинское ядро» (Dublin Core), PREMIS или профили Соглашения AGN 001/2024 (или соответствующим стандартом или директивой страны происхождения). 

    Мой комментарий: Здесь упоминается Распоряжение Национальных Архивов Колумбии AGN № 001 от 29 февраля 2024 года «Об утверждении Единого соглашения об архивных функциях; об определении технических и правовых критериев его реализации в рамках Колумбийского государства; и об установлении иных положений» (Por el cual se establece el Acuerdo Único de la Función Archivística, se definen los criterios técnicos y jurídicos para su implementación en el Estado Colombiano y se fijan otras disposiciones, https://normativa.archivogeneral.gov.co/acuerdo-no-001-del-2024/ ).
Когда эти доказательства фрагментированы, рассеяны между системой ведения переписки, ERP-системой, системой управления контрактами и облачной платформой департамента, - ни одна из этих систем по отдельности не может обеспечить полноценную документальную доказательную базу. Доказательства существуют, но ни одна система сама по себе не может полностью их реконструировать.

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

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

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

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

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

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

Истинная «цена вопроса» не проявляется в день регистрации документа

«Цена вопроса» проявляется спустя годы, когда учреждение пытается реконструировать электронные документы, доказать аутентичность документов надзорному органу, провести миграцию с одной платформы на другую, провести передачу документов и/или обеспечить их долговременную сохранность в соответствии с такими моделями, как OAIS. Именно тогда становится истинная цена, которую приходится платить за использование зависимых архитектур (arquitecturas acopladas). И к тому времени, в большинстве случаев, будет уже слишком поздно.

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

Это две совершенно разные вещи.

Так что же я на самом деле ставлю под сомнение?

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

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

Вот здесь и начинаются основные институциональные проблемы.

Слово благодарности написавшему мне человеку

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

Я считаю, что именно здесь начинается настоящая ответственная цифровая трансформация.

Техническое примечание: Последствия для долговременной сохранности электронных документов

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

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

Управляет ли Ваша организация управляет документами - или доказательствами? Различие здесь гораздо существеннее, чем Вы думаете. Выскажите своё мнение в комментариях под этих постом или же напишите мне напрямую.

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

Источник: LinkedIn
https://www.linkedin.com/pulse/radicar-es-comprender-jhon-a-gonzalez-f--2fyqe/ 

ФНС: Порядок исчисления сроков исполнения при получении электронных документов от налоговых органов в нерабочее время

Федеральная налоговая служба (ФНС России) в своем письме от 16.06.2026 №БВ-36-8/5146@ в целях обеспечения единообразного применения законодательства Российской Федерации о налогах и сборах по вопросу исчисления сроков исполнения банками обязанности по предоставлению сведений об остатках денежных средств на счетах в соответствии с пунктом 5 статьи 76 Налогового кодекса Российской Федерации (Кодекс) при получении электронных документов налоговых органов в нерабочее время сообщила следующее.

  • В соответствии с пунктом 1 статьи 6.1 Кодекса сроки, установленные законодательством о налогах и сборах, определяются календарной датой, указанием на событие, которое должно неизбежно наступить, или на действие, которое должно быть совершено, либо периодом времени;

  • Согласно пунктам 2 и 6 статьи 6.1 Кодекса течение срока начинается на следующий день после календарной даты или наступления события, которым определено его начало. Срок, определенный днями, исчисляется в рабочих днях, если такой срок не установлен в календарных днях.

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

В соответствии с приказом ФНС России от 13.12.2024 №ЕД-7-8/1140@ банки обеспечивают получение сообщений, содержащих документы налоговых органов, по рабочим дням с 09 часов 00 минут до 17 часов 00 минут по местному времени (в пятницу - до 16 часов 00 минут).

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

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

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

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

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

Мой комментарий: ФНС разъяснила свою позицию по вопросу о том, с какого момента начинается течение срока, отводимого на исполнение требования налоговиков, если электронный документ фактически поступил в банк, но в нерабочее время (ночью, в выходной или праздник).

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

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