Безопасность ИИ в 2026 году

От понимания рисков ИИ к зрелой системе контроля

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

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

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

То есть, зрелая безопасность ИИ в 2026 году — это уже не разовая проверка модели. Это сочетание архитектуры, оценки рисков, управления доступами, безопасности данных, тестирования, мониторинга, процессов эксплуатации, стратегического управления и регулярной переоценки.

Глоссарий AIBOM — перечень компонентов, зависимостей и артефактов, связанных с ИИ-системой. API — интерфейс программирования приложения. DAST — динамическое тестирование безопасности приложения. DevSecOps — встраивание безопасности в разработку, поставку и эксплуатацию программного обеспечения. DLP — предотвращение утечек данных. EU AI Act — Регламент Европейского союза об искусственном интеллекте. GPAI — модель искусственного интеллекта общего назначения. IAM — управление идентификацией и доступом. ISO/IEC — международные стандарты в области информационных технологий и кибербезопасности. LLM — большая языковая модель. MCP — Model Context Protocol, стандарт подключения ИИ-ассистентов к внешним инструментам, данным и интерфейсам. NIST — Национальный институт стандартов и технологий США. OWASP — открытое сообщество и фонд, разрабатывающие практические материалы по безопасности приложений. RAG — retrieval-augmented generation, архитектура, при которой LLM формирует ответ с использованием внешних источников знаний. SAST — статический анализ безопасности исходного кода. SIEM — система сбора, корреляции и анализа событий безопасности. SOC — центр мониторинга и реагирования на инциденты безопасности.

ИИ-система — это уже не только модель

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

В неё могут входить LLM, RAG-контур, векторная база, документы базы знаний, системные промпты, пользовательские запросы, журналы диалогов, внешние API, агенты, плагины, MCP-серверы, облачные сервисы, механизмы авторизации, средства фильтрации ввода и вывода, инструменты наблюдаемости и процессы реагирования. Ошибка в любом из этих слоёв может привести не просто к «неправильному ответу», а к утечке данных, нарушению бизнес-процесса, выполнению нежелательного действия или появлению юридического риска.

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

Практический риск здесь не ограничивается классической утечкой. Документ в базе знаний может содержать скрытую инструкцию для модели. Векторный индекс может раскрывать чувствительные знания косвенно. Пользователь может получить ответ на основе документа, к которому у него не должно быть доступа. Логи могут сохранять коммерческие, персональные или юридически значимые данные дольше, чем разрешено политиками компании. Поэтому безопасность RAG — это одновременно безопасность данных, архитектуры, прав доступа и поведения модели.

Инъекции промптов стали бизнес-риском, а не лабораторной экзотикой

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

Если ИИ только отвечает пользователю, последствия могут ограничиться неправильной рекомендацией или раскрытием части контекста. Однако если ИИ подключён к инструментам, почте, CRM, DevOps-системам, финансовым операциям или административным API, инъекция промпта уже может повлиять на действия системы. Тогда ошибка превращается из информационного риска в операционный.

Инъекции промптов – не единственный класс рисков для LLM-приложений. OWASP Top 10 for LLM Applications версии 2025 выделяет также раскрытие чувствительной информации, риски цепочки поставки, отравление данных и моделей, небезопасную обработку вывода, чрезмерную автономность, утечки системных промптов, дезинформацию, неконтролируемое потребление ресурсов, а также слабости векторных баз и эмбеддингов. Это хорошо показывает, насколько тема ушла дальше классического пентеста. Теперь проверять нужно не только формы, роли и API, но и то, как модель интерпретирует инструкции, контекст и границы своих полномочий.

ИИ-агенты увеличивают цену ошибки

В обычном сценарии LLM генерирует текст, код, анализ или рекомендацию. В агентном сценарии система может планировать шаги, выбирать инструменты, обращаться к внешним источникам, запускать команды, изменять записи, отправлять сообщения или выполнять действия от имени пользователя.

Именно здесь появляется качественно новая угроза: модель начинает не только говорить, но и действовать.

OWASP Agentic AI Threats and Mitigations описывает агентов как автономные системы, возможности и риски которых резко выросли благодаря интеграции с LLM и другим генеративным ИИ. Отдельный список OWASP Top 10 for Agentic Applications 2026 уже фокусируется на рисках автономных и агентных систем, которые планируют и принимают решения, а также действуют в сложных рабочих процессах.

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

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

MCP и внешние инструменты расширяют поверхность атаки

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

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

На практике это означает, что слой инструментов нельзя рассматривать как техническую «обвязку» вокруг модели. Его нужно проектировать как полноценную зону доверия: с разделением чтения и записи, ограничением токенов, контролем области действия, отдельным журналированием, политиками отказа, тестами злоупотреблений и пониманием “радиуса взрыва” (blast radius) — то есть максимального ущерба при компрометации или ошибке.

Цепочка поставки ИИ становится частью безопасности

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

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

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

Регуляторный и управленческий контур стал практическим

EU AI Act начал вступать в силу 1 августа 2024 года, но тогда практическая регуляция ИИ выглядела отдалённой. Сейчас для компаний, работающих в ЕС или с европейскими клиентами, это уже не абстракция. Отдельные запреты и обязательства по грамотности в области ИИ применяются с февраля 2025 года. Правила управления и обязательства для поставщиков моделей ИИ общего назначения начали применяться с августа 2025 года. Уже 2 августа 2026 года EU AI Act вступает в полную силу, хотя для некоторых случаев предусмотрены дополнительные поэтапные исключения и переходные периоды.

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

В июле 2025 года был опубликован General-Purpose AI Code of Practice — добровольный инструмент для помощи поставщикам моделей общего назначения в демонстрации соответствия обязательствам EU AI Act, включая блоки прозрачности, авторского права, безопасности и защищённости для наиболее продвинутых моделей.

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

Здесь полезны разные опорные документы, хотя ни один из них не решает всю задачу сам по себе. NIST AI RMF остаётся удобным языком управления рисками ИИ и был дополнен профилем для генеративного ИИ NIST AI 600-1. Стандарт NIST SP 800-218A развивает практики безопасной разработки для генеративного ИИ и базовых моделей ИИ на основе SSDF. Публикация NIST AI 100-2e2025 даёт таксономию и терминологию атак на машинное обучение, а предварительный NIST Cyber AI Profile связывает ИИ с управлением киберриском, защитой ИИ-систем, использованием ИИ в защите и противодействием атакам, усиленным ИИ. Стандарт ISO/IEC 42001 задаёт требования к системе менеджмента ИИ, а ISO/IEC 23894 помогает встроить управление рисками ИИ в процессы организации.

Зрелый подход не сводится к выбору «одного правильного стандарта». Строится связанная система: стратегическое управление на уровне руководства, архитектурные решения на уровне продукта, контроль данных и доступов на уровне инженерии, тестирование на уровне контрольных точек, мониторинг на уровне эксплуатации и доказательства на уровне комплаенса.

Почему классической безопасности приложений уже недостаточно

Безопасность ИИ не отменяет классическую безопасность приложений. Наоборот, без неё невозможно построить надёжную ИИ-систему. Веб-приложения, API, аутентификация, авторизация, шифрование, секреты, журналы, инфраструктура, облачная безопасность, безопасная разработка, SAST, DAST и DevSecOps остаются обязательной базой.

Проблема в другом: этой базы уже недостаточно.

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

Поэтому безопасность ИИ требует расширения классических практик. Моделирование угроз должно учитывать не только пользователей, роли и API, но и источники контекста, системные промпты, возможности агентов, маршруты данных, цепочки инструментов и точки принятия решения. Харденинг должен включать не только серверы и контейнеры, но и настройки модели, ограничения инструментов, политики контекста, изоляцию сессий, фильтры вывода, журналирование действий агента и контроль хранения данных (data retention). Мониторинг должен отслеживать не только ошибки и атаки на инфраструктуру, но и подозрительные промпты, необычные извлечения из базы знаний, попытки обхода политик, рост стоимости запросов, дрейф поведения и аномальные действия агентов.

Частные LLM: полезный вариант, но не панацея

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

Тем не менее локальная LLM сама по себе не делает систему безопасной.

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

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

От оценки рисков к внедрению контролей

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

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

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

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

Что должно входить в зрелую программу безопасности ИИ

Зрелая программа безопасности ИИ начинается с видимости. Компания должна понимать, какие ИИ-сценарии уже существуют: публичные сервисы, внутренние ассистенты, RAG-системы, агенты, copilot-функции, модели в продуктах, ИИ в SOC, разработке, аналитике, поддержке клиентов или юридической работе.

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

Следующий слой — практические контроли. К ним относятся ограничение доступа, проверка источников данных, фильтрация и валидация входа и выхода, изоляция инструментов, раздельные права чтения и записи, подтверждение человеком для высокорисковых действий, безопасные настройки MCP и API, защита секретов, журналирование, мониторинг, сценарии реагирования на инциденты (incident playbooks), в также регулярное тестирование.

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

Консультативный подход вместо иллюзии полной автоматизации

Рынок ИИ-безопасности быстро наполняется инструментами: сканерами, фреймворками для red teaming, наборами тестов, ограничителями (guardrails), средствами оценки моделей, решениями для мониторинга, платформами стратегического управления и системами сбора доказательств. Эти инструменты действительно полезны. SANS Secure AI Blueprint, например, строится вокруг трёх направлений — защита ИИ, безопасное использование ИИ и управление ИИ, подчёркивая, что внедрение ИИ часто движется быстрее, чем защитные контроли.

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

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

Часть мер клиент может внедрить сам: силами IT, отдела безопасности, DevOps, юристов, специалистов по комплаенсу и продуктовых команд. Роль внешнего консультанта в таком сценарии — не заменить всю внутреннюю команду, а усилить её там, где особенно важны независимый взгляд, глубокая кибербезопасность, архитектурная строгость и опыт оценки нестандартных рисков.

Вывод: от разовых проверок к управляемой программе

С момента выхода нашей предыдущей статьи безопасность ИИ заметно изменилась. LLM стали частью реальных бизнес-процессов. RAG, ИИ-агенты, MCP и корпоративные интеграции расширили поверхность атаки. Прямые и косвенные инъекции промптов, утечки данных, риски цепочки поставки, слабости RAG, чрезмерная автономность агентов и недостаточный мониторинг стали практическими проблемами, а не только темами для исследований. OWASP, NIST, ISO/IEC, SANS и EU AI Act сформировали более зрелый набор ориентиров, но одновременно показали: одну универсальную инженерную или регуляторную структуру для всех ИИ-систем создать невозможно. Нужно сочетание стратегического управления, архитектуры, контролей, тестирования и эксплуатации.

Для H-X Technologies это означает естественное развитие подходов. Если раньше базовая задача состояла в том, чтобы объяснить риски ИИ и показать, почему ими нужно управлять, то теперь акцент смещается к оценке, внедрению и сопровождению. В фокусе — защищённая архитектура, безопасность данных, локальные или ограниченные LLM для чувствительных сценариев, харденинг ИИ-инфраструктуры, контроль RAG, безопасность агентов и MCP, мониторинг, стратегическое управление, а также консультативная поддержка для руководителей и команд.

В ближайшие годы ИИ будет глубже входить в критичные бизнес-процессы. ИИ-агенты получат больше полномочий. Регуляторная и договорная нагрузка усилится. Стратегическое управление ИИ станет частью корпоративного управления, а безопасность ИИ будет всё теснее интегрироваться с безопасностью приложений, облаков, данных, IAM, SOC, SIEM, DLP, DevSecOps и комплаенсом.

Поэтому H-X развивает направление оценки и внедрения безопасности ИИ: от моделирования угроз и проверки RAG до безопасности агентов, MCP, частных LLM, мониторинга и управленческих контролей. Наша задача — помогать клиентам использовать ИИ без потери контроля над данными, доступами и бизнес-рисками. 

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

Внедряете LLM, RAG, ИИ-агентов, MCP-интеграции или частные модели? Только планируете? Или уже внедрили и столкнулись с проблемами? Обсудите с H-X Technologies задачи безопасности ИИ — мы поможем понять, какие данные и действия нужно взять под контроль, какие риски проверить первыми и какие меры безопасности внедрить без лишней бюрократии.