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

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

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

5.1. Зачем организации нужно управление ИИ

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

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

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

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

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

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

Рисунок 13. Цикл непрерывного управления ИИ-системой: планирование, реализация, оценка и улучшение.

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

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

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

5.2. Политика ИИ и допустимые сценарии применения

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

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

На практике политика ИИ состоит из нескольких смысловых блоков, каждый из которых отвечает на конкретный вопрос.

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

Второй блок устанавливает допустимые и запрещённые сценарии. Здесь организация проводит границу между тем, что можно делать с ИИ, и тем, что нельзя. EU AI Act задаёт минимальный уровень ограничений: запрещены системы социального скоринга, манипулятивные системы, эксплуатирующие уязвимости людей, биометрическая идентификация в реальном времени в общественных пространствах (с ограниченными исключениями). Организация может расширить этот перечень в соответствии с собственными ценностями и уровнем готовности к риску. Например, запретить использование ИИ для автоматического принятия кадровых решений без участия человека. Или запретить передачу персональных данных клиентов во внешние LLM-сервисы без шифрования и обезличивания. Или ограничить использование генеративного ИИ для создания контента, публикуемого от имени организации, без проверки человеком.

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

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

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

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

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

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

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

5.3. Роли и ответственность: от руководства до владельца модели

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

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

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

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

Центр компетенций по ИИ (AI Center of Excellence) — другая распространённая модель, особенно в организациях с ограниченной экспертизой. Центр аккумулирует знания о технологиях, рисках и лучших практиках, помогает проектным командам проводить оценку рисков, разрабатывает шаблоны и руководства, обучает сотрудников. Он не заменяет распределение ответственности по бизнес-подразделениям, а дополняет его экспертной поддержкой. Преимущество центра компетенций в том, что он создаёт единое пространство знаний. Ограничение в том, что без формальных полномочий он превращается в консультативный орган, рекомендации которого можно проигнорировать.

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

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

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

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

Специалист по защите данных (Data Protection Officer, DPO) участвует в оценке того, какие персональные данные обрабатываются ИИ-системой, на каком правовом основании и с какими мерами защиты. Его роль возрастает при дообучении моделей на корпоративных данных, при развёртывании RAG-систем с доступом к документам, содержащим персональные сведения, и при использовании внешних ИИ-сервисов, через которые данные передаются за пределы организации.

На уровне разработки и эксплуатации ключевые роли включают архитектора ИИ-системы, который проектирует архитектуру с учётом требований безопасности; исследователя данных, который готовит обучающие данные и обучает модели; инженера MLOps/LLMOps, который управляет конвейерами обучения и развёртывания; и оператора, который поддерживает систему в продуктивной среде, настраивает мониторинг и обрабатывает инциденты.