Архитектура безопасного ИИ. Риски, управление и защита искусственного интеллекта

5.4. Связь управления ИИ с действующими системами управления организации

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

ISO/IEC 42001 проектировался именно для интеграции. Его структура повторяет гармонизированную структуру международных стандартов менеджмента, общую для ISO 27001, ISO 9001, ISO 22301 и других. Это означает, что организация, уже внедрившая ISO 27001, может расширить существующую систему управления, добавив к ней ИИ-специфические элементы, вместо того чтобы строить отдельную конструкцию. Контекст организации, определённый для ISO 27001, дополняется ИИ-факторами. Оценка рисков расширяется категориями, специфичными для ИИ. Внутренний аудит включает проверку ИИ-систем. Управленческий анализ охватывает результативность управления ИИ наравне с информационной безопасностью.

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

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

ISO/IEC 23894:2023 предоставляет руководство по управлению рисками ИИ, построенное на основе ISO 31000. Стандарт подчёркивает, что организация должна учитывать особенности ИИ при определении контекста, идентификации рисков, их анализе и оценивании. Он также указывает на необходимость привлечения разнообразных экспертов, потому что риски ИИ выходят за пределы компетенции одной специальности. Оценка рисков модели кредитного скоринга требует участия специалиста по машинному обучению, эксперта по справедливости, юриста и представителя бизнеса. Ни один из них по отдельности не покрывает весь спектр.

Управление информационной безопасностью — вторая точка интеграции. ИИ-системы работают на инфраструктуре, которая уже покрыта контролями ISO 27001: управление доступом, шифрование, мониторинг, управление уязвимостями, реагирование на инциденты. Эти контроли применимы к серверам, сетям и хранилищам, на которых работают ИИ-системы. Но к ним нужно добавить контроли, специфичные для ИИ: защиту обучающих данных от отравления, контроль целостности модели, фильтрацию входных и выходных данных, мониторинг поведения модели, управление полномочиями агентов. Организация может включить эти контроли в существующее заявление о применимости (Statement of Applicability) или создать дополнительное приложение, ссылающееся на контроли из Приложения A к ISO/IEC 42001.

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

Управление поставщиками и закупками — четвёртая точка. Организации, которые закупают ИИ-сервисы через API или внедряют платформы оркестрации от сторонних поставщиков, должны включить оценку безопасности ИИ в процесс квалификации поставщиков. Существующие опросные листы для оценки поставщиков, построенные вокруг инфраструктурной безопасности и защиты данных, не покрывают ИИ-специфические вопросы: на каких данных обучена модель, как контролируется справедливость, какие механизмы фильтрации реализованы, как поставщик уведомляет об обновлениях, какие журналы предоставляет. CSA AI Controls Matrix предлагает структуру для оценки поставщиков ИИ-сервисов, включая опросник AI-CAIQ (AI Consensus Assessment Initiative Questionnaire), который организация может использовать или адаптировать к своему контексту.

Управление непрерывностью — пятая точка. Планы непрерывности бизнеса обычно описывают действия при недоступности информационных систем, потере данных или сбое инфраструктуры. Для ИИ-систем к этим сценариям добавляются специфические: недоступность модели из-за сбоя поставщика API, деградация качества ответов из-за дрейфа, компрометация базы знаний RAG, нежелательное поведение агента. Организация должна определить, какие бизнес-процессы зависят от ИИ-систем, и для каждого из них предусмотреть альтернативный режим работы. В некоторых случаях это ручной процесс, который может заменить автоматизированное решение. В других — переключение на резервную модель или резервного поставщика. Включение ИИ-зависимостей в анализ воздействия на бизнес (BIA) — обязательный шаг, который многие организации пока не сделали.

Управление соответствием требованиям — шестая точка. Организации, работающие в регулируемых отраслях, уже ведут учёт применимых требований и контролируют соответствие. С появлением EU AI Act и отраслевых руководств по ИИ этот реестр нужно дополнить. Для каждой ИИ-системы организация должна определить, какие нормативные требования к ней применимы, и отслеживать их выполнение. Это не требует отдельного процесса: расширение существующего реестра требований и включение ИИ-аспектов в программу аудита соответствия интегрирует новые обязательства в действующую систему.

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

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

5.5. Документирование решений и подотчётность

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

ISO/IEC 42001 выделяет документирование как сквозное требование. Организация должна создавать, обновлять и контролировать документированную информацию, необходимую для результативности системы управления ИИ. Стандарт требует документирования политики ИИ, области применения системы управления, результатов оценки рисков и воздействия, целей управления ИИ, решений о применении контролей и обоснования исключений. Но между требованием стандарта и работающей практикой лежит пространство, которое организация должна заполнить сама.

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

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

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

Второй вопрос — в какой форме документировать. Организации, которые уже ведут реестры рисков, журналы изменений и отчёты об инцидентах, могут расширить существующие форматы, добавив ИИ-специфические поля. Для ИИ-систем полезны несколько специализированных артефактов. Карточка модели (model card) фиксирует ключевые характеристики модели: назначение, архитектуру, обучающие данные, метрики качества, известные ограничения, результаты проверки справедливости, условия применения. Карточка системы (system card) расширяет карточку модели до уровня приложения: описывает архитектуру, интеграции, полномочия, ограничения поведения, контроли безопасности. Паспорт данных (datasheet) описывает обучающий набор: источники, состав, процесс подготовки, известные ограничения и смещения. Эти артефакты не требуют создания с нуля; несколько организаций и исследовательских групп предложили шаблоны, которые можно адаптировать.

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

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

Рисунок 15. Интеграция управления ИИ с корпоративным управлением, рисками, безопасностью, приватностью, закупками, разработкой и внутренним аудитом.

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

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

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

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

Источники и дальнейшее чтение к главе 5

— ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system — гармонизированная структура системы управления ИИ (политика, роли, ресурсы, PDCA-цикл), требования к политике ИИ, ролям и ответственности, документированию, механизму сообщения о проблемах.

— Regulation (EU) 2024/1689 (EU AI Act) — требования к управлению рисками для систем высокого риска, запрещённые сценарии (социальный скоринг, манипулятивные системы, биометрическая идентификация в реальном времени), требования к технической документации и хранению журналов.

— ISO/IEC 23894:2023. Information technology — Artificial intelligence — Guidance on risk management — руководство по управлению рисками ИИ на основе ISO 31000, необходимость привлечения разнородных экспертов при оценке риска.

— ISO 31000:2018. Risk management — Guidelines — базовый стандарт управления рисками, на который опирается ISO/IEC 23894.

— Cloud Security Alliance. AI Controls Matrix (AICM) и AI Consensus Assessment Initiative Questionnaire (AI-CAIQ) — структура оценки поставщиков ИИ-сервисов.

— Mitchell M. и др. Model Cards for Model Reporting. FAT* Conference, 2019 — концепция карточки модели.

— Gebru T. и др. Datasheets for Datasets, 2018 (пересмотрено в Communications of the ACM, 2021) — концепция паспорта данных.

Глава 6. Инвентаризация и классификация ИИ-систем

6.1. Реестр ИИ-систем: что учитывать и как вести

ISO/IEC 42001 требует от организации идентифицировать ресурсы, связанные с ИИ-системами, включая вычислительные мощности, данные, модели и человеческие ресурсы. EU AI Act вводит обязательство для поставщиков систем высокого риска регистрировать свои системы в европейской базе данных. Эти требования формируют внешний стимул, но инвентаризация нужна организации прежде всего для собственных целей: невозможно управлять рисками того, чего нет в реестре.

Реестр ИИ-систем — это структурированная запись обо всех ИИ-системах, которые организация разрабатывает, развёртывает, эксплуатирует или использует через внешние сервисы. Он отличается от привычного реестра ИТ-активов тем, что фиксирует не только инфраструктурные компоненты, но и характеристики, специфичные для ИИ: тип модели, происхождение, назначение, обрабатываемые данные, уровень автономности, способ развёртывания и распределение ответственности.

Какие ИИ-системы включать в реестр — первый вопрос, на который организация должна ответить. Очевидный ответ — все. На практике требуется уточнение. Модель машинного обучения, обученная внутри организации и развёрнутая в продуктивной среде, попадает в реестр без сомнений.

Внешний LLM-сервис, вызываемый через API для обработки клиентских обращений, тоже. А как быть с ИИ-функциями, встроенными в закупленное программное обеспечение? С генеративным ИИ, который сотрудники используют через браузер? С моделями, работающими в тестовой среде, но ещё не развёрнутыми в продуктивной? Границу полезно определять через критерий воздействия, установленный в политике ИИ: если система обрабатывает данные организации, влияет на решения, затрагивающие людей, или создаёт обязательства перед регуляторами, она попадает в реестр. Системы в тестовой среде, работающие с синтетическими данными и не связанные с продуктивными процессами, можно учитывать в упрощённом режиме.

Рисунок 16. Пример карточки реестра ИИ-системы: назначение, владелец, данные, модель, поставщики, уровень риска, ограничения и статус оценки.