ГОСТы по ИИ. Разбираю 5 стандартов

С 1 января 2025 года в России уже действует пакет национальных стандартов по искусственному интеллекту.

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

Сначала главное: а ГОСТы вообще обязательны?

Короткий ответ: формально нет.

По 162-ФЗ «О стандартизации» национальные стандарты применяются добровольно. Никто не придёт штрафовать стартап за то, что он не внедрил ГОСТ Р ИСО/МЭК 42001

Но добровольность штука лукавая. Стандарт становится де-факто обязательным двумя путями:

1. Госзаказ. Как только ГОСТ прописан в требованиях закупки по 44-ФЗ или 223-ФЗ — всё, для поставщика он обязателен.

2. Суд. Когда дойдёт до спора «разработчик знал или должен был знать», эксперт откроет именно эти стандарты.

Все пять разработаны техническим комитетом ТК 164 «Искусственный интеллект», утверждены приказами Росстандарта от 28 октября 2024 года, введены с 1 января 2025-го. Все пять являются адаптацией международных ISO/IEC. Причём идентичен оригиналу (IDT) только один, остальные четыре модифицированы (MOD).

1. ГОСТ Р ИСО/МЭК 42001-2024 «Система менеджмента ИИ»

Единственный из пятёрки, идентичный оригиналу (IDT). Построен по гармонизированной структуре систем менеджмента ИСО, той же, что у ISO 9001 и ISO/IEC 27001, только вместо качества или инфобезопасности объектом управления выступает ИИ.

Ядро стандарта не сам текст разделов 4-10 (там стандартная для систем менеджмента логика: контекст → лидерство → планирование → ресурсы → деятельность → оценка → улучшение), а Приложение A с Приложением B. Включают девять доменов мер управления:

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

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

А.4 Ресурсы систем ИИ: задокументировать не только данные и алгоритмы, но и вычислительные ресурсы, включая воздействие использования оборудования на окружающую среду (да, стандарт явно требует учитывать экологический след GPU-кластеров), а также человеческие ресурсы с их компетенциями.

А.5 Оценка воздействия систем ИИ: вероятно, самый содержательный домен. Требует оценивать воздействие системы отдельно на людей и группы (справедливость, подотчётность, прозрачность и объяснимость, защита и конфиденциальность, доступность, права человека с отдельным упоминанием защиты уязвимых групп: детей, инвалидов, пожилых людей) и отдельно на общество в целом (экологическая устойчивость, экономика, госуправление, здоровье и безопасность, культурные нормы).

А.6 Жизненный цикл системы ИИ: требования к каждой стадии от проектирования до эксплуатации. Здесь стандарт прямым текстом называет специфичные для ИИ угрозы безопасности: отравление данных (data poisoning), кража моделей и атаки с инверсией моделей, то есть попытки восстановить обучающие данные из готовой модели. Отдельно требуется вести журналирование событий системы.

А.7 Данные для систем ИИ: сбор, качество, происхождение и подготовка данных. Стандарт явно связывает качество данных со справедливостью системы: если данные смещены, организация обязана вносить коррективы и в модель, и в данные.

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

А.9 Использование систем ИИ: организация должна убедиться, что система используется строго по назначению, задокументированному в А.6.

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

2. ГОСТ Р 71539-2024 «Процессы жизненного цикла системы ИИ»

Модифицированная версия ISO/IEC 5338:2023. Если 42001 это «как управлять ИИ на уровне организации», то 71539 «как провести конкретную ИИ-систему через весь её путь». Системный инжиниринг (в основе логика ISO/IEC/IEEE 15288), расширенный специфичными для ИИ процессами.

Стандарт раскладывает жизненный цикл на 17 технических процессов:

Анализ миссии → определение потребностей заинтересованных сторон → определение системных требований → определение архитектуры → выбор проектных решений → системный анализ → приобретение знаний → инженерия данных для ИИ → реализация (обучение модели) → комплексирование → верификация → перенос в среду эксплуатации → валидация → непрерывная валидация → функционирование → сопровождение → изъятие и списание.

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

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

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

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

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

Что это значит на практике?

Это стандарт для тех, кто строит ИИ, а не дёргает чужой API. 71539 даёт понятийную карту и, что важнее, конкретные технические требования, например, требование автоматического отката при непрерывном обучении для архитектуры MLOps-пайплайна.

3. ГОСТ Р 71540-2024 «Эталонная архитектура инженерии знаний»

Модифицированный ISO/IEC 5392:2024. Самый недооценённый стандарт пакета, пока все увлечены LLM, 71540 говорит про инженерию знаний: онтологии, графы знаний, символьный ИИ. То, что многие поспешили похоронить, а оно вернулось в виде RAG и попыток прикрутить к нейросетям фактологическую дисциплину.

Стандарт задаёт шесть аспектов, важных для заинтересованных сторон инженерии знаний, и по каждому даёт содержательное требование:

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

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

Дальше сама эталонная архитектура в трёх представлениях (пользовательском, функциональном и в архитектуре распространения знаний), а поверх неё девять процессов работы со знаниями, которые стандарт сам описывает как цепочку:

Представление знаний → моделирование знаний → приобретение знаний → хранение знаний → слияние знаний → вычисление знаний → визуализация знаний → сопровождение знаний → обмен знаниями.

4. Семейство ГОСТ Р 71484 «Качество данных (части 1 и 3; всего частей четыре)»

71484 не один стандарт, а серия, адаптация международной ISO/IEC 5259. Философия умещается в старую поговорку: garbage in – garbage out.

Часть 1 (71484.1, MOD ISO/IEC 5259-1)

Здесь не только терминология, но и рабочая 6-стадийная модель жизненного цикла данных и по каждой стадии стандарт даёт конкретное содержание:

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

Стадия 2. Планирование работы с данными: разработать архитектуру данных и оценить трудозатраты на сбор и подготовку.

Стадия 3. Комплектование наборов данных: сбор данных из источников, определённых на предыдущей стадии, с обязательной защитой персональных данных субъектов уже на этом этапе.

Стадия 4. Подготовка наборов данных: трансформация, валидация, очистка, агрегирование, выборка, создание и отбор признаков, разметка.

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

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

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

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

Часть 3 (71484.3, MOD ISO/IEC 5259-3)

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

Управление компетенциями (6.3.4): документировать необходимые навыки, вести учёт квалификации сотрудников, хранить записи об обучении.

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

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

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

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

Как это всё склеивается с законопроектом об ИИ

Закон оперирует резиновыми формулировками: «безопасность модели», «исчерпывающие меры», «моделирование потенциальных рисков», «исключение дискриминации». Сами по себе они не имеют инженерного содержания. И вот сюда встают ГОСТы с конкретными пунктами:

• «Документировать архитектуру, логику и ограничения» – техническая документация системы ИИ из А.6.2.7 (42001) и технические процессы 71539.

• «Исчерпывающие меры» – заявление о применимости мер управления и оценка воздействия из обязательных приложений A и B (42001).

• «Исключить дискриминацию» – требование документировать «нежелательную предвзятость» в спецификации данных (71484.3) и требование к репрезентативности обучающих данных (71484.1), плюс «уменьшение предвзятости» как отдельный аспект в 71540.

• «Безопасность модели» -о специфичные для ИИ угрозы, прямо названные в 42001: отравление данных, кража моделей, атаки с инверсией моделей.

Иными словами: закон задаёт что нужно, а ГОСТы объясняют как это делать и чем потом доказывать, что вы это сделали.

Тревожные звоночки и скрытые риски

1. Четыре из пяти – модифицированные переводы. Идентичен оригиналу только 42001. Остальные модифицированы (MOD): отдельные фразы, значения и ссылки изменены и выделены в тексте курсивом «для учёта особенностей национальной стандартизации». Что именно поменяли, стоит читать внимательно.

2. Стандарты писались до генеративного взрыва. Первоисточники (2022-2024 годы) концептуально во многом про классический ML. Специфика больших фундаментальных моделей, о которых говорит законопроект, в них проработана слабо.

Краткие выводы для тех, кто не любит длинные посты

• Пять стандартов уже действуют с 1 января 2025 года.

• 42001 (единственный идентичный оригиналу) – система менеджмента ИИ, девять обязательных доменов мер управления: политики, внутренняя организация с whistleblower-каналом, ресурсы (включая экологический след GPU), оценка воздействия на людей и общество, жизненный цикл (с явно названными угрозами – отравление данных, кража моделей, инверсия моделей), данные, информация для сторон, использование по назначению, третьи стороны.

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

• 71540 – шесть аспектов инженерии знаний и девять процессов работы со знаниями от представления до обмена.

• 71484.1 – 6-стадийная модель жизненного цикла данных с конкретным содержанием каждой стадии и прямым указанием на риск дискриминации из-за нерепрезентативных данных.

• 71484.3 – 12 разделов требований, включая обязательное документирование «нежелательной предвзятости» в спецификации данных и контроль качества данных в цепочках поставок вплоть до права аудитора на доступ к ресурсам поставщика.

Ещё больше про регулирование ИИ, разборы стандартов и новости индустрии — в моём тг-канале. Первые в ИИ. Ну почти :)

А, пока закон сделает их обязательными? Делитесь в коммент