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

1.3. Чем ИИ-система отличается от традиционного программного обеспечения

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

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

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

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

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

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

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

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

Рисунок 3. Традиционное программное обеспечение и ИИ-система: различия в логике работы, поведении, зависимости от данных и характере ошибок.

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

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

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

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

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

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

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

1.4. ИИ как социотехническая система

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

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

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

NIST AI Risk Management Framework прямо указывает на социотехническую природу ИИ-систем и подчёркивает, что управление рисками требует учёта не только технических, но и человеческих, организационных и социальных факторов. ISO/IEC 42001:2023 включает в систему управления ИИ требования к компетенциям персонала, осведомлённости и коммуникации — признавая, что технические контроли работают только в организации, которая понимает их назначение и способна их поддерживать.

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

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

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

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

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

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

Взаимодействие человека и ИИ

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

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

Что это означает для безопасности

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

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

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

1.5. Активы и границы системы

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

Активы ИИ-системы

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

Рисунок 4. Карта активов ИИ-системы и расширенный периметр защиты.

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

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

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

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

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

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

Где проходят границы системы

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

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

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

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

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