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

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

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

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

3.1. Стадии жизненного цикла ИИ-системы

Жизненный цикл ИИ-системы описывается в нескольких международных документах, и хотя терминология различается, логика остаётся общей. NIST AI RMF выделяет фазы планирования и проектирования, сбора и обработки данных, построения модели, развёртывания и эксплуатации с мониторингом. ISO/IEC 42001 определяет стадии от проектирования и разработки через верификацию и развёртывание до эксплуатации и вывода из эксплуатации. Совет Европы в рекомендациях по защите данных в LLM-системах описывает пять этапов: предварительное обучение базовой модели, адаптация и дообучение, системная интеграция, развёртывание в продуктивной среде и взаимодействие с конечными пользователями. Организации не обязаны принимать одну из этих моделей буквально, но должны понимать общую логику и адаптировать её к собственному контексту.

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

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

Рисунок 8. Жизненный цикл ИИ-системы: от формирования замысла и подготовки данных до эксплуатации, мониторинга и вывода из использования.

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

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

Третья стадия — разработка и обучение модели. Модель обучается на подготовленных данных, проходит через циклы экспериментов, настройки гиперпараметров и оценки качества. Для организаций, использующих предобученные модели от внешних поставщиков, эта стадия может включать тонкую настройку (fine-tuning) или адаптацию через промпты, а не обучение с нуля. С точки зрения безопасности на этой стадии возникают угрозы компрометации обучающего конвейера, отравления данных, внедрения закладок в модель и утечки обучающих данных через параметры модели. Среда разработки, в которой хранятся данные, промежуточные версии моделей и ключи доступа, часто защищена слабее продуктивных систем, хотя содержит наиболее ценные активы.

Четвёртая стадия — тестирование и валидация. Модель проверяется на соответствие требованиям качества, безопасности, справедливости и устойчивости к враждебным воздействиям. На этой стадии проводится состязательное тестирование ИИ (AI red teaming), тестирование на наличие смещений, проверка устойчивости к адверсариальным атакам и инъекциям, оценка объяснимости результатов. Формулируются приёмочные критерии и принимается решение о готовности системы к развёртыванию. На практике тестирование безопасности ИИ-систем нередко ограничивается проверкой функциональности и точности модели. Проверка устойчивости к атакам, справедливости и поведения в граничных условиях остаётся за пределами стандартных процедур, хотя именно эти аспекты определяют, насколько безопасна система в продуктивной среде.

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

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

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

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

3.2. Участники и их роли на каждой стадии

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

NIST AI RMF определяет несколько категорий участников жизненного цикла ИИ: проектировщики, разработчики, развёртывающие и операторы. ISO/IEC 42001 расширяет этот перечень, включая роли, связанные с человеческим контролем, экспертизой доверия (безопасность, приватность, справедливость), управлением и заинтересованными сторонами. На практике в каждой организации эти роли распределяются по-своему, и один человек может совмещать несколько ролей или, наоборот, одна роль может быть разделена между командами. Важна не конкретная организационная структура, а полнота покрытия: есть ли кто-то, кто отвечает за каждый аспект безопасности на каждой стадии.

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

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

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

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

На стадии тестирования и валидации состав участников расширяется. К разработчикам присоединяются тестировщики, специалисты по состязательному тестированию ИИ (AI red teaming), эксперты по справедливости и объяснимости, аудиторы. Тестирование безопасности ИИ-системы требует компетенций, которых нет в традиционной команде QA. Проверка устойчивости к инъекциям в промпт, оценка поведения при адверсариальных воздействиях, анализ справедливости модели по отношению к разным демографическим группам — всё это специализированные задачи. Если в организации нет собственной экспертизы, на этом этапе привлекаются внешние специалисты. Решение о готовности системы к развёртыванию принимает владелец продукта совместно с руководителем по информационной безопасности (или CISO) и, при необходимости, юристом. Это решение должно быть документировано и основано на результатах тестирования, оценке рисков и анализе соответствия требованиям.

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

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

Сквозная роль, которая проходит через все стадии и заслуживает отдельного упоминания, — это роль владельца рисков ИИ-системы. Этот человек (или роль) отвечает за то, чтобы риски системы были оценены, приняты на осознанном уровне и управлялись на протяжении всего жизненного цикла. В разных организациях эта роль может принадлежать владельцу продукта, CISO, руководителю подразделения или специально назначенному ответственному. Важно одно: если эта роль не определена, ответственность за риски размывается между участниками, и каждый из них считает, что за безопасность отвечает кто-то другой.

3.3. Распределение ответственности: поставщик, разработчик, оператор, пользователь

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

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

CSA AI Controls Matrix (AICM) предлагает развёрнутую модель совместной ответственности для ИИ-систем, выделяя пять типов участников цепочки поставок. Поставщик облачной инфраструктуры (CSP) отвечает за физическую безопасность, вычислительные ресурсы, сетевую инфраструктуру и виртуализацию. Поставщик модели (MP) отвечает за обучение, валидацию, безопасность обучающих данных и целостность модели. Поставщик оркестрированных сервисов (OSP) отвечает за API, управление промптами, оркестрацию моделей и интеграцию компонентов. Поставщик приложения (AP) отвечает за пользовательский интерфейс, контроль входных и выходных данных, ограничение поведения модели на уровне приложения. Заказчик (AIC) отвечает за политики допустимого использования, обучение пользователей, оценку рисков и соответствие требованиям в своей юрисдикции.

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

Рисунок 9. Модель совместной ответственности в цепочке предоставления ИИ-сервисов.

EU AI Act подходит к вопросу ответственности через концепцию ролей: поставщик (provider) и развертывающий (deployer). Поставщик — тот, кто разрабатывает или заказывает разработку ИИ-системы и выводит её на рынок. Развертывающий — тот, кто использует ИИ-систему в своей деятельности. Для систем высокого риска на поставщика ложатся обязательства по управлению рисками, обеспечению качества данных, документированию, прозрачности и пост-рыночному мониторингу. На развёртывающего — обязательства по использованию системы в соответствии с инструкциями, обеспечению человеческого контроля и информированию поставщика о проблемах. Это упрощённая модель по сравнению с AICM, но она имеет юридическую силу и определяет конкретные обязанности с конкретными санкциями за нарушение.