Как использовать мощь нейросетей, не разрушая фундамент безопасности бизнеса

26 июня 2026 г.

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

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

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

Спектр угроз: Новая анатомия рисков

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

Макроуровень (Глобальные системные риски)

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

Уровень организации (Стратегические и юридические риски)

Здесь ИИ становится источником регуляторного давления. Подробнее о регуляторике можно почитать в предыдущей статье. Здесь же отметим только, что нормативная база сейчас находится на этапе формирования. Федеральный закон РФ про ИИ, например, до сих пор не вышел.

Но даже там, где законодательство нас опережает, регуляторика создает новые проблемы для ИБ. С развитием EU AI Act и обновлением GDPR, использование ИИ без надлежащей оценки воздействия на конфиденциальность (PIA) может привести к штрафам в размере до 7% от мирового оборота компании.

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

Технический уровень (Операционные и киберриски)

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

Также не забываем поглядывать в публикации ФСТЭК.

Риски стороннего ИИ

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

1. Отсутствие интерпретируемости (модель — «черный ящик»). Если вы уже внедрили систему, которая принимает решения, и выясняется, что она ошиблась, вы не сможете объяснить «почему». Для чувствительных данных это может приводить к мгновенным штрафам и остановке использования системы.

2. Конфиденциальность данных и риски использования. Использование ИИ для выявления скрытой чувствительной информации из обычных данных (профилирование, предсказание здоровья/финансов).

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

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

2. Регуляторное и этическое соответствие. Риск штрафов из-за несоблюдения меняющихся законов.

3. Валидация модели и дрейф производительности. Снижение точности модели из-за изменения внешних условий (рынка, поведения людей), что делает её неэффективной.

1. Безопасность ИИ и состязательные угрозы. Атаки типа «отравление данных», кража модели или использование специально подготовленных входных данных для обмана ИИ.

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

3. Управление человеческим фактором. Риск того, что отсутствие контроля приведет к ошибкам, а избыточный контроль — к операционным задержкам.

4. Риск чрезмерного доверия. Снижение навыков критического мышления у сотрудников и неспособность работать при отказе ИИ-системы.

Интеграция рисков ИИ: от реактивной защиты к проактивному управлению

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

Для минимизации рисков ИИ потребуется выполнить ряд мероприятий (сформированы на основе ISO/IEC 27001; CSA STAR; NIST 800-53; NIST AI RMF; CIS V8):

1. Управление:

1. Разработка политики использования ИИ с описанием ограничений и ожиданий.

2. Обновление существующих политик (SDLC и др.) для включения правил работы с ИИ.

2. Обучение:

1. Обучение сотрудников правилам использования ИИ и ограничениям.

2. Обучение распознаванию продвинутых атак (фишинг), созданных с помощью ИИ.

3. Вендоры:

1. Использование изолированных экземпляров (instances), чтобы данные не использовались для обучения чужих моделей.

2. Юридическая ответственность вендора за защиту входных данных и точность вывода.

3. Проверка безопасности и приватности вендора в соответствии с политикой управления поставщиками.

4. Приватность:

1. Маскирование или очистка обучающих данных от чувствительной информации.

2. Отображение предупреждений пользователям перед вводом данных для напоминания о правилах.

5. Обязательства клиента:

1. Предупреждение пользователя о возможных неточностях и ответственности вендора.

2. Возможность для клиентов отказаться от функций GenAI, включенных по умолчанию.

3. Получение явного согласия пользователя на использование GenAI в продукте.

4. Обновление условий использования с учетом внедрения технологий GenAI.

6. Разработка:

1. Обучение разработчиков практикам безопасной разработки при использовании ИИ-инструментов.

2. Проведение моделирования угроз в процессе разработки функций GenAI.

7. Технические средства защиты:

1. Проверка и принудительное применение допустимых параметров ввода.

2. Проверка выходных данных на точность и отсутствие предвзятости.

3. Механизм поиска чувствительных данных в репозиториях для их последующей очистки.

4. Использование архитектуры нулевого доверия для защиты критических активов (DB, LLM).

5. Регулярное обновление инструментов GenAI до последних безопасных версий.

6. Ротация паролей/ключей и использование многофакторной аутентификации (MFA).

8. Устойчивость:

1. Проведение анализа влияния на бизнес (BIA) для всех используемых инструментов GenAI.

2. Разработка планов аварийного восстановления (DRP) и непрерывности бизнеса (BCP).

С учётом приоритезации рисков при таком подходе для построения устойчивой архитектуры необходимо перенастроить контроль в четырех ключевых направлениях.

Направление 1: конфиденциальность и управление данными

Здесь самым большим риском станет вероятная утечка персональных данных через промпты.

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

Именно такой подход позволяет обеспечить соответствие системы мониторинга информационной безопасности стандарту ISO/IEC 27001 и следовать принципам Privacy by Design.

Направление 2: целостность и доверие к выводу

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

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

Направление 3: киберустойчивость и DevSecOps

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

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

Направление 4: устойчивость цепочки поставок

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

Ваш риск — это риск вашего вендора и его субподрядчиков. В идеальном мире, все вопросы надо решать локальными моделями. Но если никак, то для минимизации риска следует проводить аудит сторонних ИИ-сервисов. Необходимо оценивать не только прямого провайдера, но и прозрачность использования им внешних моделей и библиотек. Важнейшим элементом здесь является анализ влияния на бизнес (BIA) — разработка планов восстановления (DRP) на случай отказа API или изменения политики доступа стороннего вендора.

Стратегия внедрения: три столпа трансформации

Для CISO, CTO и GRC-менеджеров процесс внедрения ИИ должен базироваться на трех фундаментальных направлениях:

1. Трансформация аудита: аудит ИИ не может быть разовым мероприятием «по факту». Это должен быть непрерывный цикл мониторинга дрейфа модели и проверки соответствия политике безопасности. Аудитор сегодня проверяет не только наличие доступа, но и обеспечивает «проверку входных данных».

2. Интеграция в процесс управления рисками: каждое внедрение ИИ-инструмента должно проходить через фильтр оценки влияния на бизнес (BIA). Мы должны оценивать не только вероятность атаки, но и тяжесть последствий: может ли сбой модели остановить критический бизнес-процесс? Это требует пересмотра классических матриц рисков под нужды эпохи ИИ.

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

Заключение

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

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

Источник: Алексей Матвеев, начальник отдела методологического обеспечения информационной безопасности компании ЦКР