Становой хребет подотчётности: Обеспечение долговременной сохранности алгоритмов в автоматизированном обществе. Часть 4: Рынки, память и машинная логика (3)

(Окончание, предыдущую часть см. https://rusrim.blogspot.com/2026/02/4-2.html ) 

Реконструкция инцидента как метод расследования

Когда на финансовых рынках что-то идёт не так, следователи начинают со сбора свидетельств и доказательств. Они собирают:

• Журналы аудита оперативной деятельности,
  
  
• Отметки времени, с точностью до миллисекунды,
  
  
• Книги заявок / распоряжений,
  
  
• Переписку,
  
  
• Конфигурационные файлы,
  
  
• Проектную документацию,
  
  
• Решения в рамках управления изменениями.

Далее они восстанавливают последовательность событий -  перемещаются назад во времени и воссоздают состояние системы до, во время и после аномалии.

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

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

Почему финансовые рынки раньше осознали проблему

Рынки почувствовали хрупкость автоматизации задолго до того, как это сделало сообщество специалистов по ИИ. Самым известным примером является «Мгновенный крах» (Flash Crash) 2010 года (резкое падение американского рынка акций 6 мая 2010 года, спровоцированное проведением мнимых сделок со срочными биржевыми контрактами путем выставления и молниеносного снятия 19 тысяч заявок на покупку и продажу ценных бумаг объемом до $200 млн с помощью программ высокочастотной торговли. Злоумышленник был изобличён лишь через 5 лет – Н.Х.), но было и бесчисленное множество других, менее значительных инцидентов, в которых автоматизированные стратегии неожиданно делали ситуацию неконтролируемой контроля, или же взаимодействие между системами приводило к непредвиденным последствиям.

Говоря о ранних сбоях на автоматизированных рынках, люди часто высказываются абстрактно. Однако 6 мая 2010 года наступил момент, привлёкший к данной проблеме внимание всего мира – это был так называемый «мгновенный крах». В течение нескольких минут фондовые рынки США пережили ошеломляюще резкое падение, потеряв почти 1 триллион долларов рыночной стоимости, после чего практически мгновенно восстановились. Одни однотипные сделки заключались на сумму в один цент, другие - на 100 тысяч долларов. Рыночные данные рассинхронизировались. Книги заявок опустошались, а затем снова наполнялись с поразительной скоростью.

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

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

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

Регуляторы пришли к простому и глубокому выводу:

• Системы быстрее людей,
  
  
• Люди могут быть не в состоянии вмешаться в режиме реального времени,
  
  
• Мероприятия контроля и надзора после события невозможен в отсутствии памяти,
  
  
• Документальный «след» является единственным способом, обеспечивающим возможность понять действия автоматизированных систем.

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

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

Возвращаясь к современному стратегическому управлению искусственным интеллектом

Если сопоставить финансовое регулирование с Законом Евросоюза об ИИ, то параллели очевидны:

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

Эти два режима [нормативно-правового регулирования – Н.Х.] эволюционировали независимо друг от друга, но их объединяет одна и та же ключевая идея: стратегическое управление опирается на свидетельства / доказательства.

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

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

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

Отсюда становятся понятными дальнейшие шаги:

• В 5-й части будут описаны компоненты «пакета» для обеспечения сохранности алгоритмов (algorithm preservation package);
  
  
• В 6-й части будут рассмотрены экспертиза ценности, виды ценности, установление и отслеживание сроков хранения;
  
  
• В 7-й части речь пойдёт о том, что означает проектирование систем с функцией сохранения памяти по умолчанию.

Финансовые рынки показывают нам конечное состояние: мир, в котором автоматизированные системы управляемы, поскольку обеспечивается сохранение их памяти.

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

Эндрю Поттер (Andrew Potter)

Источник: сайт Substack
https://metaarchivist.substack.com/p/bones-of-accountability-preserving-874 

Порядок информирования ФСБ России о компьютерных атаках и компьютерных инцидентах

ФСБ России приказом от 25 декабря 2025 года №547 утвердила «Порядок информирования ФСБ России о компьютерных атаках и компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов критической информационной инфраструктуры Российской Федерации и иных информационных ресурсов Российской Федерации, принадлежащих органам и организациям, на которые возложены обязанности, предусмотренные частью 4 статьи 9 Федерального закона от 26 июля 2017 г. №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»».

Приказ вступил в силу с 30 января 2026 г.

Субъекты критической информационной инфраструктуры (КИИ) РФ обязаны (п.1):

• Информировать ФСБ России обо всех компьютерных атаках и компьютерных инцидентах;
  
  
• Реагировать на них, и 
  
  
• Принимать меры по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов КИИ, принадлежащих им на праве собственности, аренды или ином законном основании. 

В части информационных ресурсов Российской Федерации, принадлежащих органам и юридическим лицам на праве собственности, аренды или ином законном основании, то их руководители обязаны информировать ФСБ России обо всех компьютерных атаках и компьютерных инцидентах, связанных с функционированием принадлежащих им информационных ресурсов (п.2). Это должны делать руководители:

• Государственных органов (за исключением органов внешней разведки РФ, органов государственной охраны, федерального органа обеспечения мобилизационной подготовки органов государственной власти РФ, федерального органа исполнительной власти, уполномоченного в области обеспечения безопасности критической информационной инфраструктуры РФ);
  
  
• Государственных унитарных предприятий;
  
  
• Государственных учреждений;
  
  
• Государственных фондов;
  
  
• Государственных корпораций (компаний);
  
  
• Иных российских юридических лиц, которые, если иное не предусмотрено международным договором РФ, находятся под контролем Российской Федерации, и (или) субъекта РФ, и (или) контролируемых ими совместно или по отдельности лиц.

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

В случае отсутствия подключения к данной технической инфраструктуре информирование осуществляется посредством почтовой связи или электронной связи по адресам НКЦКИ, указанным на официальном сайте в сети «Интернет» ( www.cert.gov.ru ) (п.2).

Информация о компьютерном инциденте направляется в НКЦКИ (п.3):

• в значимом объекте КИИ - в срок не позднее 3 часов с момента его обнаружения; 
  
  
• в иных объектах КИИ - в срок не позднее 24 часов с момента его обнаружения;
  
  
• на информационном ресурсе Российской Федерации органа (организации) - в срок не позднее 24 часов с момента его обнаружения.

Информация о компьютерной атаке направляется в НКЦКИ:

• проведенной в отношении объекта КИИ или информационного ресурса Российской Федерации органа (организации), в срок не позднее 24 часов с момента обнаружения компьютерной атаки.

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

Для подготовки к реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак субъектом КИИ разрабатывается план реагирования (п.5), который утверждается руководителем (п.6). Копия плана направляется в НКЦКИ.

Проект плана реагирования, содержащий эти положения и проект о внесении изменений в него разрабатываются субъектом КИИ при методическом обеспечении НКЦКИ и до их утверждения направляются на согласование в Центр защиты информации и специальной связи ФСБ России (п.8).

Субъект КИИ не реже одного раза в год обязан организовывать и проводить тренировки по отработке мероприятий плана реагирования. Объем и содержание тренировки определяются субъектом КИИ исходя из мероприятий, содержащихся в плане реагирования (п.10).

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

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

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

Субъект КИИ обязан информировать НКЦКИ в срок не позднее 48 часов после завершения мероприятий по реагированию на компьютерные инциденты и принятию мер по ликвидации последствий компьютерных атак о результатах таких мероприятий (п.14).

Информацию о результатах реагирования на компьютерные инциденты и принятия мер по ликвидации последствий компьютерных атак, связанных с функционированием принадлежащих органам (организациям) информационных ресурсов Российской Федерации, органы (организации) в течение 24 часов с момента окончания мероприятий направляют в НКЦКИ.

Органы (организации) в целях принятия мер по ликвидации последствий компьютерных атак, связанных с функционированием принадлежащих им информационных ресурсов РФ, обязаны (п.16):

• Определить состав подразделений и должностных лиц, ответственных за проведение мероприятий, 
  
  
• Их задачи в рамках принимаемых мер, 
  
  
• Очередность информационных ресурсов РФ (их структурных элементов), в отношении которых будут приниматься меры по ликвидации последствий компьютерных атак, 
  
  
• Перечень мер по восстановлению функционирования информационного ресурса РФ и 
  
  
• Направить указанную информацию в НКЦКИ 

Органы (организации) после ликвидации последствий компьютерных атак и принятия мер по восстановлению функционирования и проверке работоспособности информационных ресурсов РФ обязаны информировать об этом НКЦКИ в течение 24 часов с момента завершения таких мер (п.17).

Мой комментарий: Документ содержит требования к созданию целого ряда документов. Это:

План реагирования на компьютерные инциденты (ПР) – это основной документ, который должен быть разработан (п.5-9 Порядка). В этом документе может быть определен:

• Состав группы реагирования на инциденты с перечислением их ролей и контактов (включая круглосуточные), а также порядок их взаимодействия;
  
  
• Процесс реагирования при обнаружении;
  
  
• Процедура информирования: кто, в каком формате (ссылка на форму), через какой канал, кому (внутри, в НКЦКИ, в Банк России) отправляет уведомление;
  
  
• Восстановление: Приоритеты объектов (как в п.12), процедуры;
  
  
• Завершение: Критерии закрытия инцидента, процедура итогового информирования НКЦКИ (п.14).

Поскольку данный документ требуется согласовывать с ФСБ/Банком России, нужно обязательно сохранять все версии и протоколы согласований.

Документы по проведению тренировок – прежде всего включают утвержденную программу и график тренировок, а также отчет об итогах тренировки, ключевой документ, подтверждающий выполнение п.10 и обосновывающий изменения в Плане реагирования. Все отчеты по тренировкам хранятся для предъявления ФСБ.

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

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

Становой хребет подотчётности: Обеспечение долговременной сохранности алгоритмов в автоматизированном обществе. Часть 4: Рынки, память и машинная логика (2)

(Продолжение, предыдущую часть см. https://rusrim.blogspot.com/2026/02/4-1.html )

Журналы аудита как архитектура для создания и сохранения доказательств

Если в других секторах экономики термин «журнал аудита» (audit trail) используется довольно вольно, то в финансовой сфере он имеет точное значение. Именно архитектура для создания и сохранения доказательств (evidential architecture) обеспечивает регуляторам возможность точно реконструировать действия системы.

На практике это означает:

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

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

Именно поэтому возможность реконструкция истории торгов стала самостоятельным формальным понятием. В 2016 году в Соединенных Штатах Комиссией по торговле товарными фьючерсами (Commodity Futures Trading Commission, CFTC) был предложен проект нормативного акта «Регулирование автоматизированной торговли» (Regulation Automated Trading, Reg AT, см. https://www.federalregister.gov/documents/2016/11/25/2016-27250/regulation-automated-trading ), который прямо потребовал от занимающихся алгоритмической торговлей компаний вести документацию о разработке и тестировании, журналы изменений и дела по контролю и управлению рисками. Несмотря на то, что правила Reg AT так и не вступили в силу в полной мере (В 2020 году CFTC отозвала проект Reg AT и заменила его новым предложением под названием «Принципы оценки рисков электронной торговли» (Electronic Trading Risk Principles) – Н.Х.), его основные идеи закрепились в практике деятельности рынков и перешли в более поздние рекомендации регулирующих органов. Логика документирования сохранилась, пусть даже сами правила Reg AT так и не были утверждены.

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

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

Досье разработчика и след оперативной деятельности

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

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

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

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

Совместно эти два слоя дают возможность регулирующим органам реконструировать как намерения разработчиков алгоритма, так и результаты его работы. Закон Евросоюза об ИИ отражает это разделение посредством разделения субъектов на поставщиков (providers) и внедряющие стороны (deployers). В финансовом регулировании это выражается через понятия «разработчики систем» (system developers) и «инфраструктура для реальной торговли» (live trading infrastructure).

Архитектура та же, лишь названия разные.

(Окончание следует, см. https://rusrim.blogspot.com/2026/02/4-3.html )

Эндрю Поттер (Andrew Potter)

Источник: сайт Substack
https://metaarchivist.substack.com/p/bones-of-accountability-preserving-874 

Как сохранить действительность электронных подписей на долгие годы: Краткое руководство от компании Docbyte

Данная заметка, подготовленная бельгийской компанией Docbyte, была опубликован 27 января 2026 года в социальной сети LinkedIn.

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

Почему важно сохранять действительность электронных подписей?

Электронные подписи являются обязывающими и имеют юридическую силу в Евросоюзе в соответствии с законом eIDAS (это Регламент (ЕС) №2024/1183 Европейского Парламента и Совета, вносящего поправки в Регламент (ЕС) №910/2014 в отношении создания Европейской системы цифровой идентификации» (Regulation (EU) 2024/1183 of the European Parliament and of the Council amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework), см. https://eur-lex.europa.eu/eli/reg/2024/1183/oj  - Н.Х.). Без использования надлежащих методов обеспечения долговременной сохранности действительность подписи может быть со временем поставлена под сомнение по следующим причинам:

• Изменения в технологиях и форматах файлов,
  
  
• Истечение срока действия цифровых сертификатов,
  
  
• Потеря целостности данных.

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

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

Наилучшие практики сохранения действительности электронных подписей

• Использование квалифицированных электронных подписей (Qualified Electronic Signature, QES),
  
  
• Внедрение (или использование сервисов – Н.Х.) квалифицированного электронного архивирования (Qualified Electronic Archiving, QeA),
  
  
• Использование отметок времени,
  
  
• Мониторинг криптографических стандартов,
  
  
• Использование заслуживающих доверия решений для цифрового архивирования, такие как Docbyte Vault ( https://www.docbyte.com/the-docbyte-vault/ ),
  
  
• Регулярная валидация и аудит подписей,
  
  
• Обучение персонала.

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

Полное руководство по сохранению электронных подписей с течением времени от компании Docbyte (How to Preserve Electronic Signatures Over Time: A Complete Guide) доступно по адресу https://www.docbyte.com/how-to-preserve-electronic-signatures/ .

Источник: сайт LinkedIn
https://www.linkedin.com/pulse/how-preserve-electronic-signatures-over-time-quick-guide-docbyte-tukhe/