Архитектура безопасного ИИ. Риски, управление и защита искусственного интеллекта
- -
- 100%
- +
На практике организация-заказчик часто оказывается в позиции, где ей нужно управлять рисками, которые порождены решениями, принятыми другими участниками цепочки. Поставщик модели выбрал обучающие данные — заказчик живёт с последствиями этого выбора: смещениями, запомненными фрагментами, правовыми рисками. Поставщик платформы определил архитектуру оркестрации — заказчик наследует её ограничения в области безопасности. Облачный провайдер обновил инфраструктуру — заказчик может не знать, повлияло ли это на поведение модели. При этом поставщики раскрывают свои практики безопасности в ограниченном объёме, и заказчику приходится полагаться на контрактные обязательства, сертификации и самооценки, а не на собственную верификацию.
Ситуация становится ещё сложнее, когда поставщик модели обновляет её без предупреждения. Многие провайдеры LLM через API оставляют за собой право обновлять модель, и условия сервиса часто допускают такие обновления без уведомления заказчика. Модель, которую организация протестировала и одобрила для развёртывания, может измениться, и поведение, которое было проверено, может стать другим. Кто несёт ответственность за последствия? Формально — поставщик, если обновление привело к нарушению заявленных характеристик. На практике — заказчик, потому что именно его клиенты, сотрудники и бизнес-процессы затронуты последствиями.
Отдельного внимания заслуживает ответственность конечного пользователя. В большинстве ИИ-систем пользователь формирует входные данные: текст запроса, загружаемый документ, голосовую команду. Его действия могут быть легитимными, ошибочными или злонамеренными. Пользователь, который вводит в чат-бот персональные данные клиента вопреки политике организации, создаёт риск утечки. Пользователь, который доверяет ответу модели без проверки и принимает на его основе решение с юридическими последствиями, несёт часть ответственности за результат. Организация должна определить, какие действия пользователя допустимы, обучить его работе с ИИ-системой и предусмотреть контроли, ограничивающие передачу чувствительных данных. Перекладывание всей ответственности на пользователя, которого не обучили и не обеспечили инструментами контроля, — управленческий просчёт, а не решение проблемы.
В открытых экосистемах, где модели доступны для свободного скачивания, распределение ответственности приобретает дополнительные нюансы. Организация, загрузившая модель из открытого репозитория, принимает на себя ответственность за всё, что эта модель делает в её среде. Автор модели, опубликовавший её под открытой лицензией, как правило, не несёт юридической ответственности за последствия использования, хотя этот вопрос остаётся предметом правовых дискуссий. Организация не может апеллировать к автору модели, если модель оказалась скомпрометированной, содержит вредоносные закладки или демонстрирует нежелательное поведение. Вся ответственность за проверку, тестирование и безопасную эксплуатацию ложится на того, кто принял решение использовать эту модель.
Практический вывод из этого раздела состоит в следующем. Организация не может полностью делегировать безопасность ИИ-системы поставщикам. Даже при использовании модели через API крупного провайдера организация остаётся ответственной за выбор поставщика, оценку его практик безопасности, определение допустимых сценариев использования, контроль входных и выходных данных, обучение пользователей, мониторинг поведения и реагирование на инциденты. Матрица распределения ответственности, зафиксированная документально и согласованная с каждым поставщиком, является необходимым инструментом. Без неё пробелы неизбежны, и они обнаруживаются в самый неподходящий момент — при расследовании инцидента, запросе регулятора или судебном разбирательстве.
3.4. Границы ответственности организации и модель совместной ответственности
В предыдущем разделе мы рассмотрели, как ответственность распределяется между участниками цепочки поставок. Теперь нужно ответить на вопрос, который стоит перед каждой конкретной организацией: где проходят границы моей ответственности и как мне зафиксировать их так, чтобы не оставалось зон, за которые никто не отвечает?
Ответ зависит от того, какую роль организация занимает в цепочке. Организация, которая обучает модель с нуля, несёт ответственность за весь жизненный цикл: от выбора данных до вывода из эксплуатации. Организация, которая вызывает внешнюю модель через API и встраивает её в своё приложение, отвечает за то, как она использует результаты модели, но не за внутреннее устройство самой модели. Организация, которая предоставляет свой продукт конечным пользователям с ИИ-функциями от стороннего поставщика, может нести ответственность перед своими клиентами за качество и безопасность этих функций, даже если сама их не разрабатывала. Границы ответственности определяются не только технической архитектурой, но и контрактами, регуляторными требованиями и ожиданиями заинтересованных сторон.
Модель совместной ответственности, предложенная CSA AICM, разделяет контроли на три категории по принципу владения. Контроли, полностью принадлежащие одному участнику: физическая безопасность центра обработки данных принадлежит облачному провайдеру, валидация базовой модели — поставщику модели, обучение конечных пользователей — организации-заказчику. Контроли, разделённые между двумя конкретными участниками: например, провайдер инфраструктуры предоставляет безопасную вычислительную среду, а поставщик модели конфигурирует защиту обучающего конвейера на этой инфраструктуре. И контроли, распределённые по всей цепочке: аудит, управление инцидентами, ведение журналов — каждый участник реализует их на своём уровне, и полнота покрытия зависит от координации между всеми.
Именно третья категория создаёт наибольшие сложности. Когда ответственность разделена между пятью участниками, каждый из которых ведёт журналы на своём уровне, расследование инцидента требует сбора данных из всех пяти источников. Если один из участников не предоставляет достаточной детализации или не хранит журналы необходимый срок, цепочка прослеживания прерывается. На практике организация-заказчик должна ещё до начала работы с поставщиком определить, какие данные ей потребуются для расследования инцидента и аудита, и зафиксировать эти требования в договоре.
Распространённая ошибка — считать, что модель совместной ответственности работает симметрично. В облачных сервисах она приблизительно симметрична: провайдер публикует свою часть ответственности, заказчик принимает свою, граница проходит на определённом уровне стека. В ИИ-системах симметрия нарушается. Поставщик модели обладает информацией, недоступной заказчику: на каких данных обучена модель, какие ограничения заложены в её поведение, какие уязвимости обнаружены и исправлены, когда планируется обновление. Заказчик работает с моделью как с чёрным ящиком и вынужден принимать решения о рисках на основе неполной информации. Эта асимметрия делает позицию заказчика уязвимой: он несёт ответственность перед своими пользователями и регуляторами, но не может полностью проверить то, за что отвечает.
Как организации выстроить границы ответственности на практике? Первый шаг — определить свою роль в цепочке для каждой ИИ-системы. Организация может быть заказчиком для одной системы, поставщиком приложения для другой и одновременно оператором для третьей. Каждая роль подразумевает свой набор обязательств. Второй шаг — для каждого внешнего участника зафиксировать, кто за что отвечает. Это управленческая необходимость. Документ может принимать форму матрицы ответственности, приложения к договору или отдельного соглашения об уровне безопасности.
При составлении такой матрицы организации стоит задать поставщику ряд конкретных вопросов. Кто контролирует обучающие данные и какие меры защиты к ним применяются? Как поставщик уведомляет заказчика об обновлении модели и какие гарантии даёт относительно совместимости поведения? Хранятся ли запросы и ответы на стороне поставщика, используются ли они для дообучения, и если да, как заказчик может отказаться? Какие журналы предоставляет поставщик и в каком формате? Какова процедура реагирования на инциденты, и как поставщик взаимодействует с заказчиком при расследовании? Какие сертификации или результаты аудита подтверждают практики безопасности поставщика? Каков порядок действий при обнаружении уязвимости в модели или платформе? Отсутствие ясных ответов на эти вопросы — сигнал того, что распределение ответственности не зафиксировано, и в момент инцидента каждая сторона будет трактовать его в свою пользу.
Особого внимания требуют сценарии, в которых организация встраивает ИИ-возможности в продукт, предоставляемый собственным клиентам. Финтех-организация, которая использует внешнюю модель для оценки кредитоспособности и предлагает этот сервис банкам, оказывается в промежуточной позиции. Для поставщика модели она — заказчик. Для банков — поставщик. Ответственность перед банками и их клиентами не может быть переложена на поставщика базовой модели. Если модель принимает дискриминационное решение, пострадавший заёмщик предъявит претензии банку, банк — финтех-организации, и только она обратится к поставщику модели. Каждое звено цепочки несёт ответственность перед следующим, и эта ответственность должна быть подкреплена контрактными обязательствами, техническими контролями и страхованием.
EU AI Act вводит дополнительный механизм, влияющий на распределение ответственности. Если организация, использующая ИИ-систему в качестве развёртывающего, вносит существенные изменения в её поведение — дообучает модель, меняет назначение системы, интегрирует её в контекст, не предусмотренный поставщиком — она может быть признана поставщиком со всеми вытекающими обязательствами. Это означает, что граница между ролями поставщика и развёртывающего подвижна и зависит от того, какие действия организация совершает с системой. Организация, которая дообучила базовую модель на собственных данных и развернула её для принятия решений в области HR, не может ссылаться на исходного поставщика как на ответственного за поведение модели. Ответственность переходит к ней.
В многоагентных системах распределение ответственности приобретает дополнительную сложность. Когда агент одной организации делегирует задачу агенту другой через протокол A2A, результат действий внешнего агента влияет на процессы первой организации. Если внешний агент вернул некорректные данные и на их основе было принято ошибочное решение, кто несёт ответственность? Организация, чей агент инициировал делегирование? Организация, чей агент выполнил задачу некорректно? Поставщик протокола? Ответы на эти вопросы пока не зафиксированы ни в одном нормативном акте, и организации, внедряющие многоагентные системы, вынуждены выстраивать договорённости самостоятельно, опираясь на общие принципы контрактного права и управления рисками.
Для организации практический вывод состоит в том, что модель совместной ответственности — это не теоретическая конструкция, а рабочий инструмент, который необходимо адаптировать к каждой ИИ-системе и каждому поставщику. Она должна быть зафиксирована документально, согласована всеми участниками и пересматриваться при изменении архитектуры, смене поставщика или обновлении модели. Организация, которая полагается на общие условия сервиса и не задаёт поставщику конкретных вопросов о распределении ответственности, обнаруживает пробелы в самый неудобный момент. А пробелы в ответственности — это пробелы в безопасности.
Источники и дальнейшее чтение к главе 3
— NIST AI Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, январь 2023 — стадии жизненного цикла и категории участников (designers, developers, deployers, operators).
— ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system — стадии от проектирования до вывода из эксплуатации, роли и заинтересованные стороны.
— Council of Europe, Consultative Committee of Convention 108. Draft Guidelines on Privacy and Data Protection in the Context of Large Language Model (LLM) -Based Systems. T-PD (2025) 3, Страсбург, 2 сентября 2025 — пять этапов жизненного цикла LLM (предобучение, дообучение, системная интеграция, развёртывание, взаимодействие с пользователем).
— Cloud Security Alliance. AI Controls Matrix (AICM) — пятиуровневая модель совместной ответственности (CSP, поставщик модели, поставщик оркестрации, поставщик приложения, заказчик).
— AWS Shared Responsibility Model (или аналогичный документ основного облачного провайдера, которым организация пользуется) — как первоисточник модели совместной ответственности для облачных сервисов.
— Regulation (EU) 2024/1689 (EU AI Act) — роли provider/deployer, обязательства для систем высокого риска, механизм признания развёртывающего поставщиком при существенном изменении системы.
Глава 4. Ландшафт рисков и свойства доверия
Три предыдущие главы описали, из чего состоит ИИ-система, какие типы систем существуют, через какие стадии они проходят и кто за них отвечает. Всё это — карта территории. Теперь нужно нанести на эту карту опасности. Прежде чем обсуждать конкретные угрозы, способы защиты и программу внедрения, необходимо выстроить понятийный аппарат: что мы понимаем под риском применительно к ИИ, как соотносятся угроза, уязвимость и ущерб, и какие свойства определяют, заслуживает ли система доверия.
Без общей терминологии разговор о безопасности ИИ быстро превращается в диалог глухих. Специалист по ИБ говорит об уязвимостях и атаках. Разработчик модели говорит о точности и смещениях. Юрист говорит о нарушении прав и несоответствии требованиям. Руководитель говорит о репутации и финансовых потерях. Все они описывают разные грани одного и того же явления, но каждый использует собственный словарь. Эта глава формирует общий язык, который позволит всем участникам организации обсуждать риски ИИ в одной системе координат.
4.1. Понятия риска, угрозы, уязвимости и ущерба в контексте ИИ
В информационной безопасности понятия риска, угрозы, уязвимости и ущерба давно формализованы. Риск — это сочетание вероятности события и его последствий. Угроза — потенциальная причина нежелательного события. Уязвимость — слабость актива или контроля, которую может использовать угроза. Ущерб — негативное последствие реализованного события. Эти определения работают и для ИИ-систем, но их применение требует существенных уточнений, потому что природа компонентов, характер угроз и масштаб последствий в ИИ отличаются от привычных.
Начнём с того, что в традиционной ИБ угрозы, как правило, направлены против конфиденциальности, целостности или доступности информационных активов. Атакующий пытается украсть данные, изменить их или сделать систему недоступной. Для ИИ-систем эта триада сохраняет значение, но к ней добавляются измерения, которые не укладываются в классическую модель. Модель может быть полностью доступна и не скомпрометирована с точки зрения целостности кода, но при этом принимать дискриминационные решения, генерировать опасный контент или раскрывать персональные данные из обучающего набора. Ни одна из этих ситуаций не является нарушением конфиденциальности, целостности или доступности в привычном смысле, но каждая из них причиняет реальный ущерб.
NIST AI RMF расширяет понятие риска для ИИ-систем, определяя его как сочетание вероятности и масштаба негативных последствий, которые могут затронуть людей, организации и экосистемы. Негативные последствия для людей включают ущерб здоровью, безопасности, гражданским правам, экономическим возможностям, достоинству и автономии. Для организации — ущерб операциям, репутации, финансовому положению и юридической позиции. Для экосистемы — нарушение взаимосвязанных систем, рынков, инфраструктуры и окружающей среды. Этот трёхуровневый взгляд на ущерб принципиально шире, чем привычная модель информационной безопасности, и он необходим, потому что ИИ-системы воздействуют на мир за пределами информационной среды организации.
Рисунок 10. От классической триады конфиденциальности, целостности и доступности к расширенному набору свойств доверия ИИ.
Уязвимости ИИ-систем тоже устроены иначе. В традиционном ПО уязвимость — это ошибка в коде, неправильная конфигурация или слабость в протоколе. Её можно обнаружить сканером, описать в базе CVE и устранить патчем. В ИИ-системе многие уязвимости неотделимы от самого принципа работы модели. Способность языковой модели интерпретировать любой текст как инструкцию — не ошибка в коде, а следствие архитектуры. Склонность модели к конфабуляции — не баг, а свойство вероятностной генерации. Чувствительность классификатора к адверсариальным возмущениям — не дефект конкретной реализации, а математическое свойство класса моделей. Эти уязвимости невозможно устранить патчем; их можно только ограничивать архитектурными мерами, мониторингом и процессами.
Из этого следует важное практическое наблюдение: привычная модель управления уязвимостями, в которой уязвимость обнаруживается, классифицируется по критичности и устраняется обновлением, работает для инфраструктурного слоя ИИ-системы, но не для самой модели. Организация может обновить операционную систему сервера инференса и устранить известную уязвимость. Но она не может устранить способность LLM к инъекциям в промпт так же, как устраняет SQL-инъекцию в веб-приложении. Вместо этого она выстраивает слои защиты: фильтрацию входов, ограничение полномочий, валидацию выходов, мониторинг поведения. Управление рисками ИИ ближе к управлению рисками в сложных социотехнических системах, чем к управлению уязвимостями в ПО.
Угрозы ИИ-системам можно структурировать по нескольким осям. По источнику: внешний злоумышленник, внутренний нарушитель, конкурент, активист, исследователь, автоматизированная система. По цели: данные (кража, отравление, подмена), модель (извлечение, компрометация, подмена), приложение (обход ограничений, злоупотребление функциями), инфраструктура (отказ в обслуживании, компрометация среды), люди и процессы (социальная инженерия, обход процедур). По стадии жизненного цикла: угрозы при сборе данных, при обучении, при тестировании, при развёртывании, при эксплуатации. MITRE ATLAS систематизирует тактики и техники атак на ИИ-системы, выстраивая матрицу, аналогичную MITRE ATT&CK для традиционных атак. Эта систематика подробно рассматривается в третьей части книги; здесь важно зафиксировать, что ландшафт угроз ИИ существенно шире, чем привычный периметр информационной безопасности.
Понятие воздействия (impact) в контексте ИИ приобретает особое значение. ISO/IEC 42001 требует от организации проводить оценку воздействия ИИ-системы на людей, группы людей и общество. EU AI Act выстраивает всю систему регулирования на основе уровня риска, который определяется потенциальным воздействием системы на здоровье, безопасность и права человека. Воздействие ИИ-системы может быть прямым (модель отклоняет кредитную заявку) и косвенным (рекомендательная система формирует информационный пузырь, влияющий на взгляды человека). Оно может быть немедленным (блокировка транзакции) и отложенным (накопление смещения в решениях, которое проявляется через месяцы). Оно может затрагивать конкретного человека (отказ в приёме на работу) или целую группу (систематическая недооценка кредитоспособности определённой демографической категории).
Для специалиста по безопасности это означает, что оценка рисков ИИ-системы не может ограничиваться техническими сценариями атак. Она должна включать оценку воздействия на людей, которых затрагивают решения системы. Модель, которая технически защищена от извлечения и отравления, но систематически дискриминирует определённую группу клиентов, создаёт для организации регуляторный, юридический и репутационный риск, который может оказаться более значительным, чем риск кибератаки.
Ещё одна особенность рисков ИИ — их каскадный характер. Инцидент в одном компоненте может распространиться по всей системе. Отравление обучающих данных на стадии подготовки приводит к смещению модели, которое проявляется в ошибочных решениях на стадии эксплуатации и обнаруживается только при аудите или жалобе клиента. Компрометация одного MCP-сервера позволяет внедрить инструкцию, которую агент передаёт другому агенту, и цепочка поражения охватывает несколько систем. Каскадность усложняет как оценку рисков, так и расследование инцидентов: нужно отслеживать причинно-следственные связи через несколько компонентов, стадий и участников.
Для организации, выстраивающей программу безопасности ИИ, из этого раздела следует несколько выводов. Привычная триада конфиденциальности, целостности и доступности необходима, но недостаточна: к ней нужно добавить справедливость, достоверность, подотчётность и безопасность для людей. Управление уязвимостями в классическом смысле применимо к инфраструктуре, но не к свойствам модели: здесь нужны архитектурные ограничения и непрерывный мониторинг. Оценка рисков должна охватывать три уровня последствий: для людей, для организации и для экосистемы. Каскадный характер рисков требует анализа взаимосвязей между компонентами, а не только оценки каждого компонента по отдельности. Именно эти принципы лежат в основе процесса оценки рисков, который мы разберём в седьмой главе.
4.2. Свойства доверия: безопасность, надёжность, устойчивость, справедливость
В предыдущем разделе мы определили, что привычная триада конфиденциальности, целостности и доступности недостаточна для описания рисков ИИ. Модель может быть технически защищена и при этом причинять ущерб: давать опасные рекомендации, дискриминировать определённые группы людей, работать непредсказуемо в условиях, которые не встречались при обучении. Чтобы оценить, заслуживает ли ИИ-система доверия, нужен более широкий набор критериев.
Рисунок 11. Семь характеристик доверия ИИ-систем по NIST AI RMF: валидность и надёжность, безопасность, защищённость и устойчивость, подотчётность и прозрачность, объяснимость и интерпретируемость, защита приватности, справедливость и управление вредоносными смещениями.
NIST AI RMF формулирует семь характеристик доверия к ИИ-системам: достоверность и надёжность, безопасность для людей, защищённость и устойчивость, подотчётность и прозрачность, объяснимость и интерпретируемость, защита приватности и справедливость с управлением вредоносными смещениями. Эти характеристики не существуют изолированно: они пересекаются, усиливают друг друга и иногда вступают в противоречие. Организация, которая управляет только одной из них, упускает системную картину. В этом разделе мы рассмотрим первые четыре свойства; прозрачности, объяснимости и подотчётности посвящён следующий раздел.
Безопасность для людей (safety) — свойство, которое часто путают с защищённостью от кибератак (security), хотя они описывают разные аспекты. Безопасность означает, что система не причиняет вреда людям, обществу и окружающей среде в ходе нормальной работы. ИИ-система может быть полностью защищена от внешних атак и при этом выдавать рекомендации, следование которым приводит к ущербу. Медицинская модель, которая предлагает неверную дозировку лекарства, небезопасна, даже если её инфраструктура защищена по всем стандартам. Автономный агент, который выполняет задачу способом, создающим физическую угрозу для людей, небезопасен, даже если его никто не атаковал.
Безопасность для людей определяется на этапе проектирования и поддерживается на протяжении всего жизненного цикла. Организация должна определить, какие последствия может вызвать ошибочное решение системы, и выстроить ограничения, соразмерные этим последствиям. Для системы, рекомендующей фильмы, цена ошибки — потерянное время зрителя. Для системы, влияющей на медицинский диагноз, цена ошибки может измеряться здоровьем и жизнью. Между этими полюсами лежит широкий спектр, и уровень контролей должен соответствовать уровню потенциального вреда. NIST AI RMF подчёркивает, что система должна допускать безопасное прерывание работы: если её поведение выходит за допустимые границы, должен существовать механизм остановки, не создающий дополнительных рисков.