Архитектура безопасного ИИ. Риски, управление и защита искусственного интеллекта
- -
- 100%
- +
© Гарик Давтян, 2026
ISBN 978-5-0071-0007-6
Создано в интеллектуальной издательской системе Ridero
Предисловие
Я начал работать над этой книгой, когда понял, что безопасность искусственного интеллекта перестала быть темой для узкого круга исследователей. Она стала повседневной задачей для тех, кто отвечает за защиту организаций. За последние несколько лет искусственный интеллект прошёл путь от экспериментов в лабораториях до рабочего инструмента, встроенного в бизнес-процессы. Модели принимают решения по кредитным заявкам. Генеративные системы составляют документы и ведут переписку от имени сотрудников. Автономные агенты выполняют действия в корпоративных системах, вызывая API и обрабатывая чувствительные данные. Это происходит прямо сейчас, в организациях разного масштаба и разной зрелости.
Скорость, с которой организации внедряют ИИ, значительно опережает их готовность управлять рисками этих технологий. Я наблюдаю это в собственной практике и вижу подтверждение в отраслевых исследованиях. Большинство организаций признают необходимость защищать свои ИИ-системы, но не знают, с чего начать. У них нет реестра ИИ-систем. Нет ясности, кто отвечает за безопасность модели и кто принимает решение о допустимом уровне риска. Нет процессов тестирования, мониторинга и реагирования на инциденты, в которых участвует ИИ. Привычные инструменты информационной безопасности покрывают инфраструктуру, сети и приложения, но не учитывают специфику данных, моделей, промптов и автономных агентов.
Проблема ещё и в том, что безопасность ИИ оказалась на стыке нескольких дисциплин. Она требует понимания архитектуры систем машинного обучения и одновременно знания управления рисками, нормативных требований, защиты данных и организационного управления. Специалист по информационной безопасности, который всю карьеру защищал корпоративные сети, сталкивается с незнакомыми концепциями: отравление обучающих данных, уклоняющиеся воздействия (evasion attacks), инъекция промпта, дрейф поведения модели. Специалист по машинному обучению, в свою очередь, редко задумывается о моделировании угроз, управлении доступом для нечеловеческих субъектов или криминалистике инцидентов. Руководитель видит стратегическую возможность в ИИ, но ему не хватает инструментов для принятия обоснованных решений о допустимом уровне риска. Каждый из них владеет частью картины, но полную картину собрать не удаётся.
Эта книга написана для того, чтобы такую картину создать.
Я адресую её руководителям, CISO, архитекторам информационной безопасности, CIO и CTO, специалистам по рискам и соответствию требованиям, владельцам ИИ-продуктов, разработчикам и архитекторам ИИ-систем, специалистам по данным и MLOps, юристам и руководителям подразделений, которые внедряют ИИ в свои процессы. Мне было важно, чтобы текст оставался понятным руководителю и при этом сохранял практическую ценность для технического специалиста. Это непростой баланс, но именно он определяет полезность книги: если руководитель и архитектор говорят на разных языках, безопасность ИИ остаётся набором благих пожеланий.
Слово «архитектура» в названии книги выбрано намеренно. Безопасность ИИ нельзя свести к перечню технических контролей или к набору политик. Она требует целостной системы, которая охватывает управленческие решения, роли, процессы, данные, модели, приложения, инфраструктуру, механизмы контроля, аудита и подотчётности. Архитектура безопасного ИИ — это способ организовать все эти элементы так, чтобы они работали вместе на протяжении всего жизненного цикла системы.
Книга выстроена по логике, которая отражает путь организации. Первая часть формирует основу: состав ИИ-системы, типы технологий, жизненный цикл, свойства доверия. Вторая часть выстраивает управление: политики, инвентаризация, оценка рисков, нормативные требования. Третья часть систематизирует угрозы: от отравления данных до компрометации автономных агентов. Четвёртая часть описывает архитектуру защиты: зоны доверия, защиту данных, управление доступом, безопасность моделей и конвейеров. Пятая часть охватывает безопасную разработку и эксплуатацию: моделирование угроз, тестирование, мониторинг. Шестая часть посвящена реагированию на инциденты и восстановлению. Седьмая часть переводит содержание книги в практическую программу действий с приоритетами на первый год.
Я опирался на международные стандарты и методологии: ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF, NIST AI 600—1, OWASP Top 10 for LLM Applications, MITRE ATLAS, CSA AI Controls Matrix, рекомендации NCSC и CISA по безопасной разработке ИИ, EU AI Act и другие документы. Но эта книга — не пересказ стандартов. Стандарты дают структуру и требования. Книга показывает, как эти требования работают в организации, какие ограничения возникают на практике и какие решения приходится принимать руководителю и архитектору.
Технологии ИИ продолжают развиваться быстро. Модели становятся мощнее, агенты получают больше автономности, мультимодальные системы объединяют текст, изображение, аудио и видео в единый поток обработки. Часть конкретных инструментов и протоколов, упомянутых в книге, может измениться. Но принципы архитектуры безопасности, управления рисками, эшелонированной защиты и человеческого контроля останутся применимыми. Именно поэтому я сосредоточился на принципах и подходах, которые можно адаптировать к новым технологиям, а не на описании текущих версий конкретных продуктов.
У меня нет иллюзий, что одна книга решит все вопросы безопасности ИИ. Но я уверен, что она поможет вам выстроить систему координат: понять, какие активы нуждаются в защите, где возникают угрозы, как распределить ответственность, какие контроли применить и с чего начать. Если после прочтения вы сможете провести оценку рисков для ИИ-системы в своей организации, выстроить архитектуру защиты и сформировать программу первых практических шагов, книга выполнит свою задачу.
Часть I. ИИ-система как объект защиты
Прежде чем защищать ИИ-систему, нужно понять, что именно мы защищаем. Вопрос звучит просто, но на практике ответ на него вызывает затруднения. Руководитель видит ИИ как бизнес-инструмент, который ускоряет принятие решений. Разработчик воспринимает его как модель, обученную на определённых данных и встроенную в приложение. Специалист по информационной безопасности привычно смотрит на инфраструктуру, сети и контроль доступа. Каждый из них прав, но ни одна из этих точек зрения по отдельности не даёт полной картины.
ИИ-система — это не модель и не алгоритм. Это совокупность данных, моделей, приложений, интерфейсов, инструментов, агентов, инфраструктуры, людей и процессов, которые вместе создают ценность для организации. Каждый из этих компонентов несёт собственные риски, и связи между ними порождают риски, которых нет ни у одного компонента в отдельности. Модель, безопасная в лабораторной среде, становится уязвимой, когда получает доступ к корпоративным данным через систему дополненной генерации. Агент, корректно решающий тестовые задачи, может выйти за границы полномочий в продуктивной среде, где ему доступны внешние сервисы и инструменты.
При этом ИИ-системы принципиально отличаются от традиционного программного обеспечения. Их поведение определяется не только кодом, но и данными, на которых обучена модель, и контекстом, в котором она работает. Они могут вести себя по-разному при одинаковых входных данных. Их результаты не всегда воспроизводимы и не всегда объяснимы. Они способны меняться со временем без явного обновления, если изменяются данные или условия среды. Всё это создаёт новый ландшафт рисков, который требует собственного понятийного аппарата и собственных подходов к защите.
Эта часть книги формирует основу, на которой строится всё остальное. Первая глава разбирает анатомию ИИ-системы: из каких компонентов она состоит, какие активы в ней нужно учитывать и где проходят её границы. Вторая глава раскрывает типы ИИ-систем по модальности и технологии: текстовые, визуальные, аудио, видео, мультимодальные, предиктивные. Каждый тип несёт специфические риски, и понимание этих различий определяет выбор мер защиты. Третья глава описывает жизненный цикл ИИ-системы и распределение ответственности между участниками: поставщиками, разработчиками, операторами и пользователями. Четвёртая глава вводит систему понятий для управления рисками и раскрывает свойства, которые формируют доверие к ИИ-системе: безопасность, надёжность, устойчивость, справедливость, прозрачность и подотчётность.
После прочтения этой части вы сможете описать любую ИИ-систему в своей организации как целостный объект управления и защиты: определить её состав, тип, стадию жизненного цикла, участников, активы, границы и применимые свойства доверия. Это та отправная точка, без которой оценка рисков, построение архитектуры защиты и формирование программы безопасности остаются невозможными.
Глава 1. Анатомия ИИ-системы
1.1. Компоненты ИИ-системы: данные, модели, приложения, инфраструктура
Данные
Данные — это исходный материал, из которого ИИ-система извлекает закономерности и на основании которого принимает решения. В традиционном программном обеспечении данные являются объектом обработки. В ИИ-системе они формируют саму логику работы. Модель, обученная на искажённых данных, будет выдавать искажённые результаты, даже если её архитектура и код безупречны.
Рисунок 1. Архитектурная схема ИИ-системы: данные, модель, программные компоненты, инфраструктура, интерфейсы и контуры управления.
В жизненном цикле ИИ-системы данные выполняют разные роли. Обучающие данные используются для тренировки модели и определяют, какие закономерности она усвоит. Данные для тонкой настройки адаптируют предобученную модель к конкретной задаче или области. Оценочные данные применяются для проверки качества модели перед развёртыванием. Контекстные данные подаются модели в момент запроса, например через системы дополненной генерации (RAG), и формируют основу для ответа. Входные данные поступают от пользователей и других систем в ходе повседневной работы. Выходные данные — это результаты работы модели: тексты, классификации, прогнозы, изображения, решения.
Каждая из этих категорий несёт собственные риски. Обучающие данные могут быть отравлены злоумышленником или содержать скрытые смещения. Контекстные данные в RAG-системе могут включать чувствительную информацию, которую модель раскроет в ответе. Входные данные могут содержать инъекции, направленные на изменение поведения модели. Выходные данные могут содержать конфиденциальные фрагменты, извлечённые из обучающего набора. Организация, которая не различает эти категории и не применяет к каждой из них соответствующие меры классификации, контроля доступа и мониторинга, оставляет открытыми сразу несколько направлений атаки.
Модели
Модель — это математическая структура, обученная на данных и способная выполнять задачу: генерировать текст, распознавать изображение, классифицировать транзакцию, прогнозировать спрос. С точки зрения безопасности модель является одновременно активом и потенциальным источником риска.
Как актив модель представляет значительную ценность. Она содержит знания, извлечённые из обучающих данных, и может воплощать месяцы работы и миллионы единиц вычислительных ресурсов. Извлечение модели злоумышленником означает потерю интеллектуальной собственности. Подмена модели приводит к тому, что все последующие решения принимаются на скомпрометированной основе.
Как источник риска модель способна вести себя непредсказуемо. Её поведение определяется обучающими данными и архитектурой, но конкретный результат для конкретного запроса не всегда воспроизводим и не всегда объясним. Модель может уверенно генерировать несуществующие факты. Она может раскрыть фрагменты обучающих данных в своих ответах. Она может изменить поведение после обновления без явного намерения разработчика.
На практике организация работает с моделями разного происхождения. Базовые модели (foundation models) обучаются крупными поставщиками на огромных объёмах данных и предоставляются через API или для локального развёртывания. Дообученные модели адаптируются к конкретной задаче на корпоративных данных. Собственные модели обучаются организацией с нуля. Каждый из этих вариантов влияет на профиль риска: при использовании внешней модели через API организация не контролирует её обучающие данные, архитектуру и поведение при обновлении. При локальном развёртывании сторонней модели она принимает на себя ответственность за среду выполнения и контроль доступа. При собственной разработке прибавляется ответственность за весь конвейер обучения и качество данных.
Приложения
Модель сама по себе не взаимодействует с пользователем и не выполняет бизнес-задачу. Это делает приложение — программный слой, который связывает модель с внешним миром. Приложение принимает запросы, формирует промпты, вызывает модель, обрабатывает результаты, передаёт их пользователю или другой системе. В генеративных ИИ-системах этот слой включает оркестрацию: управление контекстом, обращение к базам знаний, вызов внешних инструментов, цепочки рассуждений.
Приложение определяет, насколько опасным может быть результат работы модели. Одна и та же модель, отвечающая на вопросы в изолированном интерфейсе без доступа к корпоративным системам, представляет одну степень риска. Та же модель, интегрированная в рабочий процесс с правом записи в базу данных, отправки сообщений и вызова API, представляет принципиально иную. Именно на уровне приложения формируются полномочия модели: к каким данным она имеет доступ, какие действия способна выполнить, какие ограничения наложены на её поведение.
С точки зрения безопасности приложение — это пространство, где пересекаются традиционные уязвимости программного обеспечения и специфические риски ИИ. Инъекции в промпты проходят через приложение. Небезопасная обработка результатов модели происходит в приложении. Утечка системного промпта, раскрытие чувствительных данных, передача избыточных полномочий агенту — всё это вопросы архитектуры и логики приложения. Организация, которая сосредоточена исключительно на модели и не уделяет внимания приложению, упускает одну из самых широких поверхностей атаки.
Инфраструктура
Под инфраструктурой ИИ-системы понимается всё, что обеспечивает её работу на физическом и программном уровне: вычислительные ресурсы, хранилища данных, сети, среды выполнения, системы оркестрации контейнеров, средства мониторинга. Для обучения моделей требуются значительные вычислительные мощности: графические процессоры, тензорные процессоры, специализированные ускорители. Для продуктивной эксплуатации нужны среды инференса, балансировщики нагрузки, системы очередей. Для хранения данных и моделей используются объектные хранилища, векторные базы данных, реестры артефактов.
Инфраструктура ИИ может размещаться в публичном облаке, в частном облаке, на локальных серверах или в гибридной конфигурации. Каждый вариант определяет распределение ответственности между организацией и поставщиком. В публичном облаке поставщик отвечает за физическую безопасность, виртуализацию и часть программного стека, а организация — за конфигурацию, управление доступом, шифрование данных и безопасность приложений. В локальной инфраструктуре вся ответственность лежит на организации. В гибридных сценариях границы становятся сложнее, и без чёткого документирования распределения ответственности возникают зоны, которые не контролирует никто.
Существенная особенность инфраструктуры ИИ — разделение сред. Среда обучения, где модель тренируется на больших объёмах данных, обычно отличается от среды инференса, где модель обрабатывает запросы пользователей. Среда разработки, где исследователи экспериментируют с моделями и данными, часто защищена слабее продуктивных систем. Между тем именно в среде разработки сосредоточены ценные активы: обучающие данные, промежуточные версии моделей, ключи доступа к хранилищам и API. Компрометация этой среды может привести к отравлению данных, подмене модели или утечке интеллектуальной собственности задолго до того, как система попадёт в продуктивную эксплуатацию.
Ни один из четырёх компонентов не существует изолированно. Данные питают модель. Модель встраивается в приложение. Приложение работает на инфраструктуре. Изменение в одном компоненте отражается на остальных. Обновление обучающих данных меняет поведение модели. Новая версия модели требует пересмотра логики приложения. Миграция инфраструктуры из локальной среды в облако перестраивает модель доступа и распределение ответственности.
Для специалиста по безопасности это означает, что защита одного компонента без учёта остальных недостаточна. Шифрование данных в хранилище не спасёт от утечки через ответы модели. Контроль доступа к API приложения не предотвратит компрометацию обучающего конвейера. Защита инфраструктуры не снимет проблему избыточных полномочий агента. Безопасность ИИ-системы требует целостного взгляда, учитывающего все четыре компонента и взаимодействие между ними. Именно этому посвящена оставшаяся часть главы и книги в целом.
1.2. Агенты, инструменты и интерфейсы взаимодействия
В предыдущем разделе мы описали четыре базовых компонента ИИ-системы. Но современные системы всё чаще включают элементы, которые не укладываются в классическую схему «данные — модель — приложение — инфраструктура». Речь идёт об автономных агентах, внешних инструментах и протоколах взаимодействия, которые превращают модель из генератора ответов в участника рабочих процессов, способного выполнять действия в информационных системах организации.
Модель получает запрос и возвращает результат. Агент получает задачу и самостоятельно определяет последовательность шагов для её выполнения. Он может разбить задачу на подзадачи, обратиться к внешним источникам данных, вызвать инструменты, проанализировать промежуточные результаты и скорректировать свой план. В отличие от модели, которая обрабатывает один запрос за один проход, агент ведёт многоходовое взаимодействие с окружением и сохраняет состояние между шагами.
Архитектура типичного агента включает несколько взаимосвязанных компонентов. Восприятие отвечает за приём входных данных: текстового запроса, содержимого документа, сигнала от другой системы. Рассуждение опирается на языковую модель и определяет, какие действия нужно выполнить. Оркестрация управляет последовательностью шагов, координирует вызовы инструментов и при необходимости делегирует подзадачи другим агентам. Память позволяет агенту сохранять контекст разговора, промежуточные результаты и сведения, полученные на предыдущих шагах. Инструменты дают агенту возможность взаимодействовать с внешним миром: читать файлы, выполнять запросы к базам данных, отправлять сообщения, вызывать API.
Рисунок 2. Схема агентной архитектуры: модель, память, планирование, инструменты, внешние системы и протоколы взаимодействия MCP и A2A.
Именно сочетание автономности и доступа к инструментам делает агентов принципиально новым объектом с точки зрения безопасности. Модель, которая генерирует текст в изолированном окне чата, ограничена в своём воздействии. Агент, который по результатам рассуждения обновляет запись в CRM, отправляет электронное письмо от имени сотрудника и создаёт заявку в системе управления задачами, воздействует на информационные системы организации с последствиями, сопоставимыми с действиями человека.
Инструменты — это внешние функции, к которым агент обращается для выполнения задач. Спектр инструментов практически не ограничен: поиск в интернете, чтение и запись файлов, выполнение программного кода, запросы к базам данных, вызовы корпоративных API, отправка сообщений в мессенджерах, управление записями в учётных системах. Каждый инструмент расширяет возможности агента, но одновременно расширяет и поверхность атаки.
Когда агент вызывает инструмент, он фактически выполняет действие от имени пользователя или от собственного имени в среде, которой доверяет организация. Возникает вопрос: какими полномочиями обладает агент при вызове каждого инструмента? Если агент использует тот же API-ключ, что и администратор системы, он может выполнить любую операцию, включая те, которые для его задачи не нужны. Если инструмент возвращает агенту данные, которые содержат встроенные инструкции (например, текст документа с инъекцией), агент может интерпретировать их как команды и изменить своё поведение. Если среда выполнения кода, вызываемого агентом, не изолирована, компрометация одного инструмента может привести к доступу ко всей инфраструктуре.
Вопрос изоляции среды выполнения заслуживает пристального внимания. Организации, которые позволяют агенту выполнять произвольный код в общей среде, создают условия, при которых злоумышленник может через манипуляцию входными данными заставить агента запустить вредоносный скрипт, получить доступ к файловой системе или сети. Песочницы, контейнеры с ограниченными правами, детерминированные вызовы заранее определённых функций вместо произвольного выполнения кода — всё это архитектурные решения, которые существенно снижают риск.
По мере распространения агентов возникла потребность в стандартизации того, как они подключаются к внешним системам и взаимодействуют друг с другом. Два протокола, получивших широкое распространение, заслуживают упоминания.
Model Context Protocol (MCP) стандартизирует подключение агентов к внешним источникам данных, инструментам и корпоративным системам. Вместо создания уникальной интеграции для каждой пары «агент — сервис» MCP позволяет агенту выступать клиентом, который обращается к серверам, предоставляющим доступ к базам данных, календарям, почте, CRM и другим ресурсам через единый интерфейс. Это снижает трудозатраты на интеграцию и ускоряет развёртывание. Но одновременно MCP вводит в периметр организации внешние зависимости, каждая из которых может стать каналом атаки: скомпрометированный MCP-сервер способен передать агенту искажённые данные или вредоносные инструкции.
Agent-to-Agent protocol (A2A) решает другую задачу: он позволяет агентам обнаруживать друг друга, обмениваться описаниями своих возможностей, делегировать задачи и координировать действия. A2A вводит понятие карточки агента (agent card) — машиночитаемого описания идентичности, навыков, конечных точек и требований аутентификации агента. Это делает возможным построение многоагентных систем, в которых несколько агентов от разных поставщиков совместно решают сложную задачу.
С точки зрения безопасности оба протокола создают новый класс проблем. MCP расширяет поверхность атаки за счёт множества внешних подключений, каждое из которых требует аутентификации, авторизации и валидации данных. A2A порождает вопросы доверия между агентами: как убедиться, что агент, заявляющий определённые возможности, действительно является тем, за кого себя выдаёт? Как предотвратить ситуацию, в которой один агент передаёт другому задачу с полномочиями, превышающими необходимые? Как обеспечить аудит действий в цепочке из нескольких агентов, если каждый из них принимает решения автономно?
Стоит отметить, что эти протоколы пока находятся на ранней стадии зрелости. В отличие от устоявшихся сетевых стандартов, выросших из десятилетий открытого сотрудничества и стандартизации, MCP и A2A больше напоминают прикладные фреймворки, чем полноценные протоколы с проработанной моделью безопасности. Организации, внедряющие агентные системы, должны учитывать эту незрелость и выстраивать дополнительные контроли поверх протоколов, а не полагаться на их встроенные механизмы защиты.